Although they are aware that paper mail can be forged, most users are blissfully unaware that email can also be forged. Forged mail can lead to a serious breach of security. Two points of vulnerability that require particular attention are the queue file and the SMTP interface of sendmail.
All versions of sendmail trust the files in the mail queue. They assume that only sendmail has placed files there. As a consequence, a poorly protected queue directory can allow the attacker to create mail that looks 100 percent authentic. This can be used to send forged mail, to append to system critical files, or to run arbitrary programs as root or other users. Consider the following bogus qfAA00001 file for sending forged mail (qf files are described in Section 23.9, "The qf File Internals"):
V1 T829313834 P943442 $_root@yourhost S<root@yourhost> RPFD:george@yourhost H?P?return-path: <root@yourhost> Hmessage-id: <199604121257.GAA12601@yourhost> HFrom: root@yourhost HDate: Fri, 13 Dec 1996 05:47:46 -0700 HTo: george@yourhost HSubject: Change your Password Now!!
qf file causes mail to be sent to george that appears
in all ways to come from root.
There is nothing in this
qf file to indicate
to the recipient (or to sendmail) that the message is not authentic.
Now further suppose that the
df file (the message body) contains
the following text:
The system has been compromised. Change your password NOW! Your new password must be: Fuzz7bal Thank you, -System Administration
Unfortunately, in any large organization there will be more than a few users who will obey a message like this. They will gladly change their password to one assigned to them, thereby providing the attacker with easy access to their accounts.
The queue directory must be owned by root and writable only by root. CERT recommends that the queue directory always be mode 0700.
The queue files placed into the queue by sendmail must be well
protected by defining narrow default permissions with the
F) option (see Section 34.8.68, TempFileMode (F)).
A default of 0600 is best.
We won't illustrate the SMTP interaction here. But note
that anyone can connect to your local sendmail via
telnet(1) at port 25 or run sendmail with
-bs command-line switch. Once connected, sendmail must
of necessity believe everything it receives. The only
exception is the
hostname sent in the HELO message.
In that case the sendmail
program looks up the real hostname based on the connection. If
the stated hostname and the real hostname differ, the false
name is used as the name of the sending host with the real name
added in parentheses:
 V8 sendmail also tries to verify the connection itself with identd if possible.
550 your.host hello false.host (real.host), pleased to meet you
The real hostname is then used as the sending hostname in the construction of all headers. The result (the header and body received by the user) might look something like this:
From email@example.com Dec 13 14:36:40 1996 Received: from real.host by your.host (8.8.4/8.8.4) id AA00998; Fri, 13 Dec 1996 14:36:38 -0700 Message-Id: <9612213133.GAA05059@your.host> From: firstname.lastname@example.org (System Administration) To: email@example.com Subject: Change your password now! Date: Fri, 13 Dec 1996 05:47:46 -0700 To improve security at our location you are requested to immediately change your password. The password you have been assigned is: 7Fuzzy1's Thank you, -root
header above contains the name of the real host (which is not always
the case). An attentive user
can tell that this is a forged message because the host in that
header line differs from the false hostname used in the other header
However, most mail-reading programs allow users to filter out
(prevent your seeing) uninteresting header lines.
Typically, users choose
to ignore headers such as
For such users the task of detecting forged mail is much more difficult.
of seeing the above message, with real hostnames, they might
see the following with only false names:
 In fact, the gnu-emacs(1) mail reader deletes those lines irrevocably.
From firstname.lastname@example.org Dec 13 14:36:40 1996 From: email@example.com (System Administration) To: firstname.lastname@example.org Subject: Change your password now! Date: Fri, 13 Dec 1996 14:36:38 -0700 To improve security at our location you are requested to immediately change your password. The password you have been assigned is: 7Fuzzy1's Thank you, -root
Clearly, a user who sees only this much of the mail message will be more likely to believe that it is real.
Educate your users that mail can be forged. Teach them what to look for when they receive a message of questionable authenticity.
Rarely, if ever, send mail as root. Always communicate as yourself and always use a distinctive style of writing. If users never see mail from root, they will be more likely to question such mail when it arrives.
Train users to never send (or ask to receive) clear-text passwords or other security-related information by email.