Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!ogicse!intelhf!ichips!iwarp.intel.com!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.misc
Subject: Re: Smail 3.1.19 -- Can I get a valid return address?
Message-ID: <1991Apr22.165214.6482@chinet.chi.il.us>
Date: 22 Apr 91 16:52:14 GMT
References: <1991Apr20.194832.21739@coplex.uucp>
Organization: Chinet - Chicago Public Access UNIX
Lines: 38

In article <1991Apr20.194832.21739@coplex.uucp> dean@coplex.uucp (Dean Brooks) writes:

>   I have been relying on the $SENDER environment variable to
>determine the correct return address, but I am having major problems
>with it.  It appears that the SENDER variable is created from the
>"From" line (not the "From:" header) in the message that is *supposed*
>to be created by the UUCP transport system.

>   Of course, several uucp sites around me don't correctly put their
>entry in the message headers (no "Receieved:" lines).  Is there an
>environment variable (or a way to do this) that will allow me to use
>the "From:" (not the UUCP "From") line with all the name-comments
>and other garbage stipped off?  I would like to have a "@" type address
>if possible rather than a bang path, althought probably not possible.

Keep in mind that the address in $SENDER is where error bounces will
go, so if it is not usable your problems are worse than you think.
It is pretty unusual for a uucp site not to update the From_ line,
although they may not add a Received: header line.  If you can't
respond back the From_ path, most likely a non-uucp transport
has munged it or the patch isn't bi-directional.  Neither situation
is robust for returning error messages so it deserves to be fixed.

>    If its not possible, would it be easy for me to hack in the code?

Except for sheer size, the smail3 code is pretty easy to follow.  However,
since you are already piping to a program that has to parse the
message, why not just grab the From: line there, or use a front-end
like Deliver to parse the headers and give you the body.  If your
server has to contend with unusable "envelope-from" addresses, you should
have some mechanism to let the users give you an alternate address
within the body of the message anyway.  Lots of transports mung all
the header lines just to be consistent.  It is pretty much impossible
to have a non-domain uucp address passed through the internet and
back to a uucp site in a replyable form.

Les Mikesell
  les@chinet.chi.il.us