Actually, the OPs notion is an interesting one.
From the point of view of someone who administers a lot of systems and
mailing lists, I end up getting multiple copies of lots of messages.
I've been thinking for a while about how to implement anti-spam rules
based on receiving multiple copies of the same message. Queuing
messages for a little while, seems like a good start.
Miles Fidelman
Reindl Harald wrote:
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
_______________________________________________
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
