Re: [ietf-smtp] parsing SMTP replies (was: Proposed ESMTP keyword RCPTLIMIT}

[Viktor Dukhovni <[e-mail]>]

> 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...

-- 
-- 
	Viktor.