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
Introduction (cont)

• 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.

4
SMTP Model
5
SMTP Procedure

• 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 FROMSmith_at_Alpha.ARPA
• R 250 OK
• S RCPT TOJones_at_Beta.ARPA
• R 250 OK
• S RCPT TOGreen_at_Beta.ARPA
• R 550 No such user here
• S RCPT TOBrown_at_Beta.ARPA
• R 250 OK
• S DATA
• R 354 Start mail input end with ltCRLFgt.ltCRLFgt
• S Blah blah blah...
• S ...etc. etc. etc.

6
SMTP Procedure (Cont..)

• Forwarding
• There are some cases where the destination
  information in the ltforward-pathgt is incorrect,
  but the receiver SMTP knows the correct
  destination.
• S RCPT TOPostel_at_USC-ISI.ARPA
• R 251 User not local will forward to
  ltPostel_at_USC-ISIF.ARPAgt
• Or
• S RCPT TOltPaul_at_USC-ISIB.ARPAgt
• R 551 User not local please try
  ltMockapetris_at_USC-ISIF.ARPAgt
• 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
SMTP Procedure (Cont..)

• S VRFY Smith
• R 250 Fred Smith ltSmith_at_USC-ISIF.ARPAgt
• Or
• S VRFY Smith
• R 251 User not local will forward to
  ltSmith_at_USC-ISIQ.ARPAgt
• Or
• S VRFY Jones
• R 550 String does not match anything.
• Or
• S VRFY Jones
• R 551 User not local please try
  Jones_at_USC-ISIQ.ARPA
• Or
• S VRFY Gourzenkyinplatz
• R 553 User ambiguous.
• S EXPN Example-People
• R 250-Jon Postel Postel_at_USC-ISIF.ARPA
• R 250-Fred Fonebone Fonebone_at_USC-ISIQ.ARPA
• R 250-Sam Q. Smith SQSmith_at_USC-ISIQ.ARPA

8
SMTP Procedure (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 ltSPgt FROMltreverse-pathgt ltCRLFgt
• 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 ltSPgt FROMltreverse-pathgt ltCRLFgt
• 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 ltSPgt FROMltreverse-pathgt ltCRLFgt
• 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
SMTP Procedure (Cont..)

• OPENING AND CLOSING
• The following two commands are used in
  transmission channel opening and closing
• HELO ltSPgt ltdomaingt ltCRLFgt
• QUIT ltCRLFgt
• 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 ltspgt ltdomaingtltcrlfgt MAIL ltspgtFROMltreverse
pathgtltcrlfgt RCPT ltspgtTOltforward
pathgtltcrlfgt DATAltcrlfgt terminates with
ltcrlfgt.ltcrlfgt RSETltcrlfgt SENDltspgtFROMltreverse
pathgtltcrlfgt SOMLltspgtFROMltreverse
pathgtltcrlfgt SAMLltspgtFROMltreverst
pathgtltcrlfgt VRFYltspgtltstringltcrlfgt EXPNltspgt
ltstringgtltcrlfgt HELPltspgtltstringgtltcrlfgt NOOPltcrlfgt Q
UITltcrlfgt TURNltcrlfgt
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
• ltcrlfgt.ltcrlfgt 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
• ltstringgt 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 - ltdomaingt Service ready
• 221 - ltdomaingt Service closing transmission
  channel
• 250 - Requested mail action OK, ready
• 251 - User not local, will forward to ltforward
  pathgt
• 354 - Start mail input end with ltcrlfgt.ltcrlfgt
• 421 - ltdomaingt 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 ltforward pathgt
• 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
SECURITY CONSIDERATIONS

• Mail Security and Spoofing

• 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.

19
SECURITY CONSIDERATIONS (Cont..)

• Blind Copies

• 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.

20
SECURITY CONSIDERATIONS (Cont..)

• VRFY, EXPN, and Security

• 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.

21
SECURITY CONSIDERATIONS (Cont..)

• Information Disclosure in Message Forwarding

• 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.

22
References

• References
• 1http//www.zvon.org/tmRFC/RFC2821/Output/index.
  html
• 2http//www.ietf.org/rfc/rfc0821.txt
• 3http//www.faqs.org/rfcs/rfc2821.html
• 4http//www.cert.org/tech_tips/email_spoofing.ht
  mlIII
• 5http//www.livinginternet.com/e/ea_bcc.htm