Categories: Verification and MX Records :

MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported.

Showing 1-37 of 37 messages
MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. bbloki 6/17/12 11:28 PM
Dear Google Support,

I have posted on this matter before and received no satisfactory response. I work for a mail company and we are suffering this error when some of our
clients send mail to multiple domain names through google servers. It is creating unnecessary load and delays for our mail servers and causing direct inconvenience
to our clients. Due to client information confidentiality I will not post explicit details except through a private reply.

A recent log extraction highlighting the problem is as follows:

Jun 16 00:12:37 server agent[1]: transact_id: from=sen...@domain1.com, size=x, class=-60, nrcpts=14, msgid=<####>, proto=SMTP, daemon=MTA, relay=local_relay_server[private_ip]
Jun 16 00:12:37 server agent[1]: transact_id: to=<k...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<j...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<i...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<h...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<g...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<f...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<e...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<d...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<c...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<b...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<a...@domain2.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<m...@domain1.com>, delay=00:00:00, mailer=smtpf, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<l...@domain1.com>, delay=00:00:00, mailer=smtpf, #######, stat=queued
Jun 16 00:12:37 server agent[1]: transact_id: to=<o...@domain3.com>, delay=00:00:00, mailer=esmtp, #######, stat=queued
Jun 16 00:12:43 server agent[2]: transact_id: to=<a...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
Jun 16 00:12:43 server agent[2]: transact_id: to=<b...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
Jun 16 00:12:43 server agent[2]: transact_id: to=<c...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
Jun 16 00:12:43 server agent[2]: transact_id: to=<d...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
Jun 16 00:12:43 server agent[2]: transact_id: to=<e...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
Jun 16 00:12:43 server agent[2]: transact_id: to=<f...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
Jun 16 00:12:43 server agent[2]: transact_id: to=<g...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
Jun 16 00:12:43 server agent[2]: transact_id: to=<h...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
Jun 16 00:12:43 server agent[2]: transact_id: to=<i...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
Jun 16 00:12:43 server agent[2]: transact_id: to=<j...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
Jun 16 00:12:43 server agent[2]: transact_id: to=<k...@domain2.com>, delay=00:00:06, xdelay=00:00:01, mailer=esmtp, #######, relay=aspmx.l.google.com. [74.125.127.26], dsn=4.3.0, stat=Deferred: 451-4.3.0 Multiple destination domains per transaction is unsupported.  Please

This behavior is abhorrent and not consistent with standard mx server operation. I would appreciate a prompt reply so that the cause can be determined, and preferably resolved swiftly.

Regards,

Lochlainn.
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Derek_R 6/18/12 3:20 AM
L,

we are suffering this error when some of our
clients send mail to multiple domain names through google servers.

Due to client information confidentiality I will not post explicit details except through a private reply.

In order to check DNS etc.,

we need some actual client domain names + your actual domain name

in order to do any troubleshooting.

If total confidentiality is required and your domain is signed up to GApps,

you can contact GoogleApps support. 

If you have GApps Business Ed. you can open a support ticket.

If you don't have GApps, then all your GApps clients will need

to contact GApps support individually to report this issue,

which they can do if they have Business Edition.

If none of the above apply, then this forum is your only source of inf.. I'm afraid.





Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Derek_R 6/18/12 3:51 AM
L,

Experience has shown me that the first thing to check here

is that all domains involved have the correct SPF record

in their DNS. So that all 'sent' mail / servers are authenticated correctly.
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. ExtremelyAngryUser 8/5/12 3:02 PM
Lochlainn,

You are correct in your assessment and the replies you have received indicate a lack of understanding (at best) of the problem that you describe and (at worst) a lack of understanding of how SMTP mail works.

There's nothing that you can do... the server has been listed in the MX records for quite a few domains as being available for receipt of SMTP mail, but whoever has configured it has set it to disallow the receipt for more than one of those domains at a time... utter madness!   Yes, the rest of the world could rewrite their transport rules to cater for this, but why should they when Google has - completely unnecessarily! - created the problem? We have a huge opt-in membership too, and those users with accounts with the affected ISPs have begun to notice that they don't get all the circulations... they don't get them when our MTA tries to deliver to that one rogue server or server pool:

    SMTP error from remote mail server after RCPT TO:<------removed------->:
    host alt1.aspmx.l.google.com [173.194.70.27]:
    451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
    451 4.3.0 try again. fx10si10457720wib.29: retry timeout exceeded

