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
<moore(_at_)network-heretics(_dot_)com> 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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp