Electronic mail protocol evolution

1
Electronic mail protocol evolution
2
E-mail standards
3
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

4
SMTP (RFC 821)
5
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 ltalice_at_crepes.frgt
S 250 alice_at_crepes.fr... Sender ok C RCPT
TO ltbob_at_hamburger.edugt S 250
bob_at_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
6
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

7
RFC 822 format
8
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

9
ASCII times are over!

• Now we want
• National language support
• Possibility to send
• pictures
• audiofiles
• other applications
• video files
• multimedia applications

10
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 Procedures
• To solve RFC822 restrictions without serious
  incompatibilities with it

11
MIME
12
MIME types and sub-types
13
base64 encoding
14
Mail message format
header

• 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

blank line
body
15
Message format multimedia extensions

• MIME multimedia mail extension, RFC 2045, 2056
• additional lines in msg header declare MIME
  content type

MIME version
method used to encode data
multimedia data type, subtype, parameter
declaration
encoded data
16
Multipart Type
From alice_at_crepes.fr To bob_at_hamburger.edu
Subject Picture of yummy crepe. MIME-Version
1.0 Content-Type multipart/mixed
boundary98766789 --98766789 Content-Transfer-En
coding quoted-printable Content-Type
text/plain Dear Bob, Please find a picture of a
crepe. --98766789 Content-Transfer-Encoding
base64 Content-Type image/jpeg base64 encoded
data ..... .........................
......base64 encoded data --98766789--
17
Multipart Type
From alice_at_crepes.fr To bob_at_hamburger.edu
Subject Picture of yummy crepe. MIME-Version
1.0 Content-Type multipart/mixed
boundaryStartOfNextPart --StartOfNextPart Dear
Bob, Please find a picture of a
crepe. --StartOfNextPart Content-Transfer-Encoding
base64 Content-Type image/jpeg base64 encoded
data ..... .........................
......base64 encoded data --StartOfNextPart Do
you want the reciple?
18
Mail access protocols
SMTP
access protocol
receivers mail server

• SMTP delivery/storage to receivers server
• Mail access protocol retrieval from server
• POP Post Office Protocol RFC 1939
• authorization (agent lt--gtserver) and download
• IMAP Internet Mail Access Protocol RFC 1730
• more features (more complex)
• manipulation of stored msgs on server
• HTTP Hotmail , Yahoo! Mail, etc.

19
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)

20
Post Office Protocol (POP)
21
POP3 protocol
S OK POP3 server ready C user bob S OK
C pass hungry S OK user successfully logged
on

• authorization 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 ltmessage 1
contentsgt S . C dele 1 C retr
2 S ltmessage 1 contentsgt S .
C dele 2 C quit S OK POP3 server
signing off
22
IMAP
23
Web Mail
http//www.squirrelmail.org
24
(Adjusted) Mail Architecture
Off-Campus E-mail
smtp smtp_internal
Anti-virus
Content Filter
smtp_notify smtp_externel
Director
Antispam
root mail
parrot
petrel
alpha
mx10 smtp_external mx20 smtp_backup mx30
smtp.ecs. smtp
admsrvcs
25
(No Transcript)
26
Mail from El Presidente
Return-Path ltelvis_at_graceland.orggt Delivered-To
steve_at_blighty.com Received from
fake-name.example.com (unknown 64.71.176.18)
by gp.word-to-the-wise.com (Postfix) with
SMTP id 3DD7790000D for
ltsteve_at_blighty.comgt Tue, 2 Dec 2003 125536
-0800 (PST) From El Presidente
ltpresident_at_whitehouse.comgt To Steve Atkins
ltsteve_at_blighty.comgt Subject Fake
Mail Message-Id lt20031202205536.3DD779_at_gp.word-to
-the-wise.comgt Date Tue, 2 Dec 2003 125536
-0800 (PST) Status RO Content-Length 15 Lines
1 Some body text
27
Sending spam (relay hijacking)
Third-party mailserver (10.11.12.13)
SMTP
Spammer (64.71.176.18)
SMTP
POP3
Recipients MX
28
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
ltsteve_at_blighty.comgt Tue, 2 Dec 2003 125536
-0800 (PST) Received from fake-spammer-helo
(spammer.net 64.71.176.18) by
openrelay.com (Postfix) with SMTP id 3DD7790000D
for ltsteve_at_blighty.comgt Tue, 2 Dec 2003
125536 -0800 (PST)
You can see the relay, and the original spammer
29
Sending spam (direct to MX)
SMTP
POP3
Spammer (64.71.176.18)
Recipients MX
30
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
ltsteve_at_blighty.comgt Tue, 2 Dec 2003 125536
-0800 (PST)
You can see the spammer
31
Sending spam (proxy hijacking)
Open proxy (192.168.1.1)
HTTP
Spammer (64.71.176.18)
SMTP
POP3
Recipients MX
32
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
ltsteve_at_blighty.comgt Tue, 2 Dec 2003 125536
-0800 (PST)
You can see the open proxy
33
Sending spam (trojans)
Infected computer (192.168.1.1)
IRC?
Spammer (64.71.176.18)
SMTP
POP3
Recipients MX
34
Mapping email to postal mail- the envelope
Mail From /Envelope From / Return Path
Recipient To
35
Email Authentication Proposals

