[Top] [All Lists]

Re: [ietf-smtp] parsing SMTP replies

2021-03-21 20:17:03
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.

Hector Santos,

ietf-smtp mailing list