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

Douglas Otis <dotis@mail-abuse.org> Mon, 18 April 2011 22:56 UTC

Return-Path: <dotis@mail-abuse.org>
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 38AE5E082A for <apps-discuss@ietfc.amsl.com>; Mon, 18 Apr 2011 15:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.572
X-Spam-Level:
X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 GWtoQ4gwGWtF for <apps-discuss@ietfc.amsl.com>; Mon, 18 Apr 2011 15:56:19 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by ietfc.amsl.com (Postfix) with ESMTP id 9D608E083C for <apps-discuss@ietf.org>; Mon, 18 Apr 2011 15:56:16 -0700 (PDT)
Received: from us-dougo-mac.us.trendnet.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id EABF6A94452; Mon, 18 Apr 2011 22:57:03 +0000 (UTC)
Message-ID: <4DACC188.7010305@mail-abuse.org>
Date: Mon, 18 Apr 2011 15:56:08 -0700
From: Douglas Otis <dotis@mail-abuse.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: ietf-822 <ietf-822@imc.org>
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> <4DA876B6.9050700@dcrocker.net> <3111.1302886470.781218@puncture> <4DA878B4.9060007@dcrocker.net> <B5B267BE-98C6-40F3-9D37-0CE95AE5F1D4@network-heretics.com> <F5833273385BB34F99288B3648C4F06F1343319E5F@EXCH-C2.corp.cloudmark.com> <alpine.LSU.2.00.1104181313310.19348@hermes-2.csi.cam.ac.uk> <B6F7003D55BF792BFCCD4395@PST.JCK.COM>
In-Reply-To: <B6F7003D55BF792BFCCD4395@PST.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 19 Apr 2011 08:07:29 -0700
Cc: 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 22:56:20 -0000

On 4/18/11 5:48 AM, John C Klensin wrote:
> --On Monday, April 18, 2011 13:19 +0100 Tony Finch
> <dot@dotat.at>  wrote:
>> Murray S. Kucherawy<msk@cloudmark.com>  wrote:
>>> I don't think this work is targeted at intermediaries.  In
>>> fact, I'd be completely fine with expressly saying it's meant
>>> to address processing at ingress MTAs only.
>> If you are going to make that kind of restriction, it should
>> happen at submission servers only.
>>
>> There is a history of MX servers making "helpful" fix-ups to
>> messgaes (e.g. inserting missing message-id or from headers)
>> before handing them over to anti-spam software, which can make
>> spam/legit checks invalid in both the positive and negative
>> senses. So I think MXs should be as transparent as possible so
>> that downstream security software is less likely to have
>> interop problems. Intermediate relays should also be as
>> transparent as possible.
> Of course, this is exactly what RFCs 4409, 5068, and 5321 say:
> considerable flexibility for making fixes for the submission
> server, which is presumably under the control of (or at least
> responsible to) the sender; relays don't mess with message
> contents until they get to the delivery server.  Various
> operational considerations have modified that somewhat but, if
> this specification doesn't apply to intermediaries, it changes
> nothing except, as Eric Burger points out, the practical
> definition of well-formed messages.
>
> IMO, if we want to do that (and I'd personally not favor it), we
> should do so in some 5322bis, not try to sneak the changes in
> via a BCP that is inconsistent with 5322.
Fully Agree.

-Doug