UNIX System Administration Handbook - Evi Nemeth [362]
Forgeries
Forging email has in the past been trivial. sendmail 8.10 includes SMTP authentication that verifies the identity of the sending machine. Prior to 8.10, any user could forge mail to appear as though it came from your domain. Even in 8.10, checking must be turned on with the AuthMechanisms option.
Likewise, it is possible to impersonate any user in mail messages. Be careful if mail messages are your organization’s authorization vehicle for things like keys, access cards, and money. You should warn administrative users of this fact and suggest that if they see suspicious mail that appears to come from a person in authority, they should verify the validity of the message. This is doubly true if the message asks that unreasonable privileges be given to an unusual person. Mail authorizing a grand master key for an undergraduate student might be suspect!
The authwarnings privacy option flags local attempts at forgery by adding an Authentication-Warning header to outgoing mail that appears to be forged. However, many user agents hide this header by default.
If forged mail is coming from a machine that you control, you can actually do quite a bit to thwart it. You can use the identd daemon to verify a sender’s real login name. sendmail does a callback to the sending host to ask the identd running there for the login name of the user sending the mail. If identd is not running on the remote host, sendmail learns nothing. If the remote machine is a single-user workstation, its owner could configure identd to return a bogus answer. But if the remote host is a multiuser machine such as that found at many university computing centers, identd returns the user’s real login name for sendmail to put in the message’s header.
Many sites do not run identd; it’s often blocked by firewalls. identd is only really useful within a site, since machines you don’t control can lie. At a large site with somewhat irresponsible users (e.g., a university), it’s great.
Several years ago, when we were first experimenting with identd, a student at our site became frustrated with the members of his senior project team. He tried to send mail to his teammates as his instructor, telling them he knew that they were not pulling their weight and that they should work harder. Unfortunately, he made a syntax error and the message bounced to the instructor. sendmail’s use of the IDENT protocol told us who he was. sendmail included the following lines in the bounced message:
The original message was received at Wed, 9 Mar 1994 14:51 -0700 from
student@benji.Colorado.EDU [128.138.126.10]
But the headers of the message itself told a different story:
From: instructor@cs.Colorado.EDU
Moral: avoid syntax errors when sneaking around. Our policy on forging mail caused the student’s login to be disabled for the rest of the semester, which actually accomplished exactly what the student wanted. He was unable to work on the project and his partners had to pick up the slack.
Message privacy
Message privacy basically does not exist unless you use an external encryption package such as Pretty Good Privacy (PGP) or Transport Layer Security (TLS). By default, all mail is sent unencrypted. Tell your users that they must do their own encryption if they want their mail to be private.
See page 671 for more information about PGP.
Efforts are underway to extend SMTP to include both authentication and encryption, but such efforts have in the past been hampered by the U.S. government’s export policies. End-to-end encryption requires support from mail user agents as well as from sendmail.
Two other systems enhance the privacy of email: S/MIME and PGP. Both are documented