Dealing with bounced or non delivery of SMTP mail

[LEFT][CODE]http://www.thecodefish.com/Servers/Dealing_with_bounced_or_non_delivery_of_SMTP_mail[/CODE]
I often speak to people who are having intermittent trouble getting SMTP mail delivered, so I thought I'd put together a short list of things to check.
[B]Why is my mail rejected?[/B]

It's worth thinking about the types of problems. As an email user you might just assume that the problem is with your own mail server (IT's problem!), but that isn't always the case.
The problems can occur in a number of places. Problem solving should be done an a logical fashion, eliminating things one at a time.
So lets think about the process your email goes through.
[B]A Typical Email Send Process[/B]


[LIST][*]First you open your email program, type your message and enter a recipient address. You hit send and the message goes to your outbox.[*]So the next thing that might happen is your anti virus jumps in and checks the message.[*]Your email client connects to the mail server and tries to authenticate[*]Your SMTP server picks up the message, checks your send quota and the size of the message together with the attachments to see if you're allowed to send them.[*]Assuming all is well, now the message is moved to the server output queue, the server strips off the external domain name from the recipient address[*]The server performs an MX lookup against the recipient domain to identify the name of the recipient mail server[*]Assuming there is one, the server now does another DNS query to lookup the IP address of the recipient mail server[*]The mail server now attempts to connect to the recipient mail server by performing a telnet to port 25[*]The recipient server may now check the sending server or issue a wait command (known as greylisting) asking them to call back later[*]Recipient performs a reverse DNS lookup of the IP/hostname combination of the sending server to check they match[*]Recipient server checks a DNS blacklist to make sure the sending server isn't on the list[*]Recipient server checks that the SPF record (see [URL="http://http//www.openspf.org"]www.openspf.org[/URL] for more info) allows the sending server to relay mail for the sender domain[*]Recipient server receives the message and performs an anti virus check[*]Recipient server performs a spam check by passing the message through a message filter[*]Recipient server checks that the recipient mail user is allowed to recieve the message/has enough space/has not exceeded quota[*]The message is now transferred to the recipient mailbox[*]Recipient email program connects to the mail server and tries to authenticate[*]The message is transferred to the recipient email program[*]The message passes through some user defined rules[*]The message passes through the junk mail filter[*]Finally the message is delivered to the Inbox[/LIST]
As you can see there are a lot of steps and I've simplified the process. You also might like to throw a remote VPN connection into the mix, some SSL certificates on the client, maybe an external spam filtering relay.
Potentially any one of the steps could be the source of the problem.
[B]Troubleshooting[/B]

So where to start. Work through each area, logically.
The most common error is caused by the user - did they type the address in correctly? Did they leave out the message subject - some mail admins don't like this and reject messages with no subject.
Do you get an NDR (non delivery report) at the sender? Check the error - Google is a great help as is the manufacturer website, but don't forget that SMTP mail is governed by some internet standards so many of the errors are standardised too. (For Exchange users we have a list here [URL="http://www.thecodefish.com/Servers/Exchange_Server_And_Outlook_NDR_Error_Codes"]The Code Fish - Servers / .Net Development, SQL, Virtualization & Server Tutorials[/URL])
You don't always have to check your mail server documentation, a general search on Google for "NDR errors" will help.
Try disabling your antivirus or local firewall for a few seconds.
If several users are having problems, is your server still running? Has the firewall blocked traffic or is it blacklisted. Check the mail services blacklists, somewhere like [URL="http://www.spamcop.net/"]http://www.spamcop.net[/URL] or [URL="http://www.spamhaus.org/"]The Spamhaus Project[/URL] to make sure your server isn't listed. If you are, check why and resolve the problem before requesting removal or it may take longer to get removed. Don't try strongarm tactics with these organisations, they're there for everyone's benefit and they don't respond to threats! Think about why you've been listed in the first place. Do you have an open relay or proxy server? Are you sending out mailshots from your own server - consider using a separate server or an external company for bulk email.
Trying pinging the remote server or a telnet to port 25 - eg. telnet mailhostname.recipientdomain.com 25
Is it just one domain or is your server periodically having problems with a few domains but not others. Often this is a Reverse DNS issue. You should have a PTR record created by your ISP that matches the hostname of your mail server to the public IP address that it sends out mail on. Don't get confused with your own DNS configuration, that's a different thing. Just speak to your ISP, so long as you have a static IP address you can get them to create a PTR record for your IP address.
Is your own SPF record correct?
If the user is remote, is their VPN/RAS/Outlook anywhere configured correctly? Did you change anything? Is the server certificate still valid or has it expired?
Is the recipient mail server configured correctly. You may be surprised to find out how many are not. Use some of our mail tools [URL="http://www.thecodefish.com/Utilities"]The Code Fish - Utilities / .Net Development, SQL, Virtualization & Server Tutorials[/URL] or one of the automated tests online somewhere like [URL="http://www.mxtoolbox.com/"]MX Lookup Tool - Check your DNS MX Records online - MxToolbox[/URL]
Ask the recipient to check their own spam filters, or to check with their administator on limitations on message size or attachment types.
I hope this might help you through the troubleshooting process. It's really not rocket science, but it helps to understand the process a bit!
Good luck
[/LEFT]