phil@amdcad.UUCP (Phil Ngai) (01/20/87)
Since I posted my claim that uucp routed mail should not be rerouted,
I have gotten some responses to the effect of "but it's more expensive
if you don't reroute".
For those who just dropped in, my claim (or plea) was:
1) don't reroute a!b!c!joe
a) even if you think d!c!joe is better
o your map data could be out of date
o site d's map data could be wrong about its costs
o sender may know site d is down
b) even if you directly connect to site b
o sender may be trying to test site a's connectivity
2) do route joe@c.domain
you have to route this anyway.
The objective of saving money on network expenses is a good one. I would
like to point out some important factors, which many readers may know
but I doubt all readers do:
1) cost is not a linear or even monotonic function of distance. That
is, it is often cheaper to call out of state than within the state.
2) a lot of bad cost data is floating around out there. Many sites,
for example, have assigned a low cost to calling ihnp4, a site which
no longer runs as well as it used to.
3) There are many routes which are less expensive than they may
appear. Companies such as mine often have internal networks with
fixed (and low) charges between their facilities. These networks are
needed to do business anyway and a little extra usage costs very
little, particularly at night when these networks are almost
completely unused.
Still, it is possible that one day, all sites will be sending in
regular, consistent map updates. If this day comes to pass, I still
see the loss of the ability to test network connectivity as posing a
serious problem for network maintenance. There is also the issue of
not having a manually routed fallback for emergencies.
I would like to propose a way to keep the network managable and still
provide the benefits of auto-routing, overridable by the knowledgeble
user when needed. Simply, encourage people to use domain addresses.
These have to be auto-routed. There are several ways to provide
encouragement. Simplest is to ask people to and write it into the
various news and mail documents. Second, make it the default for news
distributions, as that is where most of the long paths come from.
Third, and most facist, is to start bouncing ! routed addresses. To
avoid breaking the network maintenance features I am arguing so
strongly for, the sites which bounce ! routed addresses would check
for a header line of the form "Netman: loopback check" or "Netman:
routing around dead site", etc. Just check for the equivalent of the
moderated newsgroups Approved header line and if present, let it
through. If it is missing, send it back with a msg advising the sender
to use domain addresses.
Note the difference from proposals to add a "Reroute: no" field in
that a few sites implementing the "Netman" field would encourage many
sites to start using domain addressing while a few sites implementing
the "Reroute" field would not have much effect beyond encouraging
people to be lazy about choosing paths because they know someone else
will take care of it.
Comments?
--
Social security is welfare for the elderly.
Phil Ngai +1 408 749 5720
UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.commark@cogent.UUCP (Captain Neptune) (01/20/87)
In article <14396@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >Third, and most facist, is to start bouncing ! routed addresses. To >avoid breaking the network maintenance features I am arguing so >strongly for, the sites which bounce ! routed addresses would check >for a header line of the form "Netman: loopback check" or "Netman: >routing around dead site", etc. Just check for the equivalent of the >moderated newsgroups Approved header line and if present, let it >through. If it is missing, send it back with a msg advising the sender >to use domain addresses. > >Comments? Does this mean that my pathalias (which I've never gotten to work properly) has to be operational? -- +----------------------------------------------------------------------------+ | Mark Steven Jeghers ECHOMPGULP - process has eaten it | | cryptography, terrorist, DES, drugs, cipher, secret, decode, NSA, CIA, NRO | | | | {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark | | | | Cogent Software Solutions can not be held responsible for anything said | | by the above person since they have no control over him in the first place | +----------------------------------------------------------------------------+
jbs@mit-eddie.MIT.EDU (Jeff Siegal) (01/20/87)
In article <14396@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >[...]. To >avoid breaking the network maintenance features I am arguing so >strongly for, the sites which bounce ! routed addresses would check >for a header line of the form "Netman: loopback check" or "Netman: >routing around dead site", etc. Just check for the equivalent of the >moderated newsgroups Approved header line and if present, let it >through. If it is missing, send it back with a msg advising the sender >to use domain addresses. This seems unnecsary to me, since RFC822 compliant address can still specify routing. The syntax for this is @host1:@host2:user@host3. I've been told that the ":"'s should be ","'s except for the right-most one (as the Berkeley sendmail configuration does), but I've been unable to find this stated in RFC822 (could someone send me a reference, if the ","'s are actually correct). Jeff
zben@umd5 (Ben Cranston) (01/21/87)
In article <4611@mit-eddie.MIT.EDU> jbs@eddie.MIT.EDU (Jeff Siegal writes: > ... The syntax for this is @host1:@host2:user@host3. [sic -zben] > I've been told that the ":"'s should be ","'s except for the > right-most one (as the Berkeley sendmail configuration does), but I've > been unable to find this stated in RFC822 (could someone send me a > reference, if the ","'s are actually correct). See extended BNF on page 27 (section 6.1). route = 1#("@" domain) ":" The parentheses are groupers, the 1# syntax is a comma-separated list of from 1 to (arbitrary) members. Thus this rule matches things like: @domain: @domain,@domain: @domain,@domain,@domain: addr-spec = local-part "@" domain mailbox = addr-spec / phrase route-addr route-addr = "<" [route] addr-spec ">" Thus a "mailbox" can be something of the form: phrase <@domain,@domain,@domain:local@domain> like: Ben Cranston <@wiscvm.wisc.edu,@umd2.bitnet:zben@umd5.umd.edu> ("Oh no, we've created a Finster!") ("You mean monster, don't you?") ("No, his name is Finster!") -- umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92 umd2.BITNET "via HASP with RSCS"
jc@cdx39.UUCP (01/21/87)
> > For those who just dropped in, my claim (or plea) was: > > 1) don't reroute a!b!c!joe > a) even if you think d!c!joe is better > o your map data could be out of date > o site d's map data could be wrong about its costs > o sender may know site d is down > b) even if you directly connect to site b > o sender may be trying to test site a's connectivity c) even if d!c!joe really is faster and/or cheaper o the mail may be private or proprietary o sender may have security-related reasons to avoid d I've run into several cases where a!b!c!joe is all within a single company, but d!c!joe goes through an 'outside' site. Many companies are concerned that mail of a proprietary nature be restricted to the company's own machines. In such cases, autorouting would generally be undesirable, unless I have a way of suppressing it for a specific piece of mail. The easiest way to do this is probably something like Phil's suggestion: > 2) do route joe@c.domain > you have to route this anyway. The 'security' issue is a somewhat stronger one. I suspect that those among us with strong interests in having a secure system are not now installing mailers that do autorouting. There is just too much danger that a message to headquarters will be routed through berkeley or moskvax. [It's hard to say which would be considered the biggest security risk! :-] After all, if you're passing around insider trading info, do you want everyone at any random network site to have a chance to scan it? A related topic that I haven't heard discussed: We have some uucp links that are internal to the company, and are rather expensive long-distance calls. For company business, it is often a good idea to encourage their use. It's easier to uucp a big chunk of source code across a phone line than it is to mess with tapes or floppies, and it gets the job done much faster. But management has some reasonable concerns that the outside world start using these links for mail. The question is what sort of cost we attribute to such links. For internal mail, we'd like to make them look cheap, so that company communication be fast. To outsiders, we'd like to make them look expensive. So far, the approach has been to tell the outside world that they either don't exist or are very expensive. Internally, we aren't using a routing mailer, so it's no problem yet. With the existing routers, it looks like we'd have to have two sets of records (just like the accounting department :-), an internal set that makes the links cheap and an external set that makes them expensive. This seems undesirable; one of them has to be incorrect, and it'd be hard to prevent them from being accidentally 'corrected' to agree with each other. Any good ideas? Any ideas at all? Has this already been hashed out? If so, can someone email me the general solution? -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 Clever-Saying: If we can't fix it, it ain't broke.
pedz@bobkat.UUCP (01/23/87)
In article <14396@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: > Social security is welfare for the elderly. Thats total fucking god damn bullshit!!!! Welfare people put nothing in and get something out. The elderly have been force to put money into the pot but are very likely not to get a thing out. -- Perry Smith {convex!ctvax,{ti-csl,infotel}!pollux}!bobkat!pedz
wls@astrovax.UUCP (William L. Sebok) (01/23/87)
>This seems unnecsary to me, since RFC822 compliant address can still >specify routing. The syntax for this is @host1:@host2:user@host3. >I've been told that the ":"'s should be ","'s except for the >right-most one (as the Berkeley sendmail configuration does), but I've >been unable to find this stated in RFC822 (could someone send me a >reference, if the ","'s are actually correct). I have had severe problems writing a sendmail.cf that would properly handle addresses of that form: @host1,@host2,@host3:user@host4 The basic problem is that the sendmail parser wants to take the above address and break it apart at the commas. This effect can be turned off if the address is enclosed in angle brackets. However 1) what if the user forgets to use angle brackets? and 2) what if your mailer receives from another site an address of that form that is not enclosed in angle brackets? Here is one place I ran up against a wall when I did my recent complete rewrite of our sendmail.cf script. When gatewaying from uucp to sites reachable by SMTP I want to avoid creating From: and envelope From addresses that mix !'s and @'s (I treat "From:" and "envelope From" together here because, as previously discussed, an unhacked sendmail does not provide the ability to treat them differently). I handled !'s in addresses by dividing the SMTP reachable world into two classes. Those sites that understand !'s in an address are sent the address untouched. For the strict RFC822 sites, those that don't understand !'s in an address, the string of ! connected sitenames is turned into an RFC822 route. This is in the theory that when the reply to that message reaches here that my site can turn it back it to a ! format route and that, as is likely to be true, the site sending the reply does not otherwise know how to get mail back to the original sender of the note. When a ! route is turned into RFC822 route it needs to be surrounded by angle brackets to protect it from sendmail's parsing. However, the ruleset trying to do this has no idea whether the original address was surrounded by angle brackets (sendmail passes what is inside them to the ruleset and the replaces what was inside with the output of the ruleset). The safest thing to do seemed to be to have the ruleset put a set of angle brackets around it. But then, if they were already there, then two sets of angle brackets would be around the address. I am not sure if <<address>> is legal RFC822. I do know that some sites reject it. I don't know why the framers of RFC822 chose that form of syntax. The form @host1:@host2:@host3:user@host4 would really have been much easier to parse. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,topaz}!astrovax!wls one of these days: wls@astrovax.princeton.edu
diamant@hpfclp.UUCP (01/23/87)
> Thus a "mailbox" can be something of the form: > > phrase <@domain,@domain,@domain:local@domain> > > like: > > Ben Cranston <@wiscvm.wisc.edu,@umd2.bitnet:zben@umd5.umd.edu> Your technical description is completely correct, but I just want to point out that your example above does not conform to RFC822 because umd2.bitnet is not a registered domain. All the domains must be fully registered to conform to RFC822. John Diamant Systems Software Operation UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO
kent@tifsie.UUCP (01/24/87)
In article <460@bobkat.UUCP> Perry Smith writes: > > In article <14396@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >> Social security is welfare for the elderly. > > Thats total f-----g g-d d--n b------t!!!! Welfare people put nothing > in and get something out. The elderly have been force to put money > into the pot but are very likely not to get a thing out. > -- > Perry Smith > {convex!ctvax,{ti-csl,infotel}!pollux}!bobkat!pedz I have two comments: 1) I find your choice of phrasing _extremly_ offensive. I also recognize that you seem to feel _very_ strongly on the subject. Could I prevail upon you to be more judicious in your choice of words in the future? 2) I do not know what the dropout rate for SS is (i.e how often does it occur that a potential beneficiary never receives benefits). I do know that those who do live to collect, receive more benefits (even when calculated in constant-dollar figures) than they paid in to SS. If the "definition" of welfare is to receive funds in ways other than conventional earning, then SS is indeed often (but not always) welfare. Russell Kent Phone: +1 214 995 3501 Texas Instruments - PAC/FSI P.O. Box 655012 Net mail: Dallas, TX 75265 ...!{ihnp4,uiucdcs}!convex!smu!tifsie!kent MS 3635 ...!ut-sally!im4u!ti-csl!tifsie!kent Disclaimer: The views stated herein are my own, and do not necessarily represent any views of Texas Instruments, Inc. Conversely, the views stated by Texas Instruments, Inc. do not necessarily represent my own. Nyah nyah nyah.
kre@munnari.oz (Robert Elz) (01/24/87)
In article <837@astrovax.UUCP>, wls@astrovax.UUCP (William L. Sebok) writes: > I have had severe problems writing a sendmail.cf that would properly handle > addresses of that form: > @host1,@host2,@host3:user@host4 > The basic problem is that the sendmail parser wants to take the above address > and break it apart at the commas. Sendmail only "breaks apart" addresses in the headers, and in the headers this form of address is illegal if not surrounded by angle brackets. If the user forgets to add them, the user has used an illegal address, and bouncing the mail is the right thing to do (it should bounce, as @host1 has no "local part", and so is illegal too). Mail received from other sites is either received via smtp, which has a single address in the Rcpt cmd (and its enclosed in < > anyway), or its handed to sendmail as a command line arg, in which case sendmail does not "break it apart". > For the strict RFC822 sites, those that don't understand !'s in an address, > the string of ! connected sitenames is turned into an RFC822 route. I have considered doing this at times, but I have been unable to convince myself that it is truly an invertible conversion. In particular, when the rfc822 only site send you back an address in route-addr form, and its addressed to a uucp (!) site, can you really assume that you can unravel the route-addr into a ! path, and be certain of not unraveling too far? I couldn't work out any safe way to guarantee this. If I can't guarantee to invert a transformation, I'm not about to make it. > When a ! route > is turned into RFC822 route it needs to be surrounded by angle brackets to > protect it from sendmail's parsing. However, the ruleset trying to do this > has no idea whether the original address was surrounded by angle brackets This is indeed a problem, and one that should be fixed. > The safest thing to do seemed to be to > have the ruleset put a set of angle brackets around it. Unfortunately, even if you could avoid the double << >> problem (which sendmail could easily arrange to do), this still doesn't necessarily generate a legal address. Anywhere a route-addr is used, there must also be a "phrase" in the address as well. Sendmail would need to invent this phrase in some cases, and inventing something rational isn't necessarily easy. > I don't know why the framers of RFC822 chose that form of syntax. Everything I have ever been able to ascertain suggests that the thought of having user level source routing was so repugnant to some of the rfc822 creators, that they deliberately made the syntax as foul as they could get away with, given that others were adamant that the facility had to be provided. Robert Elz seismo!munnari!kre kre%munnari.oz@seismo.css.gov <@seismo.css.gov:kre@munnari.oz.au>
zben@umd5 (Ben Cranston) (01/25/87)
In article <1402@munnari.oz> kre@munnari.oz (Robert Elz) writes: > In article <837@astrovax.UUCP>, wls@astrovax.UUCP (William L. Sebok) writes: >> When a ! route is turned into RFC822 route ... >> The safest thing to do seemed to be to >> have the ruleset put a set of angle brackets around it. > Unfortunately, even if you could avoid the double << >> problem > (which sendmail could easily arrange to do), this still doesn't > necessarily generate a legal address. Anywhere a route-addr is > used, there must also be a "phrase" in the address as well. > Sendmail would need to invent this phrase in some cases, and > inventing something rational isn't necessarily easy. If there were any one particular wart in 822 that it would be reasonable to "by gentleman's agreement" ignore, it would be this requirement for a non-null phrase. Nevertheless, I think what we are talking about doing (translating an address from one domain to another) falls into the category of "munging". The existing RFC standard for header munging suggests the unmunged address be included as a pseudo-comment in the munged address. This can simultaniously satisfy the syntactic requirement for "phrase". So one might want to translate the address: fee!fie!foe!fum!jack into: "fee!fie!foe!fum!jack" <@fee,@fie,@foe:jack@fum> Seems as reasonable a default as any... My Internet to BitNet relay implementation does just this. -- umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92 umd2.BITNET "via HASP with RSCS"
roy@phri.UUCP (01/25/87)
In article <613@cdx39.UUCP> jc@cdx39.UUCP (John Chambers) writes: > There is just too much danger that a message to headquarters will be > routed through berkeley or moskvax. > [...] > We have some uucp links that are internal to the company, and are rather > expensive long-distance calls. For company business, it is often a good > idea to encourage their use. [...] But management has some reasonable > concerns that the outside world start using these links for mail. There was a talk at the Atlanta Usenix (don't remember who, sorry) about domains and routing mail between the Arpa Internet, UUCP, BITNET, CSNET, etc. One of the basic ideas to to put a high price on crossing domain boundaries. If you have your company totaly contained within a domain, both of the problems described above go away. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"
hmm@exunido.UUCP (01/28/87)
I think I must throw in my 2 Pfennig's worth... we decided to do uucp autorouting a long time ago, when most unknowledgeable mail users thought that ...!unido!mcvax!decvax!... was the only way across the pond. mcvax!decvax has been an awfully slow, awfully unreliable and awfully expensive 300bd telephone link, and we have a fast, reliable and cheap x.25 link to seismo... Not doing autorouting would have meant mail delivery times in the order of several days AND high comm. cost, while with seismo we have delivery within a few hours. Compared to the real benefits that autorouting has, the disadvantages are nearly nil. Who wants to talk to a uucp site which can't choose a unique name, anyway :-) ? Hans-Martin Mosner (one of) postmaster@unido.uucp
tim@dciem.UUCP (Tim Pointing) (01/28/87)
In article <301@tifsie.UUCP> kent@tifsie.UUCP writes: >In article <460@bobkat.UUCP> Perry Smith writes: >> >> Thats total f-----g g-d d--n b------t!!!! Welfare people put nothing >> in and get something out. The elderly have been force to put money >> into the pot but are very likely not to get a thing out. >> -- >> Perry Smith >> {convex!ctvax,{ti-csl,infotel}!pollux}!bobkat!pedz > >I have two comments: >... I have only one comment: Why the ---- is this being discussed in a newsgroup "dedicated" to UUCP mail issues?! Perhaps the discussion of Social Security vs Welfare should be moved talk.politics.misc or something. -- Tim Pointing, DCIEM {decvax|ihnp4|watmath}!utzoo!dciem!tim or uw-beaver!utcsri!dciem!tim or seismo!mnetor!lsuc!dciem!tim
chris@columbia.UUCP (01/29/87)
Anyone who wants to improve mail forwarding between the UUCP and RFC822 worlds should start by reading the RFC822 spec. Among other things, it becomes obvious why <>'s are necessary in route-addrs, the reason for using commas instead of colons to separate hosts in a route, etc. Too many people are trying to get the "look and feel" of RFC822 without paying attention to the details, and if you don't follow the spec, you may do more harm than good. I strongly discourage people from using uucp paths to construct RFC822 route-addrs, particularly because the uucp path components are generally not going to be "registered", and if they're not, you just can't build a legal route-addr. Also, if you use a stock sendmail, you can't just turn a uucp path into a route-addr since to be legal, route-addrs must be preceded by a "phrase". Furthermore, a proper RFC822 user agent will ignore any explicit route in the From: header and just use the addr-spec component (the portion following the ":") when generating replies. One alternative to trying to build route-addrs out of uucp paths is to rewrite the paths by appending your RFC822 domain name *and* prepending your uucp sitename, so host!user becomes princeton!host!user@princeton.edu. This is perfectly valid RFC822, and unless someone is misusing smail, replies should come back to you one way or another, at which point you just have to make sure you strip your name off at both ends. Chris