SMTP

1. SMTP Simple Mail Transfer Protocol Crypto2006 CMPE 208

2. Introduction • to transfer mail reliably and efficiently. • is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. • capability to transport mail across networks, usually referred to as “SMTP mail relaying”. • a process can transfer mail to another process on the same network or to some other network via a relay or gateway process accessible to both networks.

3. a mail message may pass through a number of intermediate relay or gateway hosts on its path from sender to ultimate recipient. the Mail exchanger mechanisms of the domain name system are used to identify the appropriate next-hop destination for a message being transported. Introduction (cont…)

4. SMTP Model

5. SMTPProcedure There are three steps in SMTP mail transactions. The transaction is started with a MAIL command which gives the sender identification and if accepted the receiver-SMTP returns a 250 OK reply. A series of one or more RCPT commands follows giving the receiver information. If accepted, the receiver-SMTP returns a 250 OK reply, and stores the forward-path. If the recipient is unknown the receiver-SMTP returns a 550 Failure reply. Then a DATA command gives the mail data. If accepted, the receiver-SMTP returns a 354 Intermediate reply and considers all succeeding lines to be the message text. And finally, the end of mail data indicator confirms the transaction. When the end of text is received and stored the SMTP-receiver sends a 250 OK reply. This SMTP example shows mail sent by Smith at host Alpha.ARPA, to Jones, Green, and Brown at host Beta.ARPA.   S: MAIL FROM:Smith@Alpha.ARPA R: 250 OK S: RCPT TO:Jones@Beta.ARPA R: 250 OK S: RCPT TO:Green@Beta.ARPA R: 550 No such user here S: RCPT TO:Brown@Beta.ARPA R: 250 OK S: DATA R: 354 Start mail input; end with <CRLF>.<CRLF> S: Blah blah blah... S: ...etc. etc. etc. S: <CRLF>.<CRLF> R: 250 OK

6. SMTPProcedure(Cont..) • Forwarding There are some cases where the destination information in the <forward-path> is incorrect, but the receiver SMTP knows the correct destination. S: RCPT TO:Postel@USC-ISI.ARPA R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA> Or S: RCPT TO:<Paul@USC-ISIB.ARPA> R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA> • VERIFYING AND EXPANDING SMTP provides as additional features, commands to verify a user name or expand a mailing list which is done by VRFY and EXPN commands. For the VRFY command, the string is a user name, and the response may include the full name of the user and must include the mailbox of the user. For the EXPN command, the string identifies a mailing list, and the multiline response may include the full name of the users and must give the mailboxes on the mailing list.

7. SMTPProcedure(Cont..) • S: VRFY Smith R: 250 Fred Smith <Smith@USC-ISIF.ARPA> Or S: VRFY Smith R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA> Or S: VRFY Jones R: 550 String does not match anything. Or S: VRFY Jones R: 551 User not local; please try Jones@USC-ISIQ.ARPA Or S: VRFY Gourzenkyinplatz R: 553 User ambiguous. • S: EXPN Example-People R: 250-Jon Postel Postel@USC-ISIF.ARPA R: 250-Fred Fonebone Fonebone@USC-ISIQ.ARPA R: 250-Sam Q. Smith SQSmith@USC-ISIQ.ARPA R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> R: 250-joe@foo-unix.ARPA R: 250 <xyz@bar-unix.ARPA>

8. SMTPProcedure (Cont…) • Sending and Mailing This service is provided by some hosts is to deliver messages to user's terminals (provided the user is active on the host). The delivery to the user's mailbox is called "mailing", the delivery to the user's terminal is called "sending". The following three commands are defined to support the sending options. SEND <SP> FROM:<reverse-path> <CRLF> The SEND command requires that the mail data be delivered to the user's terminal. If the user is not active (or not accepting terminal messages) on the host a 450 reply may returned to a RCPT command. The mail transaction is successful if the message is delivered the terminal. SOML <SP> FROM:<reverse-path> <CRLF> The Send Or Mail command requires that the mail data be delivered to the user's terminal if the user is active (and accepting terminal messages) on the host. If the user is not active (or not accepting terminal messages) then the mail data is entered into the user's mailbox. The mail transaction is successful if the message is delivered either to the terminal or the mailbox. SAML <SP> FROM:<reverse-path> <CRLF> The Send And Mail command requires that the mail data be delivered to the user's terminal if the user is active (and accepting terminal messages) on the host. In any case the mail data is entered into the user's mailbox. The mail transaction is successful if the message is delivered the mailbox.

9. SMTPProcedure(Cont..) • OPENING AND CLOSING The following two commands are used in transmission channel opening and closing: HELO <SP> <domain> <CRLF> QUIT <CRLF> R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready S: HELO USC-ISIF.ARPA R: 250 BBN-UNIX.ARPA S: QUIT R: 221 BBN-UNIX.ARPA Service closing transmission channel

10. SMTP Procedure (Cont.) • RELAYING: This form is used to emphasize the distinction between an address and a route. The mailbox is an absolute address, and the route is information about how to get there. • DOMAINS: The use of domains changes the address space from a flat global space of simple character string host names to a hierarchically structured rooted tree of global addresses. • CHANGING ROLES: The TURN command may be used to reverse the roles of the two programs communicating over the transmission channel. If program-A is currently the sender-SMTP and it sends the TURN command and receives an ok reply (250) then program-A becomes the receiver-SMTP. If program-B is currently the receiver-SMTP and it receives the TURN command and sends an ok reply (250) then program-B becomes the sender-SMTP. To refuse to change roles the receiver sends the 502 reply.

