Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document

Nathaniel Borenstein <nsb@guppylake.com> Fri, 08 July 2011 10:10 UTC

Return-Path: <nsb@guppylake.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 2ACCF21F8993 for <apps-discuss@ietfa.amsl.com>; Fri, 8 Jul 2011 03:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWHtIR-1pEgT for <apps-discuss@ietfa.amsl.com>; Fri, 8 Jul 2011 03:10:20 -0700 (PDT)
Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id EC9F421F86D7 for <apps-discuss@ietf.org>; Fri, 8 Jul 2011 03:10:19 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=swviyCSDuD4vXvYh6vtXb4+3FTx/Ivw7zex/7yAlRv6/lZBtgWyv5E3fnvx01k8YbFg1wanTOKFT8uF52IJyL5gkQhjr7/ZjEy/fLjBMjlGjSsiGrKhcwqiJZi3RfxXf;
Received: from [195.153.194.242] (helo=[192.168.55.182]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from <nsb@guppylake.com>) id 1Qf80l-0002ZV-8M; Fri, 08 Jul 2011 06:10:15 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Nathaniel Borenstein <nsb@guppylake.com>
In-Reply-To: <20110706052247.16131.qmail@joyce.lan>
Date: Fri, 8 Jul 2011 11:10:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A93D2D06-E4EF-447C-A3AD-1122A3D5A1EA@guppylake.com>
References: <20110706052247.16131.qmail@joyce.lan>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server1.netnutz.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - guppylake.com
Cc: randy@qualcomm.com, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document
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, 08 Jul 2011 10:10:21 -0000

On Jul 6, 2011, at 6:22 AM, John Levine wrote:

>> It might be worthwhile to mention some of this immediately following 
>> the quoted text.  Also, it might be worthwhile to suggest that it's 
>> good for MSAs fix or reject stuff that is broken (obviously this 
>> draft can't mandate this).
> 
> This draft can't mandate it, but since MSAs are only supposed to
> submit valid RFC 5322 (or 2822) messages, I'd think it would be OK to
> point out that existing standards already mandate it.

This is perhaps ok for MSAs, because the rejection happens close to the sender, who will typically get feedback.  It's a different story on the receiving end.  The existing standards mandate the *submission* of valid messages, but say little about what to do when you receive invalid messages.

It has been our experience that when we reject invalid incoming messages that are "nearly valid," our users tend to complain that their previous provider/software let such messages through, and they conclude that our system is broken for blocking mail that previously reached them.   They pressure us to "fix" our system with the threat that they'll seek alternative providers.  

You may not like it -- I certainly don't! -- but the market exerts strong pressures on us to accept malformed messages if we can possibly make sense of them.  I, for one, would love to see a third alternative besides "accept" and "reject" -- perhaps accepting the message for delivery but also sending a warning to the sender.  Of course, there are lots of problems with that, too. -- Nathaniel