On Tue, Dec 17, 2019 at 01:50:44PM +0000, Tony Finch wrote:
I did mean transport-level pipelining.
The thing I want to avoid is having the entire transaction rejected
because the server considers it to have too many recipients. If the client
pipelines 100 RCPT commands, and the server incorrectly considers that too
many, then the client will have serious problems getting the message
delivered without operator intervention and/or bug-compatibility
workarounds. Operator intervention might be to disable pipelining for that
destination (assuming the sending software stops trying RCPTs at the first
452) which might be enough to avoid upsetting small-minded servers.
It is not clear that "the first 452" is sufficiently unambiguous to
presume 452 for the remaining recipients even in the absence of
pipelining. [ Perhaps "452 4.5.3 ..." would be sufficiently clear. ]
The most important text on this in the *21 RFCs is the requirement to
wait for QUIT before closing the connection even after some (reasonable
number) of error replies.
[ Note that when recipients are rejected with a 5XX error, the sender
generally makes progress even if the message transmission tempfails,
because at least the rejected recipients are now resolved. ]
If at least one recipient has been accepted, the receiving MTA SHOULD
allow the transaction to proceed to DATA (or BDAT), and accept the
message for the valid recipients.
Because pipelining can result in an "overshoot" of the receiver's
recipient limit, Postfix allows (default) 1000 additional recipients
over the configured recipient limit (also default 1000) before the
connection error count is incremented (too many errors can trigger
connection close):
http://www.postfix.org/postconf.5.html#smtpd_recipient_overshoot_limit
smtpd_recipient_overshoot_limit (default: 1000)
The number of recipients that a remote SMTP client can send in
excess of the limit specified with $smtpd_recipient_limit,
before the Postfix SMTP server increments the per-session error
count for each excess recipient.
http://www.postfix.org/postconf.5.html#smtpd_soft_error_limit
http://www.postfix.org/postconf.5.html#smtpd_hard_error_limit
http://www.postfix.org/postconf.5.html#smtpd_error_sleep_time
If the receivers recipient limit is too low, and there is not sufficient
tolerance for "overshoot" then indeed a sender's multi-recipient message
might never make it to any of the recipients.
Furthermore, even with tolerance for overshoot, if the receivers limit
is say just 1 recipient per envelope, and the sender is RFC compliant
and sending 100 (Postfix defaults to 50, to stay on the safe side), then
it will take 100 retries to deliver the message to all recipients.
If there's only one receiving MX host, that means the message would need
to be deferred and retried 100 times. Given a 5 day retry limit, and a
retry interval of 1 to 2 hours, the message can easily time out.
So I don't believe that removing the floor is a good idea. In
particular, it is essential for receiving systems that to decide to
support less than 100 recipients, to be willing to tempfail 99
recipients, and still accept the message for the 1st recipient.
On sending side, absent local policy for particular destinations based
on reasonable knowledge of the receiving systems willingness to accept
more than 100 recipients per envelope, sending systems SHOULD NOT
attempt to stuff more than 100 recipients in a single envelope.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp