On Thu, Sep 24, 2020 at 02:06:05PM -0600, Bob Proulx wrote:
> > > ... http://postmaster.comcast.net/smtp-error-codes.php#RL000001 (in reply
> > > to MAIL FROM command))
> >
> > Look carefully at the log entry. The "421" is send in response to "MAIL
> > FROM", not "RCPT TO". So the recipient limit does not look entirely
> > plausible.
>
> If this was other than Comcast I would accept that immediately at face
> value but a long history says that Comcast is an unreliable narrator
> in this story. :-(
The (in reply to MAIL FROM command) is added by Postfix, not Comcast, so
that is not subject to doubt. Because the recipients were not yet
processed when "MAIL FROM" is received, it seems unlikely that the
recipient count is the issue, rather simply trying later solved the
problem.
The Comcast message is pretty clear, they're rate limiting on total
recipients per unit time, based on IP reputation. I see no evidence
of hiding anything, the link in question publishes the numbers, ...
Some legitimate senders may find it difficult to deliver the email they
expect to send this policy, but that does not mean that the policy is
any way something other than what it appears to be.
> Also the empirical testing showed that forcing one recipient per
> message succeeds while three per message was rejected. Interlaced.
Which only proves that sending at some later time did not run into the
rate limit. Nothing else.
> So while Comcast may be putting sites into buckets and some buckets
> are allowed to send to three at the same time and others are not
> knowing what kind of rule is being applied does not help work with it.
There is zero evidence that per message recipient counts are pertinent,
unless the rate limit quantum goes all the way down to 1 recipient
per unit time, in which case you have a bit of a problem.
> > A good test would be to disable "pipelining" in a custom
> > smtp(8) transport, and use that for Comcast. That would definitely
> > rule out recipient count limits if the reject is still at "MAIL FROM".
>
> Sounds like a good thing to test. Will give that a try.
Do the pipelining test. The first recipient should be accepted, but
then if the subsequent recipients "421" (instead of 450 or similar)
that'd be unfortunate, I might reach out to comcast email engineers for
a chat about that...
> Comcast is an unreliable narrator.
That's hyperbole. There's no evidence for that.
> I agree with you. Because of lack of volume Comcast appears to be
> rejecting multiple recipients but allowing single recipients.
You have no evidence of that, indeed the evidence so far argues
against this.
> But then how do we configure Postfix to do this automatically so that
> we can gain enough reputation to send more than one recipient at a
> time?
When you set a recipient limit of 1, you get three concurrent messages
with one recipient, rather than 1 message with three recipients, and you
also break the destination concurrency limits, which become per-user
rather than per-domain.
Do not set the recipient limit below 2, unless you also have a dedicated
single-domain transport, with a low process limit in master.cf.
> Because Comcast is not rejecting all mail. Comcast is only
> rejecting mail with multiple recipients.
Again, this is speculative, and not presently supported by the
evidence.
--
Viktor.
