--------
Backdrop
--------
(1) regular SMTP session (not Extended SMTP, aka ESMTP)

 - user wants to send email, so opens mail client (Outlook, Eudora, ...) -
   which is also known as the "user agent" and composes an email, then
   clicks "Send"

 - the mail client connects to the configured SMTP server on port 25

 - the configured SMTP server is running an MTA on port 25 (e.g. sendmail,
   qmail)

 - the MTA accepts that connection; responding to completion of 3-way
   handshake with: "220 <FQDN_of_this_host>

   -- so the MTA responds with code 220 then specifies its fully-qualified
      domain name

 - then the client sends the HELO cmd: HELO <client's_FQDN> which is HELO
   followed by the client's fully qualified domain name

 - the MTA responds with code 250

   -- prior to printing this message, the MTA may take the IP address of
      the client and perform reverse DNS lookup on that IP

 - the client sends: MAIL From: <src email addy>

 - the MTA responds with code 250

 - the client sends: RCPT To: <recipient email addy>

 - the MTA responds with code 250

 - the client sends the DATA command ("DATA \r\n")

 - the MTA responds with code 354 followed by instructions, e.g. "Enter
   mail, end with "." on a line by itself"

 - the client sends the body of the email message; the body of the email
   message is more than just the actual text of the email; usually
   includes some headers, e.g.

   Received: by <client's FQDN>
   Message-Id: <some value>
   From: <src email addy> (Sender's name)
   Date: 
   Reply-To:
   X-Phone:	
   X-Mailer:
   To: <target email address>
   Subject: testing

   1, 2, 3.

   -- so the mail client takes what the user enters (as msg text) and adds
      some headers

 - then the client sends, separately, ".\r\n" to indicate that he (the
   client) is done transmitting message contents

 - the MTA responds with code 250, Mail accepted

   -- the MTA adds a few headers, adds the envelope (source and destination
      email addresses) then passes the result to the relay MTA if the
      recipient email address domain name is different than the sender's 

 - then the client sends QUIT

 - then the MTA responds with code 221, "<MTA_FQDN> delivering mail"

So, as noted above, when the user sends an email, there may be 4 MTAs
involved: the local MTA (who is contacted by the user agent), the relay
MTA (who is contacted by the local MTA and who handles delivery of mail to
different domains - i.e. across the Internet), the recipient's relay MTA
(who handles receipt of email from other domains destined to this domain),
and the recipient's local MTA (who handles receipt of email from its
relay MTA that is destined to some host w/in this domain)

QUESTIONS raised by the above: if one were to try to encrypt the email,
presumably only the content xmitted via the "DATA" command can be
encrypted... i.e. we couldn't encrypt the MAIL From: <src email addr> nor
RCPT To: <recip email addr> values since then the mail would not be
deliverable. So at the very least assuming this process, an observer would
know that the sender sent an email to the recipient.

RFC 821 specifies how 2 MTAs communicate across a single TCP connection in
order to send an email. The communication between these MTAs uses NVT
ASCII. NVT ASCII: 7-bit character code, transmitted as 8-bit bytes with
high order bit set to 0. NVT ASCII uses <CRLF> ("\r\n") to denote end of
line. 

Other cmds:

 VRFY: user sends email handle to MTA and asks MTA to verify whether there
       is such a user on that domain by that handle

 EXPN: user sends mailing list to MTA and asks MTA to expand that mailing
       list (presumably to reply with all handles that participate in
       that list)

---------------------------
Email composed of 3 pieces:
---------------------------
(1) Envelope: used by the MTAs for delivery

    - the values used for MAIL From: and RCPT To:

(2) Headers: used by user-agents; headers beginning with X- are user-defined

(3) Body: the content of the message from the sending user to the
    	  receiving user

 - according to RFC 822, must be NVT ASCII text

 - headers sent first, followed by blank line, followed by body

 - each line xferred must be <1000 bytes

 - content: headers + body; sent by email client with DATA cmd

=============
Extended SMTP: Envelope changes
=============

RFC 1425 defines framework for adding extensions to SMTP; result is
Extended SMTP (ESMTP)

A client that wishes to use ESMTP features initiates its session with the
server via issuing the EHLO cmd (instead of the HELO cmd)

 - compatible servers respond with code 250

   -- also retunrs as many lines as SMTP extensions supported by this
      server; e.g.

      250-8BITMIME
      250-EXPN
      250-HELP
      250-XADR
      250-SIZE

   -- SIZE keyword: allows client to specify the size of the message in
      bytes on the "MAIL From:" command line; that way, the receiving MTA
      can refuse to accept a message that is too big ... rather than
      waiting for the client to start sending then deciding the client has
      sent too much.

   -- may also see

      250-SIZE <val>

      where the value specified is the max msg size supported by this
      server

   -- 8BITMIME extension allows client to add the keyword "BODY" to the
      "MAIL From:" command ... specifying whether the body contains NVT
      ASCII characters (the default) or 8-bit data

      -- client must receive 8BITMIME keyword from server in EHLO response
         in order to send any characters other than NVT ASCII

 - incompatible servers respond with code 500, "Command unrecognized"

------------------------------------
Header changes: non-ASCII characters
------------------------------------

 - allowing sender and receiver names and subject to include non-ASCII chars

 - the header fields can contyain encoded words

   =? <charset> ? <encoding> ? <encoded-text> ?=

   e.g.

   =?US-ASCII?Q?Keith-Moore?=

   where US-ASCII is the charset (other valid values are iso-8859-1,...)

   where the encoding is specified by a single character; 2 values supported:

    Q : quoted-printable (intended for Latin character sets)

      - most chars sent as NVT ASCII

      - any char to be sent whose 8th bit is set, is sent as 3 chars:

      	"=AB" where A and B are hexadecimal digits

	e.g. a character whose value is 0xe9 is sent as: =E9

    B : base64 encoding; 3 consecutive bytes of text are encoded as 4
      	6-bit values

	- if # of chars to encode is not multiple of 3, equal signs used
          as pad characters

===========================================
MIME: Multipurpose Internet Mail Extensions
===========================================
Adds new headers that tell recipient the structure of the body.

 Mime-Version:
 Content-Type:
 Content-Transfer-Encoding:
 Content-ID:
 Content-Description:

E.g.	Mime-Version: 1.0
	Content-Type: TEXT/PLAIN; charset=US-ASCII

 - PLAIN is a subtype of content-type TEXT
 - the charset is a parameter

++++++++++++++
Content types: 
++++++++++++++
(1) Text: subtypes = plain, richtext, enriched

(2) Multipart: subtypes = mixed, parallel, digest, alternative

(3) Message: subtypes = rfc822, partial, external-body

(4) Application: subtypes = octet-stream, postscript

 - for octet-stream, means arbitrary binary data

(5) Image: subtypes = jpeg, gif

(6) audio: subtype = basic

(7) video: subtype = mpeg

++++++++++++++
Encoding types
++++++++++++++
(1) 7bit (NVT ASCII, the default)

(2) quoted-printable: useful when only small # of chars have 8th bit set

(3) base64: 

(4) 8bit: contains lines of characters, some of which are non-ASCII and
    	  have 8th bit set

(5) binary encoding: 8-bit data, need not include lines

All of (1) through (3) generate bodies only containing NVT ASCII chars.

Must use 8BITMIME to use encoding types (4) and (5)

----------
AUTH LOGIN: sample session
----------

------		-------				------
Server		Decoded				Client
------		-------				------
						AUTH LOGIN						

VXNlcm5hbWU6	Username:

		REDACTED			REDACTED

UGFzc3dvcmQ6	Password:

		REDACTED			REDACTED