electronic mail – protocol evolution
DESCRIPTION
Electronic mail – protocol evolution. E-mail standards. 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 - PowerPoint PPT PresentationTRANSCRIPT
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
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: <[email protected]> S: 250 [email protected]... Sender ok C: RCPT TO: <[email protected]> S: 250 [email protected] ... 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 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 ProceduresTo solve RFC822 restrictions without serious
incompatibilities with it
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: [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
multimedia datatype, subtype,
parameter declaration
method usedto encode data
MIME version
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 --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: [email protected] To: [email protected] 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)
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
(Adjusted) Mail Architecture
petrel
alpha
admsrvcs
Anti-virus
Director
Content Filter
Off-Campus E-mail
Antispam
Outgoing mail authenticationRDC 2554
S: 220 smtp.example.com ESMTP server readyC: EHLO jgm.example.comS: 250-smtp.example.comS: 250 AUTH CRAM-MD5 DIGEST-MD5C: AUTH FOOBARS: 504 Unrecognized authentication type.C: AUTH CRAM-MD5S: 334 U0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==S: 235 Authentication successful.
S: 220 smtp.example.com ESMTP server readyC: EHLO jgm.example.comS: 250-smtp.example.comS: 250 AUTH CRAM-MD5 DIGEST-MD5C: AUTH FOOBARS: 504 Unrecognized authentication type.C: AUTH CRAM-MD5S: 334 U0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==S: 235 Authentication successful.
Spam mail
Return-Path: <[email protected]>Delivered-To: [email protected]: from server.thirdstone.net (unknown [66.216.98.139])
by pumpis4.latnet.lv (Postfix) with ESMTP id C09DF4943Bfor <[email protected]>; Fri, 24 Mar 2006 15:34:29 +0200 (EET)
Received: by server.thirdstone.net (Postfix, from userid 80)id 2628636A33E; Fri, 24 Mar 2006 05:40:35 -0800 (PST)
To: [email protected]: Your online account has been limitedFrom: Chase Card Services Online Services Team <[email protected]>Content-Type: text/htmlMessage-Id: <[email protected]>Date: Fri, 24 Mar 2006 05:40:35 -0800 (PST)X-Virus-Scanned: amavisd-new 2.3.2 (20050629) at latnet.lvX-Spam-Status: No, hits=5.448 tagged_above=0 required=7
tests=[BAYES_40=-0.002, HTML_40_50=0.496, HTML_IMAGE_ONLY_32=1.052,HTML_MESSAGE=0.001, HTML_TAG2=0.1, MESSAGE_ID_EXIST1=-0.1,MESSAGE_ID_EXIST2=-0.1, MIME_HEADER_CTYPE_ONLY=0,MIME_HTML_ONLY=0.001, NO_DNS_FOR_FROM=3.2, ONLINE_IN_BODY=0.1,SARE_RD_GOOGLE=0.8, URL_STARTS_WITH_WWW=-0.1]
X-Spam-Level: *****
Return-Path: <[email protected]>Delivered-To: [email protected]: from server.thirdstone.net (unknown [66.216.98.139])
by pumpis4.latnet.lv (Postfix) with ESMTP id C09DF4943Bfor <[email protected]>; Fri, 24 Mar 2006 15:34:29 +0200 (EET)
Received: by server.thirdstone.net (Postfix, from userid 80)id 2628636A33E; Fri, 24 Mar 2006 05:40:35 -0800 (PST)
To: [email protected]: Your online account has been limitedFrom: Chase Card Services Online Services Team <[email protected]>Content-Type: text/htmlMessage-Id: <[email protected]>Date: Fri, 24 Mar 2006 05:40:35 -0800 (PST)X-Virus-Scanned: amavisd-new 2.3.2 (20050629) at latnet.lvX-Spam-Status: No, hits=5.448 tagged_above=0 required=7
tests=[BAYES_40=-0.002, HTML_40_50=0.496, HTML_IMAGE_ONLY_32=1.052,HTML_MESSAGE=0.001, HTML_TAG2=0.1, MESSAGE_ID_EXIST1=-0.1,MESSAGE_ID_EXIST2=-0.1, MIME_HEADER_CTYPE_ONLY=0,MIME_HTML_ONLY=0.001, NO_DNS_FOR_FROM=3.2, ONLINE_IN_BODY=0.1,SARE_RD_GOOGLE=0.8, URL_STARTS_WITH_WWW=-0.1]
X-Spam-Level: *****
Return-Path: <[email protected]>Received: from fifa.org (218-175-82-64.dynamic.hinet.net [218.175.82.64])
by alfred.taide.net (Postfix) with SMTP id 675FB3430Efor <[email protected]>; Sun, 26 Mar 2006 11:12:52 +0200 (CEST)
Message-ID: <000001c650b5$5fc868b0$0548a8c0@cmb1>Reply-To: "Aegle Freudenburg" <[email protected]>From: "Aegle Freudenburg" <[email protected]>To: [email protected]: Re: newDate: Sun, 26 Mar 2006 04:12:15 -0500X-Virus-Scanned: by amavisd-new at taide.netX-Spam-Status: GOOD 0.0000000 4d8e508788a7565e07ee1405c73c45f1
Return-Path: <[email protected]>Received: from fifa.org (218-175-82-64.dynamic.hinet.net [218.175.82.64])
by alfred.taide.net (Postfix) with SMTP id 675FB3430Efor <[email protected]>; Sun, 26 Mar 2006 11:12:52 +0200 (CEST)
Message-ID: <000001c650b5$5fc868b0$0548a8c0@cmb1>Reply-To: "Aegle Freudenburg" <[email protected]>From: "Aegle Freudenburg" <[email protected]>To: [email protected]: Re: newDate: Sun, 26 Mar 2006 04:12:15 -0500X-Virus-Scanned: by amavisd-new at taide.netX-Spam-Status: GOOD 0.0000000 4d8e508788a7565e07ee1405c73c45f1
SMTP: MAIL FROM: <[email protected]>SMTP: HELO server.thirdstone.net
Reverse DNS lookup
Mail from El PresidenteReturn-Path: <[email protected]>Delivered-To: [email protected]: 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 MailMessage-Id: <[email protected]>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 <[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)
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)
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 <[email protected]>; Tue, 2 Dec 2003 12:55:36 -0800 (PST)
You can see the open proxy
Mapping email to postal mail- the envelope
Mail From /Envelope From /
Return PathRecipient To
~ Sender ID’s authorization proof
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. 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.
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" <[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.
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.
DNS TXT query for:
brisbane._domainkey.football.example.com
DNS TXT query for:
brisbane._domainkey.football.example.com
AutentisksE-mails no ft.com
guntis@gulbis:~$ nslookup> set type=any> uk.update.ft.comServer: 159.148.108.1Address: 159.148.108.1#53
Non-authoritative answer:Name: uk.update.ft.comAddress: 64.73.138.246uk.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.comServer: 159.148.108.1Address: 159.148.108.1#53
Non-authoritative answer:ftcom._domainkey.uk.update.ft.com text = "k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCoNyixo7zQAb2mLAhB29hV6a7djDXrTZBo67Wa+jXykAt0O1vFhaLE1p5bFJnqhQzgmT91eVw58/Y2+MWqusiPrzycSQl7FNsmPW2iFqmO5wJbaytjkqvS5DwEiB4aHGQyCbi1Vobs7INFy1SAATdzqXFD8GNKNZRuf5fmqHvesQIDAQAB">
guntis@gulbis:~$ nslookup> set type=any> uk.update.ft.comServer: 159.148.108.1Address: 159.148.108.1#53
Non-authoritative answer:Name: uk.update.ft.comAddress: 64.73.138.246uk.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.comServer: 159.148.108.1Address: 159.148.108.1#53
Non-authoritative answer:ftcom._domainkey.uk.update.ft.com text = "k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCoNyixo7zQAb2mLAhB29hV6a7djDXrTZBo67Wa+jXykAt0O1vFhaLE1p5bFJnqhQzgmT91eVw58/Y2+MWqusiPrzycSQl7FNsmPW2iFqmO5wJbaytjkqvS5DwEiB4aHGQyCbi1Vobs7INFy1SAATdzqXFD8GNKNZRuf5fmqHvesQIDAQAB">
Return-Path: <[email protected]>Delivered-To: [email protected]: from update.ft.com (transit246.email.mms.eloyalty.net [64.73.138.246])
by pumpis4.latnet.lv (Postfix) with ESMTP id 5B0115A5DBfor <[email protected]>; Tue, 28 Mar 2006 15:10:43 +0300 (EEST)
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 <[email protected]>; Tue, 28 Mar 2006 06:10:39 -0600 (envelope-from <[email protected]>)From: "FT.com" <[email protected]>To: <[email protected]>Subject: The latest news and features on FT.comDate: Tue, 28 Mar 2006 06:10:42 -0600Message-ID: <[email protected]>Content-Return: allowedMIME-Version: 1.0Content-Transfer-Encoding: quoted-printableContent-Type: text/html; charset="iso-8859-1"X-Virus-Scanned: amavisd-new 2.3.2 (20050629) at latnet.lv
Return-Path: <[email protected]>Delivered-To: [email protected]: from update.ft.com (transit246.email.mms.eloyalty.net [64.73.138.246])
by pumpis4.latnet.lv (Postfix) with ESMTP id 5B0115A5DBfor <[email protected]>; Tue, 28 Mar 2006 15:10:43 +0300 (EEST)
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 <[email protected]>; Tue, 28 Mar 2006 06:10:39 -0600 (envelope-from <[email protected]>)From: "FT.com" <[email protected]>To: <[email protected]>Subject: The latest news and features on FT.comDate: Tue, 28 Mar 2006 06:10:42 -0600Message-ID: <[email protected]>Content-Return: allowedMIME-Version: 1.0Content-Transfer-Encoding: quoted-printableContent-Type: text/html; charset="iso-8859-1"X-Virus-Scanned: amavisd-new 2.3.2 (20050629) at latnet.lv