From: Marc Horowitz <marc@mit.edu>
Subject: base64 behavior is not MIME compliant
Date: Sat, 02 Jul 2005 19:19:32 -0400 [thread overview]
Message-ID: <t53zmt4dce3.fsf@central-air-conditioning.toybox.cambridge.ma.us> (raw)
(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 other threads:[~2005-07-02 23:19 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=t53zmt4dce3.fsf@central-air-conditioning.toybox.cambridge.ma.us \
--to=marc@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).