spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Fidelman <mfidel...@meetinghouse.net>
Subject Re: dealing with mail not yet listed in network tests
Date Fri, 14 Nov 2014 12:45:49 GMT
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 <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
> _______________________________________________
>


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra


Mime
View raw message