Re: [ietf-822] utf8 messages

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Mon, 18 August 2014 03:03 UTC

Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D251A020A for <ietf-822@ietfa.amsl.com>; Sun, 17 Aug 2014 20:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 Ix334IRYSv_2 for <ietf-822@ietfa.amsl.com>; Sun, 17 Aug 2014 20:03:54 -0700 (PDT)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05871A0202 for <ietf-822@ietf.org>; Sun, 17 Aug 2014 20:03:54 -0700 (PDT)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 64B8FFA0101; Mon, 18 Aug 2014 03:03:51 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpa id 1408331030-3336-3335/12/73; Mon, 18 Aug 2014 03:03:50 +0000
Received: by julenisse-gespenst (Postfix, from userid 1026) id 554B32836C8; Mon, 18 Aug 2014 05:03:50 +0200 (CEST)
Date: Mon, 18 Aug 2014 05:03:50 +0200
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Ned Freed <ned.freed@mrochek.com>
Message-Id: <20140818030344.GA11556@gulbrandsen.priv.no>
References: <01PB9FABWA4E0000SM@mauve.mrochek.com> <CABa8R6tns-idiZTj=+vb9fVNyH-nNYT+w9oNMb80XbCs5osvFw@mail.gmail.com> <01PBABOOL4QO0000SM@mauve.mrochek.com> <CABa8R6vBqS1ewmTtHh8tTOdzobsWpvSEokRxOqpj1Oq3hA+vsw@mail.gmail.com> <D0111ECB.195FD%dvargha@mimecast.com> <01PBCA98IPI00000SM@mauve.mrochek.com> <D013B9C1.1972E%dvargha@mimecast.com> <01PBEGWAGVDG0000SM@mauve.mrochek.com> <D013DB6D.1977B%dvargha@mimecast.com> <01PBHJY1GBTG0000SM@mauve.mrochek.com>
Mime-Version: 1.0
Content-Type: text/plain
In-Reply-To: <01PBHJY1GBTG0000SM@mauve.mrochek.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/jKEM2v0SK2Qbx5RY4gX48bjl9ag
Cc: ietf-822@ietf.org, Daniel Vargha <dvargha@mimecast.com>
Subject: Re: [ietf-822] utf8 messages
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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 Aug 2014 03:03:56 -0000

> Nonsense. I'm talking about searching for a pair of adjacent tokens in a
> string. The parsing risks are false positives - unlikely given the tokens
> involved - and false negatives - also unlikely given that anything generating
> these tokens is going to be new code written to conform to these
> specifications.
> 
> And as Arnt has pointed out, you also have control over the agent generating
> the line you care about most of the time.

Someone else this time, I think, although I've said the same thing in
the past. (My two cents: Parsing Received is simple and easy, making
sense of the parsed information often is neither.)

There is another aspect of this that I feel hasn't been thoroughly
discussed, namely the likelihood that signalling 6532 compliance in a
different way would be more (or less) reliable than the current way.

What I mean is that it certainly would be possible to say e..g "
"Mime-Version: 1.1 means 6532". But lots of people ignore
Mime-Version, including Gmail. So is there an argument that some other
way to signal 6532 compliance would be more reliable, more likely to
be set and used correctly, than the current way?

Arnt