Linux Interview Questions: Sendmail

The below questions are not my own, you can reach the author at 
-Ian! D. Allen - idallen@idallen.ca - http://www.idallen.com/

A common misconception: the place/protocol you use to fetch your email
is the same place/protocol that you use to send your email:
   - sending email uses SMTP
   - reading email uses POP3 or IMAP
   - they can be completely separate machines

   http://wiki.mutt.org/?MailConcept

Q: T/F, unlike POP3, SMTP can be used to both send and receive email.
Q: T/F, unlike SMTP, POP3 can be used to both receive and send email.

   - may be completely different servers
   - though note POP-before-SMTP (SMTP-after-POP) requires coupling:

   http://tools.ietf.org/html/rfc2476 (section 3.3)

   "Requiring a POP [POP3] authentication (from the same IP address)
    within some amount of time (for example, 20 minutes) prior to the
    start of a message submission session has also been used, but this
    does impose restrictions on clients as well as servers which may
    cause difficulties.  Specifically, the client must do a POP
    authentication before an SMTP submission session, and not all clients
    are capable and configured for this.  Also, the MSA must coordinate
    with the POP server, which may be difficult.  There is also a window
    during which an unauthorized user can submit messages and appear to
    be a prior authorized user."

Q: Describe briefly how POP-before-SMTP works to authenticate an SMTP session.

MUA - Mail User Agent (email client)
  - the user's interface to the protocols - "presentation layer"
  - usually gives access to functionality of both MTA and MRA/MAA
    - but may not itself implement any protocols (may read/write file system)

  http://en.wikipedia.org/wiki/Mail_user_agent
   "An e-mail client, also called a Mail User Agent (MUA), is a computer
    program that is used to read and send e-mail.

    Originally, the MUA was intended to be a simple program to read the user's
    mail messages, which the mail delivery agent (MDA) in conjunction with
    the mail transfer agent (MTA) would transfer into a local mailbox.

    The most important mailbox formats are mbox and Maildir. These rather
    simple protocols for locally storing e-mails make import, export and
    backup of mailfolders quite easy.

    E-mails to be sent would be handed over to the MTA, perhaps via
    a mail submission agent [MSA], therefore an MUA would not have to
    provide any transport-related functions.

   *Since the various Microsoft Windows versions intended for home use never
   *provided an MTA, most modern MUAs have to support protocols like POP3
   *and Internet Message Access Protocol (IMAP) to communicate with a remote
   *MTA located at the e-mail providers machine."
 
 - user agents (MUAs) are user-visible email clients of all descriptions
 - e.g. mutt, "mail", "Mail", "mailx", pine, elm
 - e.g. KMail, Eudora, MS Outlook
 - e.g. web-browser email (Netscape Messenger,Mozilla,Thunderbird)
 - e.g. webmail, Horde, SqurrelMail

 http://en.wikipedia.org/wiki/List_of_mail_servers#POP.2FIMAP

Q: Briefly describe the function of a mail system MUA.

MSA - Mail Submission Agent
  http://tools.ietf.org/html/rfc2476
   "acts as a submission server to accept messages from MUAs, and either
    delivers them or acts as an SMTP client to relay them to an MTA."

  - enforce policy (no open relay)
  - enforce standards (no forged headers, etc.)
  - enforce filtering (SpamAssassin, etc.)
  - may modify messages (section 8 of RFC)

  http://en.wikipedia.org/wiki/List_of_mail_servers#Mail_filtering

Q: Briefly describe the function of a mail system MSA.

MTA - Mail Transfer Agent (mail server, mail exchange server)
   "A process which conforms to [SMTP-MTA], which acts as an SMTP server to
    accept messages from an MSA or another MTA, and either delivers them or
    acts as an SMTP client to relay them to another MTA."

  http://en.wikipedia.org/wiki/Mail_transfer_agent
   "It receives messages from another MTA (relaying), a mail
    submission agent (MSA) that itself got the mail from a mail user
    agent (MUA), or directly from an MUA, thus acting as an MSA
    itself. The MTA works behind the scenes, while the user usually
    interacts with the MUA.  The delivery of e-mail to a user's
    mailbox typically takes place via a mail delivery agent (MDA);
    many MTAs have basic MDA functionality built in, but a dedicated
    MDA like procmail can provide more sophistication."

 - transfers email between machines (other MTAs) via SMTP
 - Internet-facing, open ports: security issues
 - sendmail, postfix, qmail, exim
 - may have MDA ability to transfer email to user's mailbox

  http://en.wikipedia.org/wiki/List_of_mail_servers#SMTP

Q: Briefly describe the function of a mail system MTA.

MDA - Mail Delivery Agent
  http://en.wikipedia.org/wiki/Mail_delivery_agent
   "A Mail Delivery Agent (MDA) is software that accepts incoming e-mail
    messages and distributes them to recipients' individual mailboxes
    (if the destination account is on the local machine), or forwards
    back to an SMTP server (if the destination is on a remote server).
    A mail delivery agent is not necessarily a mail transfer agent (MTA),
    although on many systems the two functions are implemented by the
    same program."
 - Unix/Linux: /bin/mail, procmail 

Q: Briefly describe the function of a mail system MDA.

MRA/MAA - Mail Retrieval Agent / Mail Access Agent
  http://tools.ietf.org/html/rfc1939  - POP3 port 110
  http://tools.ietf.org/html/rfc3501  - IMAP-V4-R1 port 143

  - often built-in to mail clients (MUAs)
  - can be stand-alone
    - e.g. fetchmail gets the mail; MUA reads mail from file system

Q: Briefly describe the function of a mail system MRA/MAA.

Mail server comparison
----------------------
  http://en.wikipedia.org/wiki/List_of_mail_servers
  - see comparison near bottom

  - PUSH protocols - sending email: MTA - SMTP
  - PULL protocols - reading email: MRA/MAA - POP3, IMAP

 MDAs write local mailboxes; they may not implement Internet protocols
 (unless they have to forward off-machine without benfit of an MTA).

 Single-user PCs often don't run separate MTA or MRA/MAA programs.
 Your chose of mail reader (e.g. Pine, Elm, Outlook) itself PULLs your
 incoming email from a remote server (acting as an MRA/MAA) and then
 PUSHes your outgoing email to the remote server (acting as an MTA).

Q: What is the difference between a PUSH protocol and a PULL protocol?
Q: T/F, SMTP is a PUSH protocol.
Q: T/F, POP3 is a PUSH protocol.
Q: T/F, HTTP is a PUSH protocol.

A History of MTAs
-----------------

I. Incoming - delivering your incoming email via SMTP:

* Sending email into Unix/Linux machines:
  Unix/Linux was traditionally multi-user and ran its own MTA
  (e.g. sendmail) that accepted incoming SMTP connections.  Remote systems
  could use SMTP to drop off your email with your local MTA (sendmail),
  and the MTA would hand the email to an MDA (/bin/mail, procmail)
  to put it in your mailbox in the local file system.  Your MUA
  (e.g. /usr/ucb/Mail) would read the mail from your inbox (no need
  for POP3 or IMAP in any MUA).  There are a few different conventions
  for inbox formats so that many different MUAs can read your email,
  all without knowing POP or IMAP.

  - sendmail (running as root!) has had many security patches
    - the first Morris Internet worm (Nov 1988) used sendmail security holes
    - http://en.wikipedia.org/wiki/Morris_worm

Q: Why don't many Unix MUAs need to know how to run POP or IMAP?

  Current single-user Unix/Linux PCs often have a local-only MTA
  that handles the sending and delivery of local on-machine email but
  doesn't accept SMTP from off-site.  (Best to keep ports closed on
  Internet-facing machines!)

  On recent single-user Unix/Linux workstations, the MUAs mimic their
  Windows counterparts and include MRA/MAA features.  Your chosen MUA
  (e.g. Elm, Pine, Mutt) is responsible for fetching your email via POP3
  or IMAP (this is an MRA/MAA function); or, you use an intermediate
  MRA/MAA program such as "fetchmail" and your MUA reads the mail out
  of the local file system after the MRA/MAA has put it there.

  - no Internet-facing MTA means fewer open ports and fewer attacks
    - don't run an Internet-facing MTA if you don't need it

