Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail)

Ned Freed <ned.freed@mrochek.com> Tue, 06 March 2012 08:13 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB90E21E80AD for <apps-discuss@ietfa.amsl.com>; Tue, 6 Mar 2012 00:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ52pooKmKT6 for <apps-discuss@ietfa.amsl.com>; Tue, 6 Mar 2012 00:13:35 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E5DA121E808C for <apps-discuss@ietf.org>; Tue, 6 Mar 2012 00:13:34 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCRXL1F4SG00409B@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 6 Mar 2012 00:13:31 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Tue, 6 Mar 2012 00:13:26 -0800 (PST)
Message-id: <01OCRXKYBLNA00ZUIL@mauve.mrochek.com>
Date: Tue, 06 Mar 2012 00:04:14 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 05 Mar 2012 19:23:32 +0100" <4F5504A4.6010902@tana.it>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> <4F549914.2020907@tana.it> <01OCQYO1P7T400ZUIL@mauve.mrochek.com> <4F5504A4.6010902@tana.it>
To: Alessandro Vesely <vesely@tana.it>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331021618; bh=qRgsBpr6jINkGeVeFipX2xAYwb2K9cNKlPnFcMyX80E=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=RL/zXgdI+jDeplbfbuORF4A3RfnpUBXJ9+yr671CpCR+K43OdSbvpkz0F4KyCBd3j LafQlphMiCD7cw60jyQQikWzTVY4GsZTeJX/X0bfKs7pN75C8kN66tBgYhRiHR76vE iE/oRIepX7/q8pLJoCcavSNyxBwZA/a6+g2NoGxA=
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 08:13:36 -0000

> On 05/Mar/12 16:25, Ned Freed wrote:
> >
> >> More non-malformation cases occur on MIME rewriting.
> >
> > It's more like malformations in the original message get exposed if it's
> > rewritten for whatever reason.

> Hm... MIME doesn't seem to say that either is better than the other.
> Based on what you write below, I'd derive that token is better than
> quoted-string, provided that quotes are actually superfluous.  Hence,
> the I-D could state that that's the canonical syntax, implying that
> DKIM signers (and verifiers) may get smoother if they convert that way
> before playing their magic.

I'm unclear as to the relevance. If you're transforming MIME content in some
way - and if you're not why are you bothering to mess around with the headers -
the content will be altered and any DKIM signature is going to be invalidated
no matter what you do to the quotes.

> I recall unsuccessfully looking for such a statement.

There's isn't one. MIME doesn't discuss canonical forms or what representations
are "better". At the time we were much more concerned with getting a
specification out the door than we were on spending what would have certainly
been lots of time arguing about optimal representations. Nor, frankly, did we
have operational experience on which to base such choices. It took 10 years at
least to accumulate that, by which time it was far too late to even consider
adding that to MIME.

Remember that this was 20 years ago. PEM, the first signature scheme
for email, was still under development.

> Scripts may opt
> for always putting quotes in order to avoid to find out whether they
> are actually needed.  Would an informational I-D have the authority to
> tell them that they shouldn't do so?  As a side note, quotes around
> HTML attributes tend to become always mandatory.

I don't see a problem with saying that, but a document that says that and that
alone doesn't seem worth it to me. I'm also dubious that anything would change
significantly because of making such a recommendation.

				Ned