El 9 May 2001, a las 9:51, Charles Lindsey escribió:
<SNIP>
that is, even
if the canonicalization was done improperly, the MD5 needs to be
computed over the form of the body part that exists *after*
canonicalization and *prior* to any content-transfer-encoding.
Yes, but the content-transfer-encoding provides a second opportunity to
canonicalize LF into CRLF (the encoding engine is likely separate from the
Copntent-MD5 engine) and so may introduce some CRLFs not appropriate for
that application type, and strange things may then arise upon upcoding.
I think the only safe way is to encode all CRLF in application types as
=0D=0A, giving
foo=0Dbar=0Abax=0D=0A=CRLF
Do you mean doing this for EVERY time you use CTE=QP or only for Content-
MD5?
If you apply this to a text/plain part, you are almost certain to defeat
the purpose of QP that is being "rather legible" if your mailer can't
MIME.
I=20would=39t=20like=20to=20be=reading=0D=0A
this=20kind=20of=20stuff=20in=20my=20mailer=2E=2E=2E=20=0D=0A
=0D=0A
And=20you=3F=0D=0A
I know most decent mailers can MIME, but then, are we in a position to
"make the switch" and ignore the rest? I don't think so...
Maybe it's time for
Mime-Version: 1.1
Aaaaaaaarrrrrrrrrrgggggggghhhhhh!!!!!!!!!
:-)
thus not relying on the CRLF at the end of the CTE lines for any meaning.
But encoding engines do not currently work this way :-( . So it seems to
me that a Content-MD5 engine (assuming it has no opportunity to alter the
document, or to influence the encoding) is forced to try and 2nd guess
what the encoding is going to do (or has already done).
--
Mariano Absatz - El Baby
mailto:baby(_at_)baby(_dot_)com(_dot_)ar
http://www.baby.com.ar/
PGP KEYS: http://www.baby.com.ar/datos/personales.html#claves_pgp
|\ _
_\\/'> Powered by Pegasus Mail
/|__) http://www.pmail.com
) )\
-----------------------------------------------------------
Okay, who put a "stop payment" on my reality check?