Electronic mail protocol evolution Email standards Electronic Mail

  • Slides: 47
Download presentation
Electronic mail – protocol evolution

Electronic mail – protocol evolution

E-mail standards

E-mail standards

Electronic Mail outgoing message queue user mailbox Three major components: • user agents •

Electronic Mail outgoing message queue user mailbox 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 agent mail server SMTP mail server user agent SMTP user agent mail server user agent

Email terminology

Email terminology

SMTP (RFC 821)

SMTP (RFC 821)

Sample SMTP interaction: TCP port 25 S: C: S: C: C: C: S: 220

Sample SMTP interaction: TCP port 25 S: C: S: C: C: C: S: 220 hamburger. edu HELO crepes. fr 250 Hello crepes. fr, pleased to meet you MAIL FROM: <alice@crepes. fr> 250 alice@crepes. fr. . . Sender ok RCPT TO: <bob@hamburger. edu> 250 bob@hamburger. edu. . . 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 RFC 822 • • • Published in 1982 Lines no longer than

Mail Standard RFC 822 • • • 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 format

RFC 822 restrictions • • • no multiple objects in a single message no

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

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

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 RFC 822 restrictions without serious incompatibilities with it

MIME

MIME

MIME types and sub-types

MIME types and sub-types

base 64 encoding

base 64 encoding

Mail message format SMTP: protocol for exchanging email msgs RFC 822: standard for text

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

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: alice@crepes. fr To: bob@hamburger. edu Subject: Picture of yummy crepe. MIME-Version: 1. 0 Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data

Multipart Type From: alice@crepes. fr To: bob@hamburger. edu Subject: Picture of yummy crepe. MIME-Version:

Multipart Type From: alice@crepes. fr To: bob@hamburger. edu 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: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data --98766789 --

Multipart Type From: alice@crepes. fr To: bob@hamburger. edu Subject: Picture of yummy crepe. MIME-Version:

Multipart Type From: alice@crepes. fr To: bob@hamburger. edu Subject: Picture of yummy crepe. MIME-Version: 1. 0 Content-Type: multipart/mixed; boundary=Start. Of. Next. Part --Start. Of. Next. Part Dear Bob, Please find a picture of a crepe. --Start. Of. Next. Part Content-Transfer-Encoding: base 64 Content-Type: image/jpeg base 64 encoded data. . . . . base 64 encoded data --Start. Of. Next. Part Do you want the reciple?

Mail access protocols user agent SMTP sender’s mail server access protocol receiver’s mail server

Mail access protocols user agent 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

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

Post Office Protocol (POP 3)

POP 3 protocol authorization phase • client commands: – user: declare username – pass:

POP 3 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: +OK POP 3 server ready user bob +OK pass hungry +OK user successfully logged C: S: 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 POP 3 server signing off on

IMAP

IMAP

Web Mail http: //www. squirrelmail. org

Web Mail http: //www. squirrelmail. org

(Adjusted) Mail Architecture Off-Campus E-mail Anti-virus Director petrel alpha admsrvcs Content Filter Antispam

(Adjusted) Mail Architecture Off-Campus E-mail Anti-virus Director petrel alpha admsrvcs Content Filter Antispam

Outgoing mail authentication RDC 2554 S: C: S: 220 smtp. example. com ESMTP server

Outgoing mail authentication RDC 2554 S: C: S: 220 smtp. example. com ESMTP server ready EHLO jgm. example. com 250 -smtp. example. com 250 AUTH CRAM-MD 5 DIGEST-MD 5 AUTH FOOBAR 504 Unrecognized authentication type. AUTH CRAM-MD 5 334 U 0 Nnbmh. NWit. OMj. NGNnd. AZWx 3 b 29 k. Lmlubm 9 zb 2 Z 0 Lm. Nvb. T 4= Zn. Jl. ZCA 5 ZTk 1 YWVl. MDlj. NDBh. Zj. Ji. ODRh. MGMy. Yj. Ni. Ym. Fl. Nzg 2 ZQ== 235 Authentication successful.

Spam mail SMTP: MAIL FROM: <www@server. thirdstone. net> SMTP: HELO server. thirdstone. net Return-Path:

