Xref: utzoo comp.mail.misc:4139 comp.unix.shell:579
Path: utzoo!attcan!uunet!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.mail.misc,comp.unix.shell
Subject: Re: Shell scripts from smail/sendmail - strange behavior
Message-ID: <28904:Oct1501:03:4390@kramden.acf.nyu.edu>
Date: 15 Oct 90 01:03:43 GMT
References: <1990Oct14.135213.28213@athena.mit.edu> <1990Oct14.194452.13627@mp.cs.niu.edu> <1990Oct14.224615.6178@athena.mit.edu>
Organization: IR
Lines: 28

In article <1990Oct14.224615.6178@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>   "Extensive sender checking" is EXACTLY what sendmail 5.61 DOES NOT do when
> it decides what user ID to use when running a program.  And, as any somewhat
> knowledgeable Unix user should know, it's REAL easy to fake sendmail out. 

Yep, I always thought -bs was an appropriate option name. :-)

To dive off into this side thread: If you want to accurately log mail
coming into your (BSD) system, look at the sendmail-auth directory in my
authutil package (c.s.unix volume 22). Assuming you already have authtcp
and attachport installed, you have to install just a couple of ten-line
shell scripts and make a few changes to sendmail.cf and rc.local. Then
connections will be logged in /usr/adm/in.mail.log as, e.g.,

  Date: Mon Apr 23 22:58:27 CST 1990 972 from root@128.122.128.22 via TCP
  Done: Mon Apr 23 22:58:38 CST 1990 972 984

if the remote site supports RFC 931. As more and more hosts realize the
advantages of authentication, the unauthenticated connections will begin
to stand out as forgeries, so you can simply chop them off. In the
meantime, we can hope that Berkeley will fix the talk-to-myself bug,
eliminate -bs, fix the uid bugs, and build in RFC 931 support...

A longer-term advantage of this strategy is that you won't have to
recompile anything to run mail over a more secure communications system,
such as Kerberos. If Jon codes Kerberized authtcp/attachport, that is...

---Dan