ietf-smtp
[Top] [All Lists]

Re: retry=

2011-10-24 21:05:32

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?