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

Ned Freed <> Wed, 29 May 2013 01:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BEC6611E80A2 for <>; Tue, 28 May 2013 18:05:41 -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]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eack5oOtq8Gp for <>; Tue, 28 May 2013 18:05:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AB3B121F8EFC for <>; Tue, 28 May 2013 18:05:35 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Tue, 28 May 2013 18:00:33 -0700 (PDT)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1
Received: from by (PMDF V6.1-1 #35243) id <>; Tue, 28 May 2013 18:00:29 -0700 (PDT)
Message-id: <>
Date: Tue, 28 May 2013 17:50:35 -0700 (PDT)
From: Ned Freed <>
In-reply-to: "Your message dated Tue, 28 May 2013 09:57:02 -0700" <>
References: <> <20130515202613.24981.qmail@joyce.lan> <> <alpine.BSF.2.00.1305152133120.63512@joyce.lan> <> <> <alpine.BSF.2.00.1305182237110.74365@joyce.lan> <>
To: "Murray S. Kucherawy" <>
Cc: Ned Freed <>, John R Levine <>, 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: Wed, 29 May 2013 01:05:42 -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"
> content.

It's nowhere near this simple. Sometimes you want filtering modules exposed
to unadulterated content. One way to arrange for that is preclude any
changes, but another is to run the modules in parallel. After all, if they're
not talking to each other, why wouldn't you want them to run simultaneously?

But other times you want them to be able to pass information to each other.
Unfortunately that often can only be done by adding headers. And there are
even times when you want much more radical transformations applies, such
as the removal of encryption, forced conversion to MIME format, etc. etc.

There really isn't a one size fits all answer here, and it's silly to think
one can be found.

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

And sometimes the opposite is true, e.g., in regards to attaching intermediate
analysis results. Again. it's not a one size fits all situation.

I'm not making any specific suggestion for a change here, more like suggesting
that certain possible changes are best not made.