On 12/17/2019 8:50 AM, Tony Finch wrote:
Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Sorry, I should have said "must not reject the whole message just because
of the number of recipients". I don't think this needs any signalling:
it's just to clarify the interoperability criteria for the existing 100
recipient rule.
I misunderstood your original point. To me pipelining refers to transport level
pipelining. You're talking about grouping as many recipients as possible into a
transaction, in which case yes, the specific "too many recipients" error would
need to be disallowed.
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.
A 452 would seem to be appropriate per RFC5321 section 4.5.3.1.10
In our Mail List Server's MTA, it handles the codes:
452 does not deactivate user, increment error count.
552 deactivate user
Technically correct I believe, this is probably a candidate for
RFC5321bis clarification. I may need make them both the same, not
deactivate the user. It wasn't the user's problem the server ran out
of space!! lol
But in all cases, the MTA does not quit the session. It continues with
RCPT TO and eventually DATA. By default, our server does not
implement a limit and the MTA is authorized to relay mail to remote
addresses. But if there were a server limit, then completing a
distribution might be lost with either 452 or 552 reply codes. These
need to trigger a distribution retry with those marked 452.
Note, this all works well when the List Server creates all the
separate mail files per target (UUCP/UUCICO mode) and the eyeballing
SMTP mail server picks them up and sends them out, one by one. This
is only a problem when pipeling or list server's MTA is going direct
to an authorizing SMTP server.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp