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

Ned Freed <ned.freed@mrochek.com> Mon, 05 March 2012 15:33 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 D009621F87A1 for <apps-discuss@ietfa.amsl.com>; Mon, 5 Mar 2012 07:33:32 -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 pMZoAgUOHfG7 for <apps-discuss@ietfa.amsl.com>; Mon, 5 Mar 2012 07:33:32 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EED3B21F8794 for <apps-discuss@ietf.org>; Mon, 5 Mar 2012 07:33:31 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCQYO400Q8007HAO@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 5 Mar 2012 07:33:27 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Mon, 5 Mar 2012 07:33:23 -0800 (PST)
Message-id: <01OCQYO1P7T400ZUIL@mauve.mrochek.com>
Date: Mon, 05 Mar 2012 07:25:31 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 05 Mar 2012 11:44:36 +0100" <4F549914.2020907@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>
To: Alessandro Vesely <vesely@tana.it>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1330961613; bh=mZCS8Dex8g5iBO8rJhKH9tt5aDLEyi+GNE+MQNSSrp0=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=OHU0X52W8ZXJJzu7Pa6clEMB6KAU/P24Re9rM9TNTI5OM2nQip3Yxn1g+bHgah+Up vqJ46c1gpnkN2ibD0rzus+9/EanPCdWdCDLA8wfnTjCLKS9kyN4tjynAXXde5auV4C QtLnwi2DOhF/yFqH4S2aPm0oniysMmfkE6AI5tKM=
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: Mon, 05 Mar 2012 15:33:32 -0000

> On 01/Mar/12 05:51, Scott Kitterman wrote:
> > On Wednesday, February 29, 2012 07:56:41 PM Murray S. Kucherawy wrote:
> >> Hi all,
> > ...
> >> When it reappears, I'd love to see some additional review comments,
> >> especially the submission of new cases that should be included in the first
> >> version.  I imagine there are many.
> >
> > One thought that immediately came to mind is that it might be useful to
> > mention case changes in header fields in paragraph 7.  "Helpful" MTAs doing
> > this have been responsible for more than a few hard to troubleshoot DKIM
> > failures.

> 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. You can sometimes avoid or at least defer this
by avoiding unnecessary rewriting; unfortunatley people always seem to come up
with more reasons for doing it.

> 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