[Top] [All Lists]

Re: [ietf-smtp] SMTP Greylisting Retry Hints + PRDR

2019-02-09 06:53:33

back to draft-santos-smtpgrey-02, in section 2.3.5 DATA the draft says:

„A GreyListing Server rejecting at the DATA may be recording more information 
besides the triplet information,
i.e.  Message-Id header.”

The discussion here concluded, that tracking the Message-Id after DATA End of 
DATA and a 451 reply is not reliable means
to achieve anything.

In section 2.4.  4yz Format Structure > Examples: consider adding an example 
with totalsecs, like
451 4.7.1 Retry after end-of-data, possibly in this TCP connection. retry=0

My reading of the example:
  421 Your connection is greylisted. Please try again later (retry=00:01:00)
is that it is not conformant to the specification, as retry= is not at the very 
end, a ) follows.

I propose inserting in the draft under section “3.  SMTP Service Keyword” the 

When the service keyword 250-GREYLIST is announced, it indicates that the 
client SHALL keep the IP address on retries.

draft-santos-smtpgrey-02 is not clear, whether clients are supposed to honour 
the retry= hint, if the server has not
announced 250-GREYLIST keyword.  This gets tricky, when the server accepts one 
RCPT per transaction, announces retry=
for the remaining RCPTs and does not care, whether the IP address is reused by 
the client on retries.

draft-santos-smtpgrey-02 wants to insert in multiple line responses the retry= 
hint on the last line.  What will happen
with other SMTP enhancements/hints?  Can they also insist on being present on 
the last line?  Can they insist to be also
the very last text in the response?

“If a SMTP client is rejected by the Greylisting Server during the
   session, the client SHOULD NOT attempt to start a new transaction
   during the same session and SHOULD immediately issue a QUIT command
   to end the session. ”

I do not like this text, as it is against the idea of accepting one/few RCPT 
per transaction, and telling all the other
recipients “421 … retry=0”.

„If a SMTP server offers a "retry=time-delay" hint which results in a
   wasted 2nd attempt and requires additional attempts, the SMTP client
   MAY begin to ignore the server's "retry=time-delay" hint after the
   2nd wasted retry. ”

Likewise.  What means “wasted”?  If the amount of remaing recipients is reduced 
on each retry, then the SMPT client
shall not begin to ignore the server's retry= hint after the 2nd wasted retry.

On Sat, 2019-02-09 at 11:28 +0100, Peter J. Holzer wrote:
On 2019-02-08 17:56:15 +0100, Dilyan Palauzov wrote:
Hello Paul,

what I proposed.

But I don't think this is what you proposed. 

As I understood it, you proposed delivering a message while returning a
4xx reply to the sender. 

On 7th February I wrote:

Strictly speaking the delivery for all recipients does not have to be 
delayed.  The server can deliver promptly the
messages to all deserving recipients, memorize the Message-Id and the per 
recipient response, and in subsequent
transactions communicate the status per recipient.  The only side effect is 
then the “Mail not delivered within four
hours” status message returned to the sender.

After some subscribers stated, that on retries the Message-Id can be changed, I 
have not insisted anymore, that
delivering promptly to all recipients, while communicating to the sender on 
RCPT “421 Retry later” does work as
expected.  It is a matter of weigthing all drawbacks.  I proposed a no-bounces 
policy, where the senders are concerned
with false positives.  As a matter of fact, I have never implemented this 
“cheating”, what I implemeted now is replying
on subsequent RCPT TO with

451 4.7.1 Retry immediately, possibly in the same TCP connection, after DATA 
End of data; retry=0

while not returning 250-GREYLIST on EHLO.

So the recepient gets the message, but the sender might get a "your
message couldn't be delivered for 4 hours" notification even though it
was actually delivered. 

I think this would be very confusing.

Absolutely!  False positives are also very confusing and whatever is done to 
fix one very confusing situation leads to
another very confusing situation.  If there is interest I can describe all 
confusing situations and what options there
are to choose the right very confusing situation for a server.

It also doesn't help with reducing the number of delivery rounds since
the message Id isn't available at the time RCPT is received.

Sure.  It helps with reducing the side effects of false positives and the side 
effects of delayed email delivery.

In the very simple case, when there is one recipient, and the mail is put in 
quarantine/spam/false positive, the SMTP
protocol allows shifting the work on dealing with false positives from the 
recipint to the sender.  This is largely not
done nowadays.  The people who decide on this are, if I remember correctly, not 
subscribed on any IETF mailing list.

The PRDR-after-DATA proposal will make progress, if providers are willing to 
switch the work on dealing with spam
folders to the sender.  As user I want not to deal with Spam folder, and this 
switch makes it possible.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>