We have taken the opposite approach... we have just kept all affected members up-to-date with details of the problem and with Google's failure (or inability) to fix it... gradually, they are opening accounts with other providers, ones that understand how SMTP mail actually works, and also care about the service that they provide to users.  We've also notified the Postmasters at the other affected domains, all except... yes, Google! Why?  Because mail to the Postmaster just generates an automatic response and directs other postmasters to the Google Support pages, where they can waste hours trying to tell Google about the problem.  That's how I got here, and I've lost patience.

Next stop, The Register... it won't fix broken Gmail, but I will feel a lot better about the time that I've wasted, and hopefully it will dissuade people from signing up with this cowboy outfit... :(

Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. ExtremelyAngryUser 8/5/12 3:08 PM
I forgot to list the affected domains...

The problem affects anyone with an e-mail address ending:

blueyonder.co.uk
ntlworld.com
virginmedia.com
virgin.net


Even the most trivial investigation by a junior sysadmin will find the server alt1.aspmx.l.google.com [173.194.70.27] listed for all of these... take that one out (or fix it!) and the problem will disappear...


Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Derek_R 8/6/12 4:14 AM
E,

the replies you have received indicate a lack of understanding (at best) of the problem that you describe and (at worst) a lack of understanding of how SMTP mail works.

OK :-)

Why don't you explain it to me then ?  

BTW I'm qualified to MSc level in Systems' Integration + 20 yrs experinence.

So you better have a good answer . . . . :-)

Those domains you mentioned are all GApps domains administered by Virginmedia PLC.

and are not google's support responsiblity under an ISP agreement.

So if you're experiencing authentication/server problems with those domains, you need to contact Virginmedia support in the UK.
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Derek_R 8/6/12 5:46 AM
b,

AFAIK,

The google MX servers don't actually send any email from GApps domains.

And they certainly aren't recommended to be used as smtp relay servers.

The list of current sending server IP addresses is contained in the Google SPF record.



The only GoogleApps recommended smtp server is smtp.gmail.com.

Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. ExtremelyAngryUser 8/6/12 8:07 AM
On 6 August 2012 12:14, Google Apps on behalf of Derek_R <ap...@googleproductforums.com> wrote:
BTW I'm qualified to MSc level in Systems' Integration + 20 yrs experinence.

So you better have a good answer . . . . :-)

Well, I have 10 years over you in experience then, and my Honours degree in pure computer science was awarded when Motorola made the disastrous mistake (because it allowed Intel to dominate) of marketing what it described as a 16-bit microprocessor (because of its internal bus size) when it actually had a 24-bit address bus and 32-bit opcodes... but I digress...

Those domains you mentioned are all GApps domains administered by Virginmedia PLC.

and are not google's support responsiblity under an ISP agreement.

So if you're experiencing authentication/server problems with those domains, you need to contact Virginmedia support in the UK.

God give me strength!

OK... Those domains - no matter what ISP agreements are in place - have MX records.  Mail Transport Agents (MTAs) use those MX records to find an available SMTP mail server to which to deliver outbound mail... OK so far?

BUT servers on the Internet don't actually use fully-qualified domain names to deliver mail, they use the IP addresses derived from those FQDNs using DNS... OK?

So we have individual e-mails to deliver to each of those domains I listed, and we deliver them one at a time.  Delivered one at a time, there's no problem - the Google mail server will happily accept any e-mail to one of those domains, no matter how many there happen to be.

But here is the problem, and it is costing you customers - because no-one wants to be told that their ISP's mail system is fubar'd, and Google's certainly is.  If an MTA has a large batch of e-mails, a batch that includes mail for more than one of those domains, it is looking up the MX records for these and being given the FQDN name - and hence the IP address - of a server that, according to those differing MX records, will accept mail for all of them.  But when actually transmitting the RCPTs for the list of intended recipients, the Google mail server is generating type-400 errors as shown above, and that keeps happening until the sending MTA retries expire and the message is classed as undeliverable.

