🚀 go-pugleaf

Mail-From: MCGREGOR created at 29-Aug-84 12:28:10
Date: Wed 29 Aug 84 12:28:09-PDT
From: Scott L. McGregor <MCGREGOR@HP-HULK>
Subject: Re:  illegality
To: ron%brl-tgr.arpa@csnet-relay
cc: MCGREGOR@HP-HULK
In-Reply-To: Message from "Ron Natalie <ron%brl-tgr.arpa@csnet-relay.csnet>" 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
-------
-------