Electronic mail – protocol evolution

E-mail standards

Electronic Mail

Three major components: • user agents • mail servers • simple mail transfer protocol:

SMTP, TCP port 25

User Agent• a.k.a. “mail reader”• composing, editing, reading mail

messages• e.g., Eudora, Outlook, elm,

Netscape Messenger• outgoing, incoming messages

stored on server

user mailbox

outgoing message queue

mailserver

useragent

useragent

useragent

mailserver

useragent

useragent

mailserver

useragent

SMTP

SMTP

SMTP

SMTP (RFC 821)

Sample SMTP interaction: TCP port 25 S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection

Mail Standard RFC822

• Published in 1982

• Lines no longer than 1000 char

• Message body - plain US-ASCII text

• Message header lines - plain US-ASCII text

• Limit on message length

RFC 822 format

RFC 822 restrictions

• no multiple objects in a single message

• no multi-part message bodies

• no non-textual bodies

• no X.400 messages can be gatewayd

• no multifont messages

ASCII times are over!Now we want:

• National language support

• Possibility to send – pictures– audiofiles– other applications– video files– multimedia applications

MIME - Multipurpose Internet Mail Extension

RFC 2045-2048 obsolete RFC 1521, 1522,1590

• RFC 2045 Format of Internet Message Bodies

• RFC 2046 Media Types

• RFC 2047 Message Header Extension for Non-ASCII Text

• RFC 2048 Registration ProceduresTo solve RFC822 restrictions without serious

incompatibilities with it

MIME

MIME types and sub-types

base64 encoding

Mail message format

SMTP: protocol for exchanging email msgs

RFC 822: standard for text message format:

• header lines, e.g.,– To:

– From:

– Subject:

different from SMTP commands!

• body– the “message”, 7-bit ASCII

characters only

header

body

blankline

Message format: multimedia extensions

• MIME: multimedia mail extension, RFC 2045, 2056

• additional lines in msg header declare MIME content type

From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg

base64 encoded data ..... ......................... ......base64 encoded data

multimedia datatype, subtype,

parameter declaration

method usedto encode data

MIME version

encoded data

Multipart TypeFrom: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789Content-Transfer-Encoding: quoted-printableContent-Type: text/plain

Dear Bob, Please find a picture of a crepe.--98766789Content-Transfer-Encoding: base64Content-Type: image/jpeg

base64 encoded data ..... ......................... ......base64 encoded data --98766789--

Multipart TypeFrom: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPartDear Bob, Please find a picture of a crepe.--StartOfNextPartContent-Transfer-Encoding: base64Content-Type: image/jpegbase64 encoded data ..... ......................... ......base64 encoded data --StartOfNextPartDo you want the reciple?

Mail access protocols

• SMTP: delivery/storage to receiver’s server• Mail access protocol: retrieval from server

– POP: Post Office Protocol [RFC 1939]• authorization (agent <-->server) and download

– IMAP: Internet Mail Access Protocol [RFC 1730]• more features (more complex)• manipulation of stored msgs on server

– HTTP: Hotmail , Yahoo! Mail, etc.

useragent

sender’s mail server

useragent

SMTP SMTP accessprotocol

receiver’s mail server

Try SMTP interaction for yourself:

• telnet servername 25• see 220 reply from server

• enter HELO, MAIL FROM, RCPT TO, DATA, QUIT commands

above lets you send email without using email client (reader)

Post Office Protocol (POP)

POP3 protocolauthorization phase• client commands:

– user: declare username– pass: password

• server responses– +OK– -ERR

transaction phase, client:• list: list message numbers• retr: retrieve message by

number• dele: delete• quit

C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> S: . C: dele 1 C: retr 2 S: <message 1 contents> S: . C: dele 2 C: quit S: +OK POP3 server signing off

S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on

IMAP

Web Mail

http://www.squirrelmail.org

(Adjusted) Mail Architecture

petrel

alpha

admsrvcs

Anti-virus

Director

Content Filter

smtpsmtp_internal

smtp_notifysmtp_externel

mx=10 “smtp_external”mx=20 “smtp_backup”mx=30 “smtp.ecs.” | “smtp”

Off-Campus E-mail

Antispam

parrot

root mail

