Troubleshooting failed email

You send email to someone at joe-blow@somedomain.com and get something back about "The following addresses had transient non-fatal errors" or "The following addresses had permanent fatal errors". What now?

If it's the "transient" message and the address is correct (check your spelling!), you just need to wait. Your mail server will try to deliver the message again and if it gets through, there's no problem (other than your email being late). If it doesn't get through after 5 days (your mailserver may have a different idea of when to give up trying, but most try for 5 days), you'll get the "permanent fatal errors" message.

Now it's time to figure out why.

I assume you already checked that "joe-blow" really is the user name. If it is not, the "somedomain.com" mailserver should have told you that, but let's just confirm that. Here I'll check manually:

$ telnet mail.somedomain.com 25
Trying xxx.xx.xx.xxx...
Connected to mail.somedomain.com.
Escape character is '^]'.
220 mail ESMTP ready
helo aplawrence.com
250 mail
mail from: tony@aplawrence.com
250 2.1.0 Sender <tony@aplawrence.com> ok
rcpt to: joe-blow@somedomain.com
550 5.1.1 Mailbox <joe-blow@somedomain.com> does not exist
quit
221 2.0.0 SMTP closing connection
Connection closed by foreign host.

The things I typed are in bold. This manual conversation says that "joe-blow" doesn't exist.

There could have been other problems. The mailserver might not have liked my "helo" or might have found my IP on a blacklist. If that were the case, it should tell me during this session, but it might just disconnect without telling me anything. That could be true if I didn't wait for the "220 mail ESMTP ready" message - that server would have just terminated:

$ telnet mail.somedomain.com 25
Trying xxx.xx.xx.xxx...
Connected to mail.somedomain.com.
Escape character is '^]'.
helo aplawrence.com
Connection closed by foreign host.
 

But that shouldn't happen when your mail client sends mail (if it does, you have a broken mail client).

Let's back up a minute. Why did I pick "mail.somedomain.com"?

I looked it up. I did this:

$ dig somedomain.com mx

; <<>> DiG 9.4.3-P3 <<>> somedomain.com mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43251
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;somedomain.com.			IN	MX

;; ANSWER SECTION:
somedomain.com.		3600	IN	MX	0 mail.somedomain.com.

;; Query time: 42 msec
;; SERVER: 192.168.11.1#53(192.168.11.1)
;; WHEN: Fri Aug 21 11:35:22 2009
;; MSG SIZE  rcvd: 53
 

That tells me that the "Mail Exchange" for the domain is "mail.somedomain.com" (note that the actual "somedomain.com" returns something different; I'm just using this as an example). That's where I need to telnet.

But "dig" might not be helpful:

$ dig rdeitxq.com mx

; <<>> DiG 9.4.3-P3 <<>> rdeitxq.com mx
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30321
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;rdeitxq.com.			IN	MX

;; AUTHORITY SECTION:
com.			900	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 1250869172 1800 900 604800 86400

;; Query time: 56 msec
;; SERVER: 192.168.11.1#53(192.168.11.1)
;; WHEN: Fri Aug 21 11:39:54 2009
;; MSG SIZE  rcvd: 102
 

I got no "Answer" section for that. I could also get "No name servers could be reached", which might mean that the name server responsible for somedomain.com is down right now. But it could also mean that that our local DNS server is confused about somedomain.com or that some router between us and that is malfunctioning or dead. Fortunately, you can ask "dig" to look elsewhere:

$ dig @208.67.222.222 aplawrence.com

; <<>> DiG 9.4.3-P3 <<>> @208.67.222.222 aplawrence.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58351
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;aplawrence.com.			IN	A

;; ANSWER SECTION:
aplawrence.com.		5521	IN	A	64.226.42.29

;; Query time: 16 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Fri Aug 21 11:47:29 2009
;; MSG SIZE  rcvd: 48
 

I picked that 208.67.222.222 address from What are Public DNS Servers? at TechFaq, but many servers will happily respond to DNS inquiries. Just because YOUR DNS can't find another server doesn't mean someone else's cannot unless it really is down. Another server may just happen to have the information cached even if the server is down!

Once you know where the MX is, you can try to telnet to it on port 25. If it can't resolve to an ip, try "dig mail.somedomain.com" at some other DNS server and use the ip address instead - the whole issue may be just a DNS problem, and if it is, you can deliver a message manually if it's that important (see How do I test a smtp connection?).

If you can't telnet out on port 25 (your ISP may block that), try 465 or 587. One of those may be configured for Secure SMTP. That's going to be a little harder to test manually (other than just verifying that you can connect). See examples of doing that at Postfix SMTP Authentication (skip the parts about setting this up and jump to the testing section).

3 comments

More Articles by Anthony Lawrence - Find me on Google+

Click here to add your comments




Fri Aug 21 20:23:53 2009:   MikeHostetler
http://www.squarepegsystems.com

This is very serendipitous that you posted this today, since I moved providers yesterday and my mail records got screwed up.

My favorite usage is /usr/bin/sendmail -v <email address>. If you are (God help you ) using sendmail it will show you the connection to the mail server and everything. If you are using Postfix and perhaps Qmail, it will mail you the connection results. I have found this to be incrediably powerful in troubleshooting email problems.





Fri Aug 21 20:42:03 2009:   TonyLawrence


If you can believe it, today I had to use mmdf.

I had to fix a wrong IP in the smtp.chn file and do a dbmbuild. I then watched it deliver the mail with /usr/mmdf/bin/deliver -cbadhosts -w

But I wrote this up because another customer was having trouble with a yahoo.com.cn address. Turned out to be a broken cable, but this article shows the steps we went through.







Fri Aug 21 20:43:53 2009:   TonyLawrence


(broken oceanic cable, that is)

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.