[Top] [All Lists]

Re: [ietf-smtp] SMTP Retrying/Sending Strategy on 452 / 4.5.3

2019-02-13 06:22:35

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 → 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.

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?


ietf-smtp mailing list