On Fri, Jun 09, 2006 at 03:12:24PM +0200, Thomas Roessler wrote:
> > Well, it's not a real bug, just confusing that mutt can't
> > handle it though it already knows what ANSI_X3.4-1968 is and
> > has code to find that out...
>
> What mutt can't handle are malformed RFC 2047 encodings. Some
> character set identifiers that mutt knows about for locale
> purposes can't show up in RFC 2047 encoded strings legitimately.
>
> That's all.
That's crap.
FACT: RFC 2047 forbids encoded-words in MIME-extended headers from
containing a '.' character. No one is arguing that point. However:
FACT: This condition exists for the expressly stated purpose to
MAINTAIN COMPATIBILITY with EXISTING BROKEN MAILERS. [See RFC 2047,
section 1, paragraphs 2 and 3.]
FACT: There is no law against writing software which does not conform
to the published RFCs. The unfortunate fact is that many users do use
such software, often without any practical choice in the matter (e.g.
it is a requirement of their job, etc.).
FACT: The official name of US-ASCII, according to IANA, is
ANSI_X3.4-1968 (see http://www.iana.org/assignments/character-sets)
FACT: The RFC does not forbid mail clients from sensibly interpreting
non-compliant headers. It only forbids the sending of such headers.
FACT: Mutt is a mail client, not a standards verification tool. It is
used by people who want to read and send mail; it is not a tool to aid
those who want to point out deficiencies in other mailers.
FACT: Users of Mutt generally expect that it will interoperate with
other mailers, regardless of whether or not those other mailers
conform 100% to RFCs. Generally, users don't care about RFCs; they
only care about whether or not they can read and reply to mail they
receive from other people without much difficulty.
FACT: There is a well-known "robustness principle" which is widely
accepted as defining, in part, good programming practice. That
principle is stated in many places, not the least of which is in one
of your Beloved RFCs:
2.10. Robustness Principle
TCP implementations will follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from
others. [RFC 793]
Is it reasonable for Mutt to accept official IANA names (let alone
their non-conforming aliases) in encoded headers, despite containing
the forbidden fruit? Of course it is, absolutely. For Mutt not to do
so violates the robustness principle, i.e. it makes Mutt less robust.
While perhaps not technically a bug, it is certainly, without
question, a deficiency in Mutt. Furthermore, to fail to sensibly
interpret such malformed headers goes against the spirit and stated
intentions of RFC 2047, on which you are falling back to justify your
decision. A decision not to work around these (admittedly) flawed
headers is clearly a decision to make Mutt suck more, and as such it
is unjustifiable.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgpY4nX2TlfTm.pgp
Description: PGP signature