up vote 2 down vote favorite
share [g+] share [fb]

As far as I can tell, this question doesn't already exist here but if it does then I apologize.

As of January 1st our company name has changed and, as such, our e-mail addresses have changed. The switch has gone off well with the exception of a few weird "5.1.1 User Unknown" errors that some external senders are getting when they attempt to send e-mails to us.

I've spoken to an external consultant to get their take on it and they seem to think the recipients have stale DNS records. The MX records to our server has existed on our external DNS for over a month - the new domain was set as our "Primary" domain on January 1st.

I've managed to get a couple of the error reports from the recipients and they look like this. Any help would be appreciated with this matter

The following recipient(s) cannot be reached:
      'User Name' on 13/01/2012 11:07 AM
            550 5.1.1 <user@new-domain.com>... User unknown

EDIT : The domain listed above is the "new domain". E-mails sent to the old domain still send without issue. I can also verify that the policy has been set to that user and that the new e-mail address exists within their "E-Mail Addresses" tab.

EDIT 2 : The receiving mail server is running VamSoft ORF for anti-spam. Neither Vamsoft ORF logs or exchange logs show any sign of the e-mails getting to our domain, however when they use the old domain they go through without issue.

link|improve this question
83% accept rate
Is the email address listed in the error in the old domain or the new one? Can you verify that the recipient policy applied to that user correctly, and that the listed address is in the email addresses tab for that account? – Shane Madden Jan 13 at 16:30
Good questions Shane. I have edited the answer to reflect your questions. – DKNUCKLES Jan 13 at 16:46
Do you use a spam filter in front of Exchange, like Appriver or Postini? – joeqwerty Jan 13 at 17:22
can you name your domain-name? – Lazy Badger Jan 14 at 5:26
feedback

2 Answers

up vote 3 down vote

The key to troubleshooting this one is going to be getting somebody to look at the logs on the outgoing SMTP transaction at the sender's server. You can try to correlate their failures with your own message tracking logs, SMTP protocol logs, or traffic sniffing, but the best data is going to come from the sender's own SMTP server. If the sender has an IT staff I'd recommend working to get in touch with them. If they don't, then try to get the sender to provide you with the non-delivery reports complete with full transport headers.

You need to know what SMTP server the sender is actually trying to perform delivery to and, from there, you should be able to track down the source of the problem. If they're talking to a server you control then you should be able to get a log of the SMTP conversation, possibly all the way down to a traffic sniff. If they're not talking to a server you own then you need to figure out why they aren't (i.e. stale DNS cache).

DNS lookups cached for wholly inappropriate times aren't completely unheard of, but they're not common either. If you know who the sender is using for an upstream DNS server you might try doing some lookups for MX records for your domain against that DNS server to see what you get back.

link|improve this answer
"best data is going to come from the sender's own SMTP server" - no! Sender see bounce-message only, OP must check local delivery path – Lazy Badger Jan 14 at 3:43
It doesn't sound, to me, like the poster is sure that the mail is even getting to his server. Ignoring valuable details in the bounce message (like what SMTP server it was actually trying to deliver to) seems like a bad plan. – Evan Anderson Jan 14 at 4:52
sorry, some addresses are bounced. Well, check MX from failed sender-part may have some sense, we'll can see (strictly theoreticaly) "All mails for domain in question routed to bad destination from this net". But on recipient's side it interceptable more fast and easy, anyway – Lazy Badger Jan 14 at 5:06
It may not be interceptible on the receiver's side at all if a stale MX record is sending the mail to an SMTP server the receiver doesn't control. Given that only some senders are having problems it seems possible that the sender's servers aren't even talking to the recipients correct MX's. – Evan Anderson Jan 14 at 5:12
agree in common, but "only some senders are having problems" is unconfirmed hypothesis, sorry, and arbitrary interpretation of known facts "few weird "5.1.1 User Unknown" errors that some external senders are getting" - and we must detect, yes, what it means in reality. Mea culpa, it may be "some senders for anybody", not some recipients" – Lazy Badger Jan 14 at 5:19
show 2 more comments
feedback
up vote 2 down vote

I've spoken to an external consultant to get their take on it and they seem to think the recipients have stale DNS records

Send this "consultant" to ass! He generates illiterate nonsense! I SMTP-session installed with correct collector (assigned as MX for domain and domain handled on server) and only some e-mails doesn't map to existing destination problem is your local rewiting rules|MDA in Exchange or (probably existing) border-MTA - can't say more without exploration in deep delivery-path for your mail-subsystem.

Sadly, I know nothing about Exchange's MTA (except well-known in postmaster's world denominator "Bullshit!"), but, as long-time postmaster, can see:

  • you have to identify, which your server really generates bounce (in case of chained processing "border - internal")
  • better will be to find all e-mails (local users), which incoming mail are bounced
  • debug (monitor) incoming SNTP-sessions for such users in real-time (if trouble-generator have ability to debug) OR compare "bad" and "good" users and search difference in definitions

Added after discussion with Evan

You have to idenify, that undelivered mail is your problem on your server. Ask any owner of bounce-mail forward ("MIME-forward", with full original message as attachment) responce to you and check headers of bounce (Received) in order to confirm (or reject) involvement of your MTA as bouncer

From my side I can offer (some amount of) my time, attention, mind, hands and my smtp-emitter for test-runs of incoming SMTP

link|improve this answer
Thank you for your assistance Lazy Badger. I am working on getting SMTP logs from the sending server. In the meantime the domain in question is hscorp.ca – DKNUCKLES Jan 16 at 16:57
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.