[comp.mail.sendmail] routing problem with sendmail/smail

evan@ndcheg.cheg.nd.edu (Evan Bauman) (07/12/88)

I just noticed a small problem with our sendmail/smail/bind mail system
and I was wondering if anyone had seen this same problem.  We're running
this all on a Sun 3/50 with SunOS 3.5.

ndcheg is the main mail machine here in engineering.  We have several
machines connected on the ethernet with names that are NOT registered
in the uucp maps.  We'd like to keep it that way.

Now here's the problem.  Let's say one of our locally un-registered
machines is called 'jupiter'.  Here at ndcheg, we get uucp mail
for 

ndcheg!jupiter!username

Since this is coming in via uucp, and not sendmail, rmail (which
is really smail in disguise!) assumes that this is mail bound for
another uucp link and bypasses sendmail completely.  I quote from
the Read.Me file in the smail distribution:

  Features of smail include:
.
.
  (5) Mail being forwarded through your machine to another uux link is
      passed from rmail directly to uux, so there's less overhead on
      your machine (sendmail stays out of the loop.)

which is NOT what I'd like to happen.  What actually happens is that
smail looks up a path to a machine called jupiter in /usr/lib/uucp/paths.
This jupiter is NOT the jupiter that the mail is destined for.

Therefore, I'd like to disable this 'feature' and put sendmail
"back into the loop".  Anyone with any ideas on how to do this??

Thanks in advance.

	Evan Bauman
	Univ. of Notre Dame
	evan@ndcheg.cheg.nd.edu
	evan@ndcheg.uucp


-- 

---------------------------------------------------------------------------
This message has been sponsored by Powdermilk Biscuits in the big blue box.
---------------------------------------------------------------------------

woods@ncar.ucar.edu (Greg Woods) (07/12/88)

In article <589@ndcheg.cheg.nd.edu> evan@ndcheg.cheg.nd.edu (Evan Bauman) writes:
>
>Since this is coming in via uucp, and not sendmail, rmail (which
>is really smail in disguise!) assumes that this is mail bound for
>another uucp link and bypasses sendmail completely.

   I ran into this one too, when first installing smail long before I ever
heard of BIND. The only fix I was able to come up with is the following
hack to main.c, which causes sendmail to be called EVERY TIME the program
is called as "rmail". This adds an extra load, because sendmail may very
well decide to hand the message back to smail again (but it would be called
as "smail", not "rmail", so there won't be a loop). However it does fix the
problem of local-etherhost!user getting bounced and as a side effect allows
your mail host to accept and route messages of the form host.domain!user
even if they come in over phoneline uucp, assuming your sendmail.cf
file can deal with this). At any rate, the hack is to find the place
where the pointer 'p' is set to rindex(argv[0],'/') and add:

if (*p == 'r')  /* called as rmail */
  handle=NONE; /* always call sendmail */
else handle=ALL; /* called as smail; do routing */

This loses if you are depending on smail to find Internet links for you,
but it sounds like it would work in your configuration.

--Greg

david@ms.uky.edu (David Herron -- One of the vertebrae) (07/12/88)

