Electronic mail – protocol evolution

standards

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 mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP

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: S: 250 Sender ok C: RCPT TO: S: 250 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 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 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 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 From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data multimedia data type, subtype, parameter declaration method used to encode data MIME version encoded data

Multipart Type From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data

Multipart Type From: To: 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 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 sender’s mail server user agent SMTP access protocol 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 without using 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 C: list S: S: S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: 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

IMAP

Web Mail

(Adjusted) Mail Architecture petrel alpha admsrvcs Anti-virus Director Content Filter smtp smtp_internal smtp_notify smtp_externel mx=10 “smtp_external” mx=20 “smtp_backup” mx=30 “smtp.ecs.” | “smtp” Off-Campus Antispam parrot root mail

Mail from El Presidente Return-Path: Delivered-To: Received: from fake-name.example.com (unknown [ ]) by gp.word-to-the-wise.com (Postfix) with SMTP id 3DD D for ; Tue, 2 Dec :55: (PST) From: El Presidente To: Steve Atkins Subject: Fake Mail Message-Id: Date: Tue, 2 Dec :55: (PST) Status: RO Content-Length: 15 Lines: 1 Some body text

Sending spam (relay hijacking) SMTP POP3 SMTP Third-party mailserver ( ) Recipients MX Spammer ( )

Sending spam (relay hijacking) Received: from openrelay.com (mail.openrelay.com [ ]) by gp.word-to-the-wise.com (Postfix) with SMTP id 3DD D for ; Tue, 2 Dec :55: (PST) Received: from fake-spammer-helo (spammer.net [ ]) by openrelay.com (Postfix) with SMTP id 3DD D for ; Tue, 2 Dec :55: (PST) You can see the relay, and the original spammer

Sending spam (direct to MX) SMTPPOP3 Recipients MX Spammer ( )

Sending spam (direct to MX) Received: from fake-spammer-helo (spammer.net [ ]) by gp.word-to-the-wise.com (Postfix) with SMTP id 3DD D for ; Tue, 2 Dec :55: (PST) You can see the spammer

Sending spam (proxy hijacking) HTTP POP3 SMTP Open proxy ( ) Recipients MX Spammer ( )

Sending spam (proxy hijacking) Received: from fake-spammer-helo (open-proxy.net [ ]) by gp.word-to-the-wise.com (Postfix) with SMTP id 3DD D for ; Tue, 2 Dec :55: (PST) You can see the open proxy

Sending spam (trojans) IRC? POP3 SMTP Infected computer ( ) Recipients MX Spammer ( )

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

Authentication Proposals Client SMTP Validation (CSV): – Bounce Address Tag Validation (BATV): – DomainKeys: – Identified Internet Mail (IIM): – Sender ID (SPF + PRA): – –

SPF: Sender Policy Framework Domains use public records (DNS) to direct requests for different services (web, , etc.) to the machines that perform those services. All domains already publish (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, , etc.) to the machines that perform those services. All domains already publish (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 ? o Do independent accreditation services consider that domain's policies and practices sufficient for controlling abuse? CSV considers two questions at the start of each SMTP session: o Does a domain's management authorize this MTA to be sending ? o Do independent accreditation services consider that domain's policies and practices sufficient for controlling abuse?

Identified Internet Mail (IIM): Identified Internet Mail (IIM) provides a means by which cryptographic signatures can be applied to messages to demonstrate that the sender of the message was authorized to use a given 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 address. Identified Internet Mail (IIM) provides a means by which cryptographic signatures can be applied to messages to demonstrate that the sender of the message was authorized to use a given 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 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 system. When an is submitted by an authorized user of that domain, the system uses the private-key to digitally sign the associated with the sending domain. The signature is added as a "DomainKey-Signature:" header to the , 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 Fetch the public-key from the claimed sending domain namespace. 3. Use public-key to determine whether the signature of the has been generated with the corresponding private-key, and thus whether the was sent with the authority of the claimed sending domain. In the event that an 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 . 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 system. When an is submitted by an authorized user of that domain, the system uses the private-key to digitally sign the associated with the sending domain. The signature is added as a "DomainKey-Signature:" header to the , 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 Fetch the public-key from the claimed sending domain namespace. 3. Use public-key to determine whether the signature of the has been generated with the corresponding private-key, and thus whether the was sent with the authority of the claimed sending domain. In the event that an 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 . $ 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= Address" $ 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= Address"

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 football.example.com [ ] by submitserver.football.example.com with SUBMISSION; Fri, 11 Jul :01: (PDT) From: "Joe SixPack" To: "Suzie Q" Subject: Is dinner ready? Date: Fri, 11 Jul :00: (PDT) Message-ID: 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 football.example.com [ ] by submitserver.football.example.com with SUBMISSION; Fri, 11 Jul :01: (PDT) From: "Joe SixPack" To: "Suzie Q" Subject: Is dinner ready? Date: Fri, 11 Jul :00: (PDT) Message-ID: 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

Two authentication strategies compared IP based (Sender ID) Find outbound IPs, publish in DNS Receiver verifies mail from authorized IP Sender is not authenticated -- Last IP to touch mail is Forwarders & mail lists must change before technology can be fully used Digital Signature (DomainKeys) Generate public/private keys, publish public-key in DNS Sign mail with private-key Receiver verifies signature Original Sender is authenticated In transit modifications may invalidate signature 19