Re: [apps-discuss] Comments on Malformed Message BCP draft
Ned Freed <ned.freed@mrochek.com> Mon, 18 April 2011 17:01 UTC
Return-Path: <ned.freed@mrochek.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 50846E0694 for <apps-discuss@ietfc.amsl.com>; Mon, 18 Apr 2011 10:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 P9jUPqMRkONr for <apps-discuss@ietfc.amsl.com>; Mon, 18 Apr 2011 10:01:15 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfc.amsl.com (Postfix) with ESMTP id 27E3DE0684 for <apps-discuss@ietf.org>; Mon, 18 Apr 2011 10:01:14 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O09A027MTC00S603@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 18 Apr 2011 10:01:11 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O07W6AHITS007FL5@mauve.mrochek.com>; Mon, 18 Apr 2011 10:01:09 -0700 (PDT)
Message-id: <01O09A012280007FL5@mauve.mrochek.com>
Date: Mon, 18 Apr 2011 09:45:34 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 18 Apr 2011 13:08:13 +0100" <alpine.LSU.2.00.1104181304010.19348@hermes-2.csi.cam.ac.uk>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <F5833273385BB34F99288B3648C4F06F1343319E22@EXCH-C2.corp.cloudmark.com> <CEDB17EC-80CE-49B5-91C1-FBCB0449BBA5@network-heretics.com> <4DA8542F.9040003@tana.it> <F5833273385BB34F99288B3648C4F06F1343319E51@EXCH-C2.corp.cloudmark.com> <3111.1302886222.968467@puncture> <alpine.LSU.2.00.1104181304010.19348@hermes-2.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1303145635; bh=SeYSlScem8rghOvTqdOxgFlF1605VI4ApaoLqRomz+g=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=JKmUsLpkwMcpDrXE3P35UoyE4+h18GlsyjfEiFhbFvHW9MAKq0dtebmoizT5KaZpy VFd4UBXZrYBpY8CygFzrXWM0wPlOuhXiDyDyU+Srp9ixPut++AqB0MWpjSYgafSLb/ 2OHzf71/wVH28u/ew4XfI/H1DdFFjR/9VaOc5O0M=
Cc: ietf-822 <ietf-822@imc.org>, General discussion of application-layer protocols <apps-discuss@ietf.org>
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: Mon, 18 Apr 2011 17:01:16 -0000
> Dave Cridland <dave@cridland.net> wrote: > > > > It may be that the discussion suggests rejecting, in which case I suggest the > > document should clearly explain why, and what the implications of not doing so > > are, beyond "it makes some problems harder to diagnose". > It does not make sense to have a uniform policy for dealing with corrupt > messages. Some kinds of corruption are caused by common legitimate > software, in which case you will want to treat it leniently; others are > caused by malware or rare kinds of incompetence, in which case it makes > more sense to reject. You can only determine which is which based on > operational experience, and the least-worst response changes from time to > time. Bingo. This is precisely the concern I have with this effort - the IETF consensus process operates in a time scale that will make it very difficult to capture a sensible set of recommendations in a specification. And even if we do manage to capture something useful, it will need to be updated regularly to remain useful. Are we prepared to do that? And it isn't a binary choice between rejection and fixup either. What sort of fixup makes sense can change over time. Consider the invalid header line case. There was a period a few years ago when it seemed like half the email agents out there couldn't consistently fold header lines. As a result the strategy of accepting such messages and not terminating the header seemed to work best. But as this issue was starting to disappear, a new one, where some group of agents decided that the blank line between the header and body was superfluous and could be omitted, started to show up. A strategy of treating an invalid header line as a stopping point works best in this case. But who's to say what's going to happen next month? This sort of behavior shifting over time is especially prevalent in certain problem areas like CJK charset usage and labeling. Another aspect to this that hasn't been discussed yet is where some agent can only tolerate a subset of what the standards allow. Is it OK to reformat messages to avoid using legitimate but neverthless problematic features? My personal favorite of these was the one where, several years back, a very popular product refused to accept MIME messages where the content-tranfer-encoding field appeared prior to the content-type in the message header. Ned
- [apps-discuss] Comments on Malformed Message BCP … Simon Tyler
- Re: [apps-discuss] Comments on Malformed Message … Nathaniel Borenstein
- Re: [apps-discuss] Comments on Malformed Message … Alessandro Vesely
- Re: [apps-discuss] Comments on Malformed Message … Murray S. Kucherawy
- Re: [apps-discuss] Comments on Malformed Message … Dave CROCKER
- Re: [apps-discuss] Comments on Malformed Message … Dave Cridland
- Re: [apps-discuss] Comments on Malformed Message … Dave Cridland
- Re: [apps-discuss] Comments on Malformed Message … Dave CROCKER
- Re: [apps-discuss] Comments on Malformed Message … Simon Tyler
- Re: [apps-discuss] Comments on Malformed Message … Keith Moore
- Re: [apps-discuss] Comments on Malformed Message … Keith Moore
- Re: [apps-discuss] Comments on Malformed Message … Dave Cridland
- Re: [apps-discuss] Comments on Malformed Message … Murray S. Kucherawy
- Re: [apps-discuss] Comments on Malformed Message … Keith Moore
- Re: [apps-discuss] Comments on Malformed Message … Keith Moore
- Re: [apps-discuss] Comments on Malformed Message … J.D. Falk
- Re: [apps-discuss] Comments on Malformed Message … Arnt Gulbrandsen
- Re: [apps-discuss] Comments on Malformed Message … Murray S. Kucherawy
- Re: [apps-discuss] Comments on Malformed Message … Larry Masinter
- Re: [apps-discuss] Comments on Malformed Message … Nathaniel Borenstein
- Re: [apps-discuss] Comments on Malformed Message … Jaap Akkerhuis
- Re: [apps-discuss] Comments on Malformed Message … Keith Moore
- Re: [apps-discuss] Comments on Malformed Message … Peter Koch
- Re: [apps-discuss] Comments on Malformed Message … Tony Finch
- Re: [apps-discuss] Comments on Malformed Message … Eric Burger
- Re: [apps-discuss] Comments on Malformed Message … Tony Finch
- Re: [apps-discuss] Comments on Malformed Message … Tony Finch
- Re: [apps-discuss] Comments on Malformed Message … John C Klensin
- Re: [apps-discuss] Comments on Malformed Message … Ned Freed
- Re: [apps-discuss] Comments on Malformed Message … Tony Finch
- Re: [apps-discuss] Comments on Malformed Message … Douglas Otis
- Re: [apps-discuss] FW: Comments on Malformed Mess… Barry Leiba
- Re: [apps-discuss] FW: Comments on Malformed Mess… Murray S. Kucherawy