Hello,
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
text:
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.
Regards
Дилян
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp