Technical Summary
The document provides a collection of the best advice available
regarding a variety of common malformed mail situations, to be used as
implementation guidance. The intended status is Informational as the
document provides guidance instead of setting best current practices.
Review and Consensus
The document was originally intended as best current practices for
handling malformed messages. There was a discussion about doing a
registry of malformations and their corresponding handling advice,
rather than updating an RFC whenever the list changes, but some thought
that violations of a protocol specification do not qualify as protocol
parameters. It was suggested to use a wiki. In the end, the working
group decided on using an Informational document that provides advice
about the safe handling of malformed messages as it did not make sense
to have a uniform policy (BCP) for dealing with malformed messages, but
there was a view that it was in the best interest of everyone to
document less-harmful avenues to take.
During the working group discussions it was mentioned that the
robustness principle has had some controversy over the years because
deployed servers that accepted non-compliant messages were responsible
for widespread deployment of broken clients. This resulted in
"standards creep" where new servers were forced to accept common but
erroneous messages and protocol usage, and that made it harder to
develop extensions.
There was a comment that the market exerts strong pressures on receivers
to accept malformed messages if the receivers can possibly make sense of
them, and it was pointed out that enforcement of RFC 5322 and its
predecessors tend to cause loss of legitimate messages instead of just
discarding unwanted messages. This led to discussions about the related
mail-related standards, MIME, and about examples of malformed messages.
The only noteworthy controversy was about the original intended status
of the document. There were reviews from Dave Crocker, John Levine, and
Alexey Melnikov. Timo Sirainen reviewed the document from an IMAP
developer's point of view. The document has the consensus of the
working group.
Personnel
The document shepherd is S. Moonesamy. The Responsible Area Director is
Barry Leiba.