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!