blm@cxsea.UUCP (Brian Matthews) (05/24/87)
I recently brought up smail 2.3 on a System V machine without
sendmail. It works quite nicely, except for one little problem.
Basically, smail appears not to look up the path when only '!'s are
used. So a path like user@machine would make it down to getpath and
have the cost filled in from the path file, but something like
machine!user wouldn't. This means that if DEFQUEUE is defined,
machine!user type paths will always just be queued.
I'd like to be able to use QUEUECOST, as we have a bunch of local
machines connected via uucp over Ethernet, so mail to these machines
should go immediately, and other external machines connected via
modem and X.25 links, mail to which should be queued. The costs in
the paths file reflect this, but of course these costs don't get
used.
Is this behaviour a feature or a bug, and if a bug, does anyone have
a fix for it? If it's a feature, is there any to force smail to do
what I want (not what I say 8-)).
Thanx for any information anyone might have.
--
+---------+
Brian L. Matthews | P L A N |
...{mnetor,uw-beaver!ssc-vax}!cxsea!blm | A H E A |
+1 206 251 6811 +--------D+
Computer X Inc. - a division of Motorola New Enterprisesjhc@mtune.ATT.COM (Jonathan Clark) (05/26/87)
In article <2088@cxsea.UUCP> blm@cxsea.UUCP (Brian Matthews) asks two questions about smail2.3. Paraphrased: > How do I force costs to be used on bang paths? Go into defs.h, change ROUTING to be ALWAYS. This is not done by default so as to leave vanilla UNIX mail syntax unaffected. > How do I make cheap mail go straight away? Same place, #undefine DEFQUEUE. -- Jonathan Clark [NAC,attmail]!mtune!jhc It's pretty steep until you reach the very top, then it falls away rather sharply.
Karl.Kleinpaste@cbstr1.UUCP (05/26/87)
blm@cxsea.UUCP writes:
I recently brought up smail 2.3 on a System V machine without
sendmail. It works quite nicely, except for one little problem.
Basically, smail appears not to look up the path when only '!'s are
used. So a path like user@machine would make it down to getpath and
have the cost filled in from the path file, but something like
machine!user wouldn't.
That's supposed to be a feature. I haven't decided whether it's
actually a bug or not myself. The idea is that, if somebody is going
to the trouble to hand smail a real, live UUCP path, then smail isn't
going to mess with it.
I just looked at smail.8, and found a small reference to this in the
section titled "Addresses," on page 2.
Karlblm@cxsea.UUCP (05/26/87)
In article <2088@cxsea.UUCP> blm@cxsea.UUCP (Brian Matthews) writes: |I recently brought up smail 2.3 on a System V machine without |sendmail. It works quite nicely, except for one little problem. |Basically, smail appears not to look up the path when only '!'s are |used. So a path like user@machine would make it down to getpath and |have the cost filled in from the path file, but something like |machine!user wouldn't. Sigh. Another case of RTFM. I did RTFM when I installed smail, but didn't really understand the three routing possibilities (JUSTDOMAIN, ALWAYS, REROUTE), so I left it at the default (JUSTDOMAIN). Of course this tells smail NOT to reroute just uucp paths. I did a little more digging in the code, and finally figured out I want ALWAYS routing. I changed it, and everything works as it's supposed to. Sorry 'bout that. -- +---------+ Brian L. Matthews | P L A N | ...{mnetor,uw-beaver!ssc-vax}!cxsea!blm | A H E A | +1 206 251 6811 +--------D+ Computer X Inc. - a division of Motorola New Enterprises
krs@amdahl.UUCP (05/26/87)
In article <239@cbstr1.att.com> Karl.Kleinpaste@cbstr1.att.com writes: >blm@cxsea.UUCP writes: > > [...] So a path like user@machine would make it down to getpath and > have the cost filled in from the path file, but something like > machine!user wouldn't. > >That's supposed to be a feature. I haven't decided whether it's >actually a bug or not myself. The idea is that, if somebody is going >to the trouble to hand smail a real, live UUCP path, then smail isn't >going to mess with it. I think that's a fine idea except (oddly enough?) on replies to netnews or other mail. Replying down a receipt path of mail, let alone news, often fails (for me) without the optimized path. I assume that's because site_a knows how to call site_b, which allows the call but either doesn't know how to call site_a back or disallows the call. The "fine idea" comment I started with revolves around stuck nodes: if our connection to site_c isn't working and normal path resolution to site_d is via site_c, I think it's pretty important that I can specify an alternate route around the failing/choked node. ...Kris -- Kristopher Stephens, | (408-746-6047) | {whatever}!amdahl!krs Amdahl Corporation | | -or- krs@amdahl.amdahl.com [The opinions expressed above are mine, solely, and do not ] [necessarily reflect the opinions or policies of Amdahl Corp. ]
lda@clyde.UUCP (05/28/87)
>From: jhc@mtune.ATT.COM (Jonathan Clark) >Subject: Re: Bug (feature?) in smail 2.3 >Summary: It's a feature >In article <2088@cxsea.UUCP> blm@cxsea.UUCP (Brian Matthews) asks two >questions about smail2.3. Paraphrased: >> How do I force costs to be used on bang paths? >Go into defs.h, change ROUTING to be ALWAYS. >This is not done by default so as to leave vanilla UNIX mail syntax >unaffected. >> How do I make cheap mail go straight away? >Same place, #undefine DEFQUEUE. We (the UUCP Project smail support organization) STRONGLY DISCOURAGE use of ROUTING == ALWAYS. Please don't do it without due consideration. People get frustrated when their mail get rerouted for no good reason. Now, to answer Brian's queston >> How do I force costs to be used on bang paths? This is was done intentionally in smail2.3 to minimize overhead on mail that's just passing through. I had several requests for the feature, so I added a #define GETCOST to cause the paths file to be searched for the cost of the first hop in the route. This feature will be in the next release of smail. The next release is due to go into beta test before the June USENIX conference with general availability "real soon now." Larry Auton
jbuck@epimass.UUCP (06/02/87)
In article <2089@cxsea.UUCP> blm@cxsea.UUCP (Brian Matthews) writes: >Sigh. Another case of RTFM. I did RTFM when I installed smail, but >didn't really understand the three routing possibilities (JUSTDOMAIN, >ALWAYS, REROUTE), so I left it at the default (JUSTDOMAIN). Of course >this tells smail NOT to reroute just uucp paths. I did a little more >digging in the code, and finally figured out I want ALWAYS routing. I >changed it, and everything works as it's supposed to. Sorry 'bout >that. You do not want REROUTE, and it should be eliminated from the code. Why? Several reasons: 1. If you do not keep your map data current, you will turn valid addresses into invalid ones, pissing off your neighbors. Since the UUCP Project does not keep the map current (I'm not blaming them, it's a tough job), it is out of date on the day it's posted. 2. REROUTE believes that there are no duplicate UUCP names. This is not true; turning it on in these cases will wreck valid UUCP paths no matter how consistent your database is. Now that the world is becoming domainized, this is officially sanctioned. To use Phil Ngai's example, there is an AT&T site named neptune and an AMD site named neptune. But there's no name conflict; the AMD site neptune does not appear in the UUCP map and its official name is neptune.amd.com. If someone mails to amdcad!neptune!user, this is a different neptune than the AT&T one, and mailers shouldn't be f*king with the address. 3. You make it impossible for users to avoid machines that are down. ihnp4, for example. Somebody posts a message "avoid ihnp4" but there's no way any of your users can. 4. You make it impossible to test specific UUCP connections with loop tests. ALWAYS, on the other hand, is perfectly OK because it does not alter valid paths. -- - Joe Buck jbuck@epimass.EPI.COM (in the brave new world of domains!) {seismo,ucbvax,sun,decwrl,<smart-site>}!epimass.epi.com!jbuck
david@ukma.UUCP (06/03/87)
In article <1217@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >1. ... > the UUCP Project does not keep the map current (I'm not blaming > them, it's a tough job), it is out of date on the day it's posted. *grin*, we try... There's times I'm glad I only take care of KY. :-) >2. REROUTE believes that there are no duplicate UUCP names. ... > > To use Phil Ngai's example, there is an AT&T site named neptune > and an AMD site named neptune. But there's no name conflict; > the AMD site neptune does not appear in the UUCP map and its official > name is neptune.amd.com. If someone mails to amdcad!neptune!user, > this is a different neptune than the AT&T one, and mailers shouldn't > be f*king with the address. This is the part I couldn't let pass by. If amdcad wants to have their neptune able to send and receive mail without hassles, then they should arrange it so that mail will be sent to amdcat!neptune.amd.com!user. (i.e. putting that out in headers when mail is sent out, announcing in the maps either the existance of a gateway for .amd.com or the existance of neptune.amd.com itself, etc). If they do anything else, they're asking for trouble. >3. You make it impossible for users to avoid machines that are down. > ihnp4, for example. Somebody posts a message "avoid ihnp4" but > there's no way any of your users can. My own strategy is to route to the first host mentioned in the path which I am given. This is merely a convenience, so that if I have some address from a well-known-site, then I don't *have* to find the path to that well-known-site. Looking down the path beyond the first site is not kosher because you don't *know* if those names you see there actually refer to the ones you have in your database. That is, unless you do some edge analysis a la peter honeyman. To be honest tho.... I don't quite practice what I just preached. I run MMDF here, and the uucp channel sort-of breaks those rules. When it receives a message it collapses the From_'s, looks down that path for sites in its' data base (assuming only .uucp places) and stops at the first one it doesn't know. Then it re-writes the header so that the From: says unk1!unk2!...!user@known.UUCP. For the rmail arguments it does exactly what I describe above. I don't quite agree with its strategy, but I don't have the time to change it... >4. You make it impossible to test specific UUCP connections with loop > tests. I would go along with this, however I haven't needed to do this for at least a year. I can't even remember the last time I had to do this. And I am a heavy user of e-mail. -- ----- David Herron, cbosgd!ukma!david, david@UKMA.BITNET, david@ms.uky.csnet ----- (also "postmaster", "news", and the Usenet map maintainer for Kentucky.) ----- bsmtp-users@ms.uky.csnet for bsmtp discussion ----- bsmtp-users-request@ms.uky.csnet for administrivia
jimb@dopey.AMD.COM (Jim Budler) (06/10/87)
In article <6762@a.ms.uky.csnet> david@ms.uky.csnet (David Herron -- Resident E-mail Hack) writes: >>2. REROUTE believes that there are no duplicate UUCP names. ... >> >> To use Phil Ngai's example, there is an AT&T site named neptune >> and an AMD site named neptune. But there's no name conflict; >> the AMD site neptune does not appear in the UUCP map and its official >> name is neptune.amd.com. If someone mails to amdcad!neptune!user, >> this is a different neptune than the AT&T one, and mailers shouldn't >> be f*king with the address. > >This is the part I couldn't let pass by. Why not? > >If amdcad wants to have their neptune able to send and receive mail >without hassles, then they should arrange it so that mail will be sent >to amdcat!neptune.amd.com!user. (i.e. putting that out in headers when It said the official name was neptune.amd.com. >mail is sent out, announcing in the maps either the existance of a >gateway for .amd.com or the existance of neptune.amd.com itself, etc). Try uuhosts 'amd.com'. Registered, mapped, gatewayed, and sendmail configured to know about the .AMD.COM long ago. > >If they do anything else, they're asking for trouble. You mean like the user who places amdcad!neptune!joe in his .signature :-)? +--------------- We do all of the above, but I still believe that ...!amdcad!dopey!... in a path should always refer to OUR dopey (dopey.amd.com). A path of the form ...!amdcad!dopey!jimb which passes through any site which has defined REROUTE will be sent to dopey, a machine in Ohio rather than to OUR dopey. ( You'll note the change of the example from neptune to dopey, above. This is for the simple reason that, with the removal of att internal machines from the maps a couple of months ago, there is no longer any non-domainized neptune in the map. But there is a dopey.) -- + Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 + + Compuserve: 72415,1200; Delphi: JIMBUDLER; Usenet: jimb@amdcad.AMD.COM +
kyle@xanth.UUCP (06/11/87)
In article <355@dopey.AMD.COM>, jimb@dopey.AMD.COM (Jim Budler) writes: > A path of the form ...!amdcad!dopey!jimb which passes through any > site which has defined REROUTE will be sent to dopey, a machine in Ohio > rather than to OUR dopey. This is as it should be. The occurrance of a name such as "dopey" in a bang route should have a unique meaning on all UUCP sites. Therefore "dopey" = "dopey.UUCP" = the "dopey" in the UUCP maps. If a site along the way knows a cheaper way to get to the machine in Ohio, more power to them... they are presumably saving themselves and maybe a few other sites some $$. However, such a site must be careful not to route mail back to a site where it has already been, and possible cause looping. kyle jones <kyle@xanth.cs.odu.edu> old dominion university, norfolk, va