Am 14.11.2014 um 13:04 schrieb David F. Skoll:
On Fri, 14 Nov 2014 08:39:13 +0100 Matthias Leisi <matth...@leisi.net> wrote:On Fri, Nov 14, 2014 at 6:35 AM, John Hardin <jhar...@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
_______________________________________________
signature.asc
Description: OpenPGP digital signature
