loverso@sunybcs.UUCP (John Robert LoVerso) (10/14/84)
I was wondering how we're supposed to parse this type of address. Our sendmail considers it @host2:host1!user, which is what I figure it would be. But, the news software considers it to be along the lines of @host1.UUCP:user@host2. I could see how this second form would be valid, by expanding the !, but I remember in rfc819 where it says internet addressing is handled right to left. Can anybody help? John [right now, I tell users to stay away from such mixed addressing] -- John Robert LoVerso @ SUNY Buffalo (716-636-3004) LoVerso%Buffalo@CSNET-RELAY -or- ..!{watmath|rocksanne}!sunybcs!loverso
honey@down.FUN (10/14/84)
can you say ambiguous? i knew you could! seriously, though, if myhost talks to host1 but not host2, you want to execute mail user@host2 on host1; conversely, if my myhost talks to host2 but not host1, you want to run mail host1!user on host2. if myhost talks to both or neither, it is impossible to do anything useful. peter
chuqui@nsc.UUCP (Zonker T. Chuqui) (10/15/84)
> I was wondering how we're supposed to parse this type of address. > Our sendmail considers it @host2:host1!user, which is what I > figure it would be. But, the news software considers it to be > along the lines of @host1.UUCP:user@host2. I could see how this > second form would be valid, by expanding the !, but I remember in > rfc819 where it says internet addressing is handled right to left. > Can anybody help? Unfortunately, I don't think this has been properly addressed. This is THE main reason why we here at nsc have decided to not put optimizing into our mailers at this time. Because there is no way of forcing ambiguities out of the addresses I can't optimize and not be sure I'm screwing up. Perhaps the standard needs to be extended to clear up precedence problems or set up some sort of precedence forcing like we do with programming languages with parens. How about (host1!user)@host2? Actually, optimization creates all sorts of interesting problems that I don't see solved very well in most of the implementations I've seen. I feel it is very important that the user be able to see (and override if neccessary) optimizations. If you hide this in sendmail or somewhere else the user can't do it. There have been a lot of interesting discussions here at nsc (and elsewhere) about where to optimize paths on news replies. The way I've got it implemented is in readnews and vnews (and Real Soon Now in Berkeley Mail as well) because the user can SEE the addresses and override them if they know a better path or if there is a problem with the given one. If it is done in sendmail (or in recmail for news as was suggested) all they see is the original path and they won't know where the thing is really going until it either gets there or bounces back, and if it disappears (they still do, too...) you'll never know why, or even where. Not a good situation in my eyes. Secondarily to this is the problem of sites downstream optimizing or REoptimizing for me. Every so often I have to send out messages that loop around and come back to me. Sometimes it's seeing if a path exists, sometimes it's to see how long it takes. In many circumstances I can't do that anymore-- sites like ihnp4 that do rightmost optimizing see a path like 'ihnp4!tektronix!hplabs!nsc!chuqui' and say ~aha! I talk to nsc, I can send it there directly!~ and I get it right back. There is no way to override it. I have this sincere distaste for software that knows more than the humans it is supposed to serve, even when it is wrong. I ALWAYS want a way to override. Imagine this nuclear power plant. Imagine a meltdown. Imagine a computer saying ~I KNOW you don't really want to shut off the plant-- I'll ignore what you are saying and you'll thank me later~. You have an added problem here where domain boundaries cross and two sites know of the name of a host, but those aren't the same hosts. Vortex on the net and vortex on the Dec net comes to mind; there is also an 'odin' on the net and an 'odin' somewhere off of cbosgd that aren't the same, and as local nets become more prominent it will get worse. Optimizing mailers do have their place-- I just don't think they should mindlessly optimize. I've been thinking about this a lot, and what seems most logical to me is this: (1) If the address you are given is domain oriented (something like dmr@research.UUCP) then find the most optimal path. It doesn't matter whether or not the message was created on the local site or not. It should be possible to mail something like 'ihnp4!dmr@research.ATT.UUCP' and get there the fastest way possible. (2) If the address is not domain oriented leave it alone. If I want ihnp4 to mail me a message I'll mail to 'ihnp4!chuqui@nsc.UUCP'. If I want to mail myself a message through tektronix and hplabs, I'll use the full path. Sendmail shouldn't make assumptions about what I want to do. Since we will (hopefully) get most users to use the 'foo@bar' addressing mode the mailers will get to do their job anyway. We can even set it up so that a mailer will pass a message along so that the next mailer will optimize again if it has better information if we want-- but we shouldn't force ourselves to do that. Unfortunately, (2) doesn't work extremely well in mixed domain addressing because of the ambiguity problem. Mailing will always be a problem until that is solved. I once tried to send a message to a site through decwrl to seismo and then somewhere else (uucp -> arpa -> uucp). I finally gave up in disgust because trying to outguess mailers in the domain transitions gave me a headache. If I had a proper precedence setup I could have done it easily. This all sounds reasonable to me, and a significant improvement over the current state of affairs. That means I'm missing something because lots of much smarter people have put a lot more time into this than me. What's wrong with the above, folks (or why haven't we thought of it before???) chuq -- From the Department of Bistromatics: Chuq Von Rospach {cbosgd,decwrl,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA How about 'reason for living?'
lee@rochester.UUCP (Lee Moore) (10/15/84)
Interpreting host!user@host2 as @host2:host!user or @host1.uucp:user@host2 is equally valid since there isn't a standard for mixed addressing. Sites that run an internet mailer give higher precedence to the "@" while UUCP only sites tend to give a nod to "!". Many sites also offer "%" as a low precedence version of "@". Nobody is offering parentheses "()" as grouping characters, unfortuately. rfc819 says that domains are interpreted right to left but doesn't recognize "!" as meaning anything. The moral is: when in doubt, use source routing. -- Internet: lee@rochester.arpa UUCP: {decvax, allegra, seismo}!rochester!lee Phone: [USA] (716) 275-7747, -5671 Physical: 43 01' 40'' N, 77 37' 49'' W