Spam mail SMTP: MAIL FROM: <www@server. thirdstone. net> SMTP: HELO server. thirdstone. net Return-Path: <www@server. thirdstone. net> Delivered-To: guntis@latnet. lv Received: from server. thirdstone. net (unknown [66. 216. 98. 139]) by pumpis 4. latnet. lv (Postfix) with ESMTP id C 09 DF 4943 B for <guntis@latnet. lv>; Fri, 24 Mar 2006 15: 34: 29 +0200 (EET) Received: by server. thirdstone. net (Postfix, from userid 80) id 2628636 A 33 E; Fri, 24 Mar 2006 05: 40: 35 -0800 (PST) To: guntis@latnet. lv Subject: Your online account has been limited From: Chase Card Services Online Services Team <chaseonline@chaseonline. chase. com> Content-Type: text/html Message-Id: <20060324134035. 2628636 A 33 E@server. thirdstone. net> 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 tests=[BAYES_40=-0. 002, HTML_40_50=0. 496, HTML_IMAGE_ONLY_32=1. 052, HTML_MESSAGE=0. 001, HTML_TAG 2=0. 1, MESSAGE_ID_EXIST 1=-0. 1, MESSAGE_ID_EXIST 2=-0. 1, MIME_HEADER_CTYPE_ONLY=0, MIME_HTML_ONLY=0. 001, NO_DNS_FOR_FROM=3. 2, ONLINE_IN_BODY=0. 1, Reverse SARE_RD_GOOGLE=0. 8, URL_STARTS_WITH_WWW=-0. 1] X-Spam-Level: ***** DNS lookup Return-Path: <freuy@fifa. org> Received: from fifa. org (218 -175 -82 -64. dynamic. hinet. net [218. 175. 82. 64]) by alfred. taide. net (Postfix) with SMTP id 675 FB 3430 E for <guntis. barzdins@taide. net>; Sun, 26 Mar 2006 11: 12: 52 +0200 (CEST) Message-ID: <000001 c 650 b 5$5 fc 868 b 0$0548 a 8 c 0@cmb 1> Reply-To: "Aegle Freudenburg" <freuy@fifa. org> From: "Aegle Freudenburg" <freuy@fifa. org> To: guntis. barzdins@taide. net 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 4 d 8 e 508788 a 7565 e 07 ee 1405 c 73 c 45 f 1

Mail from El Presidente Return-Path: <elvis@graceland. org> Delivered-To: steve@blighty. com Received: from fake-name. example.

Mail from El Presidente Return-Path: <elvis@graceland. org> Delivered-To: steve@blighty. com Received: from fake-name. example. com (unknown [64. 71. 176. 18]) by gp. word-to-the-wise. com (Postfix) with SMTP id 3 DD 7790000 D 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 Mail Message-Id: <20031202205536. 3 DD 779@gp. word-to-the-wise. com> 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.

Sending spam (relay hijacking) Third-party mailserver (10. 11. 12. 13) Spammer (64. 71. 176. 18) SMTP Recipients MX POP 3

