Ed Greshko wrote:
You are incorrect on several counts.
- 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.