SMTP

1. SMTP Tapu Ahmed Jeremy Nunn

2. Basics • Responsible for electronic mail delivery. • Simple ASCII protocol that runs on top of TCP/IP. • Uses reserved port number 25.

3. SMTP Model A B You want to send an E-Mail from A to B. Both A and B are simple workstations.

4. A submits source and destination. If both are valid, server gives the go-ahead signal If, server is busy, client will cancel connection and try again. A Server B If server can accept mail, the client submits. Port 25 We will first attempt the destination server to see if it will accept mail.

5. Our goal is to send a mail from A to B A B A A Step 1 Step 2 Step 3 Send Req ACK Send Mail ACK Local Mail Server Local Mail Server will store and queue DNS Query Local Mail Server DNS Server Reply with IP address resolution

6. Step 4 Step 5 Step 6 REQ Send Server A Server B Server A Server B: receive/store Server B ACK ACK Ring B ACK SMTP protocol exists here, between the two servers and their “jumps.” Optional

7. The exchange of mails using TCP/IP is performed by a message transfer agent (MTA). • An MTA is responsible for routing mails to their proper destinations. • MTA uses the Mail Exchange (MX) record from a DNS server to determine location. • In essence, the SMTP protocol describes how two MTAs communicate with each other using a single TCP connection.

8. Sending Host Queue User A Relay MTA Local MTA Local MTA Local MTA Relay MTA Local MTA Local MTA Local MTA Across the internet User Mailboxes User B Receiving Host Queue of mail Queue of mail

9. Topics for SMTP • SMTP Description • Primarily RFC 821 and 822 • Message formats • Extensions • SMTP Applications • Purpose • Operations • Unique problems encountered.

10. Topics for SMTP continued • Security and performance issues • Hacking • End-end delivery system performance • Spamming issues • Looking Ahead • Future standardizations

11. RFC 821 • A Description of SMTP • Objective is to deliver mail reliably and efficiently. • Points of interest • Mailing/sending • Forwarding • Relaying • Opening/closing

12. SMTP Procedure • MAIL command • Clear buffer and get ready to receive mail • Gives sender ID • RCPT command • Gives receiver information • DATA command • Send the data

13. S: MAIL FROM: group@yahoo.com • R: OK • S: RCPT TO: person1@yahoo.com • R: OK • S: RCPT TO: person2@yahoo.com • R: ERROR; no such user here • S: RCPT TO: person3@yahoo.com • R: OK • S: DATA • send mails • Ending signature • R: OK

14. RFC 821 also provides: • Verification • SMTP commands and syntax structure • State diagrams • Sequencing of commands and replies • Extensions: • RFC 1869 • EHLO command • MAIL, RCPT, DATA can all receive additional values.

15. RFC (2)822 • Describes message formatting for SMTP. • RFC 822 is the standard for the format of internet text messages. • RFC 2822: new standard • Points of interest • Message specifications • Date/time specifications • Address specifications • Different RFC extensions

16. Limitations: • 998 character/line max. 78 min. • Only ASCII characters • Header: • Composed of a field name • Terminates by a “:”, and ends with CRLF. • Address Specification: • Individual or an entire mailbox • Occurs in multiple fields to indicate sender or receiver

17. Date and Time Specification • Must be semantically valid. • Added on through numerous headers. • Extensions: • RFC 2045 and 2046 • Describe mechanisms for transmission

18. SMTP Applications • Several SMTP applications exist, too numerous to enumerate • qmail • Configuration is “unique” (one file to one config value) • Places many files in the root of your system • Awkward license prevents distributing modified source or binaries • Developer/owner is a busy guy • sendmail • Past and current versions (8) have been notoriously insecure • Remote root exploits, etc.

19. SMTP Applications • Postfix • Uses sensible defaults • Good security track record • Easier to configure • Can query LDAP to pick up new/modified users • Microsoft Exchange • Very easy to use on a Windows network • Integrates with Active Directory (uses LDAP) • Not the best security

20. Security and Performance • Who needs security? • When SMTP was initially developed, little (none maybe?) emphasis was placed on security • Design was built on the idea of cooperation and trust • Didn’t anticipate spam • Mail Relay • Relay is sending mail from one mail server to another • Most SMTP servers didn’t check authenticity of users

21. Security and Performance • Bulk mails • Unsolicited bulk mailers take advantage of this • Decreases performance of server for rightful users • Relay Restrictions • Verify that the computer is on the server’s local network • Require a local domain return address • Do not accept mail from other open relay servers

22. Security and Performance • How about a new SMTP? • The problem is obvious, so let’s change the protocol • No guaranteed way to implement without creating incompatibilities • We like the idea of cooperation • Maybe there’s another way

23. Security and Performance • Other Security Measures • Limit the use of commands • Check the validity of the envelope • Limit the size of the email • Limit the number of emails that may be sent in a given amount of time • Log everything • POP-before-SMTP Authentication • Note that SMTP has no mechanism for privacy (encryption). • This has to be done at a higher level if needed • Currently is application specific

24. Future Projections Current projects include: • Sender Policy Framework (SPF) • Only certain servers are allowed to forward mail from certain domain names • Easy to check • New DNS Blackhole Lists • Narrowly identify specific invalid senders • Will be viable once a large enough number of servers support this • Spam Filtering • Intelligent, self-learning software • Good job of identifying unwanted messages that get through • Greylisting • Receiving servers make sending servers wait • Spammers probably won’t come back • More time means more chances to add the offender to the blackhole list