[comp.mail.uucp] smail combined with sendmail

brant@manta.pha.pa.us (Brant Cheikes) (03/01/89)

I recently installed sendmail (5.58) and reconfigured smail2.5 to
serve as sendmail's UUCP front and back end.  So /bin/rmail continues
to be linked to /bin/smail, but now rmail/smail is supposed to call
sendmail to parse headers and determine proper message disposition.
Yet the manual page for smail(8) notes:

          As distributed, 'bang' mail that is not bound for a local
          recipient will be passed directly to uux without calling
          sendmail.

Would someone please explain the rationale for this behavior?  This
strikes me as a design error, as it prevents sendmail from performing
its routine header manipulation.  In particular, because sendmail
never sees the message, a "received" trace header never gets added
(smail apparently fails to do that itself, in this case).  This is a
valuable piece of information which should not be left out.

Now I can go in and hack the smail source, but I'd like to know if
there are any reasons not to.
-- 
Brant Cheikes
University of Pennsylvania, Department of Computer and Information Science
brant@manta.pha.pa.us, brant@linc.cis.upenn.edu, bpa!manta!brant

woods@ncar.ucar.edu (Greg Woods) (03/02/89)

In article <471@manta.pha.pa.us> brant@manta.pha.pa.us (Brant Cheikes) writes:
>Now I can go in and hack the smail source, but I'd like to know if
>there are any reasons not to.

   I hacked smail to always pass the message to sendmail iff it is called
as "rmail" but not if called as "smail". It isn't hard to do and I have
been running it this way since smail first came out and it works fine.

--Greg

lmb@vicom.COM (Larry Blair) (03/02/89)

In article <1500@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
=In article <471@manta.pha.pa.us> brant@manta.pha.pa.us (Brant Cheikes) writes:
=>Now I can go in and hack the smail source, but I'd like to know if
=>there are any reasons not to.
=
=   I hacked smail to always pass the message to sendmail iff it is called
=as "rmail" but not if called as "smail". It isn't hard to do and I have
=been running it this way since smail first came out and it works fine.

Why not just run the original rmail which, presumably, called sendmail?
-- 
Larry Blair   ames!vsi1!lmb   lmb@vicom.com

woods@ncar.ucar.edu (Greg Woods) (03/02/89)

In article <1518@vicom.COM> lmb@vicom.COM (Larry Blair) writes:
>Why not just run the original rmail which, presumably, called sendmail?

   The "original" rmail (whatever that is) that I had been using would
not always call sendmail. In particular, mail sent to ...mysite!localhost!user,
where "localhost" is on our local Ethernet, would fail, because rmail would
try to uux it to "localhost" and there was no such UUCP link. 

--Greg

daveb@gonzo.UUCP (Dave Brower) (03/02/89)

In article <471@manta.pha.pa.us> brant@manta.pha.pa.us (Brant Cheikes) writes:
>I recently installed sendmail (5.58) and reconfigured smail2.5 to
>serve as sendmail's UUCP front and back end.  So /bin/rmail continues
>to be linked to /bin/smail, but now rmail/smail is supposed to call
>sendmail to parse headers and determine proper message disposition.
>Yet the manual page for smail(8) notes:
>
>          As distributed, 'bang' mail that is not bound for a local
>          recipient will be passed directly to uux without calling
>          sendmail.
>
>Would someone please explain the rationale for this behavior?  This
>strikes me as a design error, as it prevents sendmail from performing
>its routine header manipulation.  In particular, because sendmail
>never sees the message, a "received" trace header never gets added
>(smail apparently fails to do that itself, in this case).  This is a
>valuable piece of information which should not be left out.

the one point that I'm unclear about is whether smail adds it's own
processing header on stuff passed through.  I thought it did, but the
poster above claims it doesn't.

Now, the reason why smail doesn't (without a hack) route incoming bang
path mail through sendmail is simple.  It is wrong to to so.  The
problem is that sending it through sendmail can make machines internal
to the domain served by the smail gateway visible to the outside world.
This can create unintentional namespace conflicts.

The audience cries for an example, forthwith.

Lets say that I have a smail/uucp gateway rtech, serving the rtech.com
domain.  There is an internal machine named gonzo, and there is also a
uucp connection to a properly mapped machine gonzo.uucp.  

If mail comes in to gonzo@rtech, it quite clearly goes through sendmail
and thence over the ether to the local machine.   But where should mail
to rtech!gonzo!person go?  If we route through sendmail, it goes to the
internal machine.  If we route back out through uux, it goes to the uucp
host.

Smail makes the judgement that if it has a bang path, it is uucp mail,
period, and going through sendmail only messes things that are supposed
to work up.

The flip side is that people who don't know any better try to send bang
pathed mail to internal machines that aren't uucp hosts.  That is, they
want the internal machine but they send it to rtech!gonzo anyway.  The
pedantic answer is that the mail is addressed wrong, and the sender
deserves to see it fall on the floor or get bounced.  In practice, this
can be somewhat anti-social.  Thus, with a hack, rtech does
(incorrectly) have smail route all mail through sendmail.  I still feel
bad about it. This only works if you are careful to avoid duplicates
between neighboring uucp sites and internal machines.

The problems with name conflict are much worse if someone turns on the
forcible re-router in Smail.  This is widely seen to be a Bad Idea, for
reasons that have been hashed out many times before.  Suffice it to say
it is a problem if smail gets mail for rtech!hoptoad!gonzo, decides that
it already talks to gonzo, then ships it to sendmail for delivery to the
internal machine.  There are other reasons, but I won't start.

I see a lot of funny mail routed through gonzo as well, usually by some
university mailer that is imagining an internal machine with that name
can best be reached by uucp through me.  My smail just bounces it around
some more.  I love sending mail saying, "fix your mailer, change your
name or send me a lot of money to make me want to change mine." 
Obviously no one has taken me up yet...

-dB

-- 
"I came here for an argument." "Oh.  This is getting hit on the head"
{sun,mtxinu,amdahl,hoptoad}!rtech!gonzo!daveb	daveb@gonzo.uucp