Typically, you state that the issue is one for those other domain owners... but although this could be fixed by those domain owners have mutually-exclusive lists of Google mail servers in their MX records, why should they when Google isn't providing the service that they are paying for?  Why should RFC-compliant MTAs have special transports written for them when Google seems to be unwilling or unable to fix their broken mail servers?

And worse - why is it that it seems to be impossible even to get Google to acknowledge that there is even a problem in the first place - you are still blaming other ISPs when you have had the problem spelled out to you in detail!  I'm still trying to understand what your colleague is going on about when he refers to SMTP relay servers... no-one is trying to relay anything, just trying to deliver mail to the servers listed in the MX records as being those for the addressee's domain... but Google doesn't seem to be able to make that work!

We've updated our members with this latest twist... and recommended that they move to an ISP that actually provides a reliable service.

If you still don't understand the problem, then...

(1) set up a mail server in a third party domain;
(2) prepare lists of multiple e-mail addresses, one list for each of the above-mentioned domains;
(3) send an e-mail to each of those bulk lists in turn - all of which will work, then...
(4) send the same e-mail again to all of them at once - the likelihood is that the MTA will try to delver them all to a single Google mail server (because it is listed in all of the relevant domains' MX records) but all mail for the second and subsequent domains will (probably) be rejected with the above error.

And the problem started at the beginning of May, when you introduced the "only-mail-for-one-domain-at-a-time" rule on all of your servers... shouldn't that be ringinging the alarm bells, even if you still don't understand the problem?

Kapeesh?
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 8/6/12 11:55 PM
Lochlainn,

There's no need to be so blunt. Derek is offering his time here to help. TBH the info you provided wasn't exactly clear, so don't shoot him down for taking a guess.

Rob

Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 8/7/12 1:06 AM
It's an unfortunate situation that Google is forced to put measures in place to combat abuse of it services. While in an ideal world, Google wouldn't need to worry about bulk senders who want to push there unwanted junk, the reality is much different.

I'm sure you are aware that alt1.aspmx.l.google.com is cluster of MTA, so if this fault can be reliably produced, it's unlikely it's a misconfiguration. That said it unusual that only one cluster is exhibiting this so called "only-mail-for-one-domain-at-a-time" rule.

I'd have to say this is the first time I've seen this exact issue, but I have seen similar issues with other bulk senders seeing non standard (RFC) responses.

If you care to detail the exact fault in a single concise post I'd be happy to pass it on to the Google Advisors to see if they can shed some light on why / how it maybe fixed.

Rob
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Derek_R 8/7/12 3:42 AM
Good answers :-)


Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. tnaindustry 8/14/12 11:57 AM
I agree with ExtremelyAngryUser that this is obviously a Google issue.  But it is not limited to a single cluster.  I have the issue with all of the school districts that on on my mailing lists.  They point to 6 different server clusters that all end with ASPMX.L.GOOGLE.COM.  There is no way I can set my mail server to do what google tells me I need to do.  So basically each of the affected districts would have to change their MX record to point to this SMTP.GMAIL.COM address.  Something that is not going to happen. The google response provided about is what the few district I have spoken with got and they have no clue what it really says.
 
My temporary fix was to put Hosts file entries for each of the ASPMX.L.GOOGLE.COM addresses that point them to the IP Address returned for SMTP.GMAIL.COM.  This basically changed all their MX records (for my server at least) without them having to do anything.  It appears to have resolved the issue for that server.  But it does not help the schools when someone from our State Department of Education sends an email to all the schools.  They still get the errors (not part of my organization).
 
Google really needs to fix the issue.  And they need to do it quickly as schools in Iowa are back in session starting this week.
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 8/14/12 8:10 PM
Hi tnaindustry,

As an EDU you have access to paid support. I suggest you escalate this via that channel, if you are looking for a quick response.

FYI, SMTP.GMAIL.COM is really for consumer GM accounts, not GA. It's obviously is working, but it's not a long term solution.

