dennis@rlgvax.UUCP (Dennis Bednar) (01/07/87)
In article <799@maynard.BSW.COM>, campbell@maynard.BSW.COM (Larry Campbell) writes: > > Well, I've been using smail for two months now and I think it works > very well. What is smail, and what are its advantages? Sorry, but I joined this discussion late. -- -Dennis Bednar {decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis UUCP
mark@cbosgd.ATT.COM (Mark Horton) (01/09/87)
Well, I'm sorry that Phil is having problems with smail. It's also unfortunate that, rather than to ask us for help in fixing whatever problems he's run into (or better yet, asking his SA, who understands smail) he's chosen to go public. I don't stay caught up on netnews these days, and it's hard to help out members if we are unaware of the problem. We are contacting AMD to see if we can work out the problems. Smail does not normally reroute mail. It is possible to configure it to do that, but in general we don't recommend that, because it gets in the way of smart users who want to force a particular path. (Rerouting was put there for hosts like ihnp4 that get lots of netnews-path replies sent through them - it saves them considerable money. Gary Murakami is an expert and fully understands the tradeoffs of doing rerouting. We don't recommend that people set REROUTE unless they really know what they are doing, and even then I discourage it.) If people are finding their mail rerouted, then either people are disregarding the warnings, or else there is a bug somewhere we'd like to track down and fix. Telephone calls tend to be about the same cost, no matter how far they go, as long as they stay within the 48 states. Intrastate calls are often more expensive, due to less restrictive local regulation. The hop that goes across the country may seem inefficient, but if pathalias chose it, it's usually pretty reasonable. Of course, direct links should be used, if they are reliable and exist, unless there is good reason not to. Mail is sometimes bounced, due to systems that violate the standards. Since UUCP is a free community with lots of R&D on it, there are always people breaking their mailers. When politely told of the problem, most SA's are very happy to fix it. But it's a fact of life, whether one runs smail or not - mail will be bouned. Within the domain world, I have found mail to be pretty solid, certainly the weakest part is the underlying UUCP connection. Before smail, I had to keep a map of the net in my head, and a lot of my mail bounced. With smail, the system keeps a map for me, and less of my mail bounces. decwrl is primarily on DEC's ENET, and secondarily on the ARPANET. They consider themselves to be only tertiarily on UUCP. Given the complexity of an ENET-ARPANET gateway, I understand their decision. As a result, anything they get for a domain they don't recognize gets sent via the ARPANET, since they have chosen not to be a forwarder between ARPA or ENET and UUCP. Brian Reid and I spent some time a while back tracking down problems with their MX handling (most of which turned out not to be decwrl's fault, but problems elsewhere on the ARPANET) and now mail from DEC to a UUCP domain is forwarded properly, as Phil points out - in his case via Sun. The extra hop should be transparent and quite fast, since it goes over the ARPANET from decwrl to sun. It would be nice if decwrl's software would deliver it directly, but that would be hard to do, and the benefit would be awfully small, so I certainly understand why they aren't devoting the effort to do so. Mark Horton
bandy@amdcad.UUCP (Andy Beals) (01/09/87)
In article <3232@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes: >[much removed] and now mail from DEC to a UUCP domain >is forwarded properly, as Phil points out - in his case via Sun. Ah, but it doesn't recognize that there already is a direct connection between decwrl and amdcad that works quite well, thank you.. Why make an extra hop? Wasteful! >The extra hop should be transparent and quite fast, since it goes >over the ARPANET from decwrl to sun. Sorry, but that isn't always the case. Decwrl, while on the Internet, isn't on the Arpanet, it's on the Milnet. Sun hangs off of one of SRI's internal networks and those networks get routed through the Arpanet, which means you have to go through one of the damnable Arpanet/Milnet gateways. In the best of all possible worlds, the packets would go through a very nearby gateway (um, SRI may have an arpa/mil gw but I don't think so) such as LBL (Lawrence Laboratory, Berkeley) but the EGP data that has been flying around these days might force their packets to go through (ugh) bbn-milnet-gw which is way the hell out on the east coast (you have to get your money changed when you go out there an everything!). -- Why have keyboards gotten so horrible in recent years? The \i\b\m-\p\c has become an \'\industry \standard\' and the vt200 is an <i<s<o standard. Ick. Give me back my vt52 keyboard! Andrew Scott Beals, {lll-crg,decwrl}!amdcad!bandy
ted@blia.BLI.COM (Ted Marshall) (01/13/87)
In article <3232@cbosgd.ATT.COM>, mark@cbosgd.ATT.COM (Mark Horton) writes: > decwrl is primarily on DEC's ENET, and secondarily on the ARPANET. > They consider themselves to be only tertiarily on UUCP... This is interesting since my 1-December-1986 Usenet backbone map (published in news.misc, last updated by spaf@gatech.edu) shows decwrl connecting ucbvax, hplabs and decvax. I am a Usenet/UUCP novice user (I've been following this discussion because I'm facinated by this free exchange of information across the world enabled by Usenet and UUCP). Now I understood that to send mail to another UUCP site, I needed to generate a path from my site to a backbone site, then through the backbone to a path given by the recipient. For example, if someone says that their address is "...mcnc!xxx!yyy", I will use the following address: mtxinu!ucbvax!decwrl!decvax!mcnc!xxx!yyy |to-backbone-|-across-backbone--|to-recip Gee, what do you know, I just used decwrl as a UUCP forwarder. This says one of three things to me: (1) that's not how you are supposed to do intra-UUCP mail (in which case, please tell me the correct way) or (2) decwrl shouldn't be listed as on the backbone or (3) decwrl is a little closer to UUCP than Mark indicated. Please do not get me wrong. This is not a flame. My major flame is that despite the mod.newuser postings and available documentation (that I've found), conventions on UUCP are still very hard for a novice to learn. (I guess that shows everyone's UNIX background (1/2 :->)). =============================================================================== Ted Marshall Britton Lee, Inc. p-mail: 14600 Winchester Blvd, Los Gatos, Ca 95030 voice: (408)378-7000 uucp: ...!ucbvax!mtxinu!blia!ted ARPA: mtxinu!blia!ted@Berkeley.EDU disclaimer: These opinions are my own and may not reflect those of my employer; I leave them alone and they leave me alone. fortune for today: Justice is incidental to law and order. -- J. Edgar Hoover
avolio@decuac.DEC.COM (Frederick M. Avolio) (01/13/87)
In article <1442@blia.BLI.COM>, ted@blia.BLI.COM (Ted Marshall) writes: > In article <3232@cbosgd.ATT.COM>, mark@cbosgd.ATT.COM (Mark Horton) writes: > > decwrl is primarily on DEC's ENET, and secondarily on the ARPANET. > > They consider themselves to be only tertiarily on UUCP... > > This is interesting since my 1-December-1986 Usenet backbone map (published > in news.misc, last updated by spaf@gatech.edu) shows decwrl connecting > ucbvax, hplabs and decvax. You mistake Usenet with UUCP mail, which is what is being discussed. Usenet connectivity does not necessarily mean UUCP connectivity. As the posting you refer to says: A Usenet "backbone" site is one which exchanges every (non-local) news article it receives with at least two other backbone sites; or which is the main newsfeed for a particular area (e.g., Australia) and exchanges news with at least one other backbone site. ... As I stated in another posting, a site has to make some decisions about "preferred" protocols and go with it. It is easier for a site on the Internet to take any domain for which it itself is not an authority and pass it off to the Internet handler for that domain. Fred
reid@decwrl.DEC.COM (Brian Reid) (01/13/87)
decwrl is a USENET backbone site. USENET does not necessarily have anything at all to do with uucp. We also happen to be a major uucp hub in Silicon Valley, and we have several people who put a lot of work into making sure that decwrl works smoothly for uucp. I suspect that the reason Mark thinks that we think we are not a serious uucp site is that we choose not to perform automatic routing. We refuse to process addresses of the form foo@baz.UUCP. This is a conscious decision on our part, based on our observations that the automatic routing database has a lot of garbage in it, and that it will frequently route messages into hyperspace. The quality of the database is improving, and we are considering making the change to our software to turn on automatic routing. Brian Reid DEC Western Research uucp, DEC E-NET, ARPAnet, CSnet
phil@amdcad.UUCP (Phil Ngai) (01/14/87)
In article <7534@decwrl.DEC.COM> reid@decwrl.UUCP (Brian Reid) writes: > >decwrl is a USENET backbone site. USENET does not necessarily have anything >at all to do with uucp. We also happen to be a major uucp hub in Silicon >Valley, and we have several people who put a lot of work into making sure >that decwrl works smoothly for uucp. {Yes, decwrl is a major uucp hub and things in general work very smoothly. I am grateful for the services that decwrl provides. >I suspect that the reason Mark thinks that we think we are not a serious uucp >site is that we choose not to perform automatic routing. We refuse to >process addresses of the form foo@baz.UUCP. This is a conscious decision on >our part, based on our observations that the automatic routing database has a >lot of garbage in it, and that it will frequently route messages into >hyperspace. I would like to make a plea here. I hope I'm not carrying coal to Newcastle; decwrl is very well run and you probably know these things already. But there are people who don't and I think it's an important topic. Please, don't ever reroute uucp routed addresses of the form a!b!c. Please don't even shorten things like a!b!c to b!c where b is a site you know you connect to directly. This takes away the ability to test uucp links. And in my experience, the testability of a network is essential to keeping it running. It also takes away the ability to explicitly route around something known to have problems. It is appropriate to route domain addresses such as phil@neptune.amd.com. In the first place, you have to. In the second place, such addresses are fair game. Let's try to maintain two classes of addresses, ones which are eligible for routing and ones which should be handled strictly as specified by the sender. By the way, Brian, if you don't route foo@baz.UUCP, what do you do with it? Drop it, bounce it, or something else? -- My left foot is digital, my right foot is analog. Phil Ngai +1 408 749 5720 UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com
gds@sri-spam.istc.sri.com (The lost Bostonian) (01/20/87)
Mark Horton posted a useful message on why autorouting should be disabled with smail. If you are doing autorouting and you don't fully understand the dynamics of it, you should reread his message, then go read the code that implements rerouting under smail. I haven't looked at smail but I imagine the algorithms used for smail rerouting are pathalias table driven. A proper network routing algorithm requires near real-time connectivity information so that costs can be computed, links declared up/down, etc. with little interference to any given message. Pathalias table data could be months out of date, not to mention just plain incorrect. The uucp network is far too autonomous for autorouting to be done, period. Whether it is ok to optimize (cutting out intermediaries in the uucp-path) is debatable. I am inclined to say it is, because a site may have specific reasons for using a shorter path (it may be cheaper in $$ to connect to a host further down the path). I am opposed to mailers that rewrite the path entirely. Unfortunately I don't have the time or energy to write a mail router, much as I'd like to. I have a strong interest in communications routers (I've worked with some on the Internet) and would like to approach the problem in our heterogeneous environment. --gregbo