Relayed outbound spam checking

Simon Wilson simon at simonandkate.net
Fri Jul 27 16:05:47 CEST 2018


Quoting Dusan Obradovic <dusan at euracks.net>:

>> On Jul 25, 2018, at 12:50, Simon Wilson <simon at simonandkate.net> wrote:
>>
>> Quoting Simon Wilson <simon at simonandkate.net>:
>>
>>> 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
>>
>
> Ideally, Spamassassin should skip rbl tests (RCVD_IN_*) for  
> authenticated submission so you can lower spam_kill_level_maps score  
> with originating policy.
>
> https://wiki.apache.org/spamassassin/TrustPath
> https://wiki.apache.org/spamassassin/DynablockIssues

Thank you Dusan. I have resolved issues with trusted_networks and  
internal_networks, and now email that is SASL auth'ed through the  
webserver to 587 is correctly identified as trusted from the mail  
server not the web server, and while SA-scanned, it is not RBL'ed,  
which is perfect.

The second article also got me thinking... so I also enabled Postfix's  
smtpd_sender_login_maps on 587 only which would have cut over 80% of  
the relayed SASL-auth'ed spam due to it not being "from" an address  
owned by the auth'ed user

I'll watch that and see how emails from my son's dynamic IP get tagged  
over a few days, then come back to configuration in Amavisd kill levels.

Thank you :)
Simon.



-- 
Simon Wilson
M: 0400 12 11 16



More information about the amavis-users mailing list