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

"Murray S. Kucherawy" <> Tue, 28 May 2013 16:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F76821F98A9 for <>; Tue, 28 May 2013 09:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kgfilMwKQZ8T for <>; Tue, 28 May 2013 09:57:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22a]) by (Postfix) with ESMTP id 2E62821F98A6 for <>; Tue, 28 May 2013 09:57:04 -0700 (PDT)
Received: by with SMTP id u59so5129050wes.1 for <>; Tue, 28 May 2013 09:57:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uEUaLSyDGLSnVE/y3AMEgd3HJMVswrUBNmYqQ8IQ/XM=; b=Xip/YttJnLkdm+d9vskY6yZfWY/1SpS03pZ3BEGd+X1Rh7MGzSRbxOMDGNZzWUBSQa dx1hRBaUBKq53SNJzX2PmTgkXJeotkFbjH8DGm38zPmrLn9rMqcJFO4MQJFc8Ol8PvnL wZ2cXYluTEm2DOn33Tept+8l/M5aNg5Pp1egNyR4+zrgQqr5xK+jhfgMfjKVf6mRPYgX Obrgu2obQOpY2JkO3GxbvwJVG/SMQu447IirkXG4YwaTg8mfbjUS/g6z98H4WFvryw25 +xtexK0nc4VYBk+1yZ522DpA19+k/ueaiWq80awLfV5iNRkvDYxFkLQp/plOcpnsWLVm JYSA==
MIME-Version: 1.0
X-Received: by with SMTP id bj7mr13034861wib.5.1369760222812; Tue, 28 May 2013 09:57:02 -0700 (PDT)
Received: by with HTTP; Tue, 28 May 2013 09:57:02 -0700 (PDT)
In-Reply-To: <alpine.BSF.2.00.1305182237110.74365@joyce.lan>
References: <> <20130515202613.24981.qmail@joyce.lan> <> <alpine.BSF.2.00.1305152133120.63512@joyce.lan> <> <> <alpine.BSF.2.00.1305182237110.74365@joyce.lan>
Date: Tue, 28 May 2013 09:57:02 -0700
Message-ID: <>
From: "Murray S. Kucherawy" <>
To: John R Levine <>
Content-Type: multipart/alternative; boundary=f46d0443048a82230804ddca27c7
Cc: Ned Freed <>, 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: Tue, 28 May 2013 16:57:10 -0000

On Sat, May 18, 2013 at 8:00 PM, John R Levine <> wrote:

> 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.

Consider a system that has several independent filtering modules.  It's
important that the modules don't change the content as it passes from one
to the next as doing so might obscure something that the next module might
consider reject-worthy.  Therefore, whatever transformations need to be
done have to be kept internal to the module and not released as the "real"

> 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 similar, but has a different nuance.  If a message makes it all the
way to an MUA where it's reported as abusive (spam, virus, whatever), then
a report generated based on what the MUA sees might not be useful to the
report receiver because it doesn't match the message that was originally

In the next revision, I've mushed 4 and 5 together since they were so
similar.  I'll post later today and see what you think.

> 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.)

That's a real-world example; it's what sendmail does.  But sure, simpler is
better.  I'll clean it up.

> 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.

That MUST should've come out in the last edit, since we're no longer doing
2119 stuff in here.  I'll just take that out.

Thanks for your comments.