Blake,
Perhaps the best case for the "From mangling" problem being prevalent is
found if you look at the IETF-S/MIME archive page and look at the first
message I sent:
http://www.imc.org/ietf-smime/mail-archive/msg01800.html
You will see the second complete paragraph begins with ">From". I sent it
as "From". So, whatever mail transfer agent received this message and
posted it to the archive was subject to this problem.
For the most part, any MTA system which uses the classic unix mail spool
will suffer from this problem. Exim and sendmail both have options to turn
on "From escaping", and the common recommendation is typically to enable
this option. (Details at bottom). Generally, the majority of UNIX,
Solaris, BSD, and Linux based mail servers I have encountered suffer from
this problem.
Additionally, this problem occurs in unexpected places due to the prevalence
of HTML-enabled email applications, which send both HTML and plain-text
versions of email messages. Although the word "From" may not appear at the
beginning of a line in the message, due to linebreaks being inserted by the
mailing application when sending, it might end up there anyway. This can
get munged by an MTA, and it is often very difficult to determine that this
is what caused a digital signature to not be verified. (The HTML gets
displayed to the reader and wasn't modified--the plaintext is what got
mangled.)
I think that adding the text from RFC2015 is an easy way to cover this
problem. It states that handling this is "not required" but "generally a
good idea". I invite you and the rest of the ietf-smime group to read about
this and consider it before we finalize son-of-2633. Thanks,
--Peter Hesse
Links to additional information:
---------------------------------
Sendmail configuration:
http://www.sendmail.org/~ca/email/doc8.8/op-sh-5.html#sh-5.4
E Escape lines beginning with From in the message with a `>' sign.
EXIM configuration
http://www.us.exim.org/exim-html-3.30/doc/html/spec_15.html#SEC443
escape_string (appendfile)
Type: string
Default: ">From "
On FAQs.org, the Linux Network Administrators Guide
(http://www.faqs.org/docs/linux_network/x-087-2-mail.message-format.html),
there is the quote:
"If you look into a local mailbox file, you may see each mail message
preceded by a "From" line (note: no colon). This is not an RFC-822 header;
it has been inserted by your mail software as a convenience to programs
reading the mailbox. To avoid potential trouble with lines in the message
body that also begin with "From," it has become standard procedure to escape
any such occurrence by preceding it with a > character."
+---------------------------------------------------------------+
| Peter Hesse pmhesse(_at_)geminisecurity(_dot_)com |
| Phone: (703)934-2031 Gemini Security Solutions, Inc. |
| ICQ: 1942828 www.geminisecurity.com |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been
a statue set up in honor of a critic." --Jean Sibelius
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Blake Ramsdell
Sent: Thursday, April 22, 2004 9:07 PM
To: 'Russ Housley'; ietf-smime(_at_)imc(_dot_)org
Subject: RE: RE: Last Call: 'S/MIME Version 3.1 Message Specification' to
Proposed Standard
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Russ
Housley
Sent: Thursday, April 22, 2004 7:26 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Fwd: RE: Last Call: 'S/MIME Version 3.1 Message
Specification' to Proposed Standard
Does the S/MIME WG have a response to this comment? I suspect so.
Please coordinate a response and send it to iesg(_at_)ietf(_dot_)org before
Last
Call expires.
I may be missing the exact details here, so people can jump in where I'm
misguided.
Basically this is a multipart/signed message where a signature was applied,
and an entity that performed intermediate processing deliberately violated
section 2.1 of RFC1847 which states:
<verbatim>
The entire contents of the multipart/signed container must be treated as
opaque while it is in transit from an originator to a recipient.
Intermediate message transfer agents must not alter the content of a
multipart/signed in any way, including, but not limited to, changing the
content transfer encoding of the body part or any of its encapsulated body
parts.
</verbatim>
So is this "From mangling" problem prevalent enough to warrant special
treatment in the S/MIME spec is the question here, since it's already been
stated that you shouldn't do it. Based on the lack of discussion and
consensus when this issue was first brought up, we need to understand the
community feel better. That is, is this particular mangling more prevalent
than the other issues that aren't currently discussed in the spec (are there
whitespace issues we need to think about, for instance)?
Blake