(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...".
I see no conflict. The decoder doesn't let the garbage affect its output but
reporting the presence of garbage is recommended.
Was the
intent here "Just keep going, and optionally tell the recipient that
everything
from this point on is pure zorkum-blattum"?
More or less.
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.
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
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822