ietf-mxcomp
[Top] [All Lists]

RE: Why we should choose the RFC2821 MAIL FROM/HELO

2004-03-26 11:49:26


Where I'm coming from, is working for a company that has historically 
sent bounce messages in response to viruses (these are now disabled 
pending a viable fix), I want to not have to argue the argument: "But 
we must send a bounce or we're violating RFCs". I think for 
the systems 
like ours that quarantine it's a valid argument to suggest that you 
don't actually have to send that bounce.

I agree here, it is really important to bring specifications into line
with actual practice, in some cases regardless of the fact that some
ideology is being violated.

Otherwise you have the situation where the RFCs are not what get used 
as the basis for implementations. I find it somewhat worrying when I find
someone implementing a protocol out of an O'Rielly nutshell guide.


Of course I think it's a valid argument anyway. Often it's better to 
violate an RFC than pollute the internet.

There is certainly no justification for sending a bounce message when
you have good reason to believe that the origin of the message is
false. 

We have a situation here where a protocol is demonstrably broken. But we 
do not have a good way to fix it. A BCP is not the way to fix it since
BCPs should not override standards.

What we really need is the defect report process that is used in the
ISO process. This should lead to an errata being issued that would then be
attached to the original spec.


We have to do things gradually here. First prove that the IETF can still
produce a standard's proposal in an acceptable timescale. Then we can 
start on some of the other issues, like why we got to this point in the
first place.

If there had been a defect reporting process there would have been no way
that spam could have been allowed to become such a problem.

But that is all a procedural issue that should be taken elsewhere, probably
after we prove that it is not necessary to take five years to write a spec.