Christopher
Verified User
- Joined
- Mar 28, 2008
- Messages
- 7
I was grepping some old logs earlier to figure out why emails from someone (who'd said they'd emailed multiple times) hadn't come through.
Not solved that one yet (have a feeling they were sending to the wrong address) but I did notice a slightly worrying 430 "multiple destination domains per transaction" error from GMail's servers when we've sent emails to that person and they've been one of several CCed recipients... So, I thought I'd ask the resident guru.
For most servers handling incoming mail this doesn't seem to be as much of an issue (or is just a silent one). However unfortunately GMail seems to take issue, as described by Lee in this Debian Admin blog entry:
Lee goes on to identify the variable
and suggests the change of transport and even provides some sample code for exim's conf. It does seem to need some further additional creation of a list to hold MX records for the "single domain mx" part of his new transport option.
Whilst I can transliterate those instructions to apply to the conf, it might be useful to highlight this potential scenario which seems to occur based on personal preferences whilst setting up exim -- and maybe include this fix, or something similar in the next spamblocker conf?
I'm loathe to just throw this code in without being able to fully appreciate the consequences and dependencies you've already coded into spamblocker conf and the fact it would then have an external dependency to properly detect servers matching the conditions in the transport). I'll gladly put up with the vastly reduced spam and more retries for now. I wonder though, is there anything realistically that can be done to workaround?
Not solved that one yet (have a feeling they were sending to the wrong address) but I did notice a slightly worrying 430 "multiple destination domains per transaction" error from GMail's servers when we've sent emails to that person and they've been one of several CCed recipients... So, I thought I'd ask the resident guru.
For most servers handling incoming mail this doesn't seem to be as much of an issue (or is just a silent one). However unfortunately GMail seems to take issue, as described by Lee in this Debian Admin blog entry:
If you attempt to send an email to multiple addresses that are handled by google's email servers, but that have multiple domains, only the mail for one of the domains will be accepted.
All the other addresses will receive a temporary rejection message:
Code:451-4.3.0 Multiple destination domains per transaction is unsupported. Please 451 4.3.0 try again. random.string
What happens next is up to the logic of the server sending the mail. It'll try sending the messages to the next in the MX priority list - which for google-handled domains are going to be the same. And again, all but one of the delivery domains will get rejected.
I've yet to see a mail bounce as a result of this, but for mails with many different domains I've seen deliveries hit their retry limits and hang around on the mail queue for over an hour. Sub-optimal. A web-search for "Multiple destination domains per transaction is unsupported" will likely locate a few annoyed mail-admins.
Lee goes on to identify the variable
Code:
multi_domain
Whilst I can transliterate those instructions to apply to the conf, it might be useful to highlight this potential scenario which seems to occur based on personal preferences whilst setting up exim -- and maybe include this fix, or something similar in the next spamblocker conf?
I'm loathe to just throw this code in without being able to fully appreciate the consequences and dependencies you've already coded into spamblocker conf and the fact it would then have an external dependency to properly detect servers matching the conditions in the transport). I'll gladly put up with the vastly reduced spam and more retries for now. I wonder though, is there anything realistically that can be done to workaround?