Subject: [ietf-822] base64 encoding in rfc2045...

From: "Valdis Klētnieks" <[email-masked]>
Date: Sun, 17 Mar 2019 15:24:35 -0400

(Man.. I was around for rfc1341. You'd think that by now, there'd be
few things that would give me a "Wait, what?" moment...)

So over on another list, a discussion arose of what an MUA should do
if it receives a base64-encoded mail that's been altered. (In this case,
it's mailing list software that's blindly stuck a "you received this because"
footer onto a mail that was UTF-8/base64)

And when I went to go cite chapter and verse, I discovered some text that
seemed to contradict itself - OK for a religious text. An RFC? Not so much.

   The encoded output stream must be represented in lines of no more
   than 76 characters each.  All line breaks or other characters not
   found in Table 1 must be ignored by decoding software.  In base64
   data, characters other than those in Table 1, line breaks, and other
   white space probably indicate a transmission error, about which a
   warning message or even a message rejection might be appropriate
   under some circumstances.

I'm having a hard time matching even a lower-case 'must be ignored'
up against "a warning message.. might be appropriate...".  Was the
intent here "Just keep going, and optionally tell the recipient that everything
from this point on is pure zorkum-blattum"?

Personally, I'm of the opinion that in reality, encountering a '=' is
sufficient grounds for stopping right there, and also punting if a null line is
encountered, because the chances it's a unintended appended text is much higher
than a properly functioning base64 encoder generating an actual correct null
line.

---

From: Ned Freed <[email-masked]>
Date: Mon, 18 Mar 2019 08:15:25 -0700 (PDT)

> up against "a warning message.. might be appropriate...". 

I see no conflict. The decoder doesn't let the garbage affect its output but
reporting the presence of garbage is recommended.

> Was the

More or less.

> than a properly functioning base64 encoder generating an actual correct null

The text doesn't address the issue of what to do when an end marker  is
encountered (the marker isn't always present) but there's material after it. 
(Note that the material could consist of only valid base64 characters.)
Absent a recommendation, you are free to handle this case however you
want.

				Ned