Milter-greylist

Adam Katz a \ufffdcrit :
>>> I've heard users describe instances where mail is delayed for about a
>>> day.
> 
>> the sending mailserver decides when it will do the next delivery
>> attempt. You have no influence if or when it will retry.
>>
>> The cause may be high load, long mailqueue, bad configuration or many
>> other things
> 
> okay, so that seems to allege that the problem isn't with
> milter-greylist's configuration ... it is still a problem, and caused by
> greylisting itself.  I've had to add a very large number of problematic
> mail relays to the whitelisting section of my greylist.conf file.
> 
> Example:  gmail doesn't play nice with greylisting (as noted at
> http://tinyurl.com/27ey2t ) so the fix is to traverse their SPF and
> whitelist every named server (noted at http://tinyurl.com/2znyqh )  ...
> other companies aren't as easily marked (lack of SPF plus the fact that I
> have to do it on a case-by-case basis).
> 

All the major ISP and email providers (such as gmail) use "mail farms" 
to handle outbound SMTP connexions: mails in the output queue may be 
processed (and retried) by whichever server in the farm.

This is *NOT* compatible with greylisting, which expects mails to be 
retried from the same IP address they were initially submitted; symptoms 
are random long greylisting delays.
So workarounds *must* be taken in greylist.conf:
- define "lazyaw" and "subnetmatch" to be more tolerant about incoming 
submissions (sounds quite dirty to me);
- locally whitelist by ACL (IP or domain match) all known server farms 
(a pain to maintain, but quickly responsive in case of problem discovery);
- make use of centralized DNS whitelists such as list.dnswl.org by a 
DNSRBL ACL clause;
- whitelist on behalf of sender's SPF record.


-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.