Re: [ietf-smtp] parsing SMTP replies

[Hector Santos <[e-mail]>]

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,
https://secure.santronics.com
https://twitter.com/hectorsantos