We are now ready to submit the email content. The server is alerted of this through the DATA command.
The server responds showing it is now waiting for the email content. All the text entered at the console will add up to it. This goes on until a special character sequence is entered:
<CRLF>.<CRLF>
<CRLF> stands for carriage return line feed. This is what you get when hitting the Enter key. Thus the end of data marker is simply a line containing only a period.
The content of a simple SMTP email is composed of a bunch of headers followed by the body text. This is covered in the RFC 2822 specifications. More complex content including attachments and an HTML body are typically submitted with the help of MIME encoding. The MIME specifications are covered by yet another set of RFCs. However this is again beyond our scope. So we just limit ourselves to the most popular email headers (From, To, Subject) and a simple text body:
From: Sender <sender@exchangeinbox.com>
To: <rcp@adminstop.com>, <rcp2@adminstop.com>
Subject: Telnet Port 25
This is a test email
bye
Alex
.
Headers start with a name immediately followed by a colon. Note the empty line following the subject header. This indicates the beginning of the body text. If missing, Exchange will normally still be able to identify the correct body start position. Also note the final period indicating the end of content data.
When performing a simple test, we don't really need to remember any syntax rules for the email body. We could have easily just entered:
This is a test email
.
Exchange will still be able to deliver this. Just be ready to seem some "less than perfect" emails at the recipient mailbox.
On detecting the end of data sequence the SMTP server queues the email for delivery. We could now submit another email starting straight from the MAIL command. When ready the QUIT command closes the connection.
This completes submitting an email in a scenario where everything is plain sailing. However, as we shall see in an upcoming article, things get more interesting when testing an email rejection or when verifying our Exchange configuration.
MAIL FROM, RCPT TO and Email Headers
From this discussion we have the opportunity to highlight an important point that tends to confuse some email administrators. In this SMTP session we specified the sender address twice, first at the MAIL command and next at the From content header. The same goes for recipient addresses. We had the same addresses on submitting RCPT TO and the To content header.
An SMTP server is only concerned with addressing information delivered through MAIL and RCPT protocol commands. It does not interpret any addressing information within content headers. Headers are what email clients see and display at their interface.
Indeed the email headers could contain anything. Legitimate email sources will typically provide consistent addressing data. However spammers often jumble these in all manners. What has to be valid are the recipient addresses specified by the RCPT protocol commands since these determine the destination mailboxes. This means that what email clients show may be completely unrelated to what an SMTP server operates on.
Final Tips
Today we looked at the basics of SMTP and used telnet to submit an email. We focused on the bare essentials that are most important in everyday use. For a thorough understanding of SMTP it is best to check RFC2821. Watch out for an upcoming article that will use telnet to test various Exchange 2003 features.
Reference
RFC 2821 - Simple Mail Transfer Protocol
RFC 2822 - Internet Message Format