In article <426@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
>In article <589@ndcheg.cheg.nd.edu> evan@ndcheg.cheg.nd.edu (Evan Bauman) writes:
>>Since this is coming in via uucp, and not sendmail, rmail (which
>>is really smail in disguise!) assumes that this is mail bound for
>>another uucp link and bypasses sendmail completely.
>... The only fix I was able to come up with is the following
>hack to main.c, which causes sendmail to be called EVERY TIME the program
>is called as "rmail". This adds an extra load, because sendmail may very
>well decide to hand the message back to smail again (but it would be called
>as "smail", not "rmail", so there won't be a loop). However it does fix the
>problem of local-etherhost!user getting bounced and as a side effect allows
>your mail host to accept and route messages of the form host.domain!user
...

While this is *a* solution I don't think it's the best and it also introduces
a misfeature.

The misfeature is that you will now be unable -- at least in Evan's case --
to route mail to the "other" jupiter.  That is, unless you're willing
to require your users to type in some!long!path!which!ends!in!the!other!jupiter.
I'm not willing to require my users to do that -- instead I've always tried
to make it as easy for them (and me) as possible by having the ability
to type just user@host.uucp and the system gets the mail to them.

If you do something to allow local-etherhost!user as an address, and one
of your local-etherhosts is "jupiter", then mail to jupiter!user or
user@jupiter will end up at the local-etherhost.  NOT at the real
jupiter as intended (maybe intended).

As I see it the best solution is to arrange somehow for the local-etherhost
to always be referred to by the full.domain.name.  Then there is no
confusion because there is no name conflict.

An example of something else I do here.  My home machine is a 3b1 on
which I've installed smail 2.5.  I've configured that smail to use
ukma as the smart-host and the paths file on my system ONLY mentions
ukma.  I quite frequently use user@full.domain.name addresses on this
machine and it turns that into ukma!full.domain.name!user for me
and ships it off.
-- 
<---- David Herron -- The E-Mail guy                         <david@ms.uky.edu>
<---- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<----
<---- Today is the yesterday you worried about tomorrow.

butler@stsci.UUCP (07/12/88)

Re: trying to get smail to deliver: mymachine!localmachine!user to "user" on
"mymachine".

Have you tried putting a line like this:

localmachine	%s

in your pathalias database?
-- 
Lee A. Butler			      Internet: butler@stsci.edu
Space Telescope Science Institute	BITNET: BUTLER@STSCI
3700 San Martin Drive			  SPAN: SCIVAX::BUTLER (6549::BUTLER)
Baltimore, MD 21218			 Phone: (301) 338-4531

bowen@sunybcs.UUCP (07/12/88)

In article <426@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
>In article <589@ndcheg.cheg.nd.edu> evan@ndcheg.cheg.nd.edu (Evan Bauman) writes:
>>
>>Since this is coming in via uucp, and not sendmail, rmail (which
>>is really smail in disguise!) assumes that this is mail bound for
>>another uucp link and bypasses sendmail completely.
>
>   I ran into this one too, when first installing smail long before I ever
>heard of BIND. The only fix I was able to come up with is the following
>hack to main.c, which causes sendmail to be called EVERY TIME the program
>is called as "rmail".

I think this is (now, at least) a compile time option to smail. I've got
ours set up to bounce everything up to sendmail and I didn't put any hacks
in it at all. I had to do this because smail didn't update the path
as it went through us and it made us invisible to mail passing through
us. Not good when replying. Now I bounce it to sendmail and sendmail
takes care of updating the headers, etc.


Devon Bowen			Packet:    KA2NRC@WA0PTV
University at Buffalo		BITNET:    bowen@sunybcs.BITNET
				Internet:  bowen@cs.Buffalo.EDU
UUCP: ...!{ames,boulder,decvax,rutgers}!sunybcs!bowen

roberts@edsews.EDS.COM (Ted Roberts) (07/13/88)

In article <9938@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes:
> In article <426@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
> >... The only fix I was able to come up with is the following
> >hack to main.c, which causes sendmail to be called EVERY TIME the program
> >is called as "rmail".

I realize this isn't true for some systems (namely those that don't use
sendmail), but it seems that this is kind of a roundabout way of solving the
problem.  Why not just remove the link from rmail to smail and let sendmail
handle the routing.  If your sendmail.cf file is set up correctly, you should
check the local system (/etc/hosts) first, then check direct uucp connections
(/usr/lib/uucp/L.sys or similiar file), and finally route to smail as a last
resort - usually in cases of an non-direct host or a host name that includes
the full domain name.

> The misfeature is that you will now be unable -- at least in Evan's case --
> to route mail to the "other" jupiter.

As long as the user uses a full domain name as the target, smail should route
it just fine.  If the user tries to mail to user@jupiter and you have a direct
link to a machine called jupiter it should be routed via the direct link.

> As I see it the best solution is to arrange somehow for the local-etherhost
> to always be referred to by the full.domain.name.  Then there is no
> confusion because there is no name conflict.

I see it as the other way around.  Foreign hosts should always be referenced by
full domain names, otherwise inbound mail directed at your jupiter will always
be routed off to the other jupiter.

Note that I set our system up here so that ALL mail on subsidiary machines is
sent to the mailhost for routing.  All mail on the local system is delivered
on the mailhost and the mail directory is mounted out to subsidiary machines.
This does put a heavier mail load on the mailhost (a SUN 3/280), but it sure
simplifies the local system.

-- 
Ted Roberts                         |  My opinions are not necessarily those
EDS Technical Services Division     |  of my employer.  Does that mean I'm
UUCP: roberts@edsews.EDS.COM        |  wrong?

evan@ndcheg.cheg.nd.edu (Evan Bauman) (07/14/88)

In article <374@eve>, butler@stsci.EDU (Lee A. Butler) writes:
> Re: trying to get smail to deliver: mymachine!localmachine!user to "user" on
> "mymachine".
> 
> Have you tried putting a line like this:
> 
> localmachine	%s
> 
> in your pathalias database?

This method is a sure ticket to disaster.  Since there is already a 'localmachine'
listed somewhere in the maps, putting this in path.local will assume that
we have a connection to the REAL "localmachine" and all the resultant
paths will be messed up.

As a followup to my original postings, I installed Greg Woods' small
patch to main.c in smail yesterday, tested it out, and it works
just fine.  There's a small increase in the overhead by calling sendmail
every time, but it's a small price to pay to make the EE's upstairs happy.

