msc (07/13/82)
I have just tried, for the nth time, to reply to news from one of the various weird mailers on the net. (In this case Berknet). As soon as I typed the 'r' command and saw the To line I realised that I was wasting my time. The situation is impossible. The only way to reply to one of these articles is to shell escape to mail with the address suitably munged. If mail (we use ucbmail) could at least allow you to edit the 'To' line, it would not be necessary type the sometimes very long paths without error. Another major problem is that in most cases I don't know how to mung the address for correct delivery. COULD SOMEONE POST A LIST TO THE NET OF HOW TO MUNG ADDRESSES FROM ALL THESE STRANGE MAIL SYSTEMS. A much easier solution (for everyone not involved in maintaining mailers) would seem to be to change these strange mailers and foreign network interfaces to send on the from line an address which when reversed, will get back to them.
smb (07/13/82)
I sympathize with the problem -- like msc, I often get frustrated by the reply addresses I see. The two main problems are non-uucp networks -- ARPA, the BerkNet, etc. -- and "shy nodes", which won't pass on mail to outside machines, but might be in a netnews path. The former tends to be much more serious, especially because of the ARPAnet -- uucp's left-host convention, and ARPA's right-host convention conflict, and can result in ambiguous parses -- given the string 'a!b@c', does one send a letter to host 'c', thence to be passed on to host 'a', or does one send to host 'a', which in turn will pass it to host 'c'. There's no way of telling which machine user 'b' is on. In our specific case, the ARPAnet link between SRI and CCA is especially troublesome; a news item can go from hplabs to sri-unix via uucp, via ARPA to cca, and then via uucp to decvax. And just to keep life interesting, cca won't act as a gateway; mail from uucp sites will not be passed through to the ARPAnet. (The other cases I know of where news has a lot of trouble generating a reply address are replies that go through alice, rabbit, or research -- they're shy -- or letters that go to teklabs -- their news path goes through ARPAVAX, which is not a good mail route.) What can be done about this? In the short term, not very much. If you know a path to the proper host, and you're using ucbmail, you can edit the 'To' line with ~h. ucf-cs!tim's or my path-calculators can help, even if they're only used manually. (Incidentally, for folks who want to use mine but can't/won't modify delivermail -- you can use the data it produces in a front-end processor much like Tim's; it should take about 10 minutes to write one (advt)). 2.7 netnews makes it easier to use non-standard mailers, since one can set the environment variable MAILER to the name of your favorite mail program. And if your mailer lets you specify the subject field on the command line, you can get that inserted automatically as well, via something like setenv MAILER "/usr/ucb/mail -s '%s'" for csh users (note the single quotes as part of the string, incidentally). The long-term answer is to do away with this explicit-routing nonsense entirely, and enter the brave new world of the Internet. In it, all addresses will be of the form 'user@host' or 'user@host.network'. Clearly, such a scheme requires a pretty good name table, but at least it gives you an unambiguous name to work with. By coincidence, just yesterday I suggested to the netnews implementors that the next version of netnews start generating a 'Reply-To: user@host' line in every news item; that way, by the time folks have mailers capable of dealing with such addresses, a substantial proportion of the news commands out there in network land might be generating them. (The routing data will still be retained; it's used as an optimization to prevent sending a news item on to a site that's already seen it. But it will become strictly left-to-right, with the '!' assuming the role of a separator character, not a network indicator.) I've not yet given much thought to the gateway question -- when should a '.uucp' or '.usenet' or '.arpa' be tacked on -- but even without that, we'll be better off than we are now.