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 ----- > <[email protected]> > (reason: 550 5.1.1 <[email protected]>: 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 > <[email protected]>... 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 > <[email protected]>... 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 > <[email protected]>... 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 [email protected], > 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 [email protected] address which shouldn't have been involved in a google SMTP transaction AFAICT. Was the 550 for [email protected] 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=<[email protected]> dsn=4.3.1, stat=Deferred: 452 Too many recipients > to=<[email protected]> 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 [email protected] will be delivered in the same way as messages addressed to [email protected] 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 <[email protected]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list [email protected] https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
