[Top] [All Lists]

Re: retry=

2011-10-24 21:57:26


This suggestion of exposing the expire time might not be such a bad idea as I can see how it can help the MTA make a better decision on retrying which does not need to be precise to

       current attempt time + GL server retry= blocking time.

but delayed to a time that may fit its Queuing/Grouping.

Related, one thing we did explore in our MTA was an option:

      RetryMinuteGranularity  ON/OFF

which help to group rejected emails that came in different times to the same minute for the next attempt. This helped to gather Multi-Transaction sessions since we don't use a connection holding concept.

So I can see some value where the max value will give logic to the MTA a time limit to retry and can possible help in a MTA queuing implementation.

In general, in my view, it has value.

The only concern I have would be the "complexity" and the advocates who want to keep this as simple as possible.

Personally, I believe most MTA will behave in such a way to minimize delays so the odds are very high from a practical standpoint the wait time is all is needed and the GL servers would be expected to consider the MTA client would have a SMTP recommended total time (i.e. 4-5 days) to retry before given up.

That reminds me of an off list discussion how a retry= idea can create new ideas for MUAs or a MSA to add a new header:

   Delivery-Expire: date-time-value

The idea was this:

The email value, for whatever reasons, is deemed to be important and most be delivery as fast as possible or within a certain date/time. this is not an email expiration concept, but a delivery time before forcing a bounce.

So suppose the header was added (by either the MUA/MSA)

   Delivery-Expire: 6 hours

If the remote server issues a 4yz rejection with time hint

   451 Greylisted. retry=08:00:00

and/or the remote host is down for over 6 hours, then the MTA would have immediate information to stop retrying and create a bounce/DSN reporting the delivery time can not be met within the time frame the email indicated.


Hector wrote:

Claus Assmann wrote:
On Mon, Oct 24, 2011, Hector wrote:

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




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)?


Hmmm, if anything, maybe a 2nd optional expire=tag

   retry=[DD-]HH:MM:SS [expire=[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.