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

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

Return-Path: <superuser@gmail.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 955BD21F915B for <apps-discuss@ietfa.amsl.com>; Sun, 12 May 2013 23:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 hVeWaAxGFjha for <apps-discuss@ietfa.amsl.com>; Sun, 12 May 2013 23:47:13 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 69E4D21F915A for <apps-discuss@ietf.org>; Sun, 12 May 2013 23:47:13 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id hn14so198053wib.13 for <apps-discuss@ietf.org>; Sun, 12 May 2013 23:47:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.180.37.109 with SMTP id x13mr16121804wij.20.1368427632589; Sun, 12 May 2013 23:47:12 -0700 (PDT)
Received: by 10.180.14.34 with HTTP; Sun, 12 May 2013 23:47:12 -0700 (PDT)
In-Reply-To: <01OTC53YHHWQ000054@mauve.mrochek.com>
References: <51657E80.8070208@bbiw.net> <CAL0qLwb-Aj+Te2uYJZo8g5LR4B6JREPFATTPSLGf_L4LvgMrZQ@mail.gmail.com> <01OTC53YHHWQ000054@mauve.mrochek.com>
Date: Sun, 12 May 2013 23:47:12 -0700
Message-ID: <CAL0qLwaBPhyPEKHPwRurqoCnNy2_tp6rCHe7YzvPonvfN_ALHQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Ned Freed <ned.freed@mrochek.com>
Content-Type: multipart/alternative; boundary=e89a8f6473f5f100e404dc93e239
Cc: Dave Crocker <dcrocker@bbiw.net>, Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-03
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: 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 <ned.freed@mrochek.com> 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?

-MSK