I have escalated the issue with the advisors, but yet to get a response on the issue.

Rob

Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. tnaindustry 8/14/12 8:40 PM
Rob,
 
Thanks for the response.  I am not an EDU, I am actually a state agency that manages my own listserv mail server for another state agency.  The response that has already been posted is what 4 school districts got from support.  Basically support is telling people if they want to get mail from mailing lists, they have to use the gmail server instead of the GA server.  This is a huge issue for those that are not receiving emails from lists that deal with funding. Our listserv server is not the only one that is having these issues.  I hope that someone does take another look at the issue.
 
Thanks
 
Allen
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 8/14/12 9:00 PM
I think it's possible they've got their wires crossed, as SMTP.GMAIL.COM is an outbound email service. It's most unlikely support would have recommended it. It's not for inbound email, atleast what the official guides say.

gmail.com.		3600	IN	MX	40 alt4.gmail-smtp-in.l.google.com.
gmail.com.		3600	IN	MX	30 alt3.gmail-smtp-in.l.google.com.
gmail.com.		3600	IN	MX	10 alt1.gmail-smtp-in.l.google.com.
gmail.com.		3600	IN	MX	20 alt2.gmail-smtp-in.l.google.com.
gmail.com.		3600	IN	MX	5 gmail-smtp-in.l.google.com.

If you have a copy of the support ticket or the ticket case numbers, I can verify this.

Rob

Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Derek_R 8/15/12 3:13 AM
Rob,

Following this thread with interest :-)

AFAIK

There's another level of complexity maybe involved here.

Google  seem to dynamically allocate their servers through

another 'not well known' domain called 1e100.net

Any information on how  1e100.net   operates ?
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 8/15/12 5:20 AM
It's a valid Google domain used for reverse DNS. The link below explains why.

http://support.google.com/bin/answer.py?hl=en&answer=174717


Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. tnaindustry 8/15/12 5:23 AM
Rob,
 
I don't have any of the ticket numbers because I am a third party to this problem.  We don't use GA for our email (although we were considering it until we saw how Google was handling this issue).  We provide a mailing list for our Department of Education but so does our state's IT Department.  Everyone is seeing this same issue.  If you search the internet, there are lots of threads that repost what I got from one of the schools as the Google Support Solution:
 

"Based on my investigation and research, I believe what's happening is your system is connecting directly to the delivery server (aspmx.l.google.com). As this is the delivery server, it does not allow:

1. Delivery to accounts that are not provisioned on Google (i.e., unauthenticated relaying).

2. Delivery to multiple different domains within the same SMTP session.

The second one is the one that is important to us. As of the beginning of this month(May2012), adjustments were made to our server settings that mean that our delivery server is strictly enforcing the multiple-domain-not-allowed rule. There are two ways to get around this. The first is to send to separate domains on separate smtp sessions, and the second is to use smtp.gmail.com in place of aspmx.l.google.com."

 
I hope this helps.  If you can direct me to a solution for our schools that will work globally for them, I would greatly appriciate it.  But as long as they are pointing to the ASPMX cluster and the cluster "is strictly enforcing the multiple-domain-not-allowed rule" then they are going to continue to have problems with mailing lists.
 
Allen
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 8/15/12 5:33 AM
I've asked the advisors for an update.

Will post back when I get a response.

If you can post links to other who have had the same problem, it will might help to make a case for it to be fixed.

Recommending smtp.google.com is most unorthodox and far from a satisfactory solution, but a work around never-less.

Rob

Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Derek_R 8/15/12 6:15 AM
Rob,

Thanks for the 1e100.net link.

================================

I can't see this MX issue being fixed by Google.

The fact that the MX servers won't send email under these conditions  . . . 

"Based on my investigation and research, I believe what's happening is your system is connecting directly to the delivery server (aspmx.l.google.com). As this is the delivery server, it does not allow:

1. Delivery to accounts that are not provisioned on Google (i.e., unauthenticated relaying).

2. Delivery to multiple different domains within the same SMTP session."

would seem to be a basic structural characteristic of GoogleApps

