Troubleshooting the simple stuff

I was talking with one of my Barry pals recently and was treated to a rant regarding deliverability experts that can’t manage simple things. We’ve been having an ongoing conversation recently about the utterly stupid and annoying questions some senders ask. Last week, I was ranting about a delivery person asking what “5.7.1. Too many receipts this session” meant. This morning I got an IM.

Barry: I see your “too many recipients” and raise you a “DNS failure.”

Me: You’re joking.

Barry: “Unknown address error (‘550’, [‘REQUESTED ACTION NOT TAKEN: DNS FAILURE’])

Me: That seems pretty self explanatory. I would close the ticket with a “not a mail issue.”

Barry: It wasn’t a ticket. It was a direct mail to me by a very well known person on the sender side. You’d die if you knew who it was. But he didn’t send me anything useful, not even an IP address.

Me: You’re kidding? Please tell me you’re kidding. Please.

This is yet another example of people bothering Barry with questions that should be answerable by anyone who holds themselves up as a delivery expert. Really.
Barry is not your free consultant. Barry has a job and it does not involve troubleshooting problems on your end. Asking questions about stupid stuff like “too many recipients this session” or “DNS failure” is why most Barry’s don’t hand out their info to senders. They don’t want to be bothered with questions just because the sender is too stupid or lazy to do their own troubleshooting.
There are two things that come to mind immediately when I see this error message and two things that I would check before even considering contacting someone.

  1. This is an internal DNS failure and the MX lookup on the sender’s side failed. The sender should do a manual DNS lookup and confirm they can get a MX record (or A) record for the recipient domain.
  2. This is a DNS failure on the receivers side. A little harder to troubleshoot, but some ISPs check the DNS of the sending domain before accepting mail. Make sure that the domain exists in DNS and is answering queries promptly.

Once you have checked DNS and everything is OK you can move to the next step. Open up a telnet session to the mail server and do a manual SMTP session. Use the same Mail From: and Rcpt To: that generated the 550 you’re attempting to troubleshoot. You don’t need to do the whole session, just through Mail From: and Rcpt To:.
If the Mail From and Rcpt To: addresses are accepted by the receiver mail server, then go back into your MTA and resend the message that originally failed.
It works, you’re done. If not, go back and think about what else might cause a DNS failure, then test it. Same as you did above. Repeat.
EDIT: While writing the post, I heard back from Barry. The problem was that the sending domain did not exist in DNS. This issue would have been identified at the 2nd DNS check. No mail to Barry needed.

Related Posts

AOL and DKIM

Yesterday, on an ESPC call, Mike Adkins of AOL announced upcoming changes to the AOL reputation system. As part of these changes, AOL will be checking DKIM on the inbound. Best estimates are that this will be deployed in the first half of 2009, possibly in Q1. This is something AOL has been hinting at for most of 2008.
As part of this, AOL has deployed an address where any sender can check the validity of a DKIM signature against the AOL DKIM implementation. To check a signature, send an email to any address at dkimtest.aol.com.
I have done a couple of tests, from a domain not signing with either DK or DKIM, from a domain signing with DK and from a domain signing with both DK and DKIM. In all cases, the mail is rejected by AOL. The specific rejection messages are different, however.
Unsighng domain: host dkimtest-d01.mx.aol.com[205.188.103.106] said: 554-ERROR: No DKIM header found 554 TRANSACTION FAILED (in reply to
end of DATA command)
DK signing domain: “205.188.103.106 failed after I sent the message.
Remote host said: 554-ERROR: No DKIM header found
554 TRANSACTION FAILED”
DK/DKIM signing domain: “We tried to delivery your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554-PASS: DKIM authentication verified
554 TRANSACTION FAILED (state 18).”
As you can see, in all cases mail is rejected from that address. However, when there is a valid DKIM signature, the failure message is “554-PASS.”
As I have been recommending for months now, all senders should be planning to sign with DKIM early in 2009. AOL’s announcement that they will be using DKIM signatures as part of their reputation scoring system is just one more reason to do so.

Read More

What is an email address? (part one)

Given we deal with email addresses every day, dozens or thousands or millions of them, it seems a bit strange to ask what an email address is – but given some of the problems people have with the grubbier corners of address syntax it’s actually an interesting question.
There are two real standards that define what is a valid email address and what isn’t. The most complex is RFC 5322 – Internet Message Format, which describes all sorts of things about the structure of an email, including what’s valid to put in From: and To: headers. It’s really too liberal in what it allows an email address to look like to be terribly useful, but it does provide for one very commonly used feature – the friendly from where the name that’s displayed to the recipient is not just the email address.

Read More

Comcast rate limiting

Russell from Port25 posted a comment on my earlier post about changes at Comcast.

Read More