Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-03

"John R Levine" <> Sun, 19 May 2013 03:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BEFC21F8C38 for <>; Sat, 18 May 2013 20:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ihmEL9IqO2cF for <>; Sat, 18 May 2013 20:00:27 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by (Postfix) with ESMTP id 1A78321F86CE for <>; Sat, 18 May 2013 20:00:26 -0700 (PDT)
Received: (qmail 40618 invoked from network); 19 May 2013 03:00:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=9ea9.51984048.k1305; bh=mNbZDTUIhoJSbo+FwJDz2z1IumNAh8XrHKCX+fFG0fY=; b=AdmrrmKz+V32EuTMn8O87bkXoj8+1cQdZZjbEpK3U79C/absXxYVfb8MZI3bdFaiolxL5T+072o89iYYMU+jKvQn3Y4qQ6E4glXdYpKhUqmBvCniGix5591BQtuK1PN4VpIugyRiau4oPGjjjauffAxTZeYo9lDB6HmGOgqZErc=
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=9ea9.51984048.k1305; bh=mNbZDTUIhoJSbo+FwJDz2z1IumNAh8XrHKCX+fFG0fY=; b=KvM+NLlifA/7hGCYa/dIUFGQoeCr+3g7BJOUhsA87/kZFrShB7YQd+I07hiTNwUv8LB/JZUe/U6oIJmGH1GoN3eQsi+5DgEu+NKTeA2PnI76Wv8YwFr0Ec6lmiU4J9X2ZJ6d33zdfaDJM/F0Uk9uWv5spblXg6V28sir/AFaPmM=
Received: (ofmipd; 19 May 2013 03:00:02 -0000
Date: 18 May 2013 23:00:24 -0400
Message-ID: <alpine.BSF.2.00.1305182237110.74365@joyce.lan>
From: "John R Levine" <>
To: "Ned Freed" <>
In-Reply-To: <>
References: <> <20130515202613.24981.qmail@joyce.lan> <> <alpine.BSF.2.00.1305152133120.63512@joyce.lan> <> <>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-908368308-1368932424=:74365"
Cc: IETF Apps Discuss <>
Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 May 2013 03:00:28 -0000

>> With it refreshed and with all the new content, I'd love to have some more
>> reviews of it in its current form.

Well, since you asked.

I'm looking at the whole thing and I have to say I don't understand the 
point of sections 4 and 5.  I understand that Exchange and Outlook smash 
messages into an internal format and sort of reconstruct the original, 
sometimes, but I can't tell whether that's what you're referring to or 
something else.

I think sec 4 is trying to say mail software may have a variety of 
internal representations, but all we're talking about here are messages 
interchanged in what purports to be 5322 (or its predecessors) format.

Sec 5 appears to say that if you try to parse and unparse a message, you 
probably won't get back quite the same thing and particularly in the 
presence of DKIM signatures and the like, details matter, so don't do 
that. If you need multiple formats, retain the original so if you need to 
bounce or report something, you can report what you actually received.

If that's not what you mean, I'm totally confused.

This is more a question for Ned: in section 7, how much legitimate mail do 
you still see with bare CR or LF?  It is my impression that the bugs that 
caused those things were fixed a long time ago.

I think 8.6 has TMI, I'd just say to synthesize a unique Message-ID. 
MSAs have been doing that for decades, people know how to do it, and your 
example seems more complicated than enlightening.  (Why use gmtime rather 
than just stick the numeric value of "now" into the ID.  Doesn't matter 
what the encoding is so long as it changes frequently.)

10.1, bottom of p. 17: MUST take?  Even after downcasing the rogue 
2119ism, I'd make it a lot milder than that.  If I am feeding stuff into 
my webmail system, and I happen to know that my display module handles 
long lines OK, I'd just leave the long lines alone.  It is my impression 
that long lines are much more likely to be from sloppy composition 
software than malicious.