Dave Herron has a valid point when he says that we will be unable to mail
to the real "jupiter", but I don't think this will ever me necessary (I checked
the maps for all the conflicting names, and they are obscure machines).

Of course, had the EE's been a little more imaginative when assigning
names to their computers, this never would have been a problem!  Hmmm,
wonder if they read this newsgroup??

	Evan Bauman
	University of Notre Dame
	evan@ndcheg.cheg.nd.edu
	evan@ndcheg.uucp
-- 

---------------------------------------------------------------------------
This message has been sponsored by Powdermilk Biscuits in the big blue box.
---------------------------------------------------------------------------

brian@ucsd.EDU (Brian Kantor) (07/14/88)

What we do at UCSD is:

All mail leaving here has a return address that looks like this 

	on the internet:
		user%campushost@UCSD.EDU
	on the uucp network
		ucsd!campushost.ucsd.edu!user

Mail addressed as

	wombat!user	will be delivered to the campus host
	'wombat.ucsd.edu' if there is such a host, otherwise it will be
	routed via the uucp maps to wherever wombat is.

	user@wombat	will be delivered to the campus host
	'wombat.ucsd.edu' if there is such a host, otherwise it will be
	returned as undeliverable.

	user@wombat.ucsd.edu	ditto
	user%wombat@ucsd.edu	ditto

	user@wombat.uucp	will be delivered via the route derived
	from the uucp maps regardless of whether is a campus host named
	'wombat' or not.

	user%wombat.uucp@ucsd.edu	ditto

In other words, we're treating '.uucp' as an explicit domain that is NOT
our local domain, and we're treating '!' as a pseudo-domain-specification 
that implies that the uucp domain should be tried if a host is not found
in the local domain.  This works really well for us.

If you want a copy of the incredibly baroque sendmail.cf file that does
all this, it's available via anonymous FTP from host UCSD.EDU
(128.54.16.1) on the Internet.

BTW, we use 'uumail' as a sendmail post-processor to do the uucp
routing.  Smail was too broken at the time we set this whole thing up to
even consider using it, and I don't like to change a working system.

	Brian Kantor	UCSD Postmaster
		UCSD Office of Academic Computing
		UCSD B-028, La Jolla, CA 92093 USA
		brian@ucsd.edu	BRIAN@UCSD ucsd!brian

daveb@llama.rtech.UUCP (Dave Brower) (07/14/88)

It happens that jupiter.uucp is a physical and uucp neighbor of ours, and we
have a nearly identical situation...

In <589@ndcheg.cheg.nd.edu> evan@ndcheg.cheg.nd.edu (Evan Bauman) writes:
>I just noticed a small problem with our sendmail/smail/bind mail system
>and I was wondering if anyone had seen this same problem.  We're running
>this all on a Sun 3/50 with SunOS 3.5.
>
>ndcheg is the main mail machine here in engineering.  We have several
>machines connected on the ethernet with names that are NOT registered
>in the uucp maps.  We'd like to keep it that way.
>
>Now here's the problem.  Let's say one of our locally un-registered
>machines is called 'jupiter'.  Here at ndcheg, we get uucp mail
>for
>
>ndcheg!jupiter!username
>
>Since this is coming in via uucp, and not sendmail, rmail (which
>is really smail in disguise!) assumes that this is mail bound for
>another uucp link and bypasses sendmail completely...
>
>Therefore, I'd like to disable this 'feature' and put sendmail
>"back into the loop".  Anyone with any ideas on how to do this??

There is a compile option in the defs.h file in the smail > 2.1 distribution
to handle this.  If you change "JUSTUUCP" below to "NONE", then you will get
what you think you want:

#ifdef SENDMAIL

#define HANDLE	JUSTUUCP	/* see HANDLE definition below */
#define ROUTING JUSTDOMAIN	/* see ROUTING definition below */

#define LMAIL(frm,sys) 	"%s -em -f%s",SENDMAIL,frm
#define LARG(user)		" '%s'",postmaster(user)
#define RLARG(sys,frm)		" '%s!%s'",sys,frm
#define LFROM(frm,now,host)	"From %s %.24s\n",frm,now

This is what we do right now, and unfortunately it is a botch.  A bang path
to your internal machine should not be visible to the outside world.  By
routing the bang path mail to it, you must resolve the conflict with other
sites that having conflicting names.  If they are mapped and you aren't,
then you either need to change or hide the host.

The correct way of handling this is to require domain addressing of mail to
your internal site, as in username@jupiter.ndcheg.uucp.  This is true
whether you are registered or not.

Another workaround is to arrange to have aliases at ndcheg for every user,
so that mail to ndcheg!username or username@ndcheg gets forwarded by
sendmail to the local username@jupiter.  This has the most appeal, but can
be an administrative problem.

