Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!tp From: tp@mccall.com Newsgroups: comp.mail.uucp Subject: Re: Imminent death of UUCP Zone predicted Message-ID: <3209.26adae8e@mccall.com> Date: 25 Jul 90 14:37:00 GMT References: <1990Jul16.202721.271@chinet.chi.il.us> <3143.26a2edd9@mccall.com> <1990Jul23.185016.7921@chinet.chi.il.us> Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 104 In article <1990Jul23.185016.7921@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <3143.26a2edd9@mccall.com> tp@mccall.com writes: >>registered. Implicit in the requirement is my help (as someone who has done >>it) to get registered. > > If you are the primary mail feed to someone else, why not just give them > a subdomain under your own domain? No one else needs to get involved > at all that way. That's always an option, but he may want his own domain. Also, doing so means my company's name is on all mail and postings emanating from his site. That implies some degree of trust that this person won't embarass me/us. It isn't obvious to anyone seeing the address that this person isn't affiliated with the company. >> 2) If an end-node with dumb mail software generates bad addresses >> that people can't reply to, that's also his problem, he won't get >> his mail. > > No, that's not just his own problem. The person sending the reply is > also screwed. I tend to think that not getting a reply to a message is most often a detriment to the original sender (the guy whose address was unreplyable when the mail was received) although that certainly isn't always the case. I tend to think that a reply is generally an answer to a question or request. In that case, it is clearly the person who asked the question and got no answer who is the worst off. In any case it is certainly less of a problem to others than a site that breaks addresses on mail that is passing through. > I don't agree with your terminology of "bad" addresses > either. Uucp addressing is self-consistent and not "bad" unless it > is passed unmodified to a system that doesn't understand it. Uucp addressing in the envelope of a message (the transport layer) is not only self-consistent and "good", it is absolutely required (by all the uucp implementations I've seen). Uucp addressing in From: lines (the topic under discussion, unless one of us is misunderstanding the other) is bad. From: lines are specified by RFC822. Uucp addresses are not rfc822 compliant. Therefore any From: line that contains a uucp address is inherently invalid. The fact that any mail systems at all understand these is because it is such a common error that people have compensated for it. It is still an error. The fact that vendors ship mail systems that ONLY work with invalid headers is a significant source of most of the problems this discussion thread has addressed. > Thus > the problem is that uucp <-> internet gateways see themselves as simple > forwarders instead of doing everything that is needed to correctly > make the two systems understand each other. Internet sites, including gateways, are not required to do anything regarding the format of mail messages except comply with RFC822. The fact that many do more is because they are nice. You certainly can't expect everyone to do more, because there isn't a standard to tell them what they should be doing. Until a standard exists that covers these situations, you can't even get agreement on what the gateway should be doing. The only fault one could find with the people running these gateways is that they've perhaps been overly generous. They've been willing to connect their standard compliant mail systems to mail systems that are not standard compliant. This may have been the initial mistake. If every site insisted that sites connecting to it must be standard-compliant, we wouldn't be discussing these problems, as they would not exist. I suggest as a compromise allowing non-compliant sites to connect, but only as end-nodes. This can cause problems, and as you point out, not only for the non-compliant site. There will be, however, fewer problems than we have now. -------- [end of reply, beginning of general statement of opinion] ------ As far as mail is concerned, the subset of the uucp mail network consisting of hosts with registered internet domains IS a part of the internet. For such hosts, mail is predictable and reliable as long as it (a) never leaves the internet (as defined here), and (b) never crosses a host that does improper (non-compliant) things to the message. The most common cause of (b) is that hosts are trying to compensate for the existance of that subset of the uucp mail network (and others) consisting of hosts that are NOT registered. (It is assumed here that an RFC822 compliant mailer is a prerequisite to having a registered domain name!) Many of these hosts make the totally erroneous assumption that all uucp connected hosts are NOT RFC822 compliant. Anyone that wants good mail service should get registered. Experience shows that complaining to people about how they handle your non-standard addresses is unlikely to do you a tremendous amount of good (there are too many people to complain at, too many different ways of handling it, and probably everyone that's tried to fix it has been told his fix is wrong at least once). For the benefit of the net as a whole, we should try to restrict the sites that cause problems to being end-nodes (to minimize the problems they can cause), or better yet, help them fix the problems. We should also try to get sites to stop rewriting messages when it isn't needed. If you have a smart mailer and your neighboring site rewrites your headers anyway, at least discuss it with them. -- Terry Poot The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA