dhesi@bsu-cs.UUCP (05/11/87)
I have seen articles complaining about the problems caused by mixed
addressing. For example, "a!b!c@d.e!f" can be taken as equivalent to
"(c@d.e)!(f)!(a!b!c)" or "(e!f)!(c@d.e)!(a!b!c)". Many other ambiguous
combinations of addresses can be invented.
The solution is trivial though it would need a change in most
software. Introduce symbols that allow you to group address
components. I have used parentheses above, but they are already
taken. Perhaps square brackets could be used. Any machine can then
safely add its own address to the path, thus converting
any_path
to:
[myname!any_path]
The next machine can then add its own name thus:
[[myname!any_path]@next]
So long as each change is accompanied by a new pair of brackets around
the entire result, there will never be any confusion. The mail
software can also strip out redundant brackets, but their presence
will do no harm.
--
Rahul Dhesi
ARPA: bsu-cs!dhesi@iuvax.cs.indiana.edu
UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesikyle@xanth.UUCP (kyle jones) (05/13/87)
In article <588@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > I have seen articles complaining about the problems caused by mixed > addressing. > ... > The solution is trivial though it would need a change in most > software. Introduce symbols that allow you to group address > components. I have used parentheses above, but they are already > taken. Perhaps square brackets could be used. Square brackets are out; the Internet uses them in address specs to specify a host number instead of a domain name, e.g. gurgler@[87.9.2.47] . Furthermore, no further address operators are needed. RFC822 states how addresses are to be parsed; the problem is getting people to accept the standard and do whatever it takes to get their mailers up to snuff. What we DO need are some rules on how to interpret the wild mixes of the non-standard operators such as "%", "!", and "::". The precedences we use here are "@ then "!" then "%". "::" is a horror from some network of which we're (apparently) not a member. Also I've seen addresses with "@!" and "!@" in them. Any ideas on what to do with these??? kyle jones <kyle@xanth.cs.odu.edu> old dominion university, norfolk, va
lel@liuida.UUCP (05/15/87)
In article <588@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > The solution is trivial though it would need a change in most > software. Introduce symbols that allow you to group address > components. I have used parentheses above, but they are already > taken. Perhaps square brackets could be used. The solution is NOT to introduce more symbols. There are many enough already, thank you. What is needed is the conformance to a single standard, whenever possible, and for the Mail Transfer Agents to otherwise do intelligent full translations from the transmitting net's standard to the receiving net's. In article <958@xanth.UUCP> kyle@xanth.UUCP (kyle jones) writes: > What we DO need are some rules on how to interpret the wild mixes of the > non-standard operators such as "%", "!", and "::". The precedences we use > here are "@ then "!" then "%". "::" is a horror from some network of which > we're (apparently) not a member. Also I've seen addresses with "@!" and "!@" > in them. Any ideas on what to do with these??? OK, let's see: "!" is used as a routing operator in the UUCP world. "%" on top of "@" is a de facto routing operator in the ARPANET world. "::" is a routing operator for VAX/VMS mail. "!@" can appear on RFC822 routes embedded in UUCP paths, as in: node!node!@domain,@domain:user@domain Let's then assume that you are a Domainist, ie. you will give "@" precedence before "!" by parsing routes like: node2!node1!user@node3 as: node3 -> node2 -> node1 -> user Now, since "%" is the natural routing operator on top of "@", an address like: node1!user@node2 that is autorouted through "node3" will probably end up looking as: node1!user%node2@node3 meaning: node3 -> node2 -> node1 -> user Giving "!" priority over "%" is clearly an error in this case. However, if you have a "!" path address ending with a "user%node", you can safely prioritize "!" over "%", since this cannot be interpreted as a domain address. Thus, node3!node2!user%node1 should be read as: node3 -> node2 -> node1 -> user One thing that *could* complicate this, is VAX/VMS mail that uses "%" as special operator delimiting a "Foreign Mail Protocol" from the host name, as in: PSI%24020010040403::LISBET::L-LOVSTRAND meaning: to host 24020010040403 using the Packet Switched Interface, then -> LISBET -> L-LOVSTRAND Fortunately, I haven't seem much of them on the net. Their forwarding MTAs seems to be intelligent enough to properly translate them into the receiving net's standard. I just wish more MTAs would do the same thing with "!" addresses going into domain land... Oh well, just wishing. --Lennart (Or perhaps not, see "Electronic Mail Addressing in Theory and Practice with the IDA Sendmail Enhancement Kit" being released to you on this net (very) shortly)
diamant@hpfclp.HP.COM (John Diamant) (05/16/87)
> Also I've seen addresses with "@!" and "!@" > in them. Any ideas on what to do with these??? > > kyle jones <kyle@xanth.cs.odu.edu> > old dominion university, norfolk, va The first form ("@!") is total trash and I haven't the faintest idea what you could do with it (I've never seen one either). The second form ("!@") occurs when mail is sent from RFC-822 world into UUCP and the From: line had a source route in it and the gateway doesn't know what to do with it. I regularly see mail coming from hplabs (my ARPANET gateway) of the form: hplabs!@foo:user@bar If this is the kind of thing you are talking about, you can ignore everything up to the first @ and treat it like a standard RFC-822 source route. Of course, you aren't allowed to do that by RFC-822, since this address is already illegal and no standard is going to tell you what to do with an illegal address. John Diamant SCO UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO
dhesi@bsu-cs.UUCP (05/16/87)
In article <559@smidefix.liu.se> lel@ida.liu.se (Lennart Lovstrand) responds to my solution for the current confusion about precedence in mail addresses, which was to introduce symbols that would force precedence, as follows: >The solution is NOT to introduce more symbols. There are many enough >already, thank you. Perhaps an analogy with programming languages will help. Count the number of different arithmetic operators, then tell me why they must include parentheses too. It simply isn't a question of whether or not you have enough symbols; it's a question of whether or not the symbols you have do what you want. Currently there is no symbol for forcing precedence. > ...What is needed is the conformance to a single >standard, whenever possible, and for the Mail Transfer Agents to >otherwise do intelligent full translations from the transmitting net's >standard to the receiving net's. This ignores the reason why the concept of "layering" is so important, as is the concept of "device independence". To expect a single component of a software system--especially a software system that spans numerous countries, cultures, and operating systems--to understand every little addressing detail of every component, is unrealistic. It makes more sense to leave the decoding of local addresses to local software. The nice thing about UUCP has been that it was so easy to get on it. Adding the ability to force precedence would allow any network to use any internal address format and still be part of a bigger network. I see no reason why [e!f!g]a@b.c should not be a valid address, where a@b.c is a site with a registered domain address, and e!f!g is a path on a smaller network feeding from site a. But intermediate nodes should NOT have to interpret the "e!f!g" part of the address. (In place of square brackets, choose another symbol if necessary.) To put it more simply: there ought to be a way of taking an arbitrary network address, and making it look like a single site by bracketing it. Thus I should be able to say "[a$b&c!d#f]@host.DOMAIN", and let "host" handle the decoding of the "[a$b&c!d]" and hand the message on to the server for the network that uses the addres format "a$b&c!d#f". No other node has any business trying to interpret "a$b&c!d#f", or insisting on converting it (usually incorrectly) to "b.c.d.f.a" or whatever, just because it wants everything to be separated by dots or percent signs. Leave the interpretation of local syntax to the local sites! -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
corwin@bsu-cs.UUCP (Paul Frommeyer) (05/17/87)
In article <631@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > > on a smaller network feeding from site a. But intermediate nodes > should NOT have to interpret the "e!f!g" part of the address. (In > place of square brackets, choose another symbol if necessary.) > > To put it more simply: > Thus I should be able to say "[a$b&c!d#f]@host.DOMAIN", and let "host" > handle the decoding of the "[a$b&c!d]" and hand the message on to the > server for the network that uses the addres format "a$b&c!d#f". No > other node has any business trying to interpret "a$b&c!d#f", or > insisting on converting it (usually incorrectly) to "b.c.d.f.a" or > whatever, just because it wants everything to be separated by dots or > percent signs. Leave the interpretation of local syntax to the local > sites! Amen! I tried for weeks with a friend to get mail through to seismo from Carnegie-Mellon U., and never did succeed. The network server INSISTED on trying to send everything via ARPAnet first, which of course didn't fly with such things as .UUCP on the end. I tried variations suggested in the CMU networking manual, consulted with CMU computer staff, all to no avail. The snag, you see, was my friend didn't have ARPA access, and since the server refused to acknowledge anything else, even tho there were Bitnet connections all over, there was no way around the problem... Layered addressing would seem to solve this problem admirably, forcing the server to interpret the bitnet address first instead of translating the intermediate addresses and going with those... On the other hand, I had no problem mailing from our site to CMU via UUCP. :-) -- Paul "Corwin" Frommeyer "Experience is no substitute for competence." UUCP: {seismo,ihnp4}!{iuvax,pur-ee}!bsu-cs!corwin
pdb@sei.cmu.edu (Patrick Barron) (05/17/87)
In article <631@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Thus I should be able to say "[a$b&c!d#f]@host.DOMAIN", and let "host" >handle the decoding of the "[a$b&c!d]" and hand the message on to the >server for the network that uses the addres format "a$b&c!d#f". No >other node has any business trying to interpret "a$b&c!d#f", or >insisting on converting it (usually incorrectly) to "b.c.d.f.a" or >whatever, just because it wants everything to be separated by dots or >percent signs. Leave the interpretation of local syntax to the local >sites! In an Internet environment (that is, one that uses RFC 822 type addressing), this should already work (with a few exceptions like explicitly routed addresses and comment conventions). At the mail transport level, there is only ONE operator: the '@' sign. Precedence is no problem, since only one '@' sign allowed in an address. Once the message arrives at the site specified on the right side of the '@', that site can interpret the left side however it wants to. No intermediary gateway should even ATTEMPT to interpret the left side. Now, you may have a problem if you want to put another '@' sign on the left side of the address, but RFC 822 has provisions for escaping "special" characters. So, sites that are really RFC 822 compliant should already be able to do what you want, with no new grouping operators needed. Or am I missing the point entirely? --Pat.
ahby@meccts.MECC.MN.ORG (Shane P. McCarron) (05/17/87)
In article <559@smidefix.liu.se> lel@ida.liu.se (Lennart Lovstrand) writes: All sorts of excellent information about routing and routing symbols... >Now, since "%" is the natural routing operator on top of "@", an >address like: > node1!user@node2 >that is autorouted through "node3" will probably end up looking as: > node1!user%node2@node3 >meaning: > node3 -> node2 -> node1 -> user It seems to me that undef RFC 976, something autorouted through "node3" should be transmitted as: node2!node1!user@node3 Also, since "node2" started life after an @, it must by definition have a domain suffix attached to it. So, if th initial address had been: node1!user@node2.edu it would be autorouted as: node2.edu!node1!user@node3 which, under RFC 976 and UUCP would be translated for forwarding as: node3!node2.edu!node1!user -- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby@MECC.MN.ORG MECC Technical Services ATT (612) 481-3589 (C) Copyright 1987 Shane P. McCarron Redistribution allowed only if your recipients can redistribute
chris@mimsy.UUCP (Chris Torek) (05/17/87)
>In article <559@smidefix.liu.se> lel@ida.liu.se (Lennart Lovstrand) responds >>The solution is NOT to introduce more symbols. There are many enough >>already, thank you. *If* one could introduce new symbols *and* get everyone to use them, they would help. The first is feasible; the second is not. In article <631@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >... To expect a single component of a software system--especially >a software system that spans numerous countries, cultures, and >operating systems--to understand every little addressing detail >of every component, is unrealistic. True. But consider: Why must so many mail systems understand so many forms of addresses? >It makes more sense to leave the decoding of local addresses to >local software. It *is* up to local software, always. >The nice thing about UUCP has been that it was so easy to get on it. *BONG* And this is exactly the problem: The networks are too highly interconnected. There are too many places that speak too many languages, and they confuse each other as to which one was spoken. If we had a single gateway between USENET and ARPAnet, messages could cross a gateway only once. Messages on the ARPAnet side would always read From: decvax!seismo!mimsy!user@Berkeley.EDU and the replies would always read From decvax!ucbvax!replier@bbn.com remote from seismo and everything would work, since mimsy would speak only UUCP-`!' and BBN would speak only ARPA-`@'. But seismo and mimsy are both on the ARPAnet as well, and if they are not careful about which language they are speaking, they will lose track of the proper meaning of the addresses. While bracketing would work around the problem, there are other solutions. *All* complete solutions require that *all* gateways do something sensible. This is easy when there are few gateways, or when there is some authority that can control the software used at each gateway. UUCP is not in this situation. Just as an example, another solution would be for USENET/ARPAnet gateways to encode the part of the address that is supposed to be `private'. Mail forwarded through ucbvax/Berkeley.EDU to replier@bbn.com might read From: hebviqtbxzergwqvaueccuothksefgo@Berkeley.EDU, this ridiculous string being the result of encoding `via UUCP from decvax!seismo!mimsy!user'. When it receives this user name back (possibly changed to uppercase!), it could decode this and send the message on its way. Note that all networking characters have been removed (as with parentheses) without using any extra symbols (which requires others to understand the symbols). (A more readable encoding, say, using modified byte stuffing, might be `From: decvvaxvlseismovlmimsyvluser@Berkeley.edu'. Nonetheless, this should not be necessary. There is nothing technically wrong with `!'s on the left of an `@' in ARPA-land.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
Karl.Kleinpaste@cbstr1.UUCP (05/18/87)
With all due respect, I think the correct solution to the problem of forced precedence in mail addresses is to conform to RFC <you-name-it> by installing smail or other compliant software. The suggestion that [a$b&c!d#f]@host.domain ought to be shipped off to "host" who will then interpret the remaining mess is fine - except that the brackets to force the high-order precedence of `@' are not at all necessary by virtue of the fact that `@' is the only recognized addressing character according to the relevant RFCs. So everything right of `@' is what a compliant host needs to consider for relay purposes, everything left of `@' is used for whatever you want to use it for, and I don't have to cope with that in any way. The only way I'd have to try to cope with it is if strcmp(host.domain, "cbstr1.att.com") == 0, in which case I'm obliged to handle the "local part" on the left - and in which case I'll bounce it back at you as an unrecognizable mess. (Full names and login names only, thanx much.) The RFC is nice enough to hand me a very clear rule about this, so your brackets to force precedence are really very unnecessary. Sites converting local.part@host.domain to some other syntax, or trying to handle local.part when they are not the destination host.domain, are violating the RFC constraints. Karl
corwin@bsu-cs.UUCP (Paul Frommeyer) (05/18/87)
Uh, being relatively new to the net, I realize this may be a) a very foolish
question and b) one that has no doubt been debated hotly before, but what
about establishing a UUCP administration center? (and watch the sparks fly
from this...!)
It seems there are already a number of major figures in the UUCP and Usenet
world. Would it be unrealistic to consider the establishment of a UUCP
"regulatory authority" acting in a purely non-profit fashion?
I am not speaking simply of designating a group of users as "the people
in charge," and imposing upon them an even larger burden of responsibility
on top of their present employment, though this would be one method.
What if an actual physical UUCP or Usenet Incorporated were to be established?
AA number of possibities open up: First, all inter-network messages could be
routed through there. Second, it would certainly provide a means for easing
the excessive Usenet data flow; any site overtaxed by this could, if they
chose, initiate direct communication with the UUCP HQ. UUCP HQ could
use as many disk storage systems as they could find, and as many phone
lines too, and act as a clearinghouse for all the UUCP/Usenet traffic.
If the installation was set up as a non-profit corporation, ough, there
are many, many problems, too. First, of course, is who is going to staff
the place? No-one can work for free, or at least not do that full-time and
eat as well, so there is a big question of salaries and incoming revenue.
Secondly, more money is needed to buy facilities and pay equipment. The
concept rapidly runs into the millions of dollars, and that's just to get
started. Of course since it would be non-profit, the advantage here is to
assess usage charges from the various UUCP/Usenet sites. Unfortunately, this
is really just against the spirit of Usenet, it seems to me, but perhaps
a closer study is needed. After all, if a connection charge of, say, $20 is
made and then $5 weekly use charges, assuming Usenet continues to grow at
its present rate, if there were 50,000 users revenue would be $50,000
a week. Not too shabby, it seems to me, but I do not have enough experience
with running a large-scale computing center to even guess at the costs, though
the thought of 1,000 or so phone lines makes me shudder, not to mention all
the disks and other hardware needed to get things going.
But still, the advantages seem to me to be pretty powerful. I do not doubt
there would be no lack of people willing to work for Usenet, INC. (I'd die
to be in on this...!). And we've got hundreds of people putting in unpaid
overtime on Usenet ANYWAY. There would be the vantage of having one
central Usenet site database, so not only would it be easier to track
Usenet usage, but new sites could easily find their nearest neighbor,
and it might be possible to figure out how to better distribute the network
load. Note that not all sites would have to go through Central; all sites
would simply have to pay a registration fee. But this would alleviate
ihnp4's handling of, say, several hundred systems, and vice-versa.
What on earth has this to do with network protocol? Another plust
would be that all Usenet sites would send trans-network mail only
through Usenet CentralCentral could then perform appropriate address
translation and forward to the appropriate net in cooperation with major
gateways. Of course, another big plus would be that "unknown host"
would virtually vanish; if you don't know the path, send it to Central.
Anyway, it was just an idea I had based on all the complaining about
Usenet traffic, addressing foul-ups, nebulous network size, etc. It would
depend totally on the support of the user community; registration and
fee payment would be impossible to force, and sites could always permit
bogus Usenet connections. Public domain accounting records would do nothing
to defray the dismay of a $200 weekly network use bill.
I thought I'd go ahead and display my ignorance for all, though, because
most of you out there are much better equipped to make judgements on this
than me. So flame away at this idea; that's why I wrote it. I am
no doubt out of touch with reality in this idea, but maybe if there's an
ensuing debate something good will come of it. And this is why we all
share ideas, is it not?
Cheers,
--
Paul "Corwin" Frommeyer "Experience is no substitute for competence."
UUCP:
{seismo,ihnp4}!{iuvax,pur-ee}!bsu-cs!corwinrick@seismo.CSS.GOV (Rick Adams) (05/18/87)
You have just described the UUNET project without the enforced regulation. ---rick
lel@ida.liu.se (Lennart Lovstrand) (05/19/87)
In article <2767@meccts.MECC.MN.ORG> ahby@meccts.UUCP (Shane P. McCarron) writes: > In article <559@smidefix.liu.se> lel@ida.liu.se (Lennart Lovstrand) writes: > All sorts of excellent information about routing and routing > symbols... > > Now, since "%" is the natural routing operator on top of "@", an > > address like: > > node1!user@node2 > > that is autorouted through "node3" will probably end up looking as: > > node1!user%node2@node3 > > meaning: > > node3 ->node2 ->node1 ->user > > It seems to me that undef RFC 976, something autorouted through "node3" > should be transmitted as: > node2!node1!user@node3 Not if node2 is an ARPANET node, say, that doesn't subscribe to RFC976. Remember that RFC976 means "UUCP Mail Interchange Format". Even though neither "!" nor "%" is an official routing operator for RFC822 complying nodes, I would say that the latter is much more frequent than the former. > Also, since "node2" started life after an @, it must by definition have a > domain suffix attached to it. So, if th initial address had been: > [...] Well, yes, I was thinking of both node2 and node3 as domains, thanks for pointing it out. Still, that doesn't necessarily mean that they have a dot in them. RFC920 explictly states that a multiorganization could become a top level domain, which means that you might wind up with addresses like "TheSecretaryGeneral@UN". Cheers, --Lennart -- Dept of Computer and Information Science, University of Linkoping, Sweden Internet: Lennart.Lovstrand@IDA.LiU.SE EAN/X.400: lel@ida.liu.sunet UUCP: {mcvax,munnari,seismo}!enea!liuida!lel EARN/BITNET: LEL@SELIUI51 -- Dept of Computer and Information Science, University of Linkoping, Sweden Internet: Lennart.Lovstrand@IDA.LiU.SE EAN/X.400: lel@ida.liu.sunet UUCP: {mcvax,munnari,seismo}!enea!liuida!lel EARN/BITNET: LEL@SELIUI51