Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: rob@violet.berkeley.edu (Rob Robertson)
Newsgroups: comp.sys.sun
Subject: Re: sendmail 4.0 without -f picks return path user at random
Keywords: Software
Message-ID: <23774@agate.BERKELEY.EDU>
Date: 9 May 89 23:51:15 GMT
References: <299@odi.UUCP>
Sender: usenet@rice.edu
Organization: University of California, Berkeley
Lines: 24
Approved: Sun-Spots@rice.edu
Original-Date: 29 Apr 89 18:58:40 GMT
X-Sun-Spots-Digest: Volume 7, Issue 279, message 7 of 23

In article <299@odi.UUCP> odi!benson@uunet.uu.net (Benson Margulies) writes:
>X-Sun-Spots-Digest: Volume 7, Issue 260, message 12 of 13
>...
>when mail is sent from one person to another (locally), the return path is
>set to some user OTHER than the sender. The mapping from sender to return
>path is consistent for any given person, but varies from person to person.
>I've checked, and there are no duplicated uid's or any such bizarrity.
>Has anyone else seen this? 

yes.  i am experiencing it here, on machines that have the OR option set
(send send any mail to the server you have /var/spool/mail mounted from).

in the same configuration, the other thing i've noticed is that when
sendmail is involked with the -t option (ie look in the message for who
the mail is to, as it isn't specified on the command line), sendmail
expands aliases.  this is really blecherous when you've got :include:
aliases.  sendmail then passes the message to the mailbox machine, error
or not.  we can work around this by using indirection in our aliai, but it
is annoying to find out.

rob

			  william robertson
		       rob@violet.berkeley.edu