Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hou3c.UUCP Path: utzoo!watmath!clyde!burl!hou3c!MCGREGOR%hp-labs.csnet@csnet-relay.arpa From: MCGREGOR@hp-labs.csnet (Scott L. McGregor) Newsgroups: net.mail.headers Subject: [Scott L. McGregor : Re: illegality] Message-ID: <8408291932.AA24117@HP-VENUS> Date: Wed, 29-Aug-84 15:32:03 EDT Article-I.D.: hou3c.808 Posted: Wed Aug 29 15:32:03 1984 Date-Received: Thu, 30-Aug-84 02:25:42 EDT Sender: ka@hou3c.UUCP (Kenneth Almquist) Lines: 75 To: header-people@mit-mc.arpa Source-Info: From (or Sender) name not authenticated. Mail-From: MCGREGOR created at 29-Aug-84 12:28:10 Date: Wed 29 Aug 84 12:28:09-PDT From: Scott L. McGregor Subject: Re: illegality To: ron%brl-tgr.arpa@csnet-relay cc: MCGREGOR@HP-HULK In-Reply-To: Message from "Ron Natalie " of Fri 24 Aug 84 14:19:49-PDT I will just make a few observations on "illegality","protocol police", and "shooting mail system administrators who allow illegal headers to leave their mailsystems", and then I will step out of the fray. It is ironic that a document called RFC (request for comment) is regarded as a law that some would have treated as a capital offence and to be policed by protocol police. While I don't regard the violations of the guidelines proposed in RFC822 as quite as serious as some do, I do recognize that there is much a human problem here as a machine or program problem. Here's my analysis: Many people see great benefits in reaching the Internet community by mail. This makes it desirable for them to get up a mail bridge to get into the system as quick as possible, and as is equally human, with the least amount of effort required. There are two strategies in building such a mail connection that are particularly of interest: 1) saving on building a input checking routine (assuming everyone follows the standard) and 2) saving on building an output checking routine (assuming that no one will hand you bad stuff to send out). Some sites seem to have adopted one strategy or the other. Some have even adopted both. Whenever someone who doesn't do output checking sends some garbage to someone who doesn't do input checking, the fur starts to fly in header-people. RFC733 and 822 have something to recommend about this, and there has long been a policy recommended by header-people and others that goes something like this (in various variants): 'It is good courtesy (and smart practice) to make your mail interface to the net as strict as possible about what it transmits (outbound) and as flexible as possible about what it will receive (inbound).' This is of course entirely contrary to the two strategies described above (don't input check and don't output check). For a real problem to exist there have to be two systems at fault, the one who sent the garbage and the one who received it and belched. Both sides have failed to meet the courtesy standard, and so argue about who is more at fault, and who should have to do something about it in the future. I don't find this kind of discussion very helpful. Both systems need to change. Given human organizations, the one who doesn't change is just asking for another problem in the future. Both systems should be made more error tolerant in my opinion. Of course, any changes that need to happen, won't happen overnight. Thats just how organizations and people work. But there are things that can be done to speed up these changes, and I find discussing these much more productive. In particular, there seems to be precious little discussion on how to do better error checking on output and how to do correction on input. What we mainly hear is that we should all just do a better job of it. I must admit that in my mail interface programs I have made many mistakes in the past and that these have been pointed out to me by angry mail administrators. I have tried to address them as quickly as possible, but I'll let you all in on a hint to quicker fixes. I have always responded faster to complaints that suggested how the actual repair could be accomplished (in code or pseudo code) than I have to those that just said that it needed to be fixed and that I should do it now. In the interest of more robust systems everywhere, I would like to see much more code sharing. recklessly yours, Scott McGregor ------- -------