It may be inconvenient to disallow incoming gateway!localmachine!user mail,
but I fear it is inevitable.  The sooner we start discouraging the practice,
the better off we will be.

-dB
"Ready when you are Raoul!"
{amdahl, cpsc6a, mtxinu, sun, hoptoad}!rtech!daveb daveb@rtech.com <- FINALLY!

woods@ncar.ucar.edu (Greg Woods) (07/14/88)

In article <9938@g.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes:
>In article <426@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
>>... The only fix I was able to come up with is the following
>>hack to main.c, which causes sendmail to be called EVERY TIME the program
>>is called as "rmail".

>While this is *a* solution I don't think it's the best and it also introduces
>a misfeature.
>
>The misfeature is that you will now be unable -- at least in Evan's case --
>to route mail to the "other" jupiter.  That is, unless you're willing
>to require your users to type in some!long!path!which!ends!in!the!other!jupiter.

As Brian Kantor pointed out, this is not at all true. Mail addressed to
user@jupiter.uucp (in Evan's case) will still be routed to the "other"
jupiter. Only the UNQUALIFIED name is assumed to be local. It is true
that this is a slight inconsistency since machines in the uucp maps
that do NOT have conflicting names with local hosts can be addressed
as "user@host" (without the explicit .uucp) whereas the .uucp is required
if there is a name conflict. I solved THAT problem by simply requiring them
to ALWAYS append .uucp if they want automatic routing. I.e. an address
of the form $-@$- (sendmail.cf syntax, i.e. only a single token to the
right of the @-sign, meaning no domain specified) *must* refer to a local
host or the message will be bounced by sendmail before smail is ever called.

--Greg

woods@ncar.ucar.edu (Greg Woods) (07/14/88)

In article <430@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
>As Brian Kantor pointed out, this is not at all true. Mail addressed to
>user@jupiter.uucp (in Evan's case) will still be routed to the "other"
>jupiter.

  I need to make a brief addendum to this. This assumes that you don't
list all your local machines in your uucp map. Otherwise the .uucp
address would still route to the local host (and fail, since smail
would try to invoke uux to it). Actually, all you have to do is follow
the official rules for map entries and just avoid listing any local hosts for
which there is a name conflict. The safest thing is to list none of them
unless it is a real uucp link (in which case you better NOT have
a name conflict!). As it happens, I do list a few of them, but only
for historical reasons (they were in my map entry when I inherited
it, and that entry was created before the days of smail).

--Greg

marcl@vax.3Com.Com (Marc Lavine) (07/14/88)

In article <426@ncar.ucar.edu> woods@handies.UCAR.EDU (Greg Woods) writes:
>   I ran into this one too, when first installing smail long before I ever
>heard of BIND. The only fix I was able to come up with is the following
>hack to main.c, which causes sendmail to be called EVERY TIME the program
>is called as "rmail".

There's a simpler way to do this.  When installing smail, just install
it as /bin/smail, and leave your old rmail as /bin/rmail.  Your old
rmail will call sendmail just like it did before you installed smail.
-- 
Marc Lavine				Internet: marcl%vax.3Com.Com@Sun.Com
Smart mailer: marcl@vax.3Com.Com	UUCP: ...{oliveb|sun}!3comvax!marcl

duncan@comp.vuw.ac.nz (Duncan McEwan) (07/14/88)

In article <12545@sunybcs.UUCP> bowen@sunybcs.UUCP (Devon E Bowen) writes:
>I've got ours set up to bounce everything up to sendmail ...
>... I had to do this because smail didn't update the path as it went
>through us and it made us invisible to mail passing through
>us. Not good when replying.

I believe smail does update the uucp "From_" line and intentionally leaves the
"From: " line untouched.  Having smail pass the message onto sendmail for the
purpose of adding your host to the front of the "From: " line is wrong.  As has
been rehashed in this and other groups many times before, the "From: " line
should be left as a valid rfc822 "user@domain" style address.

Mail user agents that do not understand rfc822 should only look at the "From_"
which smail has updated for you.  Sites whose mailers know about rfc822 can
look at the *domain* address in the "From: " header and figure a route back to
the sender -- they shouldn't need it to contain a valid path.

Apologies if I have misinterpreted what Devon is saying, or if my memory of the
behaviour of smail is incorrect (we no longer use it here so I can't check).

Duncan

edm@nwnexus.WA.COM (Ed Morin) (07/19/88)

In article <13955@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes:
>I believe smail does update the uucp "From_" line and intentionally leaves the

If memory serves me correctly, I had to hack on smail 2.3 to get it to update
the From_ line.  Maybe this was corrected in newer releases...

Ed Morin
Northwest Nexus Inc.
edm@nwnexus.wa.com