Newsgroups: comp.mail.sendmail
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!malgudi!osc.edu!karl.kleinpaste
From: karl.kleinpaste@osc.edu
Subject: Re: Security in sendmail and SMTP?
Message-ID: <1991Jun3.132342.16685@oar.net>
Sender: news@oar.net
Nntp-Posting-Host: ashley.osc.edu
Organization: Viento Gigabit Testbed, Ohio Supercomputer Center
References: <1443@idcapd.idca.tds.philips.nl>
Date: Mon, 3 Jun 1991 14:21:56 GMT
Lines: 82

dejong@idca.tds.philips.nl writes:
   1) Sendmail has no possibility to change headers in a mail item. It can add
      header lines, but will not affect them when they are present.
   2) The only exception seems to be the From: line, but only the machine name
      part of the address. Changing that requires root permission. 
      But the user can directly set the username as well as the full name.

When suitably (mis-)configured, sendmail can hack on nearly any header
present.  It will definitely hack on Sender:, From:, To:, Cc:, and (I
believe) Reply-To:.  Your particular installation may leave more
things alone that someone else's.  This has to do with how much there
is to your rulesets such as S1 and S2 in particular, and whether S3 is
particularly relevant to how your installation canonicalizes.  For
myself, S3 is nearly the entire universe of hacking, and S[12] are
empty.

   3) SMTP uses no passwords. So any machine that can connect to another
      machine will be accepted as the machine it pretends to be (i.e.,
      whatever is in the HELO command or MAIL FROM: command is accepted.

It will be accepted, yes; but the Received: header will normally
reflect what sendmail believed to be the case regarding the host to
which it was speaking at the time; for example:

Received: from bogus.name.org (real.entity.edu) by my.host.com

What you see there is that the originating SMTP speaker identified
itself during HELO as bogus.name.org.  Regardless of the speaker's
claims, sendmail knows the IP addr of the origin, and it calls
gethostbyaddr() to learn that it was really real.entity.edu which was
connected at the time.

   1) Are my observations correct?

Partly.

   2) Are there options in sendmail to avoid that the user can pretend to send
      mail as someone else?

There is no fundamental way to prevent the sending of mail as someone
other than oneself; anyone can "telnet desti.nation.edu smtp" and
find themselves speaking to the right program, and can speak the SMTP
dialogue as well as an SMTP-speaking program.  If you're careful, you
can do a very complete forgery.

See RFCs 1113, 1114, and 1115 for details on privacy-enhanced mail.  I
am not aware of much yet in the way of implementations of these, but
progress is being made -- I think there's an IETF group working on the
problem.

   3) Reading RFC821, the From: line may be set to indicate another
      user than the one actually sending. In that case there should be
      a Sender: line present to indicate who the actual sender is. But
      sendmail doesn't seem to enforce this.

In that case, your sendmail is broken somehow.  The only way that
sendmail should allow a modified From: field to pass is if the sending
user is one of the "trusted users" (T entry in sendmail.cf).
Otherwise, a Sender: identifying the real user is added -- mine does it.

      At the same time, it
      doesn't allow for a different machine name in From: than the own
      machine (unless I am superuser).

That's a question of the configuration.  You can do many, varied, and
weird things to what sorts of origin hostnames you identify in From:
via suitable hacks to sendmail.cf, and I don't know why any of it
would necessarily be affected by superuser status (except as a trusted
user again, but I don't think this falls into those categories).  A
common thing for a configuration to do is to hide individual hostnames
for a set of hosts within a single (sub)domain, if the user is
reachable at the host which is the "domain head."  In such a case, the
Received: and Message-Id: headers may contain notations of individual
hosts, but things like From: and Reply-To: will generally contain only
a top-level domain name.

      Is there literature outside RFC821 that describes how the From:, Sender:,
      Resent-From: and Resent-Sender: lines have to be treated.

See RFC1123, in part.

--karl