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
I misunderstood your original point. To me pipelining refers to transport
pipelining. You're talking about grouping as many recipients as possible into
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.
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
Whitby to Gibraltar Point: Variable 3 or less, becoming south or southeast 3
to 5 later. Smooth or slight. Rain at first in south. Good, occasionally
moderate at first in south.
ietf-smtp mailing list