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

Ned Freed <ned.freed@mrochek.com> Mon, 18 March 2019 15:24 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBA112D827 for <ietf-822@ietfa.amsl.com>; Mon, 18 Mar 2019 08:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waq3wRFnAcTA for <ietf-822@ietfa.amsl.com>; Mon, 18 Mar 2019 08:24:48 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D101310FE for <ietf-822@ietf.org>; Mon, 18 Mar 2019 08:24:41 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R4FUXNG0FK001MM0@mauve.mrochek.com> for ietf-822@ietf.org; Mon, 18 Mar 2019 08:19:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1552922378; bh=NmFrk5XCWKwDM8ZguF9bYM1SNUxgFWDK0G8ESgBxKr0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=HOGnhwv10lF1d1QJ9l/H4gRqbDA7xZrQ0QOxr8j2xVVJxpqfWSOPMmrWf4r6oYQNC Mwp0VsT3Ab75Nd1zsmVVyW9r8s+1jw+cZwmDXmOnOMa/A3f5Gh+mxrjAE7gfqZ6zbn S0ALivnaXjTW2lFo+YsoCAYImPyF1X/j0iG+BdAo=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R48YWVU7R4000051@mauve.mrochek.com>; Mon, 18 Mar 2019 08:19:35 -0700 (PDT)
Cc: ietf-822@ietf.org
Message-id: <01R4FUXLYBSE000051@mauve.mrochek.com>
Date: Mon, 18 Mar 2019 08:15:25 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sun, 17 Mar 2019 15:24:35 -0400" <15314.1552850675@turing-police>
References: <15314.1552850675@turing-police>
To: Valdis Kl=?utf-8?Q?=c4=93?=tnieks <valdis.kletnieks@vt.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-822/LFfN1p-FdmPAHX9rwO9B8tm41b8>
Subject: Re: [ietf-822] base64 encoding in rfc2045...
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2019 15:24:50 -0000

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