On 3/17/2021 10:39 PM, Keith Moore wrote:
On 3/17/21 9:37 PM, Sam Varshavchik wrote:
I believe that the generally good track record of historical
interoperability of SMTP implementations goes back to what's in
section 4.5.3 of RFC 821, that gives the minimal limits of various
things, like line lengths. And, incidentally, the minimum number of
recipients that an SMTP server should accept is 100 recipients.
It's been a long time but I'm pretty sure I've seen situations in
which it made sense for the recipient limit to be 1.�� For example:
a special-purpose device (e.g. email to fax, email to printer) or a
gateway to a dissimilar mail system, or anything for which it makes
sense to insist that per-recipient errors get immediately reported
to the client.
Despite any standard, pseudo or otherwise, the ultimate limit is the
local receiver/system and the minimum for a protocol complete SMTP
transaction would be 1.
Our system has no limit out of the box and its system wide (global
registry value). No current out of the box logic per user. There
might be a 3rd party RCPT command override p-code script
(smtpcmd-rcpt.wcx) that may place a limit. Can't a typical system
handle 1000, 10K, 100K+ RCPTs? How does a big list send mail 1
million subscribers? When our MLS is going thru a submission
distribution, it has a transport to SMTP or create UUCP-ready files
option. The former method gets to learn from the SMTP receiver RCPT
responses where a permanent 5yz result could unsubscribe the user
after a number of consecutive different message times. Any permanent
negative results with the intention of just being a limit could be
interpreted as a user does no longer exist.
ietf-smtp mailing list