* Sending email into MS Windows machines (or not):
  Windows had (has?) no MTA - you can't send an email to a Windows PC
  using SMTP.  Your personal Windows MUA has to fetch the email itself
  via POP3 or IMAP and keep a copy in the local file system.

 - no open ports for incoming email; no open mail port security issues

* Note that MUAs that implement POP/IMAP typically store the email in
  the local file system in a format that only that MUA can handle.
  (Thunderbird can't use an Outlook mail folder, and vice-versa.)
  The concept of a common inbox format usable by different MUAs was lost.

Q: T/F, the standards for inbox formats developed under Unix were adopted
   by MUAs on PCs, so that different MUAs can read the same inbox.

II. Outgoing - sending your outgoing email via SMTP:

* Unix/Linux machines have traditionally each had their own MTA (sendmail)
  that could directly deliver email on the Internet using MX record lookup.

  Every local Unix MUA would put email into a directory where the MTA
  (sendmail) would eventually pick it up and transfer it, retrying as
  necessary.  No MUA needed to know how to do SMTP; only the MTA did that.

  You could optionally tell your machine's MTA not to send mail directly
  to its destination via SMTP over the Internet, but to use a remote
  "smart" MTA that could accept your outgoing email and figure out
  how to deliver it.  (You have to use such a "smart" host here at
  Algonquin; since, you cannot connect to any off-campus SMTP servers.)
  The MTA on your machine would use SMTP to drop off the queued mail at
  the smart host, and the smart host would do the MX record lookup and
  final SMTP delivery.

  Since the local Unix MTAs were separately scheduled programs, you could
  queue email from a MUA into the file system even when your machine was
  not connected to the Internet.  The MUA or local MTA would queue up
  your email in the file system until your MTA was finally able to make
  a connection to deliver it off-machine.  (In the days of modems, the
  Internet connection was often made late at night when rates were lower.)

Q: Why don't most Unix MUAs need to know SMTP?

  Current single-user Unix/Linux PCs now have MUAs that mimic their
  Windows counterparts - the MUAs ignore the file system and the local
  MTA and expect you to give the name of a remote "smart" MTA to which
  all email will be sent via SMTP for actual delivery.

  The Algonquin Linux lab has both types of mail systems:  Command-line
  email (e.g. the "mail" command) queues up mail for the local
  MTA (sendmail) to send.  (This is currently broken.)  GUI MTAs
  (e.g. Thunderbird, Mozilla) ignore the local file system and the local
  MTA and use a "smart" remote MTA (e.g.  outmail.algonquincollege.com)
  to deliver the mail.  (This supposedly still works.)

* MS Windows has no local MTA - no program exists whose job it is just
  to deliver queued email.  Each MUA has to know how to do its own
  SMTP connection and each MUA has to be configured (separately!) with
  the address of a smart MTA to which it connects.  MUAs on Windows
  machines all contain networking code to drop off email at some "smart"
  MTA that does the actual delivery.  There is no local MTA queue and
  much duplication of SMTP code in all the MUAs.

  On Windows, it is up to each MUA to deal with what happens if the
  message being composed can't be dropped off right away at the remote
  smart MTA.  Better MUAs will queue the email for later transmission.
  Poor MUAs will tell you that your mail can't be sent.

Q: Why do MUAs on Windows all need to know how to talk SMTP?

Q: Unix/Linux mail user agents didn't need to know how to talk to SMTP
   servers - you never had to configure your "outgoing mail" preferences.
   All the Windows MUAs need to be configured with a mail server.  Why?

Like the post? Please Subscribe to free RSS feed to get updates