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