Mail from El PresidenteReturn-Path: <elvis@graceland.org>Delivered-To: steve@blighty.comReceived: from fake-name.example.com (unknown [64.71.176.18]) by gp.word-to-the-wise.com (Postfix) with SMTP id 3DD7790000D for <steve@blighty.com>; Tue, 2 Dec 2003 12:55:36 -0800 (PST)From: El Presidente <president@whitehouse.com>To: Steve Atkins <steve@blighty.com>Subject: Fake MailMessage-Id: <20031202205536.3DD779@gp.word-to-the-wise.com>Date: Tue, 2 Dec 2003 12:55:36 -0800 (PST)Status: ROContent-Length: 15Lines: 1

Some body text

Sending spam (relay hijacking)

SMTP

POP3

SMTP

Third-party mailserver (10.11.12.13)

Recipients MX

Spammer(64.71.176.18)

Sending spam (relay hijacking)Received: from openrelay.com (mail.openrelay.com [10.11.12.13]) by gp.word-to-the-wise.com (Postfix) with SMTP id 3DD7790000D for <steve@blighty.com>; Tue, 2 Dec 2003 12:55:36 -0800 (PST)

Received: from fake-spammer-helo (spammer.net [64.71.176.18]) by openrelay.com (Postfix) with SMTP id 3DD7790000D for <steve@blighty.com>; Tue, 2 Dec 2003 12:55:36 -0800 (PST)

You can see the relay, and the original spammer

Sending spam (direct to MX)

SMTP POP3

Recipients MXSpammer(64.71.176.18)

Sending spam (direct to MX)

Received: from fake-spammer-helo (spammer.net [64.71.176.18]) by gp.word-to-the-wise.com (Postfix) with SMTP id 3DD7790000D for <steve@blighty.com>; Tue, 2 Dec 2003 12:55:36 -0800 (PST)

You can see the spammer

Sending spam (proxy hijacking)

HTTP

POP3

SMTP

Open proxy (192.168.1.1)

Recipients MX

Spammer(64.71.176.18)

Sending spam (proxy hijacking)Received: from fake-spammer-helo (open-proxy.net [192.168.1.1]) by gp.word-to-the-wise.com (Postfix) with SMTP id 3DD7790000D for <steve@blighty.com>; Tue, 2 Dec 2003 12:55:36 -0800 (PST)

You can see the open proxy

Sending spam (trojans)

IRC?

POP3

SMTP

Infected computer (192.168.1.1)

Recipients MX

Spammer(64.71.176.18)

Mapping email to postal mail- the envelope

Mail From /Envelope From /

Return PathRecipient To

~ Sender ID’s authorization proof

Email Authentication Proposals

• Client SMTP Validation (CSV):– http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-intro-01.txt

• Bounce Address Tag Validation (BATV):– http://www.ietf.org/internet-drafts/draft-levine-mass-batv-00.txt

• DomainKeys:– http://antispam.yahoo.com/domainkeys

• Identified Internet Mail (IIM):– http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-01.txt

• Sender ID (SPF + PRA):– http://www.ietf.org/internet-drafts/draft-ietf-marid-pra-00.txt– http://www.ietf.org/internet-drafts/draft-ietf-marid-core-03.txt

SPF: Sender Policy Framework

Domains use public records (DNS) to direct requests for different services (web, email, etc.) to the machines that perform those services. All domains already publish email (MX) records to tell the world what machines receive mail for the domain. SPF works by domains publishing "reverse MX" records to tell the world what machines send mail from the domain. When receiving a message from a domain, the recipient can check those records to make sure mail is coming from where it should be coming from.

With SPF, those "reverse MX" records are easy to publish: one line in DNS is all it takes.

Domains use public records (DNS) to direct requests for different services (web, email, etc.) to the machines that perform those services. All domains already publish email (MX) records to tell the world what machines receive mail for the domain. SPF works by domains publishing "reverse MX" records to tell the world what machines send mail from the domain. When receiving a message from a domain, the recipient can check those records to make sure mail is coming from where it should be coming from.

With SPF, those "reverse MX" records are easy to publish: one line in DNS is all it takes.

Client SMTP Validation (CSV):

CSV considers two questions at the start of each SMTP session:

o Does a domain's management authorize this MTA to be sending email?

o Do independent accreditation services consider that domain's policies and practices sufficient for controlling email abuse?

CSV considers two questions at the start of each SMTP session:

o Does a domain's management authorize this MTA to be sending email?

o Do independent accreditation services consider that domain's policies and practices sufficient for controlling email abuse?

Identified Internet Mail (IIM):

