Security Issues
E-mail Standards
The vast majority of e-mail consists of simple character data
formatted according to the Internet Engineering Task Force (IETF)
RFC 822 standard
and transmitted via the Simple Mail Transfer Protocol (SMTP) described in
RFC 821.
The character stream containing the message also contains the addressing
data and the routing history of each message.
The major extensions to e-mail enabled it to contain more of the
world's alphabets, encapsulate attachments, and permit multimedia
files to be transmitted. Collectively, these are known as the
MIME standards and are described in RFCs 2045-2049.
Keep in mind that MIME encodes the arbitrary data as a sequence
of ordinary characters using schemes such as
Base64.
The SMTP design, which harkens from a simpler era, makes each message
a self-contained morsel, but it's also the reason why spammers
can be so successful.
As the proposed update to SMTP explains in
RFC 2821:
Various protocol extensions and configuration options that provide
authentication at the transport level (e.g., from an SMTP client to
an SMTP server) improve somewhat on the traditional situation
described above. However, unless they are accompanied by careful
handoffs of responsibility in a carefully-designed trust environment,
they remain inherently weaker than end-to-end mechanisms which use
digitally signed messages rather than depending on the integrity of
the transport system.
Essentially, it isn't possible to stop junkmail without filtering
given the present design.
Furthermore the MIME standards provide the basic mechanism whereby
arbitrary binary data can be transmitted and malicious authors have
been able to deceive some mail clients into decoding and executing
programs which has made e-mail the main transmission vector for viruses.
However, the bottom line is that messages are simple flat
character data and most of the mail system can be manipulated
with ordinary editors and tools.
Mail Agents
The Internet Mail Model defines three logical agents which
operate within the system and and a fourth type is now widespread:
- MTA - Mail Transport Agent
Moves the mail around the internet communicating via SMTP over reserved
TCP/IP port 25. Since the mail protocols are all defined in ASCII,
it is still perfectly possible to do "telnet someplace 25" and type in SMTP
commands directly.
Traditional MTAs were set up to cheerfully accepted mail for anyone, but
spammers learned that they could use the MTA as an open relay
to forward their messages. Now virtually no MTA will accept a
message from outside its domain unless either (a) the message is to be
delivered inside the domain or (b) the connected session has done
a login to the MTA. Since login usually requires a password,
such sessions may be encrypted using
SSL technology.
The original, and still very widely used MTA, is
sendmail.
It is a monolithic program combining an MTA, MDA, and even
the outbound part of an MUA. Sendmail has a notoriously arcane
configuration file.
Other popular MTAs include
qmail,
postfix, and
exim.
- MDA - Mail Delivery Agent
Delivers mail locally according to the instructions
of the user or system defaults.
Programs like
procmail and
fetchmail are
popular because of their ability to apply filters to
the mail. Most MTAs actually include a default MDA
to put mail in a single incoming folder known as a mailspool
and/or the MTA will consult a user file which
configures other options to forward messages to another host or program.
- MAA - Mail Access Agent
As computing has become more decentralized and mobile a new kind
of agent has appeared to provide remote access to the mailspool
and mail folders.
These servers look like MUAs to the system they're running on,
but they are really accepting instructions from remote programs.
- POP(port 110) is the original MAA and it simply delivers all
messages from the incoming mailspool to the remote MUA.
The remote system has the option of deleting the messages
from the spool or leaving them.
Since only incoming messages need be retained, POP is the
service offerred by most ISPs.
- IMAP(port 143) works with a remote MUA accepting commands to
manage folders, download messages, move them to folders, or delete them.
Both POP(port 995) and IMAP(port 993) accept encyrpted connections.
- MUA - Mail User Agent
Sends mail to the MTA and retrieves messages from
the mailspool. It also manages the mail folders
on behalf of the user.
This the most visible part of the system and the one
that interacts with humans.
There are too many MUAs to list.
Here are examples from the major categories:
- traditional text
mail, mailx, elm, pine, mutt.
- windowed GUI
Netscape Messenger, KMail, Eudora, Microsoft Outlook family.
- webmail
IMP, SilkyMail, SquirrelMail,TWIG
Many of the traditional text programs can only handle local mail whereas
the GUI clients also speak POP and IMAP. Since the webmail programs
run transiently inside browsers, they usually are configured to talk
to IMAP servers.
Storing Messages
Collections of messages are stored in folders which fall into
three major families:
- mailbox - a flat file with many messages
There are a half-dozen or so variants in this category, but
the general idea to just append individual messages to the
end of a file.
However, the simplicity of this format makes
integrity complex when adding, or even worse, deleting messages.
Typically the MUA or MAA has to lock the entire file during manipulation.
This process is fraught with danger when done over NFS file systems which
have a long and checkered history in file locking.
There are allegations that folders with lots of messages consume
a lot of resources as the MUA and MAA constantly reread and re-sort the
contents so the system doesn't scale.
For a list of the format variants and an absolutely convincing
argument that mailbox is better than maildir, see the
UW IMAP documentation page
Mailbox Format Characteristics.
- maildir - directories with one message per file
There are a few variants of this, most notably the
qmail version, but all of them share the characteristic of
one file per message.
Reliability of mail handling is accomplished without file
locking because this format leverages the automatic
serializations built into every file systems for creating,
renaming, and deleting files.
There are allegations that the overall system serializations
invoked during changes to file system metadata mean that
the system won't scale.
For an absolutely convincing argument that maildir
is better than mailbox see the Qmail page
Using maildir format.
- db - relational databases
These are typically found in commercial-grade mail systems
and make a lot of sense for managing myriad accounts and lots
of simultaneous active users.
One can leverage database technology for searches and transactions.
However databases require a fair amount of care and attention,
and are not transparently accessible by editors.
For an absolutely convincing argument that database mail is
the best, talk to a salesman of a commercial e-mail product.
Security Issues
There are several major areas of security with respect to mail traffic
and they are linked in that we need encryption to safeguard
authentication. Security of mail folders themselves is dependent
on the file system and not considered here.
- Encryption
All the mail protocols, smtp, imap, and pop come in both
plain and encrypted forms.
For pop and imap, the distinction is the TCP/IP port number
but smtp switches to encrypted mode via a the STARTTLS command
from the MUA.
Since encryption in and of itself only prevents snooping on
the conversation, the second part of security is knowing
whom you're talking with.
- Authentication
Authenticaion necessarily runs in both directions of a conversation.
When the MUA connects to either smtp or imap, these servers
present a certificate to identify themselves.
Once the MUA accepts the server certificate, it creates
the encrypted connection and uses that to forward the account
name and password so that the server knows that MUA is valid.
One could use certificates for this authentication as well,
but they are a maintenance headache.
- Tunneling
A second strategy for authentication is for the MUA
to create an encrypted tunnel to an agent program on
the MTA. Since the agent program is runnning locally
on the MTA machine it acquires the user's credentials
there.
Tunneling with ssh can be done for both sending and
receiving mail without having to enter passwords.
Last update:
June 24, 2002 09:50:38 AM
© 1994-2013
Stanford Computer Graphics Laboratory