On 2/9/2019 2:11 PM, valdis(_dot_)kletnieks(_at_)vt(_dot_)edu wrote:
“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”.
Agreed on that - it means that if there are multiple mail items queued for
a delivery to a host that has been unreachable for some amount of time,
the client can't complete running the queue - even if the remaining messages
would not have been greylisted.
I have not observed this in over 15+ years of Greylisting operations.
The specific paragraph in SMTP-GREY, in whole, is:
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. Its been observed that some mail senders will
hold the connection for 1-5 minutes and retry the same mail
transaction or a new transaction. The SMTP server rejecting the
initial transaction MAY stop accepting any new transactions attempts
during the same session.
This is based on real scenarios where unauthenticated, anonymous
(unknown) senders try to bypass SMTP 5yz/4yz filter responses by
restarting a new transaction, for example:
C: MAIL FROM: <user1(_at_)example1(_dot_)com>
S: 250 OK
C: RCPT TO: <local(_dot_)user(_at_)localhost(_dot_)example(_dot_)com>
S: 250 Local User and/or Local Host Ok
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
...payload transferred, local filters spawned ...
S: 451 Greylisted. Please try again later (TempFail) retry=00:00:55
C: RSET
S: 250 Reset State #1
C: MAIL FROM: <user2(_at_)example2(_dot_)com)
S: 451 Transactions disabled due to policy.
This was learned not from Greylisting but, in fact, from SPF and other
SMTP rejection filters where the unknown client attempted a new
transaction to bypass an earlier rejection. In addition, there were
clients (determined to be from mail services using a specific SMTP
package) that allowed for holding a socket connection open while it
waited for any new outbound mail to arrive and to be sent. Without a
client/server negotiated authorized contract, this was consdered to be
CPU and load expensive and a high scaling overhead on the receiver
side. In fact, because of this, our SMTP package offers local policy
options to change the SMTP wait time from 5 minutes to 1 min or less
to help minimize these client hold times which normally do not send
another transaction.
I agree, overall, this thread is about dealing with multiple
recipients and also multiple transactions per session. So there should
be information about this, but I think the protocol doesn't prohibit
these design considerations. The above protocol note implies the
Compliant SMTP-GREY Client should be aware a negative reply code COULD
restrict a client from starting a new transaction and also apply other
restrictions. i.e. lower wait times is a possibility.
Should I add this protocol note?
Compliant Clients SHOULD be aware Greylisting Server MAY restrict
multiple transactions, multiple recipients and wait times after
a 4yz Greylist response has been issued.
It's all possible today, even without greylisting. In today's era of
advancing filtering methods, it could even be a general SMTP state
machine note to consider, if not already implied in RFC5321.
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.
And as a user, if the sender is doing the spam management, you *can't* deal
with your spam folder anymore. Which will totally suck if the sender decides
that
since the mail got greylisted, it must be spam - and it's a false positive on
an actually important mail like a bank notification. Remember - spam folders
exist precisely because spam detection isn't perfect.
If I follow, I am not sure I agree, this is about driving the SMTP
client retry scheduler by providing a wait time delta to the existing
equation. Server controls using 4yz have long existed. What is
different is the "reply=" hint.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp