[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 [127.0.0.1]) 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-Level:
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 ([208.66.40.236]) by localhost (ietfc.amsl.com
[127.0.0.1]) (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 [127.0.0.1]) 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: <6.2.5.6.2.20110418113432.0501e038@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
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 Format." 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. Regards, -sm 1. http://asset.rue89.com/files/imagecache/panorama/files/illustration/niqabitch_burqa_illus.jpg