• Client SMTP Validation (CSV)
• http//www.ietf.org/internet-drafts/draft-ietf-mar
  id-csv-intro-01.txt
• Bounce Address Tag Validation (BATV)
• http//www.ietf.org/internet-drafts/draft-levine-m
  ass-batv-00.txt
• DomainKeys
• http//antispam.yahoo.com/domainkeys
• Identified Internet Mail (IIM)
• http//www.ietf.org/internet-drafts/draft-fenton-i
  dentified-mail-01.txt
• Sender ID (SPF PRA)
• http//www.ietf.org/internet-drafts/draft-ietf-mar
  id-pra-00.txt
• http//www.ietf.org/internet-drafts/draft-ietf-mar
  id-core-03.txt

36
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.
37
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?
38
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.
39
DomainKeys
Under DomainKeys, a domain owner generates one or
more private/public key-pairs that will be used
to sign messages originating from that domain.
The domain owner places the public-key in his
domain namespace (i.e., in a DNS record
associated with that domain), and makes the
private-key available to the outbound email
system. When an email is submitted by an
authorized user of that domain, the email system
uses the private-key to digitally sign the email
associated with 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,
the receiving 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 the signature
verification fails, the receiving system
retrieves the policy of the claimed sending
domain to ascertain the preferred disposition of
such email.
openssl rsa -in rsa.private -out rsa.public
-pubout -outform PEM -----BEGIN PUBLIC
KEY----- MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ
8XlVambQfMXn3LRGKOD5o6l MIgulclWjZwP56LRqdg5ZX15bh
c/GsvW8xW/R5Sh1NnkJNyL/cqY1aGzzL47t7E XzVcnRLWT1
kwTvFNGIoAUsFUqJ6OprwIDAQAB -----END PUBLIC
KEY----- This public-key data is placed in the
DNS _domainkey IN TXT "ty o- nnotes
remailAddress"
40
DomainKeys Example
DNS TXT query for brisbane._domainkey.footba
ll.example.com
DomainKey-Status good DomainKey-Signature
arsa-sha1 sbrisbane dfootball.example.com
csimple qdns bdzdVyOfAKCdLXdJOc9G
2q8LoXSlEniSbavyuU4zGeeruD00lszZ
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 210154
-0700 (PDT) From "Joe SixPack"
ltjoe_at_football.example.comgt To "Suzie Q"
ltsuzie_at_shopping.example.netgt Subject Is
dinner ready? Date Fri, 11 Jul 2003 210037
-0700 (PDT) Message-ID lt20030712040037.46341.
5F8J_at_football.example.comgt Hi. We lost
the game. Are you hungry yet? Joe.
41
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