[apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05
S Moonesamy <sm+ietf@elandsys.com> Fri, 02 December 2011 19:03 UTC
Return-Path: <sm@elandsys.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 A4AA321F8B77; Fri, 2 Dec 2011 11:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TCpYUvq6nr9; Fri, 2 Dec 2011 11:03:38 -0800 (PST)
Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id BBCE421F8B6D; Fri, 2 Dec 2011 11:03:37 -0800 (PST)
Received: from SUBMAN.elandsys.com ([41.136.236.29]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id pB2J3SpZ000643; Fri, 2 Dec 2011 11:03:34 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1322852617; bh=ab6QDBWM7UDVxFwdT/+VCHuX/PA=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=YPoDxh8gitoaeunT2GcTw7cFZNIEK+kaSIl45AeKmDOOopprmsnGOwKlu2BCFOPyk 6sxrsxVz5O5hPcNeINiZrs8R69zbTqGOfYjsv1B1HkYuiTs00Zmf0GsdphezFtJKiV zKcgFea3m70OK9o3H0d3vhPZ9a7HgfEyEFJozDl4=
Message-Id: <6.2.5.6.2.20111202075917.09d8d070@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 02 Dec 2011 11:02:30 -0800
To: apps-discuss@ietf.org, draft-ietf-marf-authfailure-report.all@tools.ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: marf@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05
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, 02 Dec 2011 19:03:39 -0000
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). The review is not being copied to the IESG as a Last Call has not been issued. Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-marf-authfailure-report-05 Title: Authentication Failure Reporting using the Abuse Report Format Reviewer: S. Moonesamy Review Date: December 2, 2011 Summary: This draft is almost ready for publication as a Proposed Standard. Major issues: None. Minor Issues: In the Abstract Section: "This memo registers an extension report type to ARF for use in reporting messages that fail one or more authentication checks" In the Introduction Section: "There is now also a desire to extend the ARF format to include reporting of messages that fail to authenticate using known authentication methods" "Thus, this memo presents such extensions to the Abuse Reporting Format to allow for detailed reporting of message authentication failures." In Section 3: "The current report format defined in [ARF] lacks some specific features required to do effective sender authentication reporting." The use of "authentication" is not consistent throughout the text quoted above. This drafts builds upon RFC 5451 in which DKIM and SPF are referred to as email authentication methods. I suggest using the term "email authentication method" for consistency. The wording "presents such extensions" in the Introduction Section is not clear. Section 3.1 of the draft defines a new feedback type of "auth-failure" as an extension to RFC 5965. Is there more than one extension? This memo should update RFC 5965. In Section 3.1: "Original-Envelope-Id: As specified in [ARF]. This field SHOULD be included exactly once if available to the entity generating the report." RFC 5965 defines the field as optional and MUST NOT appear more than once". The above is a rewording of a requirement level. I suggest rewriting the last sentence to remove the key word: As specified in [ARF]. This field is included only once if available to the entity generating the report. "Original-Mail-From:" Please see the comment above about "Original-Envelope-Id". "Source-IP: As specified in [ARF]. This field SHOULD be included exactly once for SPF, or for other methods that evaluate authentication during the SMTP phase." Please see the comment above about "Original-Envelope-Id". Why is there a "SHOULD" for SPF? "Reported-Domain: As specified in [ARF]. This field MUST appear at least once." Is it the format which is being imported from RFC 5965 or is it also what is specified for the field? 'The third MIME part of the message is either of type "message/rfc822" (as defined in [MIME-TYPES]) or "text/rfc822-headers" (as defined in [REPORT]) and contains a copy of the entire header block from the original message. This part MUST be included (contrary to [REPORT]).' I suggest having a reference to draft-ietf-appsawg-rfc3462bis-04 instead of RFC 3462 and removing the "(contrary to [REPORT])". In Section 3.2.1: "Auth-Failure: Indicates the type of authentication failure that is being reported. The list of valid values is enumerated in Section 3.3." What is being reported is the failure from an email authentication method and not an "authentication failure". In Section 3.2.2: "policy: The message was not delivered to the intended inbox due to authentication failure." Please refer to my comment about the usage of "authentication failure". Nits: In Section 3.2.4: 'DKIM-Canonicalized-Body: A base64 encoding of the canonicalized body of the message as generated by the verifier. The encoded content MUST be limited to those bytes that contribute to the DKIM body hash (i.e., the value of the "l=" tag; see Section 3.7 of [DKIM].' I suggest replacing the word "bytes" with "octets" (RFC 6376). "If DKIM-Canonicalized-Header and DKIM-Canonicalized-Body encode redacted data, they MUST NOT be included. Otherwise, they SHOULD be included. The data presented there have to be exactly the canonicalized header and body as defined by [DKIM] and computed at the verifier. This is because these fields are intended to aid in identifying message alterations that invalidate DKIM signatures in transit. Including redacted data in them renders the data unusable. (See also Section 5 and Section 7.6 for further discussion.)" It is better to restate the above as "SHOULD be included" and mention that it is not applicable if the date has been modified. If the working group wants to mention "redacted data", it can include an informative reference to draft-ietf-marf-redaction-03. Section 5 is the IANA Considerations Section. The draft does not contain a Section 7.6. In Section 3.2.5: "DKIM-ADSP-DNS: Includes the ADSP record discovered and applied by the entity generating this report" I suggest: DKIM-ADSP-DNS It is the ADSP record used to obtain the ADSP result. I did not include a "MUST" as there is already one in Section 3.3 (adsp). In Section 3.3: "The list of defined authentication failure types" Please refer to my previous comments about the usage of "authentication failure". "Supplementary data MAY be included in the form of [MAIL]-compliant comments." Why is there a "MAY"? There should be a normative reference to RFC 5234 given the ABNF in Section 4. In Section 6.2: "Perhaps the simplest means of mitigating this threat is to assert that these reports should themselves be signed with something like DKIM." I suggest removing the "something like". From the example in Appendix B.1: "Received: from mail.example.com (mail.example.com [192.0.2.1]) by mx.example.net (8.14.4/8.14.4) with ESMTP id c6cs67945pbm; Sat, 8 Oct 2011 13:16:24 +0000 (GMT) Return-Path: feedback@arf.mail.example.net" Isn't the Return-Path: mail header inserted before the Received: mail headers? "For more information about this format please see http://datatracker.ietf.org/doc/draft-ietf-marf-authfailure-report" I suggest adding a comment for the RFC Editor to reference "this RFC". "Policy-Action: none" That field has not been defined. I suggest that the working group reviews the example for correctness. Regards, S. Moonesamy
- [apps-discuss] APPSDIR review of draft-ietf-marf-… S Moonesamy
- Re: [apps-discuss] APPSDIR review of draft-ietf-m… Murray S. Kucherawy
- Re: [apps-discuss] APPSDIR review of draft-ietf-m… S Moonesamy
- Re: [apps-discuss] APPSDIR review of draft-ietf-m… Alessandro Vesely