Identified Internet Mail (IIM) provides a means by which cryptographic signatures can be applied to email messages to demonstrate that the sender of the message was authorized to use a given email address. Message recipients can verify the signature and consult the sender's domain to determine whether the key that was used to sign the message was authorized by that domain for that address. This confirms that the message was sent by an party authorized to use the sender's email address.

Identified Internet Mail (IIM) provides a means by which cryptographic signatures can be applied to email messages to demonstrate that the sender of the message was authorized to use a given email address. Message recipients can verify the signature and consult the sender's domain to determine whether the key that was used to sign the message was authorized by that domain for that address. This confirms that the message was sent by an party authorized to use the sender's email address.

DomainKeysUnder DomainKeys, a domain owner generates one or more private/publickey-pairs that will be used to sign messages originating from thatdomain. The domain owner places the public-key in his domainnamespace (i.e., in a DNS record associated with that domain), andmakes the private-key available to the outbound email system. When anemail is submitted by an authorized user of that domain, the emailsystem uses the private-key to digitally sign the email associatedwith the sending domain. The signature is added as a "DomainKey-Signature:" header to the email, and the message is transferred to its recipients in the usual way.

When a message is received with a DomainKey signature header, thereceiving system can verify the signature as follows:

1. Extract the signature and claimed sending domain from the email.

2. Fetch the public-key from the claimed sending domain namespace.

3. Use public-key to determine whether the signature of the email has been generated with the corresponding private-key, and thus whether the email was sent with the authority of the claimed sending domain.

In the event that an email arrives without a signature or when thesignature verification fails, the receiving system retrieves thepolicy of the claimed sending domain to ascertain the preferreddisposition of such email.

Under DomainKeys, a domain owner generates one or more private/publickey-pairs that will be used to sign messages originating from thatdomain. The domain owner places the public-key in his domainnamespace (i.e., in a DNS record associated with that domain), andmakes the private-key available to the outbound email system. When anemail is submitted by an authorized user of that domain, the emailsystem uses the private-key to digitally sign the email associatedwith the sending domain. The signature is added as a "DomainKey-Signature:" header to the email, and the message is transferred to its recipients in the usual way.

When a message is received with a DomainKey signature header, thereceiving system can verify the signature as follows:

1. Extract the signature and claimed sending domain from the email.

2. Fetch the public-key from the claimed sending domain namespace.

3. Use public-key to determine whether the signature of the email has been generated with the corresponding private-key, and thus whether the email was sent with the authority of the claimed sending domain.

In the event that an email arrives without a signature or when thesignature verification fails, the receiving system retrieves thepolicy of the claimed sending domain to ascertain the preferreddisposition of such email.

$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

-----BEGIN PUBLIC KEY-----MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB-----END PUBLIC KEY-----

This public-key data is placed in the DNS:

_domainkey IN TXT "t=y; o=-; n=notes; r=emailAddress"

$ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

-----BEGIN PUBLIC KEY-----MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB-----END PUBLIC KEY-----

This public-key data is placed in the DNS:

_domainkey IN TXT "t=y; o=-; n=notes; r=emailAddress"

DomainKeys Example

DomainKey-Status: good DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com; c=simple; q=dns; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR; Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] by submitserver.football.example.com with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT) From: "Joe SixPack" <joe@football.example.com> To: "Suzie Q" <suzie@shopping.example.net> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game. Are you hungry yet?

Joe.

DomainKey-Status: good DomainKey-Signature: a=rsa-sha1; s=brisbane; d=football.example.com; c=simple; q=dns; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR; Received: from dsl-10.2.3.4.football.example.com [10.2.3.4] by submitserver.football.example.com with SUBMISSION; Fri, 11 Jul 2003 21:01:54 -0700 (PDT) From: "Joe SixPack" <joe@football.example.com> To: "Suzie Q" <suzie@shopping.example.net> Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com>

Hi.

We lost the game. Are you hungry yet?

Joe.

DNS TXT query for:

brisbane._domainkey.football.example.com

DNS TXT query for:

brisbane._domainkey.football.example.com

Two authentication strategies compared

IP based (Sender ID)• Find outbound IPs, publish

in DNS• Receiver verifies mail from

authorized IP• Sender is not authenticated

-- Last IP to touch mail is• Forwarders & mail lists

must change before technology can be fully used

Digital Signature (DomainKeys)• Generate public/private keys,

publish public-key in DNS• Sign mail with private-key• Receiver verifies signature• Original Sender is authenticated• In transit modifications may

invalidate signature

19