[Mailman-Users] Google mail servers reply "Multiple destination domains per transaction is unsupported "

Stephen J. Turnbull stephen at xemacs.org
Sat Mar 9 05:02:18 CET 2013


Joseph Brennan writes:

 > I reported this a few months ago, as a Google Apps for Edu customer, and 
 > Google refuses to fix it. I spent a couple of weeks back and forth with 
 > several people, and I got beyond the first line helpdesk. None of them 
 > could give me a good explanation,

I bet they think it's an anti-spam measure.  None of the big services
likes to talk much about that.

 > but they confirmed it is not considered a bug, it was done
 > deliberately.

Can you confirm that this is happening at your outgoing MTA (ie, the
first Google MX you encounter when submitting as a Google customer)?

I'm just guessing, but in practice is this issue restricted to mailing
lists and other software that automatically mails to several users?
Did they perhaps say "you should be using the submission protocol
(port 587)"?

The reason I ask is that surely academic users regularly send mail
personally to recipients at multiple domains.  Some users surely have
personal networks that involve multiple Google-hosted domains, and
they would find their mail *very* unreliable if they were experiencing
this issue.  I don't see any way an institution could use such a
service, or that Google could afford to not fix it.  "Neither snow
... stays swift completion" and all that.

On the other hand, AFAIK queueing is rarely implemented in clients:
they just hand a message text and a list of addresses to the MTA,
which then decides which addresses to transfer via which MXes.  The
only way I can see this working at all well in the face of the issue
we're discussing is that "personal" clients are subject to different
authorization procedures from others.  One way to accomplish that is
if personal clients are using Submission to submit messages instead of
SMTP.  Section 9 of RFC 4409 gives specific support to having
different security policies for SMTP and Submission.

Programmatic submission typically uses SMTP.


More information about the Mailman-Users mailing list