Smtp Basics

As the S in its name suggests, SMTP is designed to be a simple protocol for delivering messages between two entities, commonly referred to as Mail Transfer Agents (MTA) and Mail User Agents (MUAs). These are just two of the recurring acronyms involved in any mail system. There are many more, and they are fairly important to know and understand, especially when dealing with and comparing different SMTP implementations. A simple example of the interactions between MTAs and MUAs can be seen in Figure 14-1, or actually, any email headers.

A message, from the SMTP point of view, consists of headers and a body. Headers are machine-parseable statements containing information of all kinds, the most basic being headers like To: for the mail recipient or Subject:. The sender address might be quickly dismissed as a basic piece of information easy to describe but you'll see that it's a more complex concept.

The body of the message contains everything else (everything other than headers) and it's not normally parsed by MTAs (although, as you'll see, parsing by MTAs might happen for filtering purposes). Usually the body of the message contains simple text, but it can also be HTML (which often annoys really technical people), and in multipart messages (i.e., messages with attachments) MIME is used. MIME stands for Multipurpose Internet Mail Extensions and it's a standard that is used for sending different character encodings other than plain ASCII and binary content; the email client automatically uses MIME when needed.

Some headers can be removed, some can be modified, and some will be added by different components in the mail-flow process. Every MTA should always add a Received header for tracking its role along the email path during transmission. In theory, by looking at the header you should always be able to track the original sender. You'll soon see why this is not always the case, however.

Every email should have a set of headers in order to be parseable by the SMTP standard, some headers that most SMTP implementations consider standard but aren't really, and some headers (X-*) that are customizable and can contain any sort of message. Think of it as a way to shift user-definable content from the body to the headers. Some of the most widely used examples are filtering applications information (X-Spam) and MUA (X-Mailer).

Subject: Re: linux security kernel chapter From: <[email protected]>

Date: 12/14/2007 7:37 PM To: [email protected] X-Account-Kev: |

X-Uidl: 221120db8ee84cl2 X-Moziila-Status: 0011 X-Mozilla-StatusZ: 00000000 Return-Path: Delivered-To: X-Envelope-To: [email protected]

Received: {gmail 10678 invoked from network); 14Dec2007 18:37:03 -0000

Received: from ( bv^^^^^^H with SI^TTP; 14Dec 2007 18:37:03 -0000

Received: from localhost (localhost []) by (Postfix) with SMTP id 62891C93B2 for>; Fri, 14Dec 2007 13:37:03 -0500 (EST) X-Vir u s- Ch eck- By: mailwash4, pair, com X- Spa rri - Ch eck-By: X-Spam-Status: No, hits=-101.4 required=5.0 tests =ALL_TRUSTED,USER_IN_VVHrTELICT autoleam=disabled version=3.00 200 3 X-Spam-Flag: NO X-Spam-Filtered: 6 34e4e 7703096dd lb 2eb4116e745b72b X-Whitelisting: sender whitelisted by rule^H

Received: from ( []) by (Postfix) with SMTP id 48827C93B0 for

<[email protected]>; Frir 14Dec 2007 13:37:03 -0500 (EST) Received: (gmail 6680 invoked by uid 0); 14Dec2007 18:37:03 -0000

Received: from unknown (HEIO^^^^^H) (unknown) by unknown with SMTP; 14Dec 2007 18:37:03 -0000 X-Pair-Autlienticated: I B Message-Id: <475 2CD4E. 90 30 505 aisecom. org > User-Agent: | Mime-Version: 1.0 B References: <476 2CS06.70 Z0608 Msecom. org > B In-RepEy-To: 1

Content-Type: text/plain; charset=ISO-8859-l; tiormat=flowed Content-Transfer-Encodinn: 7bit

It's not uncommon to spot very interesting customized headers in the wild; most emails from security consultants have weird ones!

<Verbatim listing 1> [Sample message]

From [email protected] Sat Sep 30 13:50:39 2006 Return-Path: <[email protected]>

Received: from (localhost.localdomain [])

by (8.13.8/8.13.7) with ESMTP id k8UBodHB001194 for <[email protected]>; Sat, 30 Sep 2006 13:50:39 +0200 Received: (from [email protected])

by (8.13.8/8.13.5/Submit) id k8UBoNcZ001193 for root; Sat, 30 Sep 2006 13:50:23 +0200 Date: Sat, 30 Sep 2006 13:50:23 +0200

Message-Id: <2 [email protected]> From: [email protected]

To: [email protected] Subject: foobar test

</Verbatim listing>

If you look at your raw mail, you can sometimes see an additional From followed by a space and then a sender address, without the colon seen in the usual From: header. This is an internal separator for messages defined by the mbox storage format and it's not really an SMTP header. The mbox format is part of a family of formats for storing email where the messages are stored in plain text and linked to a single file.

The Mail Delivery Agent (MDA), which is the component responsible for storing the message during final delivery, also has the task of protecting any existing line that begins with From in the body of the message and is considered prone to misinterpretation.

The sample message shown in Figure 14-1 was transmitted with the following SMTP transaction:

<Verbatim listing 2> CONNECT [12]

220 ESMTP Sendmail 8.13.8/8.13.7; Sat, 30 Sep 2006 14:08:38 +0200 EHLO Hello localhost.localdomain [], pleased to meet you




250-SIZE 5000000




250 HELP

MAIL From:<[email protected]> SIZE=57

250 2.1.0 <[email protected]>... Sender ok

RCPT To:<[email protected]>


250 2.1.5 <[email protected]>... Recipient ok Received: (from [email protected])

by (8.13.8/8.13.5/Submit) id k8UC8EMj001346 for root; Sat, 30 Sep 2006 14:08:14 +0200 Date: Sat, 30 Sep 2006 14:08:14 +0200

Message-Id: <200609301208.k8UC8EMj00134 [email protected]>

From: [email protected]

To: [email protected]

Subject: foobar test

250 2.0.0 k8UC8c3M001347 Message accepted for delivery


221 2.0.0 closing connection

</Verbatim listing>

SMTP is "spoken" on port 25 for clear-text connections (which can be upgraded to encrypted ones with STARTTLS), port 465 for SSL, and port 587 as a Mail Submission Agent (MSA). MSA is a relatively new concept (RFC 2476) that provides a separate port (587) with slightly different message processing for MUA submission, which can be treated differently from other MTA message transfers (email client talking to a mail server, as opposed to two mail servers talking to each other). This difference has no security implications.

Was this article helpful?

0 0
The Ultimate Computer Repair Guide

The Ultimate Computer Repair Guide

Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.

Get My Free Ebook

Post a comment