Re: [ietf-smtp] parsing SMTP replies

[Michael Peddemors <[e-mail]>]

While our servers 'might' accept different limits, and the MTA operator 
is free to set those limits, I will give you one example that goes WAY 
below the 100 limit defined as a minimum.

Incremental Weight systems..

A valid RCPT TO address couple be 1:1

Invalid RCPT TO address treated the same as 20:1, eg so that you can't 
use it for email harvesting as easily.. Send to 5 invalid users, and it 
can have the same weight as another MTA sending 100 valid users.

A particular IP space known for spambots might have a weight of 50:1

Or in reverse, the limit could be lower, say 10 RCPT permitted, except 
for known larger email providers based on the PTR records..

Personally, think the IETF should just stay out of recommending any 
limits, or advertisement of limits, we already have mechanisms via the 
4xx and 5xx to tell the remote MTA what to do, and even a reason why we 
did it, but there is no real 'standard' that is evident out there, so 
why are we (IETF) attempting to set standards..

This should come from the industry, and right now, every MTA admin has 
different ideas on this, depending on their usage scenario.

IMHO



On 2021-03-17 7:54 p.m., Viktor Dukhovni wrote:
>> On Mar 17, 2021, at 10:39 PM, Keith Moore <[e-mail]> wrote:
>>
>> 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.
> 
> That's really the realm of LMTP, final delivery, not relaying.
> 
> But much as I agree that MTAs should avoid going below the 5321 limits,
> I don't know that we can realistically win in the face of the clout of
> the my way or the highway crowd of Gmail, Outlook.com and perhaps still
> even Yahoo.
> 
> So long as they are willing to reply with 452 as many as (100-N) times
> when enforcing a limit of N, things mostly work out provided N is not
> so small that one ends up deferring some of the message recipients more
> than a couple of times in order to deliver the remaining recipients.
> 
> The real question is what to do when you have prepared an envelope of
> say 100 recipients, and encounter an MTA with a limit of 5?  Do you
> then open 20 parallel connections (they'll hate you for that too),
> or do serially transmit the same message over the existing connection
> (they may also have an unannounced message per connection limit), or
> finally serially open new connections, without deferring, but then
> this destination ends up hogging multiple delivery agent cycles out
> of turn (this matters when a queue manager is trying to manage
> some semblance of fairness).
> 
> So limits below the expected limit are damaging to sender performance,
> and should not be routinely applied.  The problem is that by the usual
> suspects many independently operated smaller MTAs are treated with
> suspicion...
> 



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.