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

"Murray S. Kucherawy" <> Mon, 13 May 2013 06:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 955BD21F915B for <>; Sun, 12 May 2013 23:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hVeWaAxGFjha for <>; Sun, 12 May 2013 23:47:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::234]) by (Postfix) with ESMTP id 69E4D21F915A for <>; Sun, 12 May 2013 23:47:13 -0700 (PDT)
Received: by with SMTP id hn14so198053wib.13 for <>; Sun, 12 May 2013 23:47:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=t5BMqX+Ut91ALpMrobU6dOMYT8b+Y2FQiTQzZz3+gJI=; b=kjOQkfKVW4VHrcEo14ocEMY581ErW3Oc/EThn/L+RZsRwZbYeSCBkE86twSyfwCqjk gqI8TyRf2Ayg+BWU78o1sNgt81uqD9atQdXaodYnl4qX0VAi5mQMidC3TtIGlDwmlB8/ g0Gt8YloxQLracCXIR6iCVKlvMGn0Jl/ULT2xJKA18rR9StQvvM1ldqd4ATupWb0ILI6 xjCzayY8uiJXC8c2nELeawFI1LzG3OIjFQKHmfpV2gzo+J6r48tuvt6GMQlxiOkIspZA 8iCWGd/72XmX5Y9U2bEIF29Rse44ULCBVf1xkG8ZGrGIBUVztLpZbxErduU0oWgl6M6b b9BQ==
MIME-Version: 1.0
X-Received: by with SMTP id x13mr16121804wij.20.1368427632589; Sun, 12 May 2013 23:47:12 -0700 (PDT)
Received: by with HTTP; Sun, 12 May 2013 23:47:12 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Sun, 12 May 2013 23:47:12 -0700
Message-ID: <>
From: "Murray S. Kucherawy" <>
To: Ned Freed <>
Content-Type: multipart/alternative; boundary=e89a8f6473f5f100e404dc93e239
Cc: Dave Crocker <>, 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: Mon, 13 May 2013 06:47:14 -0000

Hi Ned, thanks for your comments.  I've worked in most of your suggestions,
but have the following to ask further on some of your points:

On Mon, May 6, 2013 at 2:14 PM, Ned Freed <> wrote:

> Eight-Bit Data (section 8.7) needs a bunch of work, and once again it's a
> failure to consider the semantics of where the 8bit shows up. 8bit
> appearing in
> a header is a very different proposition from 8bit in a body. EAI deserves
> a
> shout-out in the former case because it's new, and the latter case is now
> so
> much of a ho-hum for many agents that a recommendation to reject 8bit is
> nothing short of silly.
> I'm also far from convinced that rejecting messages because of a single
> null is
> a good idea. I think a fair assessment of the likely intent in this case
> is the
> presence of a null or two is simply a message construction error, and
> silently
> dropping them is a much better bet.

Eight bit data is far from something I'm expert on.  Could I ask you to
write up a paragraph or three to include here, or replace what's here?

> Header Field Names (section 9.1) is certainly cute, but MIME is actually
> quite clear that the first place a boundary can occur is in the following
> body, not the associated header. I'm not really comfortable with
> this document acting on an assessment of intent of material that is in fact
> completely valid. My suggestion is therefore to refrain from talking about
> rejecting such messages.

It's a real attack seen in the wild.  I see your point about MIME and the
location of boundaries, however, so I think this section can just go.

> I'm afraid "Missing MIME-Version Field" (section 9.2) is flat-out
> incorrect.
> The intent of a message that has a valid content-type and possibly
> content-transfer-encoding is pretty darned clear, and perhaps more to the
> point, failing to interpret such a message as MIME, given that many other
> agents, e.g., metamail, are going to, is exceedingly poor practice from a
> security standpoint.

This is also something real I dealt with at a previous employer.  More
often than not it was seen as part of a spam attack that targeted specific
MUAs.  I'm fine with removing this section however if the advice is
controversial; I don't have access to data to back up how important or
useful this change was.

> (If we're up for additions at this late date, it might also be good to add
> a
> section on how to handle bogus base64 or quoted-printable.)

Yup, we are.  Do you have anything specific in mind?