Dan Wing <dwing(_at_)Cisco(_dot_)COM> writes:
Section 2.2 says:
Response messages SHOULD NOT include significant content from the
subject message. In particular responses SHOULD NOT contain
non-text/plain attachments from the subject message.
This requires further discussion in the I-D. For example, if the
subject message contains only text/html, what's the autoresponder
supposed to do (I would advise not including any portion of the
message).
By the way, I have noticed some autoresponders don't decode
RFC2047-encoded subject lines correctly when they include the Subject of
the "subject message" in the body of the response. It might be good to
point out RFC2047-encoded Subjects as a case that needs to be properly
handled by autoresponders.
Requiring that an autoresponder handle RFC 2047 decoding and MIME
disassembly and reassembly of the original message is a pretty hefty
requirement for a poor little autoresponder. That's probably an order of
magnitude complexity above what a lot of autoresponders are now, for what
seems to me to be a fairly minimal gain.
Bounces already routinely include the entire original message for good
reason, since otherwise it might be lost. I'm not sure this is actually
preventing any attack which isn't just as easy to perform another way.
And it really isn't the end of the world if a Subject line shows up in the
body of the text RFC 2047 encoded. Note that trying to include the
decoded form in free-form text may require a MIME multipart to set a
different character set from the rest of the surrounding message, which is
approaching a rather excessive degree of complexity.
If the Subject is included as part of the headers of the message in a
message/rfc822 or equivalent attachment, there's no need to decode the
Subject header, which is a reasonable argument in favor of using
multipart/report.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>