Separate Suites of Protocols
• Protocols for retrieving email:POP, IMAP, MAPI (Microsoft Exchange)
• Protocols for sending email:SMTP
2
POP (Post Office Protocol)
• Current version is POP3, RFC 1939.
• Client connects to POP server on port 110
• Originally, everything was sent in the clear.
• Yes, everything, including user name, password, and your mail.
• Now it’s common to connect instead to port 995 using SSL/TLS, same PKI as Web.
3
POP3 DialogS: <wait for connection on TCP port 110>C: <open connection>S: +OK POP3 server ready <[email protected]> C: USER mroseS: +OK User acceptedC: PASS tanstaafS: +OK Pass accepted C: STAT S: +OK 2 320 C: LISTS: +OK 2 messages (320 octets)S: 1 120S: 2 200S: .C: RETR 1S: +OK 120 octetsS: <the POP3 server sends message 1>C: QUITS: +OK dewey POP3 server signing off (maildrop empty)C: <close connection>S: <wait for next connection>
4
Experimenting with a POP3 Server
telnet pop.example.com 110
openssl s_client -connect pop.example.com:995 -quiet
5
APOP (RFC 1460)
S: <wait for connection on TCP port 110>C: <open connection>S: +OK POP3 server ready <[email protected]>C: APOP mrose c4c9334bac560ecc979e58001b3e22fbS: +OK mrose's maildrop has 2 messages (320 octets)
6
Other authentication methods include SASL and Kerberos.
• 1896.697170952 is a time stamp• shared secret is the password "tanstaaf“• Client applies MD5 algorithm to the string <[email protected]>tanstaaf
• which produces a digest value of c4c9334bac560ecc979e58001b3e22fb
• Password not sent in the clear, digest can’t be reused
IMAP (Internet Message Access Protocol)
• Current version is IMAP4, RFC 3501.
• Client connects to IMAP server on port 143.
• Originally, user name, password, mail sent in the clear.
• Now connect to port 993 using SSL/TLS.
7
IMAP Dialog
S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
8
More IMAP Authentication Mechanisms (RFC 1731)
Kerberos, GSSAPI, S/Key (like APOP)
Kerberos example:S: * OK IMAP4 ServerC: A001 AUTHENTICATE KERBEROS_V4S: + AmFYig== (random 32-bit number)C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh (ticket and an authenticator for the principal "imap.hostname@realm")
S: + or//EoAADZI= C: DiAF5A4gA+oOIALuBkAAmw==S: A001 OK Kerberos V4 authentication successful
9
SMTP (Simple Mail Transfer Protocol)
• Currently described in RFC 5321
• Client connects to SMTP server on port 25
• Originally everything was sent in the clear
• Originally client could send mail without authenticating! *** SPAM *** ***FORGERY***
• Port 465 used for SSL/TLS
• Sender’s SMTP server relays mail to receiver’s SMTP server
• DNS Mail Exchanger (MX) records used to resolve mail domain name to IP address of SMTP server of recipient, e.g., [email protected]
10
SMTP DialogS: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <[email protected]>
C: To: "Alice Example" <[email protected]>
C: Cc: [email protected]
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye {The server closes the connection} 12
STARTTLS
Instead of using separate ports for SSL/TLS connections, POP, IMAP, SMTP connections can be converted from plain text to encryped communications through the use of the STARTTLS command.
S: <waits for connection on TCP port 25> C: <opens connection> S: 220 mail.example.org ESMTP service ready C: EHLO client.example.org S: 250-mail.example.org offers a warm hug of welcome S: 250 STARTTLS C: STARTTLS S: 220 Go ahead C: <starts TLS negotiation> C & S: <negotiate a TLS session> C & S: <check result of negotiation> C: EHLO client.example.org
13
SMTP AUTH Extension
S: 220 smtp.example.com ESMTP Server
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250-AUTH GSSAPI DIGEST-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
... TLS negotiation proceeds. Further commands protected by TLS layer ...
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
S: 235 2.7.0 Authentication successful
14
Warning!
• Mail relayed between two SMTP servers might not be encrypted.
• (Even if sender and recipient connect securely to their SMTP and IMAP servers.)
15
SORBS (SPAM and Open-Relay Blocking System)
• Database of bad SMTP (blacklisted) relays accessed through DNS
• Mail won’t be accepted from these relays
(Also SPAMHAUS database.)
16
Proving your SMTP Relay is Legit
• Register reverse DNS name
• DKIM – relay signs headers with its private key, receiver can verify that relay is in the same domain (e.g., cs.duke.edu) as sender
• SPF – list of which servers are permitted to originate email for which domains, accessed via DNS
17
Signing Your Email
• PGP (Pretty Good Privacy)
• Certificate signed by certificate authority, e.g., Comodo.
18
PGP
• Developed by Phil Zimmerman
• OpenPGP standard described in RFC 4880
• Public key bound to user name or email address
• No centralized certificate authority in original design
• Public keys can be signed by other users attesting to their authenticty, often at key-signing parties
• Supported in Thunderbird, Pine, with plug-in in Outlook.
19