Transcript DomainKeys
Electronic mail – protocol evolution
E-mail standards
Electronic Mail
outgoing message queue user mailbox Three major components: • user agents • mail servers • simple mail transfer protocol: SMTP, TCP port 25 mail server 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 SMTP mail server user agent user agent SMTP SMTP user agent mail server user agent user agent user agent
Email terminology
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:
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 gatewayed • 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
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 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 access protocol sender’s mail server 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 (POP3)
•
POP3 protocol
authorization phase • client commands: –
user:
declare
S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on
username – • server responses – –
pass: +OK -ERR
password transaction phase, client: • • •
list:
numbers list message
retr:
number retrieve message by
dele:
delete
C: list S: 1 498 S: 2 912 S: . C: retr 1 S:
IMAP
Web Mail
http://www.squirrelmail.org
(Adjusted) Mail Architecture
Off-Campus E-mail Anti-virus Director petrel alpha admsrvcs Content Filter Antispam
Outgoing mail authentication RDC 2554
S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5 C: AUTH FOOBAR S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5 S: 334 U0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== S: 235 Authentication successful.
Spam mail
SMTP: MAIL FROM:
Return-Path:
Received: by server.thirdstone.net (Postfix, from userid 80) To: [email protected]
Subject: Your online account has been limited Content-Type: text/html Date: Fri, 24 Mar 2006 05:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new 2.3.2 (20050629) at latnet.lv
X-Spam-Status: No, hits=5.448 tagged_above=0 required=7 MESSAGE_ID_EXIST2=-0.1, MIME_HEADER_CTYPE_ONLY=0, SARE_RD_GOOGLE=0.8, URL_STARTS_WITH_WWW=-0.1] X-Spam-Level: *****
SMTP: HELO server.thirdstone.net Received: from server.thirdstone.net (unknown [66.216.98.139])
by pumpis4.latnet.lv (Postfix) with ESMTP id C09DF4943B for
Reverse DNS lookup
Return-Path:
Received: from fifa.org (218-175-82-64.dynamic.hinet.net [218.175.82.64])
by alfred.taide.net (Postfix) with SMTP id 675FB3430E for
Subject: Re: new Date: Sun, 26 Mar 2006 04:12:15 -0500 X-Virus-Scanned: by amavisd-new at taide.net
X-Spam-Status: GOOD 0.0000000 4d8e508788a7565e07ee1405c73c45f1
Mail from El Presidente
Return-Path: < [email protected]
> Delivered-To: [email protected]
Received: from fake-name.example.com
by gp.word-to-the-wise.com (Postfix) with SMTP id 3DD7790000D for
]) 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
You can see the relay, and the original spammer
Sending spam (direct to MX)
Spammer (64.71.176.18) SMTP Recipients MX POP3
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
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
You can see the open proxy
Mapping email to postal mail the envelope
~ Sender ID’s authorization proof Mail From / Envelope From / Return Path Recipient To
Email Authentication Proposals (not directly related to spam!)
•
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.
from where it should be coming from.
When receiving a message from a domain, the recipient can check those records to make sure mail is coming With SPF, those "reverse MX" records are easy to publish: one line in DNS is all it takes.
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"
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <[email protected]> Hi.
We lost the game. Are you hungry yet?
Joe.
DNS to distribute Domain-Level Keys
[DomainKeys]
DomainKeys
DomainKeys
• intra-domain authentication?
• SK must be online • mail-forwarding services?
>
Autentisks E-mails no ft.com
guntis@gulbis:~$ nslookup > set type=any
uk.update.ft.com
Return-Path:
Received: from Server: 159.148.108.1
update.ft.com (transit246.email.mms.eloyalty.net [64.73.138.246])
by pumpis4.latnet.lv (Postfix) with ESMTP id 5B0115A5DB for
DomainKey-Signature:
a=rsa-sha1; c=nofws; q=dns; s=ftcom; d=uk.update.ft.com; b=oILD038lHibyKsc7uPFA3Qx7n7CwegCQeNOAOIg+BZ3ZG+aIE68Mc5zB6FdHrJlWb+yxzkYOlqmf 8Qqzc2rmJXOtwtEFgO4BGUYpmGa6mYvXohBJC8Lf5CFbnyr0UjuGVzU46O249STEJ88e+A5eN3ep 9OvvBrSxGJ9HPnGHdsE=; Received: by update.ft.com (PowerMTA(TM) v3.0r11) id h54jse07d1s6 for
Date: Tue, 28 Mar 2006 06:10:42 -0600 Message-ID: <[email protected]> Content-Return: allowed MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" Address: 159.148.108.1#53 Non-authoritative answer: Name: uk.update.ft.com
Address: 64.73.138.246
uk.update.ft.com mail exchanger = 10 uk.update.ft.com.
uk.update.ft.com
text = "v=spf1 ip4:64.73.138.0/24 -all“
>
ftcom._domainkey.uk.update.ft.com
Server: 159.148.108.1
Address: 159.148.108.1#53 Non-authoritative answer:
ftcom._domainkey.uk.update.ft.com text = "k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCoNyixo7zQAb2mLAhB29hV6a7djDXrTZBo67Wa+j XykAt0O1vFhaLE1p5bFJnqhQzgmT91eVw58/Y2+MWqusiPrzycSQl7FNsmPW2iFqmO5wJbaytjkqvS5D wEiB4aHGQyCbi1Vobs7INFy1SAATdzqXFD8GNKNZRuf5fmqHvesQIDAQAB"
>