and is probably designed in from the ground floor for authentication/security reasons.

Anyway, is it not best to 'bite the bullet', and use a 3rd party system for sending large email lists

to/from addresses on multiple domains  from a GApps domain ? eg Sendgrid, Jangomail etc 


Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. tnaindustry 8/15/12 6:32 AM
Derek,
 
So basically you are saying I should pay someone to send my mailing lists that I have been sending for 15 years because Google decided to change something in May?  I prefer to get the issue fixed.  While I know that Google could care less if I am not using Google Apps for my 200 emails, but if a 200 school districts each with thousands of email addresses decided to leave because of this issue, it might get their attention.
 
This is not a problem built into the core of Google Apps.  It is a setting changed in May.  They flipped a switch in my to say Multiple Destination Domains Per Transaction were no longer permitted.  Solution, Flip the setting back until you figure out how to keep it from causing everyone else in the world from changing.  Do you really think this is going to stop the spammers?  They are the ones writing the bots to harvest addresses.  Pretty sure they already have written scripts to get past this little speed bump.  It really only affects those that have legitimate reasons to send mail to multiple google apps domains. 
 
Allen
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Derek_R 8/15/12 7:15 AM
A,

I'm not recommending anything . . . . 

just trying to discuss the issue rationally . . .

If it's as simple as flipping a switch, then I'm sure it will be done.

And if not, I'm sure a valid reason will be passed on to Rob.
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 8/15/12 10:05 PM
No word as yet, but it's being followed up.

That is a good point about the speed bump. I don't think it's really going to stop the bulk emailers. But it probably does cut a significant volume of email, that people probably don't miss, else it would be a hot issue.


Google's thinking is might be bulk emailers can deal with the issue along with the many other hurdles they have to deal with everyday. AFAIK Hotmail, Yahoo, AOL and other large email providers often implement non-standard MTA policies, to try and curb abuses. Unfortunately legitimate users get caught up in the net.

It certainly not a technical issue as you said. Google obviously implemented the policy for a reason and it maybe a case of protecting the masses, outweighs the convenience of a few.

The real way to get this sorted is for the schools to escalate the complaint with Google. I know that's not an easy thing to do, but someone in the district (admins) have the Google connections to do so. Google are going to be more receptive to a compliant from a customer than a thirdparty bulk mailer.

If such a ticket/case already exists, then I'm happy to fwd these onto the advisors -> engineers.

These are just my private thoughts on the matter obviously and not official Google policy etc.

Rob
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. tnaindustry 8/16/12 8:52 AM
Thanks Rob,  I have requested the trouble ticket information from any that had open tickets and asked everyone with the issue to open a ticket if they haven't yet opened one.  I will forward the ticket numbers to you as they roll in. 
 
What the Google folks might not understand is that this doesn't just affect Bulk mail senders.  As an example, a person at our Department of Education (DE) might have to send an email to 5 or 6  school districts. This might be a time sensitive email but if all 5 or 6 of these schools us Google Apps, it will take 4 or 5 retries of sending the message for all the messages to be delivered. With maybe 2 or 3 hours delay and possibly more depending on how many retires it is set to do.  And Joe Schmuckatelli at the DE is not going to understand the Multiple Domain error and will probably think that email address is no good and remove that person from their contact list.  So it affects so much more than just people sending mailing lists. 
 
Again, thanks for your help.
 
Allen
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 8/18/12 7:25 PM
I'll await the details.

Rob

Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. ExtremelyAngryUser 8/27/12 2:28 PM
"But it probably does cut a significant volume of email, that people probably don't miss, else it would be a hot issue."

It sure will cut out a significant volume of e-mail, because as the knowledge of what Google has done spreads (keep doing a - Ha! - Google search for "Multiple destination domains per transaction is unsupported") more and more people affected by this are accepting the advice that we have been giving out members - complain to their ISP that the latter's contract with Google to provide that ISP's mail service is not being fulfilled because of this issue, and then if the ISP doesn't respond that they will take it up with Google as a contractual issue, move to another ISP that doesn't use Google's mail services for their domain(s).

