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.
Agreed; the simple solution is that an autoresponder shouldn't try
to put the contents of the original message's Subject into the body
of the response. Using the original Subject in the Subject of the
response works without any problems (as it'll still be RFC2047-
encoded).
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.
I wasn't suggesting that autoresponders send the entire message back
to the originator - I was only commenting that Keith should include
a reminder that RFC2047-encoded subjects exist (especially outside
languages using the US-ASCII charset), and autoresponders need to
handle RFC2047-encoded subjects properly (by the methods I described
above).
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.
Yeah, well, I haven't yet encountered a discussion in the IETF which
causes the end of the world!
But showing users RFC2047-encoded junk is akin to showing users
Quoted-Printable, and I think we're all well aware of how much users
enjoy seeing "=" at the end of lines and other QP cruft. Implementors
need a reminder of RFC2047, is all I'm saying.
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.
Using multipart/report for 'vacation'-like autoresponders is
arguably a Best _Future_ Practice, but isn't a Best _Current_
Practice.
I'd like to get things to conform to best current practice -- which
they don't today -- and then move on to more optimal solutions.
-d