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@xxxxxxxxx
