[apps-discuss] Comments on draft-kucherawy-mta-malformed-00

SM <sm@resistor.net> Mon, 18 April 2011 19:42 UTC

Return-Path: <sm@resistor.net>
X-Original-To: apps-discuss@ietfc.amsl.com
Delivered-To: apps-discuss@ietfc.amsl.com
Received: from localhost (localhost []) by ietfc.amsl.com (Postfix) with ESMTP id EF740E070C for <apps-discuss@ietfc.amsl.com>; Mon, 18 Apr 2011 12:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfc.amsl.com []) (amavisd-new, port 10024) with ESMTP id NKcxOtpoR8uG for <apps-discuss@ietfc.amsl.com>; Mon, 18 Apr 2011 12:42:21 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id AE26CE06EC for <apps-discuss@ietf.org>; Mon, 18 Apr 2011 12:42:20 -0700 (PDT)
Received: from subman.resistor.net (IDENT:sm@localhost []) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p3IJgCPu019905; Mon, 18 Apr 2011 12:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1303155739; bh=Rr9wTlU5YvwMJe7u0wLb9Md3mRa19EUf2btiro7OlLs=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:Mime-Version: Content-Type; b=aSieifWEp7hAzsp8R7qM/HBnFoIyTwzwGhBAHEh3JAfHCxkSKIQtycLqmdS1nU621 twelvtsFxQ4ywQVbzTud+IXyXZRfnf3oTpy/z7LM45adgcqzDALo6T1XsZ1JsvRtxt y5lnKFMLIJ74dqWouxMRjn+JMVowHXriTD02za7A=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1303155739; bh=Rr9wTlU5YvwMJe7u0wLb9Md3mRa19EUf2btiro7OlLs=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:Mime-Version: Content-Type; b=WCouKXNiWDJYdiJ5F5E1TknhYrCPgUC+/VVAQlHOUwuyokbnhaVISK+t0aid3FYPP SguMNhGdptzNkMnjndXWaEW2VfFrsWFDCQSGK2yvgtd8StzUPDHVt3iyvmUqvnkG1R 9AFB+ZG/b4H2USZt9R4tvVJeBWl7Bdb6BtMIdaQM=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 18 Apr 2011 12:40:42 -0700
To: "Murray S. Kucherawy" <msk@cloudmark.com>
From: SM <sm@resistor.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Comments on draft-kucherawy-mta-malformed-00
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 19:42:24 -0000

Hi Murray,

I have a few comments about draft-kucherawy-mta-malformed-00.  From Section 4:

   "This situation is exacerbated when a claim of message validity is
    inferred by something like a valid [DKIM] signature."

 From the discussions in the DKIM working group, I guess that this 
draft was written to address a DKIM/RFC 5322 issue.  It's the usual 
IETF issue where it's difficult to get one of two WGs to fix a 
problem as nobody wants to claim the baby.

It's good to document brokenness and even better if it can be 
fixed.  Sometimes a problem cannot be fixed but that's another story [1].

 From Section 3:

   "Of particular interest is the Internet Message Format, detailed in
    [MAIL]. Throughout this document, the use of the term "messsage" should be
    assumed to mean a block of text conforming to the Internet Message

There is a typo for "messsage".

As this draft recommends fixes that affect RFC 5322, it should not be 
published as a BCP.  If it is the consensus to have such fixes, it 
can be expressed through a Proposed Standard that updates RFC 5322.

 From Section 5.1:

   "Consensus indicates the preferred implementation is to terminate
    header processing before the first character in line four, as
    described in (2) above.  Thus, a module compliant with this
    specification MUST terminate header processing upon encountering the
    first line of text that is not a valid header field."

Is the module a filter or a MTA?

As you are aware, "SMTP is now also widely used as a message 
*submission* protocol, that is, a means for Message User Agents 
(MUAs) to introduce new messages into the MTA routing network".  If 
any fixes are to be made, it is better to have them done by the MSA 
instead of the MTA.  Having the MTA make changes to address header 
anomalies creates another set of "middleboxes".

 From Section 6.3 of RFC 4409:

   "The MSA MAY issue an error response to the DATA command or send a
    failure result after end-of-data if the submitted message is
    syntactically invalid, or seems inconsistent with permissions given
    to the user (if known), or violates site policy in some way."

You could use the above to fix the problem closer to the source 
instead of doing it in the MTA.  It should be easier for the 
postmaster to identify the source of the problem and take any action.

On an unrelated note, I received the following bounce (edited 
version) a few days ago:

   From: <postmaster@telecomitalia.local>
   Date: Sat, 16 Apr 2011 13:44:01
   Subject: Impossibile recapitare

Irrespective of whether the above is good practice, I found the 
message useful as it got the "message" through.