Claus,
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:
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?