SMTP Tapu Ahmed Jeremy Nunn

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

SMTP Model You want to send an from A to B. Both A and B are simple workstations. AB

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

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

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

The exchange of mails using TCP/IP is performed by a message transfer agent (MTA). 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. In essence, the SMTP protocol describes how two MTAs communicate with each other using a single TCP connection.

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

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

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

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

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

S: MAIL FROM: S: MAIL FROM: R: OK R: OK S: RCPT TO: S: RCPT TO: R: OK R: OK S: RCPT TO: S: RCPT TO: R: ERROR; no such user here R: ERROR; no such user here S: RCPT TO: S: RCPT TO: R: OK R: OK S: DATA S: DATA –send mails –Ending signature R: OK R: OK

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

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

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

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

SMTP Applications Several SMTP applications exist, too numerous to enumerate Several SMTP applications exist, too numerous to enumerate qmail 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 sendmail –Past and current versions (8) have been notoriously insecure –Remote root exploits, etc.

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

Security and Performance Who needs security? 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 Mail Relay –Relay is sending mail from one mail server to another –Most SMTP servers didn’t check authenticity of users

Security and Performance Bulk mails Bulk mails –Unsolicited bulk mailers take advantage of this –Decreases performance of server for rightful users Relay Restrictions 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

Security and Performance How about a new SMTP? 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

Security and Performance Other Security Measures Other Security Measures –Limit the use of commands –Check the validity of the envelope –Limit the size of the –Limit the number of s 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). Note that SMTP has no mechanism for privacy (encryption). –This has to be done at a higher level if needed –Currently is application specific

Future Projections Current projects include: Sender Policy Framework (SPF) Sender Policy Framework (SPF) –Only certain servers are allowed to forward mail from certain domain names –Easy to check New DNS Blackhole Lists New DNS Blackhole Lists –Narrowly identify specific invalid senders –Will be viable once a large enough number of servers support this Spam Filtering Spam Filtering –Intelligent, self-learning software –Good job of identifying unwanted messages that get through Greylisting 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