At 09:07 AM 2003-06-05 -0700, James Lick wrote:
>On Thu, 5 Jun 2003, Al Iverson wrote:
> > Subject: automatische =?iso-8859-1?Q?R=FCckantwort_?=
>
>RFCs 2047 and 2231.
Just as a point: This is a really poorly thought out RFC. You might want
to decode those in your MTA or mailing list manager before forwarding them
to your subscribers. You *can't* safely do so. I have considered doing
this in demime. Several times. The best scheme I can some up with is to
convert everthing that is not a letter or number or known punctuation mark
to a space.
For example: It is completely legitimate for someone to encode a sequence
of multiple line end characters in the header, and to have that sequence
shielded by the encoding. They could do this to force compliant MUAs to
"set the subject off" for emphasis, by encoding
Subject: line-end line-end Actual Subject Line-end Line-end
This might mean that the subject of the mail would be displayed with blank
lines before and after.
This, of course, if decoded in transit, would cause the subject to become
blank since the first blank line would now delimit the header, and then to
move the "actual subject" into the body. They could do nefarious things as
well -- since the decoding could also create new headers, possibly after
you have elided some headers. This is a real bag of worms.
The subject might or might not display there where it was moved into the
body...or it might cause the content headers to become part of the body so
that the mime decoding of the entire letter is hosed, depending on whether
the subject line is before or after the critical headers.
As a worst case: Supposing you only allow subscribers to post. If you do
the check before this decoding, someone could code their subject ahead of
the From: header, and then chop the From: header off, pushing it into the
usually not displayed no-mans-land following the header, and causing a new
From header that was not the one you checked to appear in the headers...
Or they could even convert a text/plain to a text/html.
The standard itself says that it is impossible for anything other than the
end user's MUA to safely decode these headers, and then it can only decode
them for the purpose of display, the original form should be retained and
used for header parsing.
Like I said, this is a real mess. No one thought about retaining a plain
text section, since it seems that the attitude of many of the people who
write the mime standards is that people should be forced to upgrade to the
latest and greatest bit of mail display software, or get left in the
dust. Or that maybe these augmented headers should be hidden somewhere.
--
"Forgive him, for he believes that the customs of his tribe are the laws of
nature!"
-- George Bernard Shaw (1856-1950)
Nick Simicich - njs@scifi.squawk.com
Follow-Ups:
References:
|
|