Sending spam (relay hijacking) Received: from openrelay. com (mail. openrelay. com [10. 11. 12.

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 3 DD 7790000 D 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 3 DD 7790000 D 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) Spammer (64. 71. 176. 18) SMTP POP 3 Recipients

Sending spam (direct to MX) Spammer (64. 71. 176. 18) SMTP POP 3 Recipients MX

Sending spam (direct to MX) Received: from fake-spammer-helo (spammer. net [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 3 DD 7790000 D for <steve@blighty. com>; 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.

Sending spam (proxy hijacking) Open proxy (192. 168. 1. 1) Spammer (64. 71. 176. 18) HTTP SMTP Recipients MX POP 3

Sending spam (proxy hijacking) Received: from fake-spammer-helo (open-proxy. net [192. 168. 1. 1]) by

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 3 DD 7790000 D for <steve@blighty. com>; Tue, 2 Dec 2003 12: 55: 36 -0800 (PST) You can see the open proxy

Mapping email to postal mail- the envelope ~ Sender ID’s authorization proof Mail From

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): –

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 • Domain. Keys: – 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

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.

Domain. Keys Under Domain. Keys, a domain owner generates one or more private/public key-pairs

Domain. Keys Under Domain. Keys, 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 "Domain. Key-Signature: " header to the email, and the message is transferred to its recipients in the usual way. When a message is received with a Domain. Key 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----MHww. DQYJKo. ZIhvc. NAQEBBQADaw. Awa. AJh. AKJ 2 lz. DLZ 8 Xl. Vamb. Qf. MXn 3 LRGKOD 5 o 6 l MIgulcl. Wj. Zw. P 56 LRqdg 5 ZX 15 bhc/Gsv. W 8 x. W/R 5 Sh 1 Nnk. JNy. L/cq. Y 1 a+Gzz. L 47 t 7 E Xz. Vc+n. RLWT 1 kw. Tv. FNGIo. AUs. FUq+J 6+Oprw. IDAQAB -----END PUBLIC KEY----This public-key data is placed in the DNS: _domainkey IN TXT "t=y; o=-; n=notes; r=email. Address"

Domain. Keys Example DNS TXT query for: brisbane. _domainkey. football. example. com Domain. Key-Status:

Domain. Keys Example DNS TXT query for: brisbane. _domainkey. football. example. com Domain. Key-Status: good Domain. Key-Signature: a=rsa-sha 1; s=brisbane; d=football. example. com; c=simple; q=dns; b=dzd. Vy. Of. AKCd. LXd. JOc 9 G 2 q 8 Lo. XSl. Eni. Sbav+yu. U 4 z. Geeru. D 00 lsz. Z Vo. G 4 ZHRNi. Yz. R; 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 Six. Pack" <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. 5 F 8 J@football. example. com> Hi. We lost the game. Are you hungry yet? Joe.

DNS to distribute Domain-Level Keys [Domain. Keys]

DNS to distribute Domain-Level Keys [Domain. Keys]

Domain. Keys

Domain. Keys

Domain. Keys • intra-domain authentication? • SK must be online • mail-forwarding services?

Domain. Keys • intra-domain authentication? • SK must be online • mail-forwarding services?

Return-Path: <ft. com@uk. update. ft. com> Delivered-To: guntis@latnet. lv Received: from update. ft. com

Return-Path: <ft. com@uk. update. ft. com> Delivered-To: guntis@latnet. lv Received: from update. ft. com (transit 246. email. mms. eloyalty. net [64. 73. 138. 246]) by pumpis 4. latnet. lv (Postfix) with ESMTP id 5 B 0115 A 5 DB for <guntis@latnet. lv>; Tue, 28 Mar 2006 15: 10: 43 +0300 (EEST) Domain. Key-Signature: a=rsa-sha 1; c=nofws; q=dns; s=ftcom; d=uk. update. ft. com; b=o. ILD 038 l. Hiby. Ksc 7 u. PFA 3 Qx 7 n 7 Cweg. CQe. NOAOIg+BZ 3 ZG+a. IE 68 Mc 5 z. B 6 Fd. Hr. Jl. Wb+ yxzk. YOlqmf 8 Qqzc 2 rm. JXOtwt. EFg. O 4 BGUYpm. Ga 6 m. Yv. Xoh. BJC 8 Lf 5 CFbnyr 0 Uju. GVz. U 46 O 249 STEJ 88 e+A 5 e. N 3 ep 9 Ovv. Br. Sx. GJ 9 HPn. GHds. E=; Received: by update. ft. com (Power. MTA(TM) v 3. 0 r 11) id h 54 jse 07 d 1 s 6 for <guntis@latnet. lv>; Tue, 28 Mar 2006 06: 10: 39 -0600 (envelope-from <ft. com@uk. update. ft. com>) From: "FT. com" <ft. com@uk. update. ft. com> To: <guntis@latnet. lv> Subject: The latest news and features on FT. com Date: Tue, 28 Mar 2006 06: 10: 42 -0600 Message-ID: <7 jzv 8 j 3782 t 5 nd 6 v 2 f. Sp 997 ml 2@uk. update. ft. com> Content-Return: allowed guntis@gulbis: ~$ nslookup MIME-Version: 1. 0 Content-Transfer-Encoding: quoted-printable > set type=any Content-Type: text/html; charset="iso-8859 -1" > uk. update. ft. com X-Virus-Scanned: amavisd-new 2. 3. 2 (20050629) at latnet. lv Server: 159. 148. 108. 1 Autentisks E-mails no ft. com 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 text = "v=spf 1 ip 4: 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=MIGf. MA 0 GCSq. GSIb 3 DQEBAQUAA 4 GNADCBi. QKBg. QCo. Nyixo 7 z. QAb 2 m. LAh. B 29 h. V 6 a 7 dj. DXr. TZBo 67 Wa+j Xyk. At 0 O 1 v. Fha. LE 1 p 5 b. FJnqh. Qzgm. T 91 e. Vw 58/Y 2+MWqusi. Przyc. SQl 7 FNsm. PW 2 i. Fqm. O 5 w. Jbaytjkqv. S 5 D w. Ei. B 4 a. HGQy. Cbi 1 Vobs 7 INFy 1 SAATdzq. XFD 8 GNKNZRuf 5 fmq. Hves. QIDAQAB" >