On Dec 15, 2019, at 11:57 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
Noting that I am nearly neutral on this question even though I
am in favor in principle in anything that would remove
requirements for unnecessary workarounds from 5321bis, thereby
making it shorter and less convoluted, I have a question that, I
believe, complements Victor's. At present, RFC 5321 (and its
predecessors) insist that a server should accept up to 100 RCPT
commands. I know of several, possibly many, systems that have
been configured, based on operational experience, to use much
lower limits. Is it appropriate for us to lower the limit in
the 5321bis (and, if so, to what?) and/or to insert text
encouraging a somewhat more flexible approach to that limit?
Yes, I noted the same issue in the final paragraphs of:
https://mailarchive.ietf.org/arch/msg/ietf-smtp/AhT_hPXCPA_73vfuj9VYzVZP0Jc
[...] it sadly does not match today's reality
very well. The "too big to fail" cloud email providers have taken the
liberty to flout the requirement to accept at least 100 valid recipients
per envelope, and senders have had to hand-tune ad-hoc limits. I don't
know what, if anything can or should be done here to reconcile theory vs.
practice. :-(
this an area where practice appears to have diverged from the standard.
I not keen to see the limit reduced, but perhaps advice to clients to
default further below 100 than they may doing already may be warranted.
I can only speak to Postfix, which defaults to sending up to 50 and
accepting 1000.
It would be good to know whether there's any sort of new consensus limit
practiced by the likes of Google, Microsoft, ... Or whether it is all
now highly variable depending on the client's IP reputation and sender
domain and perhaps even list of attempted recipients.
If there is no longer any predictable lower bound, then it becomes
rather difficult to efficiently send multi-recipient mail. We end
up devolving to Qmail's always one at a time approach. [ Perhaps
even when DJB appears to be initially "wrong", he has on multiple
occasions been seen to be eventually right. ]
Mailing list email already tends to use techniques like VERP which
result in one delivery per recipient, so the main source of email
to multiple recipients is ad-hoc lists via Cc and Bcc, and legacy
1-to-many aliases that are not instantiated via a list manager.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp