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 xyz.xx.xx.xyz...
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 xyz.xx.xx.xyz...
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).

Got something to add? Send me email.

3 comments

Fri Aug 21 20:23:53 2009: 6779   MikeHostetler


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: 6780   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: 6781   TonyLawrence


(broken oceanic cable, that is)

------------------------

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us