No information is available for this file.
851cb3a712165da58292f4ac4615e4a7140d2ef0a9f0e240ad56fcb6e0342c61<!DOCTYPE HTML PUBLIC "-//W3O/DTD HTML//EN">
<html>
<head>
<title>Internet Email, How it Works</title>
<meta name="description"
content="Users should make themselves
aware of the mail system. System administrators should be aware that most security problems with sendmail are related to the
complexity and flexibility of the configuration file.
">
<meta name="GENERATOR" content="Microsoft FrontPage 1.1">
<meta name="FORMATTER" content="Microsoft FrontPage 1.1">
</head>
<hr>
<hr>
<h1 align="center">Internet Email, How it Works: Check Your
Privacy and Security at the Door</h1>
<h2 align="center">By:<br>
David Hesprich</h2>
<h3 align="center">CS230.10<br>
April 30, 1996</h3>
<hr>
<h2>Abstract</h2>
<p><br>
</p>
<p>Most e-mail isn't truly private. It can be intercepted en
route; read by any person with root privileges or your account
privileges; read from the mailqueue on outgoing, intermediate, or
in going systems; redistributed by the recipient; or simply
accidently sent to the wrong person by a malformed address.
Consequently, e-mail should never be considered a secure medium.
Users should make themselves aware of the mail system. System
administrators should be aware that most security problems with <i>sendmail</i>
are related to the complexity and flexibility of the
configuration file. Although it can be possible to use electronic
mail as a secure means of communication. Digital signatures and
strong encryption can help authenticate the source of messages
and protect content. However, the Internet mail system has no
provisions for tight integration with such enhancements and they
are often awkward and difficult to use. Point to point IP
encryption can protect system passwords and communications
between hosts. But this type of encryption only works between the
encryption gateways. Until security packages become more
reliable, cheaper, and accessible to the end user, it is doubtful
they will see widespread use.</p>
<hr>
<h3>Index:</h3>
<ul>
<li><a href="#smtp">SMTP</a></li>
<li><a href="#headers">Mail headers</a></li>
<li><a href="#sendmail"><i>sendmail</i></a></li>
<li><a href="#security">Security</a>
<ul>
<li>Probes</li>
<li>The <i>sendmail</i> Configuration File</li>
<li>File Permissions</li>
<li>Packet Sniffing</li>
</ul>
</li>
<li><a href="#spoofing">Forged Mail</a></li>
<li><a href="#mailbombing">Mailbombing</a></li>
<li><a href="#iproperty">Intellectual Property</a></li>
<li><a href="#appendix">Appendix: Information Resources</a>
<ul>
<li>CERT Advisories</li>
<li>Request for Comments</li>
<li>Other Information Resources</li>
<li>Other Security References</li>
</ul>
</li>
<li><a href="#bibliography">Bibliography</a></li>
</ul>
<hr>
<h3><a name="smtp">The Simple Mail Transport Protocol (SMTP)</a><br>
<i>(Adapted from </i><a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc821.html"><i>RFC
821</i></a><i>)</i></h3>
<p>There are three steps to SMTP mail transactions. The
transaction is started with a <code>MAIL</code> command which
gives the sender identification. A series of one or more <code>RCPT</code>
commands follows giving the receiver information. Then a <code>DATA</code>
command gives the mail data. And finally, the end of mail data
indicator confirms the transaction.</p>
<p>The first step in the procedure is the <code>MAIL</code>
command. The <reverse-path> contains the source mailbox.</p>
<blockquote>
<pre>MAIL FROM:<reverse-path><CRLF></pre>
</blockquote>
<p>This command tells the SMTP-receiver that a new mail
transaction is starting and to reset all its state tables and
buffers, including any recipients or mail data. It gives the
reverse-path which can be used to report errors. If accepted, the
receiver-SMTP returns a <code>250 OK</code> reply.</p>
<p>The <reverse-path> can contain more than just a mailbox.
The <reverse-path> is a reverse source routing list of
hosts and source mailbox. The first host in the
<reverse-path> should be the host sending this command.</p>
<p>The second step in the procedure is the <code>RCPT</code>
command.</p>
<blockquote>
<pre>RCPT TO:<forward-path><CRLF></pre>
</blockquote>
<p>This command gives a forward-path identifying one recipient.
If accepted, the receiver-SMTP returns a <code>250 OK</code>
reply, and stores the forward-path. If the recipient is unknown
the receiver-SMTP returns a <code>550 Failure</code> reply. This
second step of the procedure can be repeated any number of times.</p>
<p>The <forward-path> can contain more than just a mailbox.
The <forward-path> is a source routing list of hosts and
the destination mailbox. The first host in the
<forward-path> should be the host receiving this command.</p>
<p>The third step in the procedure is the <code>DATA</code>
command.</p>
<blockquote>
<pre>DATA<CRLF></pre>
</blockquote>
<p>If accepted, the receiver-SMTP returns a <code>354
Intermediate</code> reply and considers all succeeding lines to
be the message text. When the end of text is received and stored
the SMTP-receiver sends a <code>250 OK</code> reply. Since the
mail data is sent on the transmission channel the end of the mail
data must be indicated so that the command and reply dialog can
be resumed. SMTP indicates the end of the mail data by sending a
line containing only a period. A transparency procedure is used
to prevent this from interfering with the user's text.</p>
<p>Please note that the mail data includes the memo header items
such as <code>Date:</code>, <code>Subject:</code>, <code>To:</code>, <code>Cc:</code>,
and <code>From:</code>.</p>
<p>The end of mail data indicator also confirms the mail
transaction and tells the receiver-SMTP to now process the stored
recipients and mail data. If accepted, the receiver-SMTP returns
a <code>250 OK</code> reply. The <code>DATA</code> command should
fail only if the mail transaction was incomplete (for example, no
recipients), or if resources are not available.</p>
<blockquote>
<h4>Example of the SMTP Procedure</h4>
<p>This SMTP example shows mail sent by John.Doe at host
Alpha.ARPA, to Jones, Smith, Lee, Green, and Brown at host
Beta.ARPA. Here we assume that host Alpha contacts host Beta
directly.</p>
<p><br>
</p>
<blockquote>
<table border="1">
<tr>
<td colstart="1"><tt>220 Alpha.ARPA Simple Mail
Transfer Service Ready<br>
</tt><b><tt>HELO Beta.ARPA</tt></b><tt><br>
250 Alpha.ARPA<br>
</tt><b><tt>MAIL FROM:<John.Doe@Alpha.ARPA></tt></b><tt><br>
250 OK<br>
</tt><b><tt>RCPT TO:<Jones@Beta.ARPA></tt></b><tt><br>
250 OK<br>
</tt><b><tt>RCPT TO:<Smith@Gamma.ARPA></tt></b><tt><br>
251 User not local; will forward to
<Smith@Gamma.ARPA><br>
</tt><b><tt>RCPT TO:<Lee@Beta.ARPA></tt></b><tt><br>
551 User not local; please try
<Robert.E.Lee@Delta.ARPA><br>
</tt><b><tt>RCPT TO:<Green@Beta.ARPA></tt></b><tt><br>
550 No such user here<br>
</tt><b><tt>RCPT TO:<Brown@Beta.ARPA></tt></b><tt><br>
250 OK<br>
</tt><b><tt>DATA</tt></b><tt><br>
354 Start mail input; end with
<CRLF>.<CRLF><br>
</tt><b><i><tt>Message headers and body...</tt></i></b><tt><br>
</tt><b><tt><CRLF>.<CRLF></tt></b><tt><br>
250 OK<br>
</tt><b><tt>QUIT</tt></b><tt><br>
221 Beta.ARPA Service closing transmission
channel</tt></td>
</tr>
</table>
</blockquote>
<p><br>
</p>
<p>The mail has now been accepted for Jones and Brown.</p>
<p>In the case of Smith, the <code>251 User not local</code>
reply indicates that the receiver-SMTP knows the user's
mailbox is on another host and indicates the correct
forward-path to use in the future. Note that either the host
or user or both may be different. The receiver (in this case
Beta) takes responsibility for delivering the message.</p>
<p>For Lee, the <code>551 User not local</code> indicates
that the receiver-SMTP knows the user's mailbox is on another
host and indicates the correct forward-path to use. Again,
note that either the host or user or both may be different.
The receiver (Beta) refuses to accept mail for this user, and
the sender (Alpha) must either redirect the mail according to
the information provided or return an error response to the
originating user.</p>
<p>Green did not have a mailbox at host Beta.</p>
</blockquote>
<p><a href="http://www.cis.ohio-state.edu/htbin/rfc/rfc821.html">RFC
821</a> has more information on the Simple Mail Transfer
Protocol, as well as the SMTP commands.</p>
<p><br>
<br>
</p>
<h3><a name="headers">Mail Headers</a></h3>
<p>Every mail message is composed of two parts: a header and a
body. The header is composed of all lines from the first until a
blank line. The body consists of all lines after the first blank
line. The first blank line acts as a separator and belongs to
neither the header nor the footer. Although there are many header
lines that can appear in a mail message, some are required, some
are optional, and some lines may appear more than once.</p>
<ul>
<li><code>From:</code> not required for some programs (like <i>mh</i>),
it is only required by some programs (like <i>/bin/mail</i>),
it is added by the program that performed the actual
delivery.</li>
<li><code>Delivery-Date:</code> is the date and time the
message was delivered into the recipient's system
mailbox. This line is usually added by the program that
performs final delivery (usually <i>/bin/mail</i>).</li>
<li><code>Return-Path:</code> contains the address the
recipient can use to reply to the sender. It should only
be added by the system that performs final delivery (<i>sendmail</i>).</li>
<li><code>Received:</code> this line is added for every
machine that handled the message moving it from the
sender to the recipient. Each line represents a hop. If a
message goes through too many hops, the message will
bounce (fail) and be returned to the sender as a failed
message. Note that this actually two lines, the indented
line following it is a continuation of the preceding
Received: line.</li>
<li><code>Date:</code> the date and time the message was
originally sent.</li>
<li><code>From:</code> the email address and full name of the
sender. The order of the two may be reversed and still be
syntactically correct.</li>
<li><code>Message-Id: </code>a unique identification string
constructed from the date, time, a unique filename, and
the originating machine.</li>
<li><code>To:</code> a list of one or more recipients,
separated by commas.</li>
</ul>
<p>The header used by <i>sendmail</i> is defined by <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">RFC822</a>,
with some additional explanation found in <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1123.html">RFC1123</a>.
Several other <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc-index.html">RFCs</a>
define additional headers.</p>
<p><br>
<br>
</p>
<h3><a name="sendmail"><i>sendmail</i></a></h3>
<p><i>Sendmail</i> is a mail transport agent (MTA). Like other
MTA's such as <i>MMDF</i>, <i>Smail</i>, and <i>Zmailer</i>, <i>sendmail</i>
is a program which handles the delivery of mail for many users
and the forwarding of email between machines or networks.
Consequently, <i>sendmail</i> needs to be able to route mail
between various types of networks (local, UUCP, Internet,
BITNET), which <i>sendmail</i> does through the use of a very
flexible (and complicated) configuration file and supporting
programs, files, tables, and services.</p>
<p><br>
<br>
</p>
<h3><a name="security">Security</a></h3>
<p>The <i>sendmail</i> program can be a potential doorway to
system abuse since <i>sendmail</i> is typically configured to run
as an <i>setuid root</i> process. This means that <i>sendmail</i>
has all the powers and privileges of the <i>root</i> user.
Incorrect file permissions can be used to trick <i>sendmail</i>
into giving root privilege away. For instance, forcing <i>sendmail</i>
to run the following shell script will create a setuid shell:</p>
<blockquote>
<pre>#!/bin/sh
cp /bin/sh /tmp/.shell
chmod u+s /tmp/.shell</pre>
</blockquote>
<p>Since <i>sendmail</i> runs most of the time as <i>root</i>,
any user which runs <i>/tmp/.shell</i> will then have root access
privileges. The Morris Worm used a flaw in old versions of <i>sendmail</i>
to gain access to thousands of machines.</p>
<p><br>
</p>
<blockquote>
<h4>Probes </h4>
<p>One method of attack upon a system is to probe it in order
to either force it to give up information about itself which
may make it more susceptible to attack, or to look for
security loopholes or system software bugs.</p>
<blockquote>
<h5>SMTP <i>debug</i> and <i>showq</i></h5>
<p>A probe attempting to exploit an unfixed bug can use
the SMTP <i>debug</i> and <i>showq</i> commands. The <i>debug</i>
command allows the local <i>sendmail</i> to be placed in
debugging mode (as the -<code>d</code> command-line
switch) from any other machine attached to the network.
The <i>showq</i> allows other machines to request a list
of the contents of the mail queue (like the command <i>mailq</i>
on the local machine).</p>
<p>If during compilation of <i>sendmail</i> the SMTPDEBUG
macro is defined, the SMTP commands <i>debug</i> and <i>showq</i>
are enabled. SMTPDEBUG should never be defined in a
official release of sendmail. This can be checked in the
following manner:</p>
<p><br>
</p>
<blockquote>
<table border="1">
<tr>
<td colstart="1"><tt># </tt><b><tt>telnet
somehost.domain.com 25</tt></b><tt><br>
Trying 198.76.10.2 ...<br>
Connected to somehost.domain.com.<br>
Escape character is '^]'.<br>
220 somehost.domain.com ESMTP Sendmail
8.7.4/8.6.12 ready at Wed, 20 Mar 1996
13:42:43 -0500 (EST)<br>
</tt><b><tt>debug</tt></b><tt><br>
500 Command unrecognized<br>
</tt><b><tt>quit</tt></b><tt><br>
221 somehost.domain.com closing connection<br>
Connection closed by foreign host.</tt></td>
</tr>
</table>
</blockquote>
<p><br>
</p>
<p>While connected to port 25 of the host, enter the
command <code>debug</code>; if you are answered <code>with
500 Command unrecognized</code>, SMTPDEBUG is not
defined. If the answer is <code>200 Debug set</code>,
SMTPDEBUG is set. When SMTPDEBUG is undefined, and a
nonlocal user attempts the debug or showq commands, the
IDA and V8 versions of Sendmail may issue a syslog(3)
message:</p>
<blockquote>
<pre>Mar 20 13:42:52 localhost sendmail[28650]: "debug" command from user@farhost [xxx.xxx.xxx.xxx] (yyy.yyy.yyy.yyy)</pre>
</blockquote>
<h5>SMTP <i>vrfy</i> and <i>expn</i></h5>
<p>The SMTP <i>vrfy</i> and <i>expn</i> cause sendmail to
verify that a given address is valid. If a login name is
given, then the full and login name are reported back.
This is a security risk where users choose passwords
which are a copy of their login names, or some variation
of their name. With well-defined passwords (which can
oftentimes be enforced by the system), full and login
names can be safely given to the world at large.</p>
<p>Some versions of <i>sendmail</i> monitor the SMTP <i>vrfy</i>
command: V8 and IDA may individually log requests, while
the SunOS version sends mail to <i>postmaster</i>
indicated failed attempts. Pre-V8 versions of <i>sendmail</i>
do not report <i>vrfy</i> attempts at all. V8 <i>sendmail</i>
allows <i>vrfy</i> and <i>expn</i> services to
selectively accepted or rejected.</p>
</blockquote>
<p><br>
</p>
<h4>The <i>sendmail</i> Configuration File</h4>
<p>When sendmail reads its configuration file, it usually
does so as root, and can consequently read or write to any
file.</p>
<blockquote>
<h5>F - Define Classes, File Form (F<i>c</i>/<i>path</i> <i>pattern</i>)</h5>
<p>Using the F command to read a file which is not
world-readable can allow otherwise protected information
to be released. Even if the scanf(3) option is correct, a
core dump or frozen configuration file can still allow
sensitive information to be examined.</p>
<h5>F - Define Classes, Program Form (F<i>c</i>| /<i>path</i>)</h5>
<p>The program form of the <code>F</code> (file)
configuration command runs a program, specified by <i>path</i>,
to fill the class <i>c</i> with new values and can be
modified to run a program which gives away <i>root</i>
access privileges.</p>
<p>The <i>sendmail</i> configuration file should never be
writable by anyone other than <i>root</i>, in a directory
owned and writable only by <i>root</i>. Every path
component of the directory should also be owned and
writable by <i>root</i> as well.</p>
<h5>M - Define Delivery Agent</h5>
<p>The pathname of a mailer (<code>P=</code> equate) for
a delivery agent can be modified to run a program which
gives away <i>root</i> access privileges. The S flag (do
not reset the userid before calling the mailer) in the <code>F=</code>
equate causes <i>sendmail</i> to retain its <i>root</i>
privilege when executing the <code>P=</code> equate, and
is especially dangerous.</p>
<p><code>P=</code> equates must be protected by
protecting the configuration file. Relative pathnames
should never be used in the <code>P=</code> equate.</p>
<h5>Delivery Agent Statistics (OS<i>file</i>)</h5>
<p><i>Sendmail</i> checks for the existence and
writability of the file specified in the <code>S </code>configuration
file. If the file specified is in a world-writable
directory, <i>sendmail</i> will overwrite that file, or
any file pointed to by a link of that name. This can
cause critical system files to be destroyed.</p>
<p>Any file sendmail writes to must be writable only by
root, and exist in a directory, every path component of
which is owned, and writable, only by <i>root</i>.</p>
</blockquote>
<p><br>
</p>
<h4>File Permissions</h4>
<p>All directories in the path of a <i>root</i>-owned file
must be owned by <i>root</i> and writable only by root. This
is true for all files, not just those pertaining to <i>sendmail</i>.
Group writability should be avoided.</p>
<blockquote>
<h4><code>:include:</code> Permissions</h4>
<p>When delivering to a <code>:include:</code> mailing
list sendmail changes its UID to that of a non-privileged
user. Access to the UID owning the list can be gained if
recipients list can be modified by any other user than
the list owner.</p>
<p>Mailing lists (<code>:include:</code>) must be
writable only by root, and exist in a directory, every
path component of which is owned, and writable, only by <i>root</i>.
The lists themselves must be writable only by the owner.
If the owner is an ordinary user, group writability may
be enables, providing the user is notified of the risks.</p>
<p>Mailing lists (<code>:include:</code>) may be safely
owned by <i>root</i>. <i>Sendmail</i> processes a <i>root</i>-owned
mailing list by changing itself to run as the user and
group specified by the <code>u</code> and <code>g</code>
options (which should be set to <i>nobody</i> and <i>nogroup</i>,
rather than the <i>daemon</i> defaults.</p>
<p><br>
</p>
<h4><i>~/.forward</i> Permissions</h4>
<p>User <i>~/.forward</i> files must be writable only by
the owning user. User home directories should live in a
directory , and owned and writable only by the user.</p>
<p><br>
</p>
<h4>Aliases File</h4>
<p>The aliases file can be used to gain privileged access
if improperly administered. Aliases that execute a
program (like the decode alias most systems ship with),
can be used to create SUID files or programs.</p>
<p><br>
</p>
</blockquote>
<h4>Packet Sniffing</h4>
<p><a
href="ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks">Network
monitoring attacks</a> are becoming quite common. An intruder
compromises a system and attains root-level access. While
running a network monitoring tool, the intruder captures the
first few keystrokes of all newly opened FTP, telnet, and
rlogin sessions visible within the compromised system's
domain. Typically the first group of keystrokes contain host,
account, and password information for user accounts on other
systems - all sent in the clear (unencrypted). Intruders
usually install Trojan horse programs to support subsequent
access to the compromised system and to conceal their network
monitoring process(es).</p>
</blockquote>
<p>The CERT Coordination Center publishes information on known
Sendmail vulnerabilities and workarounds, as well as warnings
about ongoing attacks.</p>
<p><br>
<br>
</p>
<h3><a name="spoofing">Forged Mail</a></h3>
<p>Like paper mail, electronic mail can be forged.</p>
<blockquote>
<h4>Mail Queue</h4>
<p>All versions of <i>sendmail</i> implicitly trust the mail
queue, as it is assumed that only <i>sendmail</i> has created
the contents. Using the queue directory, it is possible to
created forged messages that appear completely authentic.</p>
<p>The queue directory must be owned and writable only by <i>root</i>. <a
href="ftp://info.cert.org/pub/">CERT </a>recommends that the
mail queue directory be set mode 700. Queue files should be
protected, a file mode of 0600 is recommended.</p>
<h4>SMTP Forgeries</h4>
<p><i>Sendmail</i>, of necessity must allow connections at
port 25, and with the exception of the hostname sent in the <code>HELO</code>
message, will believe everything it is told. In the case of
the sending host, <i>sendmail</i> looks up the real hostname
based on the connection (V8 <i>sendmail</i> will also attempt
to use <i>identd</i>), if they differ, the real hostname is
used as the sending hostname in the construction of the <code>Received:</code>
and <code>Message-Id:</code> headers.</p>
</blockquote>
<p><br>
<br>
</p>
<h3><a name="mailbombing">Mailbombing</a></h3>
<blockquote>
<p><i>Well there's egg and bacon; egg, sausage and bacon; egg
and spam; bacon and spam; egg, bacon, sausage and spam; spam,
bacon, sausage and spam; spam, egg, spam, spam, bacon and
spam; spam, spam, spam, egg and spam; spam, spam, spam, spam,
spam, spam, baked beans, spam, spam, spam and spam; or
lobster thermidor aux crevettes with a mornay sauce garnished
with truffle pate', brandy and a fried egg on top of spam.</i>
-- Monty Python's Flying Circus</p>
</blockquote>
<p>Mailbombing is the deliberate, unsolicited sending of large
volume and/or length email to another user. It is typically a
form of revenge for some real or imagined injury (deserved or
otherwise) done by the victim.</p>
<p>There are also indirect forms of mailbombing, where the
mailbomber hijacks the identity or e-mail address of the victim
(or claims to be a friend, relative, or coworker, etc.), and says
something in a public forum that is guaranteed to draw a flood of
responses, or subscribes to multiple high-traffic mailing lists,
or performs some other action with the intent of generating large
volumes of e-mail directed at the victim.</p>
<p>All forms of mailbombing result in the great inconvenience of
the user(s) involved. Mailboxes can fill up, preventing mail from
being delivered; mail spools can overflow on the affected system,
causing all mail delivery on that system to halt, and may result
in the system finally crashing.</p>
<p>There is unfortunately, little or no way to prevent
mailbombing. It takes no talent or special knowledge, and raw
materials for mailbombs are always at hand (a favorite method of
mailbomber to fill mailboxes is to send multiple copies of core
dumps). The mail sever can be offered some protection by giving
the mail queue a separate filesystem space. This protects the
rest of the system in that it keeps the mail queue from filling
critical disk space needed by other running system processes.</p>
<p><br>
<br>
</p>
<h3><a name="iproperty">Intellectual Property</a></h3>
<p>As computer networks become more common in day-to-day life,
lawyers will try to adapt existing laws to fit the digital world.
Currently, some nations are attempting to change the law to adapt
to the new technology. This is of interest to the Internet user
in that new legislation may restrict current freedoms. The user
must understand the law in order to develop new technologies that
protect the current environment for change.</p>
<p>The truth of the matter is that there is no perfect answer to
the questions of ownership or liability. When digital information
crosses states lines, is it interstate commerce? Chances are it
may very well be. Which "community standards" apply on
the Internet, which topologically reduces geography to a single
point? What control do you have over your e-mail after it has
been sent, is it truly private?</p>
<p>E-mail may exist only as digital information held in a
computer's temporary storage, which calls into question the
"fixed in any tangible medium of expression"
requirement of copyright. On the other hand, e-mail is very much
like a written letter, which is protected by copyright. Like
written letters, people often use e-mail to communicate, and have
an interest in having their ideas protected. Unfortunately,
e-mail's status under copyright remains uncertain.</p>
<p>Under the Electronic Communications Privacy Act of 1986, the
owner of the system, rather than the author or recipient of the
e-mail, is the owner of the the message. This holds regardless of
the nature of the message. An extension of that logic has been
held forth in some company's policies which maintain that e-mail
sent using accounts paid for by the company, but not on systems
owned by the company, are similarly owned by the company.</p>
<p><br>
<br>
</p>
<h3><a name="conclusion">Conclusion</a></h3>
<p>Most e-mail isn't truly private. It can be intercepted en
route; read by any person with root privileges or your account
privileges; read from the mailqueue on outgoing, intermediate, or
in going systems; redistributed by the recipient; or simply
accidently sent to the wrong person by a malformed address.
Consequently, e-mail should never be considered a secure medium.
Many times the mail queues and user directories are backed up as
part of system maintenance, so mail that a user has deleted may
actually exist on backup storage that may be retained for years.</p>
<p>Users should take the following precautions when using e-mail:</p>
<ul>
<li>Make certain to use care when composing mail, especially
the recipient and carbon copy header lines.</li>
<li>Write your message as if it was to be distributed as a
widely-read newspaper.</li>
<li>Remember that your password give both access to your
e-mail and your identity, as well as your account's
files.
<ul>
<li>Do not undermine the secrecy of your password by
using your name, birthday, address, telephone
number or extension, Social Security Number, or
anything else that exists in public or official
records.</li>
<li>Do not place your password in a publicly
accessible area, on or around the computer, under
the mouse pad, etc.</li>
</ul>
</li>
<li>Be aware of your system's privacy and security policies.</li>
</ul>
<p>System administrators should be aware that most security
problems with <i>sendmail</i> are related to the complexity and
flexibility of the configuration file.</p>
<ul>
<li>Use extreme care when configuring <i>sendmail</i>. Do not
use a configuration file that you have not examined.</li>
<li>Avoid allowing aliases to run external programs.</li>
<li>Develop a policy for handling new security holes, user
abuses, and external attacks.</li>
<li>Develop a contingency plan should mail services fail.</li>
</ul>
<p>In conclusion, it should be noted that it can be possible to
use electronic mail as a secure means of communication. Digital
signatures and strong encryption (like those provided by the
popular <a href="http://web.mit.edu/network/pgp.html">Pretty Good
Privacy</a> software) can help authenticate the source of
messages and protect content. However, the Internet mail system
has no provisions for tight integration with such enhancements
and they are often awkward and difficult to use. Point to point
IP encryption can protect system passwords and communications
between hosts. But this type of encryption only works between the
encryption gateways. Until security packages become more
reliable, cheaper, and accessible to the end user, it is doubtful
they will see widespread use.</p>
<hr>
<h2><a name="appendix">Appendix: Information Resources</a></h2>
<h3>CERT Advisories<br>
<i>(Adapted from the </i><a href="http://www.cert.org/"
name="cert"><i>CERT FAQ</i></a><i>)</i></h3>
<p>The CERT Coordination Center is the organization that grew
from the computer emergency response team formed by the Defense
Advanced Research Projects Agency (DARPA) in November 1988 in
response to the needs identified during the Internet worm
incident. The CERT charter is to work with the Internet community
to facilitate its response to computer security events involving
Internet hosts, to take proactive steps to raise the community's
awareness of computer security issues, and to conduct research
targeted at improving the security of existing systems.</p>
<p>CERT products and services include 24-hour technical
assistance for responding to computer security incidents, product
vulnerability assistance, technical documents, and seminars. In
addition, the team maintains a number of mailing lists (including
one for CERT advisories) and provides a web site, <a
href="http://www.cert.org/">www.cert.org</a>, and an anonymous
FTP server, <a href="ftp://info.cert.org/">info.cert.org</a>,
where security-related documents, CERT advisories, and tools are
available.</p>
<p>A CERT advisory is a document that provides information on how
to obtain a patch or details of a workaround for a known computer
security problem. The <a href="http://www.cert.org/">CERT
Coordination Center</a> works with vendors to produce a
workaround or a patch for a problem, and does not publish
vulnerability information until a workaround or a patch is
available. A CERT advisory may also be a warning about ongoing
attacks.</p>
<blockquote>
<h4>Network Monitoring</h4>
<blockquote>
<p><a
href="ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks">ftp://info.cert.org/pub/cert_advisories/CA-95:01.network.monitoring.attacks</a><br>
<a
href="ftp://info.cert.org/pub/cert_advisories/CA-95:01.README">ftp://info.cert.org/pub/cert_advisories/CA-95:01.README</a></p>
</blockquote>
<h4>Sendmail</h4>
<blockquote>
<p><a
href="ftp://info.cert.org/pub/cert_advisories/CA-93:16.sendmail.vulnerability">ftp://info.cert.org/pub/cert_advisories/CA-93:16.sendmail.vulnerability</a><br>
<a
href="ftp://info.cert.org/pub/cert_advisories/CA-93:16a.sendmail.vulnerability.supplement">ftp://info.cert.org/pub/cert_advisories/CA-93:16a.sendmail.vulnerability.supplement</a> <a
href="ftp://info.cert.org/pub/cert_advisories/CA-93:16a.README">ftp://info.cert.org/pub/cert_advisories/CA-93:16a.README</a><br>
<a
href="ftp://info.cert.org/pub/cert_advisories/CA-95:05.sendmail.vulnerabilities">ftp://info.cert.org/pub/cert_advisories/CA-95:05.sendmail.vulnerabilities</a><br>
<a
href="ftp://info.cert.org/pub/cert_advisories/CA-95:05.README">ftp://info.cert.org/pub/cert_advisories/CA-95:05.README</a><br>
<a
href="ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerabilities">ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerabilities</a><br>
<a
href="ftp://info.cert.org/pub/cert_advisories/CA-95:08.README">ftp://info.cert.org/pub/cert_advisories/CA-95:08.README</a><br>
<a
href="ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul">ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul</a><br>
<a
href="ftp://info.cert.org/pub/cert_advisories/CA-95:11.README">ftp://info.cert.org/pub/cert_advisories/CA-95:11.README</a><br>
<a
href="ftp://info.cert.org/pub/cert_advisories/CA-95:13.syslog.vul">ftp://info.cert.org/pub/cert_advisories/CA-95:13.syslog.vul</a><br>
<a
href="ftp://info.cert.org/pub/cert_advisories/CA-95:13.README">ftp://info.cert.org/pub/cert_advisories/CA-95:13.README</a></p>
</blockquote>
</blockquote>
<p><br>
</p>
<h3>Request For Comments (RFC)</h3>
<blockquote>
<h4>SMTP</h4>
<blockquote>
<p><a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc821.html">821</a>
J. Postel, "Simple Mail Transfer Protocol",
08/01/1982. (Pages=58) (Format=.txt) (Obsoletes <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc788.html">RFC0788</a>)
(STD 10)</p>
</blockquote>
<h4>Message Headers</h4>
<blockquote>
<p><a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">0822</a>
D. Crocker, "Standard for the format of ARPA
Internet text messages", 08/13/1982. (Pages=47)
(Format=.txt) (Obsoletes <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc733.html">RFC0733</a>)
(STD 11) (Updated by <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1327.html">RFC1327</a>, <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc987.html">RFC0987</a>)</p>
<p><a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc987.html">0987</a>
S. Kille, "Mapping between X.400 and RFC 822",
06/01/1986. (Pages=69) (Format=.txt) (Updates <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">RFC0822</a>)
(Obsoleted by <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1148.html">RFC1148</a>)
(Updated by <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1026.html">RFC1026</a>)</p>
<p><a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1026.html">1026</a>
S. Kille, "Addendum to RFC 987: Mapping between
X.400 and RFC-822", 09/01/1987. (Pages=4)
(Format=.txt) (Updates <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc987.html">RFC0987</a>)
(Updated by <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1138.html">RFC1138</a>)</p>
<p><a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1123.html">1123</a>
R. Braden, "Requirements for Internet hosts -
application and support", 10/01/1989. (Pages=98)
(Format=.txt) (STD 3)</p>
<p><a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1138.html">1138</a>
S. Kille, "Mapping between X.400(1988) / ISO 10021
and RFC 822", 12/01/1989. (Pages=92) (Format=.txt)
(Updates <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1026.html">RFC1026</a>)</p>
<p><a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1148.html">1148</a>
B. Kantor, S. Kille, P. Lapsley, "Mapping between
X.400 (1988) / ISO 10021 and RFC 822", 03/01/1990.
(Pages=94) (Format=.txt) (Obsoletes <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc987.html">RFC0987</a>)
(Obsoleted by <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1327.html">RFC1327</a>)</p>
<p><a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1327.html">1327</a>
S. Hardcastle-Kille, "Mapping between X.400(1988) /
ISO 10021 and RFC822", 05/18/1992. (Pages=113)
(Format=.txt) (Updates <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html">RFC0822</a>)
(Obsoletes <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1148.html">RFC1148</a>)
(Updated by <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1495.html">RFC1495</a>)</p>
<p><a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1495.html">1495</a>
H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson,
"Mapping between X.400 and RFC-822 Message
Bodies", 08/26/1993. (Pages=15) (Format=.txt)
(Updates <a
href="http://www.cis.ohio-state.edu/htbin/rfc/rfc1327.html">RFC1327</a>)</p>
</blockquote>
</blockquote>
<p><br>
</p>
<h3>Other Information Resources</h3>
<blockquote>
<p>The CancelMoose™ Home Page. <code><</code><a
href="http://www.cm.org/"><code>http://www.cm.org/</code></a><code>></code>.</p>
<p>The SPAM FAQ. <code><</code><a
href="http://ddi.digital.net/~gandalf/spamfaq.html"><code>http://ddi.digital.net/~gandalf/spamfaq.html</code></a><code>></code>.</p>
<p>Reagoso, Christopher D. "Internet Abuse Series:
Surviving Abusive Repetitive Email Messages on the Internet
(a.k.a. Spam Mail and Mail Bombs)." <code><http://www.apci.net/~reagosoc/IAB_MailBombs.htm></code>.</p>
</blockquote>
<p><br>
</p>
<h3>Other Security Resources</h3>
<blockquote>
<p>The SATAN (Security Analysis Tool for Auditing Networks)
Homepage. <code><</code><a
href="http://stud1.tuwien.ac.at/~e9125110/satan.html"><code>http://stud1.tuwien.ac.at/~e9125110/satan.html</code></a><code>></code>.</p>
<p>The CERT Coordination Center. <code><</code><a
href="http://www.cert.org/"><code>http://www.cert.org/</code></a><code>></code>.</p>
<p>MIT PGP Distribution Site. <code><</code><a
href="http://web.mit.edu/network/pgp.html"><code>http://web.mit.edu/network/pgp.html</code></a><code>></code>.</p>
</blockquote>
<hr>
<h2><a name="bibliography">Bibliography</a></h2>
<p><br>
</p>
<blockquote>
<p>Allman, Eric. <i><u>sendmail</u></i><u> Installation and
Operation Guide, Version 8.36</u>. Berkeley, CA: University
of California, 1995.</p>
<p>Costales, Bryan. <u>sendmail</u>. Sebastopol, CA: O'Reilly
& Associates, Inc., 1994.</p>
<p>Miller, Steven E. <u>Civilizing Cyberspace: Policy, Power,
and the Information Superhighway</u>. New York, NY: ACM
Press, 1996.</p>
</blockquote>
<p><br>
</p>
<hr>
<hr>
<p> </p>
</body>
</html>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed