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.