Since posting my previous list of affected ISPs (see post dated 5 August), I've discovered that the broadband service provided by the (UK) Post Office, i.e. the domain mypostoffice.co.uk, is also provided with mail services by Google, and is therefore affected.  That will be a huge number of older people who will switch rather than try to understand the problem that Google has created.

Allen, I admire your optimism, but do you really think that whoever is responsible for this is going to back down?  Google seems to be claiming that this is an anti-spam measure, but clearly that is a rearguard action to try to save face over what is becoming a huge issue. We "only" have around 1,100 members on our list, and we are affected... you will see that a model railway enthusiast club is also reporting that they are affected, and I think they only have a few hundred members.

I wouldn't be surprised if Google starts to "tinker" with its own search engine to try to remove reference to this problem, as the hits seem to be growing daily as people wonder what is happening to their e-mails.

I will bet a reasonable sum that Google will try to ignore this and I also bet that it will blow up in their faces sometime soon.   "The Register" hasn't reported the story yet, but when it does...
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 8/28/12 8:36 AM
I have some feedback from the Google Advisor assisting with the issue.

"This is a known issue and is being evaluated by our engineers."

I expect we'll get some more details in due course, but I'm not in a position to make promises. :)

Rob


Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. tnaindustry 8/28/12 9:39 AM
Rob,  Thanks for the update.  I have passed this thread on to the schools that seem to be affected so the tech people out there (usually a teacher doing double or triple duty) can follow it if they want.
 
ExtremelyAngryUser, I do believe that this will get corrected eventually. Many have already put work arounds in place like I have.  But they will eventually resolve the issue.  Are they trying to save face, sure they are.  But that is human nature.  We work on lots of projects with multiple vendors and it is always the other guys fault until we prove it isn't.  So I try to just provide the information and let the vendors fix the issues. 
subhunt 9/6/12 11:34 PM <This message has been deleted.>
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. subhunt 9/6/12 11:36 PM
Dear Rob,

I send out a monthly email newsletter to 650 subscribers (sent bcc from an earthlink web-hosted email address; 7 separate emails to app. 90 subscribers each). 160 of the subscribers have @gmail.com addresses.

Both last month's and this month's newsletters were returned for 37 of the @gmail.com addresses, with the ever popular "<<< 451-4.3.0 Multiple destination domains per transaction is unsupported. Please <<< 451 4.3.0 try again. g4si3853746vdv.65". It was the same 37 addresses both times. I know the addresses are valid, since I correspond with many of them regularly. I did a search and found this forum.

This is beyond frustrating
. I am not a computer techie, and will not be performing workarounds involving SMTP. I do this as a volunteer for a small non-profit. My only recourse appears to be to send the newsletter individually to those 37 subscribers. That is crazy.

Please pass this on to your engineers. They need to fix this NOW. There must be some way to prevent spam without punishing the folks who are using this service legitimately.

Thank you.

Susan
subhunt 9/6/12 11:47 PM <This message has been deleted.>
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 9/7/12 1:22 AM
Hi Susan,

Thanks for your report and feedback.

FYI I'm not formally associated with Google, I just participate in the Top contributor program that assist Google in helping users in the these product forums use their products. My comments are my own and I don't speak for Google.

I have reached out to the contacts at Google to report the issue I and can say they're aware of the issue. The Google Advisor who I've liaised with, have forwarded on the issues raised here with the responsible staff/department.

The fact that it's not been addressed so far, indicates that it's not a trivial issue to solve or has implications in doing so. Gmail and Google Apps Mail is a massive platform and it's used by some very big companies and institutions world wide. It's reasonable to expect that Google approaches such changes with caution as, a simple policy change could potentially open up huge floods of spam affecting a much wider audience than this thread. Don't get me wrong...I'm not saying the issue (AFAIK) is unimportant to Google, just that there are probably significant factors for implementing this non RFC standard policy and why it can't be just switched off.

It's unlikely Google will offer much commentary about this issue, as they've traditionally not spoken about anything that fringes on spam prevention/techniques/policies, for obvious reasons. That said I would expect some response confirming it is/will be addressed in the near future. If I get any feedback I will be sure to post an update ASAP.

