spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reindl Harald <h.rei...@thelounge.net>
Subject Re: dealing with mail not yet listed in network tests
Date Fri, 14 Nov 2014 12:35:34 GMT

Am 14.11.2014 um 13:04 schrieb David F. Skoll:
> On Fri, 14 Nov 2014 08:39:13 +0100
> Matthias Leisi <matthias@leisi.net> wrote:
>
>> On Fri, Nov 14, 2014 at 6:35 AM, John Hardin <jhardin@impsec.org>
>> wrote:
>
>>> if you're in a business environment you may have an uphill battle
>>> with managing expectations, to wit: email is *not* intended to be
>>> instant messaging - and may run up against the brick wall of
>>> management not being willing to delay emails from prospective new
>>> paying clients *at all*.
>
>> You can mitigate this risk somewhat by avoiding greylisting for a
>> certain set of whitelisted mailservers.
>
> You can also tremendously mitigate the risk by remembering when a
> given SMTP client passes the greylisting hurdle and avoiding
> greylisting it for the next few weeks.  If it passes greylisting once,
> there's likely no point in greylisting it in the future.  It's a sort
> of automatically-built greylist-whitelist

postfix practically supports that out-of-the-box

http://www.postfix.org/POSTSCREEN_README.html#after_220
postscreen_cache_retention_time      = 7d
postscreen_bare_newline_ttl          = 7d
postscreen_greet_ttl                 = 7d
postscreen_non_smtp_command_ttl      = 7d
postscreen_pipelining_ttl            = 7d
postscreen_bare_newline_enable       = yes
postscreen_bare_newline_action       = enforce
postscreen_pipelining_enable         = yes
postscreen_pipelining_action         = enforce
postscreen_non_smtp_command_enable   = yes
postscreen_non_smtp_command_action   = enforce
_______________________________________________

*but* it makes a ton of troubles for large *legit* sending clusters 
which often after a 4xx reject handover that mail to a different node 
and so get again a 4xx

hence better use postscreen without the deep-tests and let the client IP 
once per week or so wait around 10 seconds after respond with a RBL 
reject or hand it over to the smtpd daemon - after some months you will 
see the amount of botnet connections going down at all because it harms 
them waste 10 seconds for each delivery attempt

then you have "postscreen_whitelist_interfaces" where you reject based 
on RBL's or respond with 4xx *unconditional*, so the client comes back 
some minutes later on the primary MX (in fact the same machine!)

well, within that minutes it may got blacklisted and 50% of all IP's 
connecting to the backup-mx first *never* come back!

postscreen_bare_newline_enable       = no
postscreen_pipelining_enable         = no
postscreen_non_smtp_command_enable   = no
postscreen_cache_retention_time      = 7d
postscreen_bare_newline_ttl          = 7d
postscreen_greet_ttl                 = 7d
postscreen_non_smtp_command_ttl      = 7d
postscreen_pipelining_ttl            = 7d
postscreen_dnsbl_ttl                 = 5m
postscreen_dnsbl_threshold           = 8
postscreen_dnsbl_action              = enforce
postscreen_greet_action              = enforce
postscreen_greet_wait                = ${stress?3}${stress:10}s
postscreen_whitelist_interfaces      = !<backup-mx-ip>, static:all
_______________________________________________



Mime
View raw message