Re: [apps-discuss] Comments on Malformed Message BCP draft

Keith Moore <moore@network-heretics.com> Fri, 15 April 2011 18:00 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: apps-discuss@ietfc.amsl.com
Delivered-To: apps-discuss@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6FA7DE0886 for <apps-discuss@ietfc.amsl.com>; Fri, 15 Apr 2011 11:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki7ZZjWpuTk5 for <apps-discuss@ietfc.amsl.com>; Fri, 15 Apr 2011 11:00:24 -0700 (PDT)
Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfc.amsl.com (Postfix) with ESMTP id A70ECE07CF for <apps-discuss@ietf.org>; Fri, 15 Apr 2011 11:00:24 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.messagingengine.com (Postfix) with ESMTP id 71B8D223AE; Fri, 15 Apr 2011 14:00:24 -0400 (EDT)
Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 15 Apr 2011 14:00:24 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=kKkpLuNUCMIN72S2CLgN05CzuAk=; b=mp9UdGSkLwGHidSkB5J4mkr4vPFAkYMbXcSeo4ElGugQv8nqzfIAdw5EAXSk/RX19vV1Z6E2gr/4zX2IMU05Ou9hlMTfv4pOh/Qbzmem9/ZH6Kulc1cKnUooiq86SEnk/cltbuWrCkC+Ah42XLvwiTcBpu7xBqWhqLI/DbQBlCk=
X-Sasl-enc: wwPunYhhuyEguHXadkKmTExWgHsyX8j23JwNe4+ogYzC 1302890424
Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id B6151400969; Fri, 15 Apr 2011 14:00:23 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <3111.1302889836.721157@puncture>
Date: Fri, 15 Apr 2011 14:00:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <38DD2AED-CDEC-4AFE-80B9-DB8867B715FA@network-heretics.com>
References: <F5833273385BB34F99288B3648C4F06F1343319E22@EXCH-C2.corp.cloudmark.com> <CEDB17EC-80CE-49B5-91C1-FBCB0449BBA5@network-heretics.com> <4DA8542F.9040003@tana.it> <5FBD6703-40D0-482F-B6A5-4C17EC88B9D3@network-heretics.com> <3111.1302889836.721157@puncture>
To: Dave Cridland <dave@cridland.net>
X-Mailer: Apple Mail (2.1084)
Cc: ietf-822 <ietf-822@imc.org>, General discussion of application-layer protocols <apps-discuss@ietf.org>, Alessandro Vesely <vesely@tana.it>
Subject: Re: [apps-discuss] Comments on Malformed Message BCP draft
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: Fri, 15 Apr 2011 18:00:29 -0000

By default, MTAs should not care about the contents of a message.  To do so is a layering violation.   The message should be opaque and the MTA should look only at the envelope.   The only "standard" exception is 8bit to 7bit conversion, which hopefully is rarely an issue these days.  

So the fact that a message is "malformed" should not prevent delivery of that message.

But if MTAs are going to care about contents of messages (say, for the purpose of filtering spam or viruses, which pretty much everyone will acknowledge as necessary measures against evil these days), then there will inevitably be cases where the MTAs are unable to parse those contents, presumably because the messages are malformed.  If the spam or virus filter can reliably tell that the message is spam or a virus, dropping it is the proper thing to do.  But if the filter cannot tell, or cannot parse the message because it is malformed, bouncing it is probably better.

The problem of using MIME to send malware exists whether or not the message is bounced.  Bouncing messages, if properly done, does not amplify the problem, because there should never be more than one bounce address.  Either the message containing malware is delivered (in which case the recipient UA deals with the threat) or it is bounced (in which case the "return-path" UA deals with the threat).   And again, if properly done, bouncing should not "mask" the source of the malware, because the Received headers should be present in the returned content in any case.  

Keith

On Apr 15, 2011, at 1:50 PM, Dave Cridland wrote:

> On Fri Apr 15 18:38:50 2011, Keith Moore wrote:
>> Bouncing is absolutely what should happen if the message is merely malformed.  Otherwise, the sender has no idea that his message didn't arrive (or why), and nothing will ever be done to fix the problem.
> 
> But the problem is that the message didn't arrive. The reason is that it's malformed, but that's not the problem that people care most about. Now, *we* may care, but that's a wholly different thing, and largely irrelevant to the average user.
> 
> Bouncing has problems too - it's trivial to use such a server to bounce malformed MIME back to some other address which then processes the MIME and allows some malware through.
> 
> As I said before, differences in error handling behaviour may result in malware vectors being available. If you standardize the error handling (to whatever you like - pass through, bounce, or reject) then the net result is that exploits of this form cannot happen.
> 
> Dave.
> -- 
> Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade