Email ???

[Les Mikesell]

Ed Greshko wrote:

>>> You are incorrect on several counts.
>>>
>>> 1.  The time to delay is configurable in a good greylist milter.  Mine is
>>> set to 15 minutes since this is pretty much the default retry interval of
>>> most MTAs.
>> Really? The standard says
>>    The sender MUST delay retrying a particular destination after one
>>    attempt has failed.  In general, the retry interval SHOULD be at
>>    least 30 minutes;
>> (RFC 2821 section 4.5.4.1)
>>
>> Calling half an hour "a while" seems reasonable to me...
>>
>> I'd argue that your first sentence is misleading, too -- the delay is a
>> result of the configuration of both sending and receiving MTAs.
> 
> Whatever....  It is certainly not 4 hours.....
> 
> You need to understand the meaning of "should" v.s. "must".

The point here is that it is up to the sender to retry.  If you tempfail 
the first attempt you have no control over how long it will be until the 
next attempt happens.  If the sender has a big queue, it could be 4 
hours or more.


>> There are two ways around this -- either you can (as Tony said) maintain
>> a list of senders which use this sort of system, or hope that the
>> senders put their sending MTAs in no more than a few /24 subnets. You
>> then get the greylist to consider that one sending attempt from
>> 127.36.5.1[1] and a retry from 127.36.5.2 is Good Enough.
> 
> I think you have no idea of what you speak.

At the very least you should permit a sending host once it is known to 
retry.  Some schemes match up senders/recipients - which is appropriate 
for the first connection, but once you know a host is going to retry you 
might as well let it through.

-- 
   Les Mikesell
    lesmikesell at gmail.com