[Top] [All Lists]

Re: [ietf-smtp] Reducing minimum recipient limit?

2019-12-19 10:38:49
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

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.


ietf-smtp mailing list

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