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

Alessandro Vesely <vesely@tana.it> Mon, 05 March 2012 18:23 UTC

Return-Path: <vesely@tana.it>
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 8146121F88D7 for <apps-discuss@ietfa.amsl.com>; Mon, 5 Mar 2012 10:23:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.65
X-Spam-Level:
X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
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 VCODw6PHx5JM for <apps-discuss@ietfa.amsl.com>; Mon, 5 Mar 2012 10:23:35 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 57D1A21F88D2 for <apps-discuss@ietf.org>; Mon, 5 Mar 2012 10:23:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330971812; bh=tqOHISwm2haLeO6HnYkDNPkjKXQi3mWBzanZxZWDQgM=; l=1921; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=dGgQSMmOH+XxNkxP01TXLeopQ2Yy/vpxWgZ/DQRlO0M+Xa44iHj0CE99m9Yp7gvoG B7POtzOUYlJp3+CCWnLppMLF5sVTwK3DfR2Ohtm/mKJ27qnDAb1FpNgKFa+44Pyme9 nbHAHKFtnKPm2tObgX/PZrte8A6aMfsvrJ/4sJRo=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 05 Mar 2012 19:23:32 +0100 id 00000000005DC039.000000004F5504A4.000039A2
Message-ID: <4F5504A4.6010902@tana.it>
Date: Mon, 05 Mar 2012 19:23:32 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> <4F549914.2020907@tana.it> <01OCQYO1P7T400ZUIL@mauve.mrochek.com>
In-Reply-To: <01OCQYO1P7T400ZUIL@mauve.mrochek.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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: Mon, 05 Mar 2012 18:23:37 -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 recall unsuccessfully looking for such a statement.  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.

> You can sometimes avoid or at least defer this by avoiding
> unnecessary rewriting; unfortunately people always seem to come up 
> with more reasons for doing it.

Yes, when they came out they looked as smart enhancements :-/

>> It may be
>> helpful to encourage tool developers to stick to the original choice
>> of token / quoted-string in MIME parameters (format="flowed" vs.
>> format=flowed see http://tools.ietf.org/html/rfc2045#section-5.1 )
>> as well as keeping the original boundaries, if at all possible.
> 
> IMO both of these are really bad suggestions. The first assumes that all agents
> tolerate superfluous syntax and some actually require it; my experience has
> been exactly the reverse.
> 
> The second effectively either mandates forced encoding to base64 of all parts
> or multi-pass processing to implement. The former often causes more problems
> than it solves, the latter is a both a PITA to implement as well as being more
> error-prone.
> 
> 				Ned