11. SMTP Commands HELO <sp> <domain><crlf> MAIL <sp>FROM:<reverse path><crlf> RCPT <sp>TO:<forward path><crlf> DATA<crlf> terminates with <crlf>.<crlf> RSET<crlf> SEND<sp>FROM:<reverse path><crlf> SOML<sp>FROM:<reverse path><crlf> SAML<sp>FROM:<reverst path><crlf> VRFY<sp><string<crlf> EXPN<sp> <string><crlf> HELP<sp><string><crlf> NOOP<crlf> QUIT<crlf> TURN<crlf>

12. Commands • HELO • identifies the client to the server, fully qualified domain name, only sent once per session • MAIL • initiate a message transfer, fully qualified domain of originator • RCPT • follows MAIL, identifies an addressee, typically the fully qualified name of the addressee • for multiple addressees use one RCPT for each addressee • DATA • send data line by line • <crlf>.<crlf> tells server data transfer is over

13. Commands • RSET • tells server to abort current message and clear all of it buffers • same state as after HELO • SEND , SOML , SAML • like MAIL, outdated not used any more • VRFY • ask server to verify a user name • server replies positively of it knows user, negatively if not • EXPN • ask server to confirm mailing list alias • server reply is multi-line, one per user

14. Commands • HELP • ask server for help • by itself get a list of server supported commands • <string> get help for that command • NOOP • ask server to respond with a positive reply • QUIT • tell server that client is ending session • server replies positively and closes connection • TURN • reverse roles of client and server • outdated, rarely used on modern internet

15. Reply codes • 211 - System status or help ready • 214 - Help message • 220 - <domain> Service ready • 221 - <domain> Service closing transmission channel • 250 - Requested mail action OK, ready • 251 - User not local, will forward to <forward path> • 354 - Start mail input; end with <crlf>.<crlf> • 421 - <domain> Service not avail, closing transmission channel • 450 - Requested mail action not taken, mailbox not available • 451 - Requested action aborted, local error • 452 - Requested action not taken, insufficient storage • 500 - Syntax error, command unrecognized • 501 - Syntax error in parameters • 502 - Command not implemented • 503 - Bad sequence of commands • 504 - Command Parameter not implemented

16. Reply codes (more) • 550 - Requested action not taken, mailbox unavailable • 551 - User not local, please try <forward path> • 552 - Requested mail action not taken; exceeded storage allocation • 553 - Requested action not taken, mailbox name not allowed • 554 - Transaction failed

17. State Diagram for Commands For each command there are three possible outcomes: “success”(S), “failure”(F), and “error” (E). In the state diagram below we use the symbol B for “begin”, and the symbol W for “waite for reply”.

18. SECURITYCONSIDERATIONS • SMTP mail is inherently insecure and the messages can be spoofed easily. • SMTP mail inherently cannot be authenticated, or integrity checks provided, at the transport level. • Various protocol extensions and configuration options for authentication. • Using cryptographic signatures to identify the sender and to ensure that the message has not been altered in transit. • Configure the mail delivery daemon to prevent someone from directly connecting to your SMTP port to send spoofed email to other sites. • Consider a single port of entry for email by configuring the firewall so that the SMTP connections outside the firewall will go through the central mail hub. This will assist in detecting the origin of the mail spoofing attempts. Mail Security and Spoofing

19. SECURITYCONSIDERATIONS (Cont..) • Addresses that do not appear in the message header can be seen in the RCPT • Commands because of the following reasons: • 1. List Exploder • 2. Blind Copies • When more than one RCPT command is present, and in order to perform the above • Mechanisms, • Sending SMTP that are aware of “bcc” use may send each blind copy as a • separate message transaction containing only a single RTCP command • Receiving SMTP should not alter the headers of the message for delivery. “Blind” Copies

20. SECURITYCONSIDERATIONS (Cont..) • Individual sites may want to disable either or both of VRFY or EXPN command for • security reasons. • The SMTP server must send a 252 response. • The contents of mailing lists have become popular as an address source for spammers • So the administrators have installed protections against the use of the lists for themselves. • Implementations should still provide support for EXPN • Some sites choose to make EXPN available only to authenticated requesters. • Information Disclosure in Announcements • Some experts argue that there are some advantages in debugging if you know the server type • and version in the greeting response or in response to the HELP command. • Implementations are strongly encouraged to minimally provide for making type and version • information available. VRFY, EXPN, and Security

21. SECURITYCONSIDERATIONS (Cont..) • Reply codes to identify the replacement address associated with a mailbox may • inadvertently disclose sensitive information. • Sites that are concerned about those issues should ensure that they select • and configure servers appropriately. • Scope of Operation of SMTP Servers • It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reasons of the site providing the server. • So, considerable care should be taken if a site decides to be selective about the traffic. • However, some sites have decided to limit the use of the relay function to known or identifiable source. • Implementations should be performed for this type of filtering. • When the mail is rejected, a 550 code is used in response to HELO, MAIL, or RCPT as appropriate. Information Disclosure in Message Forwarding

22. References References: [1]http://www.zvon.org/tmRFC/RFC2821/Output/index.html [2]http://www.ietf.org/rfc/rfc0821.txt [3]http://www.faqs.org/rfcs/rfc2821.html [4]http://www.cert.org/tech_tips/email_spoofing.html#III [5]http://www.livinginternet.com/e/ea_bcc.htm