Xref: utzoo comp.mail.misc:1088 comp.mail.uucp:1443 comp.sources.d:2463
Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!rtech!llama!daveb
From: daveb@llama.rtech.UUCP (Dave Brower)
Newsgroups: comp.mail.misc,comp.mail.uucp,comp.mail.sendmail,comp.sources.d
Subject: Re: routing problem with sendmail/smail
Summary: There is a config option, but it's a botch.
Keywords: mail,smail,sendmail,route
Message-ID: <2319@rtech.rtech.com>
Date: 13 Jul 88 21:39:51 GMT
References: <589@ndcheg.cheg.nd.edu>
Sender: news@rtech.rtech.com
Reply-To: daveb@llama.UUCP (Dave Brower)
Organization: Relational Technology, Inc. Alameda, CA
Lines: 61

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!