Email Routing

SMTP traffic is generally used by your client application (MUA) for connecting to an MTA or between MTAs. The final stage of mail transmission is usually the end delivery of the message in a mailbox by an MDA.

The first thing to understand about mail routing is that, as we mentioned in the previous chapter, domains are mapped to their mail server(s) using MX DNS records. Here's a sample query that shows an MX record:

<Verbatim listing 3> $ dig -t mx google.com

; <<>\> DiG 9.3.0 <<>\> -t mx google.com ;; global options: printcmd ;; Got answer:

;; ->\>HEADER<<- opcode: QUERY, status: NOERROR, id: 23016

;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 8

;; QUESTION SECTION:

;google.com. IN MX

;; ANSWER SECTION:

google.com.

3600

IN

MX

10

smtp1.google.

com

google.com.

3600

IN

MX

10

smtp2.google.

com

google.com.

3600

IN

MX

10

smtp3.google.

com

google.com.

3600

IN

MX

10

smtp4.google.

com

;; AUTHORITY

SECTION:

google.com.

67916

IN

NS

ns3

.google.com.

google.com.

67916

IN

NS

ns4

.google.com.

google.com.

67916

IN

NS

ns1.google.com.

google.com.

67916

IN

NS

ns2.google.com.

;; ADDITIONAL SECTION:

smtp1.google.com.

600

IN

A

216.239

.57.25

smtp2.google.com.

600

IN

A

64.233.

167.25

smtp3.google.com.

60 0

IN

A

64.233.

183.25

smtp4.google.com.

600

IN

A

66.102.

9.25

ns1.google.com.

152442

IN A

216.239.

.32.

10

ns2.google.com.

152442

IN A

216.239.

.34.

10

ns3.google.com.

152442

IN A

216.239.

.36.

10

ns4.google.com.

152442

IN

A 216.

239.38.10

SERVER: 140.105.134.1#53(140.105.134.1) WHEN: Wed Oct 11 19:28:03 2006

Query time: 157 msec

SERVER: 140.105.134.1#53(140.105.134.1) WHEN: Wed Oct 11 19:28:03 2006

;; MSG SIZE rcvd: 316 </Verbatim listing>

The MX record is accessed at the beginning of the email transaction; after lookup the MTA/MUA establishes an SMTP connection to the specified server (usually the one with highest priority) for delivering the message. In this example, all MX records returned have the same preference value (10). The lower the preference number the higher the priority; an MX with a preference value of 10 will be tried before an MX with preference 20 (but this is not always the case such as when the other MTA is statically linked by IP address).

Each MTA decides what to do with a message (including whether or not to accept it) depending on its routing configuration. Basically an MTA will perform the two following evaluations upon receiving a message over SMTP:

• If the email address is considered local, the message will be delivered to the local mailbox (usually a file or directory on the server, but it could be a database or other fancy thing).

• If the email address is not local but is allowed to be relayed, or the source IP address of the incoming connection is allowed to relay, then the message is accepted and passed along to another MTA (either a statically configured one or the MX record one).

Usually servers that allow relay based on the IP address are the ones that your ISP provides for sending outgoing emails. The ones that allow relaying a specific domain are the exposed servers of a specific domain, which don't necessarily host the mailboxes themselves (they may simply pass the messages to other servers farther inside their internal network). Of course, like TCP/IP routing, email relaying and routing rules have endless possibilities and you are likely to find all kinds of loops and configurations out there.

The path of an email message is traced with the Received headers:

<Verbatim listing 4> Delivered-To: <[email protected]> Return-Path: [email protected]

Received: from smtp.isecom.org (smtp.isecom.org [140.211.166.183])

by azzurra.isecom.org (8.13.6/8.13.6) with ESMTP id k4KL5UOq014773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[email protected]>; Sat, 20 May 2006 21:05:30 GMT Received: by smtp.isecom.org (Postfix)

id D138A64413; Sat, 20 May 2006 21:05:29 +0000 (UTC) Delivered-To: [email protected]

Received: from localhost (localhost [127.0.0.1])

by smtp.isecom.org (Postfix) with ESMTP id B87EF64409 for <[email protected]>; Sat, 20 May 2006 21:05:29 +0000 (UTC) Received: from smtp.isecom.org ([127.0.0.1]) by localhost (smtp.isecom.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24780-13 for <[email protected]>; Sat, 20 May 2006 21:05:23 +0000 (UTC) Received: from mail2.isecom.org (bsiC.pl [83.18.69.210])

(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested)

by smtp.isecom.org (Postfix) with ESMTP id 6B37E64405 for <[email protected]>; Sat, 20 May 2006 21:05:23 +0000 (UTC) Received: from localhost (localhost.isecom.org [127.0.0.1])

by mail2.isecom.org (Postfix) with ESMTP id BDF11B02DE for <[email protected]>; Sat, 20 May 2006 23:12:55 +0200 (CEST) Received: from mail2.isecom.org ([127.0.0.1]) by localhost ([127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11508-04 for <[email protected]>; Sat, 20 May 2006 23:12:42 +0200 (CEST) Received: from localhost (unknown [192.168.0.5])

by mail2.isecom.org (Postfix) with ESMTP id 54666B02DC for <[email protected]>; Sat, 20 May 2006 23:12:41 +0200 (CEST) Date: Sat, 20 May 2006 23:05:04 +0200 From: John Doe <[email protected]> To: [email protected] </Verbatim listing>

Every MTA should add its own trace when routing a message, but adding forged Received headers to confuse the message path is trivial. Since every MTA adds a Received header, at some point, you are going to have legit ones that are valid (since the spammer owning every server in the message path is unlikely).

A very common forgery is passing an invalid domain in the HELO command, which is the initial greeting command (we'll discuss validation options for this command later in "The Initial Phase"). Here's an example of a forged domain. You can quickly find out that 82.52.175.137 does not resolve to foo.com. The correct IP information is saved by the receiving MTA and cannot be forged; the domain can, and it's done to deceive anyone reading the header who's too lazy to actually check if it correctly matches the IP address.

<Verbatim listing 5>

Received: from foo.com ([82.52.175.137])

by mail.isecom.org (8.13.8/8.13.7) with SMTP id k96DsnOS005189 for andrea; Fri, 6 Oct 2006 13:55:06 GMT </Verbatim listing 5>

The MTA can be configured to perform reverse resolution itself. In this case, you get a better header:

<Verbatim listing 6>

Received: from foo.com (host137-17 5.pool82 52.interbusiness.it [82.52.175.137])

by mail.isecom.org (8.13.8/8.13.7) with SMTP id k96DsnOS005189 for andrea; Fri, 6 Oct 2006 13:55:06 GMT </Verbatim listing 6>

Some MTAs are friendly enough to report a possible forgery (triggered because the domain name of 213.155.199.178 doesn't resolve back to the IP address, common with dial-up pools):

<Verbatim listing 7>

Received: from [213.155.199.178] (hwadsl-213-155-199-178.telvia.it [213.155.199.178] (may be forged))

by dns1.vanja.com with ESMTP<9C> id k77LAwaI005476

(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Aug 2006 23:11:00 +020C </Verbatim listing>

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