bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

base64 behavior is not MIME compliant


From: Marc Horowitz
Subject: base64 behavior is not MIME compliant
Date: Sat, 02 Jul 2005 19:19:32 -0400
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

(emacs-version)
"GNU Emacs 21.4.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2005-03-17 on trouble, modified by Debian"

(gnus-version)
"No Gnus v0.4"

RFC 3548 has this to say about characters not part of the encoding
alphabet:

    Implementations MUST reject the encoding if it contains characters
    outside the base alphabet when interpreting base encoded data, unless
    the specification referring to this document explicitly states
    otherwise.  Such specifications may, as MIME does, instead state that
    characters outside the base encoding alphabet should simply be ignored
    when interpreting data ("be liberal in what you accept").

The second sentence is a reference to RFC 2045:

   Any characters outside of the base64 alphabet are to be ignored in
   base64-encoded data.

The base64-decode-region function is somewhere in the middle, and
therefore compliant with neither spec: in addition to the alphabet
characters, it seems to accept whitespace, but nothing else.

Gnus's mm-decode-content-transfer-encoding method, in mm-bodies.el,
both in No Gnus and in the verison shipped with emacs 21.4, uses
base64-decode-region, which means it does not conform to the MIME
standard.

I believe the best fix is for base64-decode-region to take an optional
argument which specifies how liberal it should be about it's input,
defaulting to the current behavior, and for Gnus to use this argument.
It should, at the least, provide modes for strict parsing (no extra
chars or whitespace), the current behavior (accept whitespace), and
the MIME-compliant behavior (ignore all extra chars).  Of course, Gnus
can fix this independently by using an external base64 implementation
which is MIME-compliant.

                Marc




reply via email to

[Prev in Thread] Current Thread [Next in Thread]