I'll ping the advisor again, in hope to get an update etc.

Regards
Rob
 
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. alien_intel 11/2/12 5:34 AM
This is still happening (Nov/2012).

Setup:

Fred and Wilma host mail at domain1.com using Google Apps for Business, while Barney and Betty host mail at domain2.com also using Google Apps.

Test cases:

  1. We can email To: "fr...@domain1.com, wi...@domain1.com" no problem;
  2. We can also email To: "bar...@domain2.com, be...@domain2.com" with no problem; however
  3. If we email To: "fr...@domain1.com, bar...@domain2.com" then the 'barney' email is rejected with the message "Multiple destination domains per transaction is unsupported".  The 'fred' email gets through.  If we reverse the order then only the 'barney' email gets through.

The domains in question have identical MX configuration:

IN        MX        10 aspmx.l.google.com.
IN        MX        20 alt1.aspmx.l.google.com.
IN        MX        20 alt2.aspmx.l.google.com.
IN        MX        30 aspmx2.googlemail.com.
IN        MX        30 aspmx3.googlemail.com.
IN        MX        30 aspmx4.googlemail.com.
IN        MX        30 aspmx5.googlemail.com.
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. Rob. 11/2/12 4:56 PM
Thanks or following up. I've not had a report back from the Google rep, but will follow up with them.

Rob

Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. jlee 12/3/12 5:16 AM
 I can reproduce this message by trying to send both @blueyonder.co.uk and @virgin.net an email using the same session. If I telnet to aspmx.l.google.com port 25 and run:

(the bold lines are SMTP commands that I ran, the rest is the Google server response)

220 mx.google.com ESMTP fs7si10266939qab.108
250-mx.google.com at your service, [69.65.108.211]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES
250 2.1.0 OK fs7si10266939qab.108
250 2.1.5 OK fs7si10266939qab.108
451-4.3.0 Multiple destination domains per transaction is unsupported.  Please
451 4.3.0 try again. fs7si10266939qab.108

Both blueyonder.co.uk and virgin.net have aspmx.l.google.com as their primary MX record. What's happening here is that when the same message is sent to multiple users across domains but those users both use Google Apps, some mail servers try to "be clever" and save traffic by sending the message to both users in one SMTP session.

The problem with this is the new delivery manager content filters. A receiving mail server has the chance to reject (5xx response), delay (4xx response) or accept (2xx response) each and every recipient of a message when the sending server mentions the recipient (rcpt to). The mail server has another chance to reject, delay or accept the entire message after the message body has been transmitted in full. However, for that last chance, the accept, reject or delay applies to all recipients. There's no way for the receiving mail server to accept the message for some recipients but reject it for others after the message body has been sent. This is a limitation of the SMTP protocol itself.

Google's delivery manager content filters allow admins to reject messages based on their content. So you could create a content filtre in blueyonder.co.uk that says any messages with the word "poop" in the subject or body should be rejected. Now because the filter is based on the content of the message, the receiving server has to wait until it's received the message and performed the filter scan to decide if the filter should allow the message or reject it with a 5xx response.

But what if Google had allowed me to specify both @blueyonder.co.uk and @virgin.net as recipients of the message in the same session? Then it would have a real issue with the filter. Because the content filter rules for blueyonder.co.uk say reject that message with the word poop in it but the virgin.net Google Apps instance has no such content filter and the message should be accepted. Remember, the receiving server can only accept, delay or reject the message for all recipients after the body is sent.

So what should happen here? Instead of trying to lump the message together in one SMTP session for @blueyonder.co.uk and @virgin.net addresses, the sending server should make separate SMTP connections per-domain (but not necessarily per-user). This gives the receiving SMTP server the chance to reject the message to @blueyonder.co.uk based on content but accept it for @virgin.net all on the first try (at the expense of some extra bandwidth)..

