Hello,
the answer is “You cannot change systems installed ten years ago and at the end
everything is implementation specific”.
What was the question?
492 can mean “Mailbox is full”, or “Too many recipients in this iteration”
since the very beginning.
4.5.3 means only the latter and communicating “the too many recipients” can be
used to limit the incoming spam or be
means to achieve other things.
What retry strategy is reasonable, when the server communicates “Too many
recipients in this transaction”?
Do more MX/IP addresses for a domain suggest more frequent retries (more total
amount of iterations per time unit) on
“Too many recipients in this transaction”?
Is publishing 1024 distinct IPv6 addresses for MX on a domain a good idea, in
order to decrease the average delay
imposed by “Too many recipients in this transaction” temporary error?
… So if the client is having trouble connecting to a server, the retries
times can change. How long do you continue
trying a BAD IP address? It might be bad only for a day or so until the
receiver's DNS records is corrected or has
propagated thru the network.
See https://wiki.apache.org/spamassassin/OtherTricks → Fake MX Records, hence
an MX/IP address can be bad forever. This
shall not have impact on the retry times for the valid IP addresses.
But I am not sure why a "retry=0" was suggested. Is Dilyan suggesting
that client should try immediately when it sees an explicit
"retry=time-value" with a time-value of zero?
Exactly. The answer of “Why this is needed” is for a separate discussion, lets
first fix how to convince the client how
to retry immediately.
How are 452 and 451 4.5.3 supposed to be different than the retry=0 hint?
As far as SMTP-GREY draft is concern, a retry=time-delay value of zero
is undefined. A zero value goes against the point of Greylisting where
a block delay was determined to be necessary. See section 2.5.
Recommended Blocking Times.
https://tools.ietf.org/html/draft-santos-smtpgrey-02#section-2.5
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.
My reading of:
retryhint = "retry=" time-delay
time-delay = ( [days "-"] hours ":" minutes ":" seconds) / totalsecs
totalsecs = 6*DIGIT ; 0-999999
is that retry=0 and retry=00:00:00 is the same.
Because retry=0 is not specified in the smtpgrey-draft, I asked here on 06 Feb
2019 21:47:58 +0000 to amend, that on
retry=0 the server shall retry after end-of-data. There are use cases, not
related to greylisting, where the server
answers with retry=0 to a set of recipients and with retry=1 to other sets of
recipients, and so on. This recipients
shall be retried in group transactions together. That is why I propose now to
add to the draft:
When a server combines a retry hint with 4.5.3 Enhanced status code, the client
can reuse the TCP connection for the
retries, but repeat the RCPT after DATA end-of-data. Different values of the
retry hints suggest grouping the
recipients with the same value in a single retry transaction and repeating the
iteration for each such group.
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".
Absolutely! Nevertheless it is still possible to write down what is reasonable
and the motivation for one or other
implementation is.
I don't think I like the idea of using an explicit time-value of zero
as way to try to drive a client to retry immediately.
What is the problem with immediate retry, when we are not talking about
greylistting, but about Too many recipients in
this transaction?
Greetings
Дилян
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp