Transcript DomainKeys

Electronic mail – protocol evolution
E-mail standards
Electronic Mail
outgoing
message queue
user mailbox
user
agent
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
mail
server
SMTP
SMTP
mail
server
user
agent
SMTP
user
agent
user
agent
mail
server
user
agent
user
agent
SMTP (RFC 821)
Sample SMTP interaction: TCP port 25
S:
C:
S:
C:
S:
C:
S:
C:
S:
C:
C:
C:
S:
C:
S:
220 hamburger.edu
HELO crepes.fr
250 Hello crepes.fr, pleased to meet you
MAIL FROM: <[email protected]>
250 [email protected]... Sender ok
RCPT TO: <[email protected]>
250 [email protected] ... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Do you like ketchup?
How about pickles?
.
250 Message accepted for delivery
QUIT
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 Procedures
To 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
blank
line
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
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
Multipart Type
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: 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--
Multipart Type
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=StartOfNextPart
--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?
Mail access protocols
user
agent
SMTP
SMTP
sender’s mail
server
access
protocol
receiver’s mail
server
• 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.
user
agent
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 protocol
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
S:
C:
S:
C:
S:
+OK POP3 server ready
user bob
+OK
pass hungry
+OK user successfully logged
C:
S:
S:
S:
C:
S:
S:
C:
C:
S:
S:
C:
C:
S:
list
1 498
2 912
.
retr 1
<message 1 contents>
.
dele 1
retr 2
<message 1 contents>
.
dele 2
quit
+OK POP3 server signing off
on
IMAP
Web Mail
http://www.squirrelmail.org
(Adjusted) Mail Architecture
Off-Campus E-mail
smtp
smtp_internal
Anti-virus
Director
Content
Filter
smtp_notify
smtp_externel
Antispam
root mail
parrot
petrel
alpha
admsrvcs
mx=10 “smtp_external”
mx=20 “smtp_backup”
mx=30 “smtp.ecs.” | “smtp”
Mail from El Presidente
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from fake-name.example.com (unknown [64.71.176.18])
by gp.word-to-the-wise.com (Postfix) with SMTP id 3DD7790000D
for <[email protected]>; Tue, 2 Dec 2003 12:55:36 -0800 (PST)
From: El Presidente <[email protected]>
To: Steve Atkins <[email protected]>
Subject: Fake Mail
Message-Id: <[email protected]>
Date: Tue, 2 Dec 2003 12:55:36 -0800 (PST)
Status: RO
Content-Length: 15
Lines: 1
Some body text
Sending spam (relay hijacking)
Third-party mailserver (10.11.12.13)
Spammer
(64.71.176.18)
SMTP
SMTP
Recipients MX
POP3
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 <[email protected]>; 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 <[email protected]>; Tue, 2 Dec 2003 12:55:36 -0800 (PST)
You can see the relay, and the original spammer
Sending spam (direct to MX)
Spammer
(64.71.176.18)
SMTP
POP3
Recipients MX
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 <[email protected]>; Tue, 2 Dec 2003 12:55:36 -0800 (PST)
You can see the spammer
Sending spam (proxy hijacking)
Open proxy (192.168.1.1)
Spammer
(64.71.176.18)
HTTP
SMTP
Recipients MX
POP3
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 <[email protected]>; Tue, 2 Dec 2003 12:55:36 -0800 (PST)
You can see the open proxy
Sending spam (trojans)
Infected computer (192.168.1.1)
Spammer
(64.71.176.18)
IRC?
SMTP
Recipients MX
POP3
Mapping email to postal mailthe envelope
~ Sender ID’s
authorization proof
Mail From /
Envelope From /
Return Path
Recipient To
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.
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?
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.
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----MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5o6l
MIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7E
XzVc+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
DNS TXT query for:
brisbane._domainkey.football.example.com
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" <[email protected]>
To: "Suzie Q" <[email protected]>
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <[email protected]>
Hi.
We lost the game. Are you hungry yet?
Joe.
Two authentication strategies
compared
IP based (Sender ID)
Digital Signature (DomainKeys)
• Find outbound IPs, publish • Generate public/private keys,
in DNS
publish public-key in DNS
• Receiver verifies mail from • Sign mail with private-key
authorized IP
• Receiver verifies signature
• Sender is not authenticated • Original Sender is authenticated
-- Last IP to touch mail is • In transit modifications may
• Forwarders & mail lists
invalidate signature
must change before
technology can be fully
used
19