On 13/10/2011 05:13, Keith Moore wrote:
My guess is that most MTAs aren't set up to be able to (re)attempt delivery
within a particular time window.
Which is exactly my point. This is a tricky thing to add to an existing
queuing strategy.
yes, I agree. parsing the dates isn't a problem, but changing a queueing
strategy in an existing product could be a huge problem.
But no one is saying they would have to. The server would just give a
'hint' about the delay needed for the next retry. The client can ignore
that and just use its existing retry mechanism, and there would be no
change to existing behaviour, or the client could choose to use the hint
to avoid having unnecessary failed retries in the meantime.
So, if the server says 'retry in 1 hour', and the client retries every 5
minutes, that's no crisis, just a wasted bit of effort for the client
and the server. If the client can heed the advice, it just saves a few
retries which were doomed to failure. If the server says 'retry in 24
hours' the client is quite at liberty to say 'I don't believe you, I'll
try sooner than that'.
As I see it, it would be a bit like the "[in-use]" flag in POP3 login
error responses. If the client ignores it, it's no problem at all, but
the extra information is there in case the client wants to use it. I see
it as a minimal impact extension.