1 / 47

Electronic mail – protocol evolution

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

malik-rodriguez
Télécharger la présentation

Electronic mail – protocol evolution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Electronic mail – protocol evolution

  2. E-mail standards

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

  4. Email terminology

  5. SMTP (RFC 821)

  6. 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: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@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

  7. 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

  8. RFC 822 format

  9. 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

  10. ASCII times are over! Now we want: • National language support • Possibility to send • pictures • audiofiles • other applications • video files • multimedia applications

  11. 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

  12. MIME

  13. MIME types and sub-types

  14. base64 encoding

  15. SMTP: protocol for exchanging email msgs RFC 822: standard for text message format: header lines, e.g., To: From: Subject: differentfrom SMTP commands! body the “message”, 7-bit ASCII characters only Mail message format header blank line body

  16. MIME: multimedia mail extension, RFC 2045, 2056 additional lines in msg header declare MIME content type From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data Message format: multimedia extensions MIME version method used to encode data multimedia data type, subtype, parameter declaration encoded data

  17. 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: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data --98766789--

  18. Multipart Type From: alice@crepes.fr To: bob@hamburger.edu 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?

  19. 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 user agent sender’s mail server SMTP Mail access protocols SMTP access protocol receiver’s mail server

  20. 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)

  21. Post Office Protocol (POP3)

  22. 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: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on POP3 protocol 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

  23. IMAP

  24. Web Mail http://www.squirrelmail.org

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

  26. Outgoing mail authenticationRDC 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: 334U0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== S: 235 Authentication successful.

  27. 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 pumpis4.latnet.lv (Postfix) with ESMTP id C09DF4943B for <guntis@latnet.lv>; 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: 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.2628636A33E@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_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: ***** Reverse 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 675FB3430E for <guntis.barzdins@taide.net>; Sun, 26 Mar 2006 11:12:52 +0200 (CEST) Message-ID: <000001c650b5$5fc868b0$0548a8c0@cmb1> 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 4d8e508788a7565e07ee1405c73c45f1

  28. 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 3DD7790000D 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.3DD779@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

  29. Sending spam (relay hijacking) Third-party mailserver (10.11.12.13) SMTP Spammer (64.71.176.18) SMTP POP3 Recipients MX

  30. 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 <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 3DD7790000D for <steve@blighty.com>; Tue, 2 Dec 2003 12:55:36 -0800 (PST) You can see the relay, and the original spammer

  31. Sending spam (direct to MX) SMTP POP3 Spammer (64.71.176.18) Recipients MX

  32. 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 <steve@blighty.com>; Tue, 2 Dec 2003 12:55:36 -0800 (PST) You can see the spammer

  33. Sending spam (proxy hijacking) Open proxy (192.168.1.1) HTTP Spammer (64.71.176.18) SMTP POP3 Recipients MX

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

  35. ~ Sender ID’s authorization proof Mapping email to postal mail- the envelope Mail From /Envelope From / Return Path Recipient To

  36. 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

  37. 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.

  38. 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 theemail, and the message is transferred to its recipients in the usualway. 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"

  39. 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" <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.5F8J@football.example.com> Hi. We lost the game. Are you hungry yet? Joe.

  40. DNS to distributeDomain-Level Keys [DomainKeys]

  41. DomainKeys

  42. DomainKeys • intra-domain authentication? • SK must be online • mail-forwarding services?

  43. Return-Path: <ft.com@uk.update.ft.com> Delivered-To: guntis@latnet.lv Received: from update.ft.com (transit246.email.mms.eloyalty.net [64.73.138.246]) by pumpis4.latnet.lv (Postfix) with ESMTP id 5B0115A5DB for <guntis@latnet.lv>; 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 <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: <7jzv8j3782t5nd6v2fSp997ml2@uk.update.ft.com> Content-Return: allowed MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" X-Virus-Scanned: amavisd-new 2.3.2 (20050629) at latnet.lv AutentisksE-mails no ft.com guntis@gulbis:~$ nslookup > set type=any > uk.update.ft.com Server: 159.148.108.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+jXykAt0O1vFhaLE1p5bFJnqhQzgmT91eVw58/Y2+MWqusiPrzycSQl7FNsmPW2iFqmO5wJbaytjkqvS5DwEiB4aHGQyCbi1Vobs7INFy1SAATdzqXFD8GNKNZRuf5fmqHvesQIDAQAB" >

More Related