On 11/02/2019 16:09, Hector Santos wrote:
However, problematically, a server issuing a "retry=00:00:00" hint
would translate to a no block time delay and the client can try again
when it decides to try again.
The key point is that a server issuing ANY 'retry=' means that the
client can try again when it decides to try again. That is even if the
client understands the 'retry=' hints. It's a *hint*.
The client may look at "retry=00:05:00" and say "that's too short, I'll
try again in 20 minutes, or at "retry=04:00:00" and say "that's too
long, I'll try again in 1 hour".
The client is what determines when it will retry. Basing any scheme
around the server being able to control that is doomed to failure.
Using the hints for greylisting isn't going to be problematic because
greylisting is usually solved by a single retry in the correct
timeframe. Subverting them for other purposes (which may involve
multiple retries, even after the specified delays) may give unintended
results.
If you're on your 20th retry and the server is STILL saying
'retry=00:00:01', for the 20th time, then it wouldn't be unreasonable
for the client to say 'stuff that, I'll leave it a few hours and then
try it again'.
--
Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53
Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp