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

"Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <valdis.kletnieks@vt.edu> Sun, 17 March 2019 19:24 UTC

Return-Path: <valdis@vt.edu>
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 640EA1311A5 for <ietf-822@ietfa.amsl.com>; Sun, 17 Mar 2019 12:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 E8NT4QqCnXRK for <ietf-822@ietfa.amsl.com>; Sun, 17 Mar 2019 12:24:44 -0700 (PDT)
Received: from omr1.cc.vt.edu (omr1.cc.ipv6.vt.edu [IPv6:2607:b400:92:8300:0:c6:2117:b0e]) (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 C6B011311A4 for <ietf-822@ietf.org>; Sun, 17 Mar 2019 12:24:43 -0700 (PDT)
Received: from mr1.cc.vt.edu (inbound.smtp.ipv6.vt.edu [IPv6:2607:b400:92:9:0:9d:8fcb:4116]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id x2HJOgdn010227 for <ietf-822@ietf.org>; Sun, 17 Mar 2019 15:24:42 -0400
Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by mr1.cc.vt.edu (8.14.7/8.14.7) with ESMTP id x2HJOb0p019882 for <ietf-822@ietf.org>; Sun, 17 Mar 2019 15:24:42 -0400
Received: by mail-qk1-f197.google.com with SMTP id y64so5189273qka.3 for <ietf-822@ietf.org>; Sun, 17 Mar 2019 12:24:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:mime-version:date :message-id; bh=uwWBVgQ831SnkHIJSp8uSkx5uFRtcDB53fSWqt+JeK0=; b=ViIu4orKtTR2vqiPjHKYh+/wxD7L9oiAZqgnb/eh4SwlLuZZpcicpvwE9CvUlJodoX GXsT7uUXbN3wSaRkk/vuD1V3zpngt6wnhR+QKNPW+sEg8PXi2W/LuMRLv4CkkFdgywOm +gHFaR3Jyraaosxc3xbsus2lksUQnRYI+mD9Itsc9boWMF2EBrSyMKWha/ByWoNLCf5/ wHHmpUrD1LkCZ9vsYabzffTqvAqpV9Bk4/7lRcjqfAKZwsial3Ds2BW/FGMQlCV/LCIK EEpAVITVCDc6pQwedz+gte7jiPR9AfNhmZSyVZ4qNkQ/weBUvbMxarYzGw/9IhQDEcP2 jSww==
X-Gm-Message-State: APjAAAUGfruhPOe/mcpwpDvJVgrsExLwW7ZiuCJ7Ln2TG6UKhkeFOqr9 Hyd3FbEp3zj2idEztTdqTnMfgmITdUuVt1DKPqzxrjK4es83SIlB4zSxMd4hqwZ0y7VVNhMTy7S 2NDCSxu1danu0S1J+BNY8ZD7DMqYrFU3Dvgk9ksYq66vSjRwar7xR/narDvn8F32lu+2HyMuqUL NsJQ==
X-Received: by 2002:a37:f507:: with SMTP id l7mr10698747qkk.302.1552850677240; Sun, 17 Mar 2019 12:24:37 -0700 (PDT)
X-Google-Smtp-Source: APXvYqyg73ICm5gwFhfaayQlvemOz/K6OhzyaV+WFu9e+iqYxIKl7AZK6EZDIxbqw+cEBYvaG9+sVw==
X-Received: by 2002:a37:f507:: with SMTP id l7mr10698738qkk.302.1552850676965; Sun, 17 Mar 2019 12:24:36 -0700 (PDT)
Received: from turing-police ([2601:5c0:c001:4341::9ca]) by smtp.gmail.com with ESMTPSA id h10sm8122242qta.3.2019.03.17.12.24.35 for <ietf-822@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 17 Mar 2019 12:24:35 -0700 (PDT)
Sender: Valdis Kletnieks <valdis@vt.edu>
From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <valdis.kletnieks@vt.edu>
X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <Valdis.Kletnieks@vt.edu>
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
To: ietf-822@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 17 Mar 2019 15:24:35 -0400
Message-ID: <15314.1552850675@turing-police>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-822/sVStUHKCdEN-Y5dGMAHSL3pcNYE>
Subject: [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: Sun, 17 Mar 2019 19:24:45 -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...".  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.