Quoting Simon Wilson <[email protected]>:
Hi list, wondering if I can get some help with the below.
I have run a small Postfix mail server for many years, with amavisd
and spamassassin. We have about 10 users, 95% of the time using only
Horde Webmail as the interface to send mail.
The server is set to only allow mail send through port 587, and only
for authenticated users. This auth is generally only through the
Horde server on the same subnet, but I do have a requirement for
port 587 to be externally accessible for direct (non-Horde)
submission.
I had outbound mail not spam scanning, but got stung when one of our
users had their email/password on a cracked list, and the server
spent 24 hours relaying authenticated email that was spam. Ouch.
Immediate fix was to change the user's password, stopped the
problem, but I want to prevent similar happening again. I enabled
spam scanning on outbound (commented out bypass_spam_checks_maps
=> [1] in the policy ban), with Amavisd set to kill level 6.2... BUT
one of my users is in Ecuador, on the end of a dodgy internet
connection with a dodgy ISP, and his outbound email starting getting
dropped, as coming through Horde shows the path from the web client
in use, and SA scanning was penalising based on his location:
Content analysis details: (8.5 points, 6.2 required)
pts rule name description
---- ----------------------
--------------------------------------------------
3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[190.131.127.84 listed in zen.spamhaus.org]
1.4 RCVD_IN_BRBL_LASTEXT RBL: No description available.
[190.131.127.84 listed in
bb.barracudacentral.org]
0.0 HTML_MESSAGE BODY: HTML included in message
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.4956]
1.0 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS
2.0 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr
1)
I have set kill level to 10 to let his through but that is obviously
not helping with the original issue... and with it set to 10 kill
level I do not get notified.
I want to be notified for ONE policy bank, if a user sends a SPAMMY
mail (say hits from 2.5 to 10) but let the mail through; but
kill_level 10 for SPAM. That way I can let email from Ecuador client
through, but still be notified if anyone else starts sending mail
above 2.5 (none of the rest of my outgoing is ever above 2.5).
Policy bank that applies is currently:
$policy_bank{'ORIGINATING'} = { # mail supposedly originating from our users
originating => 1, # declare that mail was submitted by our smtp client
allow_disclaimers => 1, # enables disclaimer insertion if available
# notify administrator of locally originating malware
virus_admin_maps => ["virusalert\@$mydomain"],
spam_admin_maps => ["spamalert\@$mydomain"],
warnbadhsender => 1,
spam_kill_level_maps => [10],
# bypass_spam_checks_maps => [1], # don't spam-check this mail
# forward to a smtpd service providing DKIM signing service
forward_method => 'smtp:[127.0.0.1]:10025',
# force MTA conversion to 7-bit (e.g. before DKIM signing)
smtpd_discard_ehlo_keywords => ['8BITMIME'],
bypass_banned_checks_maps => [1], # allow sending any file names and types
terminate_dsn_on_notify_success => 0, # don't remove NOTIFY=SUCCESS option
};
Any advice or suggestions would be appreciated.
--
Simon Wilson
M: 0400 12 11 16
So my query seems to have been too complex.
Let's simplify:
Default non-policy-bank setup is:
$sa_tag_level_deflt = -999; # add spam info headers if at, or above
that level
$sa_tag2_level_deflt = 6.2; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 1000; # triggers spam evasive actions (e.g.
blocks mail)
So always add headers; call it spam above 6.2; but let it through for
imapd and sieve to deal with.
How do I configure a *policy bank* that applies to sasl-authenticated
port-587-submitted outbound mail only to:
1. spam scan
2. if it hits above 2.5, let it out, but notify admin of spammy outbound
3. if it hits above 10, discard it, notify admin of spam outbound
Alternately any other recommendations to catch email accounts where
password has been compromised so sasl_auth is passed, to prevent
submission port abuse.
Thanks
Simon.
--
Simon Wilson
M: 0400 12 11 16
