Claus Assmann wrote:
On Mon, Oct 24, 2011, Hector wrote:
http://www.ietf.org/internet-drafts/draft-santos-smtpgrey-00.txt
retry=delay is not entirely sufficient, it would be helpful to also
specify an upper bound (after which the entry will be removed from
the cache and another attempt will not counted as retry, but as a
new one).
Hence my suggestion is to use
retry=min-max
e.g.,
retry=5-3600
where the time unit is minutes...
Interesting suggestion.
Minutes granularity is not sufficient. There are many servers that
use less than 1 minute blocking time. e.g.; we use 55 seconds for our
GL implementation as the default stock value out of the box. I think
its needs to be available that seconds is not excluded from the
possibility GL servers prefer to minimize their GL impact on
legitimate SMTP compliant mail senders using very short delays.
Regarding the min-max suggestion, I had to think about this to see how
it can apply with existing Grey Listing implementations. Don't quite
see the reasoning stated above for the min-max, but maybe this?
While it varies, the related common GL parameters I am aware of are:
blocking time - time delay required for accepting
record expire time - life time of recorded triplet before expire
So I guess maybe, it can be
MIN - blocking time
MAX - record expire time
Is that what you were thinking?
If so, for us, we use (stock defaults)
Expire.block 55 # secs to block greylisted senders
Expire.record 2880 # mins to expire recording
So in this case, you would be suggesting it would be (keeping it in
seconds)?
retry=55-172800
Hmmm, if anything, maybe a 2nd optional expire=tag
retry=[DD-]HH:MM:SS [expire=[DD-]HH:MM:SS]
or
retry=[DD-]HH:MM:SS[-[DD-]HH:MM:SS]
Either way, it would do the same goal you seek (right?) but not force
the GL server to expose the expiration if it doesn't wish to.
Comment?