[Mailman-Users] gmail "Multiple destination domains" error

[Mark Sapiro]

On 02/17/2015 05:59 PM, Andrew Daviel wrote:
> 
> 
> I have a mailman list running on Linux CentOS 5 with sendmail 8.13.8.
> Generally, everything works (I believe/hope).
> 
> Today I got a bounce action notification. When I looked at it,
> there's a regular DSN e.g.
> 
>   ----- The following addresses had permanent fatal errors -----
> <xxxx at utvinternet.com>
>     (reason: 550 5.1.1 <xxxx at utvinternet.com>: Recipient address
> rejected: User unknown)
> 
> OK so far. Then in the same message I see
> 
>    ----- Transcript of session follows -----
> ... while talking to gmail-smtp-in.l.google.com.:
>>>> DATA
> <<< 451-4.3.0 Multiple destination domains per transaction is
> unsupported. Please
> <<< 451 4.3.0 try again. r2si3773706igh.8 - gsmtp
> <user_1 at gmail.com>... Deferred: 451-4.3.0 Multiple destination domains
> per transaction is unsupported.  Please
> <<< 451-4.3.0 Multiple destination domains per transaction is
> unsupported. Please
> <<< 451 4.3.0 try again. r2si3773706igh.8 - gsmtp
> <user_2 at gmail.com>... Deferred: 451-4.3.0 Multiple destination domains
> per transaction is unsupported.  Please
> <<< 451-4.3.0 Multiple destination domains per transaction is
> unsupported. Please
> <<< 451 4.3.0 try again. r2si3773706igh.8 - gsmtp
> <user_3 at gmail.com>... Deferred: 451-4.3.0 Multiple destination domains
> per transaction is unsupported.  Please
> etc.


So your MTA is sending to many gmail.com and other addresses using the
same SMTP MX in one transaction.


> When I grep the mail logs, all the deferred messages to
> gmail-smtp-in.l.google.com (74.125.192.27) are xxx at gmail.com,
> i.e. all to gmail.com
>
> However, I've also got several users on googlemail.com, also using
> 74.125.192.27. Those messages went through OK, and seem to be associated
> with the ID r2si3773706igh.8


This is what the "Multiple destination domains per transaction is
unsupported" complaint from google is about. Presumably, all those 451s
were ultimately retried by sendmail and succeeded.

Mailman is delivering a whole bunch of recipients per SMTP transaction
(up to Mailman's SMTP_MAX_RCPTS, default 500). Sendmail is taking that
one message transaction and delivering and many RCPTs as it can in one
of it's transactions.

It appears the the first RCPT TO seen by google was a googlemail.com
address so it then gave the 451 response to all the succeeding gmail.com
addresses.

The only puzzle is why this particular transaction transcript was
included with a bounce of the xxxx at utvinternet.com address which
shouldn't have been involved in a google SMTP transaction AFAICT. Was
the 550 for xxxx at utvinternet.com included in the transcript?


> Has anyone else seen this ? Does Google not like sendmail anymore ?


You might be able to configure sendmail to send fewer (one) RCPT TO per
transaction, but see below.


> A bit later, I see things like
> to=<user_10 at hotmail.com> dsn=4.3.1, stat=Deferred: 452 Too many recipients
> to=<user_11 at hotmail.com> dsn=4.3.1, stat=Deferred: 452 Too many recipients
> 
> 
> Again, does Hotmail not like sendmail ? Is there something I should
> tune, or is this just normal mail behaviour and it will be dlayed till
> the next queue run ?


These should all be deferred and retried, but will add delay.

I suggest verifying that Mailman's VERPing will work, i.e., that
messages sent to

listname-bounces+user=example.com at your.mailman.server

will be delivered in the same way as messages addressed to

listname-bounces at your.mailman.server

If you'd rather use a '-' delimiter rather than '+' as above, see the
FAQ at <http://wiki.list.org/x/8683535>.

Then I suggest setting

VERP_PASSWORD_REMINDERS = Yes
VERP_PERSONALIZED_DELIVERIES = Yes
VERP_DELIVERY_INTERVAL = 1

in mm_cfg.py to enable VERP on outgoing messages. The first two are
essentially no cost as long as VERP like addresses work. The third has
some performance impact, but it isn't severe. These will result in more
reliable, automated bounce processing and will result in messages being
delivered from Mailman to the MTA (sendmail) with one RCPT TO per
transaction and then sendmail doing the same. The major cost is the DATA
(i.e. message body) has to be included for each RCPT, but this isn't huge.

If you don't want to VERP for some reason, you can set SMTP_MAX_RCPTS to
a small number, e.g. 10 or less, in mm_cfg.py. This will eliminate the
hotmail issue and make the gmail/googlemail issue much less likely to
occur, but note that in all of this, I'm sure all the 45x responses were
queued and retried, eventually successfully, with additional delay being
the only real issue.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan