base64 encoding in rfc2045...

(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.

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822