Google's 4xx delay response for the @virgin.net address should cause something similar to happen even for servers that are trying to be clever and lumping the two together in one session. The sending server should see that the blueyonder.co.uk address at least was accepted, continue with the message body and get it's ultimate 2xx accept or 5xx reject message back from the receiving server. For the @virgin.net address, the sending server should backoff for a few minutes, then retry sending the message to just those addresses that failed. On each retry, at least one domain's worth of users should succeed in getting the messgae through. However, the sending servers may not be retrying the message like they should (failing to soon) which is causing either very large delays or ultimate failure of the delivery.

I'm not certain if the sending servers are out of RFC compliance, but Google's response is definitely acceptable under RFC. The sending servers just need to learn to deal with it properly. I am continuing to research this but in the mean time. What sending SMTP servers are you guys using?

Jay
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. ExtremelyAngryUser 12/3/12 7:33 PM
some mail servers try to "be clever" and save traffic by sending the message to both users in one SMTP session.

No, this isn't "trying to be clever", this is perfectly valid behaviour.  Mail for any domain is delivered to an SMTP server specified in the MX record for that domain, and the number of recipients is limited only by MAX_RCPT, which RFC 821 says should be a minimum of 100, although it will be no surprise for anyone to know that Microsoft ignores this in the same way as it ignores most international standards, so the MAX_RCPT has to be set lower for mail sent to any of the poor wretches using Microsoft mail services.


The problem with this is the new delivery manager content filters.

Well, I'm glad that at least someone with any responsibility for Google mail has finally, after over 6 months of growing numbers of complaints for those affected by the problem, has now admitted that it is Google's fault and that the problem has indeed been caused by their mail transport agents.


I'm not certain if the sending servers are out of RFC compliance, but Google's response is definitely acceptable under RFC.

I'm pretty certain that they are not, and you haven't given a single reason or any evidence whatsoever to support even the remote possibility or suspicion that they are.  So, given that SMTP mail has managed to get along pretty well until Google decided to introduce "the new delivery manager content filters", irrespective of whether or not Google's response is, or is not, acceptable under RFC, the rest of the known world is still working on the very clear evidence that Google's mail servers are now broken by these changes.  Reminder - mail is still flowing around the world, but more and more Google-hosted customers are waking up to the fact that some of their mail hasn't been arriving for over six months because Google insists on identical MX records for all of the domains used by its customers, despite the fact that it knows this causes high levels of message delivery failures. 

The sending servers just need to learn to deal with it properly.

Sure... everyone is RFC-compliant, but Google's new filters, and its insistence on handling all mail on the same servers regardless of the problems that this is causing, mean that everyone else in the world has to make changes to deal with it.

Yeah, right.

Dear Google, the world has been managing to deal with multiple domains on mail servers for quite a long while now, and the fact that you can't is highly amusing, as it represents tangible evidence that you need better-trained technical support.  But this is where I came in, because six months ago I explained on one of these threads that this is precisely what the rest of the world will NOT do, and a good couple of dozen or so of the affected members of our opt-in mailing list (to whom we have explained why their receipt of e-mail has become intermittent) have provided details of their new, non-Yahoo managed, e-mail addresses.  To the users, it's simple - if Google-hosted mail services are broken, find a different service that isn't Google-hosted.  And these users talk to each other.

Small numbers to you, maybe, but that represents about 15% of the total number of our members using affected domains, a list of which is on our site, and if the owners of those domains who are paying you to provide mail services are happy to lose that proportion of their customers, or even more, as a direct consequence of what you have done, then I congratulate you on your ability to retain revenue streams. But somehow, I don't think they are going to be very happy at all... the problem still exists, and their customers' mail is still being rejected because of this issue.

The ball is still in your court, and I suggest that you monitor the Google searches - now, when one searches for "Multiple destination domains per transaction is unsupported", Google suggests "multiple destination domains per transaction is unsupported gmail".

I think it is trying to tell you something!
Re: MX Server issue: 4.3.0 - Multiple destination domains per transaction is unsupported. ExtremelyAngryUser 12/3/12 7:38 PM
... have provided details of their new, non-Yahoo managed, e-mail addresses...

This was, of course, a simple typo by me, but in fact it is technically true... it means "e-mail addresses that are not managed by Yahoos"!

ya - hoo (noun) - an uncultivated or boorish person; lout; philistine; yokel.
More topics »