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

Ned Freed <ned.freed@mrochek.com> Wed, 14 March 2012 22:52 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 21B2011E8089 for <apps-discuss@ietfa.amsl.com>; Wed, 14 Mar 2012 15:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 z5OGhitU8CtU for <apps-discuss@ietfa.amsl.com>; Wed, 14 Mar 2012 15:52:42 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD8411E8081 for <apps-discuss@ietf.org>; Wed, 14 Mar 2012 15:52:42 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OD40Q1Y3QO00PK4E@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 14 Mar 2012 15:52:35 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Wed, 14 Mar 2012 15:52:28 -0700 (PDT)
Message-id: <01OD40PXSWDK00ZUIL@mauve.mrochek.com>
Date: Wed, 14 Mar 2012 15:36:06 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 14 Mar 2012 19:48:58 +0000" <9452079D1A51524AA5749AD23E00392808B2E2@exch-mbx901.corp.cloudmark.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392808B2E2@exch-mbx901.corp.cloudmark.com>
To: "Murray S. Kucherawy" <msk@cloudmark.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331765559; bh=GJeUhgKy4MySwP+//oChUc1PuJXLCiIqYlCQyFkn6Dc=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=haAIV/J7rsHahkp04D35ZpRBwTDQRrJCeqjJ1W+EavsWarl7A3NTU94t1o9Drc2Ef fPFfXxcq7f0WEosDHjXE5TieQEIMbyIFdloAnB9DKH5kCKwWC/Wywyi5pQDN3clEgL EYju3cowqJ4VV+o7MFOI7f62X8Gml9CK0ulvwwk0=
Cc: "apps-discuss@ietf.org" <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: Wed, 14 Mar 2012 22:52:43 -0000

> > -----Original Message-----
> > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Scott Kitterman
> > Sent: Wednesday, February 29, 2012 8:52 PM
> > To: apps-discuss@ietf.org
> > Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail)
> >
> > 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.

> That's certainly a concern but I'm not sure it's on topic for this draft.  Altering header field name cases is not strictly a malformation, it's a questionable handling choice that doesn't really alter the semantics or interpretation of the message in a meaningful way.  And DKIM does have a way (relaxed header canonicalization mode) to deal with it.

> A separate document that lists annoying MTA habits which don't actually result in non-compliant messages would quite possibly be a lot larger than this one.  :-)

Completely agree. This needs to focus on malformations that actually change
RFC5322/MIME message semantics and which cause problems for end users. There's
plenty of graund to cover here.

If you want a header rewriting one that *does* affect end users, the one that
immediately comes to mind isn't, or rather shouldn't, be a malformation per se,
but some clients treat it as such: Some clients get all pissy unless headers
appear in a certain order. I don't think mentioning specific clients is any
help here (especially since it would involve some industry heavyweights who
really should have known better), but a specific example of headers that have
had ordering dependencies would be Content-Type: and Content-Transfer-Encoding.
Most clients put CT before CTE, but not all MIME downgraders do, resulting in
... interesting behavior.

Now, you can argue that this behavior malforms the MIME headers because MIME
says header ordering must be preserved. OTOH, it doesn't really talk about
the downgrading case, so it isn't clear this applies when downgrading.

Another interesting example of header ordering issues shows up when Received:
fields are stripped from messages. (This is unfortunately pretty common to have
happen, especially at final delivery.) The obvious problem with this is good
luck on tracing the message or figuring out where it was delayed, but a less
obvious one shows up when some clients attempt to process Resent-* fields. It
seems some of them depend on there being Received: fields in between the
sets of Resent-* fields. Blow away the Received: fields and ... oops.

				Ned