The SMTP protocol

SMTP (Simple Mail Transport Protocol) is the heart of what makes email work. Other protocols for reading email such as POP3 and IMAP represent a session between a client and a server - simple enough. But sending an email can mean a complicated path is taken in message delivery.

In addition to that, any one of the servers along the destination path may be temporarily unavailable, and the protocol must account for this.

Numerous DNS lookups are required for even the most simple paths from source server to destination server. Problematic or misbehaving DNS servers can wreak havoc on  an SMTP server, causing queues to back up.

As opposed to POP3 and IMAP for reading, SMTP must be implemented properly on a global level so that all servers involved speak the same 'language', if you will. To further complicate things, parts of the definition of the SMTP protocol (RFC822) are extremely vague in language leaving many things open to interpretation. RFC822 makes for good bedtime reading making it difficult to read and fully understand it's many finer points.

But these fine points are the problem of those who must implement the protocol, and there are plenty good implementations available for purchase and as open source for any software developer to use.

One of the important points to understand about SMTP is that is a store and forward protocol. Meaning that an email on its path to deliver can make many stops and hops along its way, from server to server until final delivery. Each one of these intermediate SMTP servers, including the originating server, receive, store, and then forward the message on to its next hop, or final delivery.

In the event that the next server in the delivery path is unavailable, the sending server will continue to store the message and retry delivery at a specified interval for a specified period of time. It can also look for other servers to deliver to by looking up secondary or tertiary MX records.

Should time exceed what is specified, the sender will be notified that delivery failed so email is not lost without the sender knowing about it.

In troubleshooting issues with send email, a manual SMTP session using telnet is most helpful. After looking up the primary MX record for your domain you know how to start your telnet session. Following previous examples, lets say that an MX lookup reveals that the SMTP server for browncow.com is named mail.browncow.com

The following is a fictitious manual SMTP session. The < character shows what you would type. and the > characters shows what the SMTP server might reply (which is probably different from what you see below). Your telnet session might not echo what you type so you need to be extra careful about typos. Backspace cannot be used to correct a typed.

< telnet mail.browncow.com 25
> 220 mail.browncow.com EMPTS Postfix

Just having made the connection and gotten a reply is enough to help troubleshoot most elementary problems with sending email. Other things you can do is test that the server does not allow simple relay.

< helo somespammer.com
> 250 browncow.com
< mail from: joe@somespammer.com

Here we started a session with the mail server hosting browncow.com We told it we want to send mail from joe@somespammer.com and we want to send it to fred@spam-recipient.com

This is a relay since the browncow.com server is not hosting the spam-recipient.com domain. Here, we correctly saw the server deny our relay attempt.

In the event that your server responds 250 to a relay request you might want to look at your configuration. But just because you get a 250 at this point does not automatically mean that the server is allowing relay. The request might get denied later on in the session.