Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!touch!kehres
From: kehres@touch.touch.com (Tim Kehres)
Newsgroups: comp.mail.sendmail
Subject: Re: problem with uucp-originated mail
Message-ID: <199@touch.touch.com>
Date: 12 Dec 90 03:47:07 GMT
References: <9812@darkstar.ucsc.edu> <1990Dec6.234758.28937@mp.cs.niu.edu> <198@touch.touch.com> <1990Dec11.040246.11831@mp.cs.niu.edu>
Organization: Touch Communications Inc, Campbell, CA
Lines: 105

In article <1990Dec11.040246.11831@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
:
> >text regading how rmail looks for bang characters (!) to determine the remote
> >machine name....
:
:
>  While I certainly don't object to changing rmail to accept domain style
> addresses, and am using such an 'rmail' myself, there are reasons I suggested
> changing the code on the Mac is the best approach:
> 
> 	1.  Changing the mail format on the Mac to conform with UUCP standards
> 	    will make the MAC address acceptable if it starts talking UUCP
> 	    to other hosts.

By supplying a non-broken version of 'rmail', you then have the option of
sending either UUCP style bang addresses, or domain addresses.  The user has
the choice of what to send.  You are not force feeding them antiquated 
addressing types.

> 	2.  Just changing 'rmail' to accept domain style addresses may not be
> 	    reliable.  You may also have to make it suid root, and change it
> 	    to do setuid(0) internally.  (This of course has security
> 	    implications).

I have been running this type of configuration at several sites now for going
on two years without any reported problems.  There is no need to make the 
program suid root or anything else (including the referenced call to setuid).
All that is being done internally is to not mandate bang style addressing.
This of course assumes that you are running sendmail as your router.  If this
is the case, all you need to do is to take whatever address that is presented
to you, and pass it on to sendmail for interpretation and further routing.

This type of configuration is especially attractive to sites that are
communicating via UUCP to an internet mail forwarder.  By specifying a "smart"
style of uucp mail agent in the sendmail.cf (one that does not mandate the
rewrite of domain style addresses into bang style addresses), it is possible
to transparently send and receive mail using domain style addressing without
any rewrites taking place.   BTW, if you need examples of how to set this up,
let me know and I'll provide you with a sample configuration.  Several vendors
are now supporting this type of configuration, so if you have a recent copy
of sendmail from one of the major workstation vendors, you may find examples
there as well.

> 	    The problem is that sendmail tries to prevent a user forging
> 	    another user's mail.  It will only accept a specified 'from'
> 	    address in one of three conditions:
> 	      (a) The user invoking sendmail is a 'trusted' user.  (Typically
> 		  root, sendmail, daemon).

Or uucp or nuucp.  When mail come in through UUCP, the user is typicall uucp, 
or some other id which is associated with uucp.  I have yet to see a system 
where this is a problem.  This includes BSD, System V.2, and V.3 systems.

> 	      (c) The from address contains a '!'.

Perhaps you could show me where there is any reference to this.  I have 
certainly not seen anything like this in any of the rewriting rules that
I have come across, likewise never come across any kind of limitations in
any of the versions I have either ported or used.  The System V machines that
I have provided a modified rmail to have never had any problems with sendmail
due to the lack of a '!'.  (The recent BSD versions of rmail have already
fixed this, so they don't need a 'fixed' version).

> 	    The last of these options is there specially to accomodate UUCP,
> 	    because you can not reliably assume that rmail is run by a
> 	    trusted user.  A local user may do a 'uucp' command, which
> 	    initiates a connection, and collects remote mail.  Since many
> 	    versions of 'sendmail' determine the user from the getlogin()
> 	    command, the login name of this user will be used to decide if
> 	    trusted.  Usually the answer will be no.

I have only come across this as a problem in delivering mail with one
implementation of sendmail.  All others passed mail correctly, domain names
or not.  The problem implementation (I would rather not name vendors here),
has the problem that, as you say, when uucp is started and remote mail
retreived, the UUXQT gets fired off with the uid of the user that initiated
the poll, and then sendmail makes the (incorrect) assumption that this is
who the mail is from.  This particular version however instead of bouncing
the mail, does deliver the message, but the UNIX From line gets corrupted
in the process.  The message From: line however remains intact.  Even in
this remote case however, there have been no problems in reliable mail
delivery.

>  All in all, modifying the code of the mac to conform to UUCP standards is
> likely to be the most reliable and simplest approach.

It can most likely be just as reliable as the modification of rmail, but you
will still have the problem of not being able to pass valid domain style
addresses across your mail interface.  Seeing that the UUCP world has been
migrating to domain style addressing for the past five or so years, this
will continue to be more and more of a problem for anyone that only changes
the mac code and expects to be communicating in an internet type of 
environment.  

With this in mind, it may be the simplest approach for the system 
administrator, but probably not for the user.  UUCP addressing has always 
been a pain in the neck for administrators since the addressing is location 
dependent.  This frequently requires significant hand holding by the host 
administrator with the users in trying to figure out uucp addresses.  The 
domain style addressing has resolved this by letting the system figure out 
the routing.  MUCH simpler for the user.

Regards,

Tim Kehres