From iesg-secretary@ietf.org Thu Dec 1 08:21:07 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AF111E81FA; Thu, 1 Dec 2011 08:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 FmCtGOYLzdCc; Thu, 1 Dec 2011 08:21:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A0B11E8231; Thu, 1 Dec 2011 08:21:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111201162104.1088.81619.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2011 08:21:04 -0800 Cc: marf@ietf.org Subject: [marf] Last Call: (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Informational RFC X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 16:21:07 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Redaction of Potentially Sensitive Data from Mail Abuse Reports' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Email messages often contain information which might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-redaction/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Thu Dec 1 16:00:21 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09F81F0CBE; Thu, 1 Dec 2011 16:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 XNWZd5mQpdZR; Thu, 1 Dec 2011 16:00:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7CA1F0C45; Thu, 1 Dec 2011 16:00:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111202000021.21241.16968.idtracker@ietfa.amsl.com> Date: Thu, 01 Dec 2011 16:00:21 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 00:00:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Authentication Failure Reporting using the Abuse Report = Format Author(s) : Hilda L. Fontana Filename : draft-ietf-marf-authfailure-report-05.txt Pages : 19 Date : 2011-12-01 This memo registers an extension report type to ARF for use in reporting messages that fail one or more authentication checks performed on receipt of a message, with the option to include forensic information describing the specifics of the failure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-05.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-05.txt From vesely@tana.it Fri Dec 2 04:56:02 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BD721F982A for ; Fri, 2 Dec 2011 04:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] 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 Uitu1-T9qqgr for ; Fri, 2 Dec 2011 04:56:02 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1067021F9823 for ; Fri, 2 Dec 2011 04:56:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1322830558; bh=f2ORz0M8ItVGn2CEHIyeoEZVJOliuK6WKE/6elADEM0=; l=2570; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Ut+7u1XlUdQUhL6uf+j76jiIG29x4+i4zJoUHn7Rb848EcKwsA+ENSfBBDISeIocV EDYgt+6v4guRozJG9mUMKCWRio9hxCCz4Ae9FQsFEBQGjw1eiZH1mKD5k8CCS4xxKZ SGA4rK42jsP3p/vuyjvsHQX+8Znb0hOhRcKxWjtc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 02 Dec 2011 13:55:58 +0100 id 00000000005DC04A.000000004ED8CADE.00004E9C Message-ID: <4ED8CADD.3070809@tana.it> Date: Fri, 02 Dec 2011 13:55:57 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111202000021.21241.16968.idtracker@ietfa.amsl.com> In-Reply-To: <20111202000021.21241.16968.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 12:56:03 -0000 On 02/Dec/11 01:00, internet-drafts@ietf.org wrote: > Filename : draft-ietf-marf-authfailure-report-05.txt I still have some problems with the example. It seems that ".com" and ".net" were swapped at least in one place, and in any case it is difficult to avoid confusion with them. Perhaps it's me, but wouldn't it be possible to replace the domain names (tentatively) like so? s/example.com/originator.example/ s/example.net/verifier-reporter.example/ Specific nits in the text/rfc822-headers (3rd) part are as follows: * There is no "To:" header field, * the topmost Received has ".com" and ".net" swapped, * there are more than three minutes between internal servers handling, and they are inconsistent with the Date field. I'd change those lines with, say, Received: from anexample.example.com ([192.0.2.1]) by mta1011.mail.tp2.example.net with ESMTP Sat, 08 Oct 2011 04:16:24 -0700 (PDT) Received: from internal-client-001.example.com by mail.example.com (an alias for anexample) with SMTP id o3F3BwdY028431; Sat, 08 Oct 2011 04:16:23 -0700 (PDT) Date: Sat, 8 Oct 2011 09:16:23 -0400 (EDT) * the DKIM-Signature has d=example.net rather than d=example.com, and * the A-R field misses a semicolon at the end of the first line while the second line conflates two methods. I'd rewrite it taking three lines, e.g. Authentication-Results: mta1011.mail.tp2.example.net; spf=pass smtp.mailfrom=anexample.example.com; dkim=fail (bodyhash) header.d=examle.com; For the second part, this should instead be Authentication-Results: mta1011.mail.tp2.example.net; dkim=fail (bodyhash) header.d=examle.com; Also in the second part, where would Reported-URI be derived from? Then, the report would be sent from the verifier/reporter back to example.com. Instead, the outermost "Received:" field is "from mail.example.com by mx.example.net". The IP address 192.0.2.1 doesn't seem to belong here. Do we need an outermost Received field? If the intent is to exemplify a generated but not yet sent report, it can be omitted as well as Return-Path and Authentication-Results. If not, I'd also add a DKIM-Signature. One more nit, there is an unbalanced parenthesis in the last line of the second paragraph of 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]. From vesely@tana.it Fri Dec 2 07:22:22 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6304321F8C4E for ; Fri, 2 Dec 2011 07:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 nleAmxmILhfL for ; Fri, 2 Dec 2011 07:22:21 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 436A121F8C43 for ; Fri, 2 Dec 2011 07:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1322839336; bh=oe3ASCkn0TudqQ7lKdLeEQqfIOOIvY2M8jARt5U6218=; l=159; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=V/NscCOAWQT2YGpG9JqPHMSUMv1mEHctEu4H310Al8jxy5soqugsQ472xLbpsr8Rl i8beMizcohIEjaRWN3Ho6VS5/2MLSp1QAgql92J/m2Kr9YaCcxpH+TFqV5fAZ7BFIV IshrdHyPB6nvqrYpUgh4CEOKOl8YOoU/XhOtGzTc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 02 Dec 2011 16:22:16 +0100 id 00000000005DC033.000000004ED8ED28.000076BB Message-ID: <4ED8ED27.3060308@tana.it> Date: Fri, 02 Dec 2011 16:22:15 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111202000021.21241.16968.idtracker@ietfa.amsl.com> <4ED8CADD.3070809@tana.it> In-Reply-To: <4ED8CADD.3070809@tana.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 15:22:22 -0000 Oops, perhaps that should be On 02/Dec/11 13:55, Alessandro Vesely wrote: > Sat, 08 Oct 2011 04:16:24 -0700 (PDT) Sat, 08 Oct 2011 06:16:24 -0700 (PDT) From sm@elandsys.com Fri Dec 2 11:03:39 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@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 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Fri, 02 Dec 2011 11:32:13 -0800 Cc: marf@ietf.org Subject: [marf] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From msk@cloudmark.com Fri Dec 2 11:59:37 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44CF11E80E5 for ; Fri, 2 Dec 2011 11:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.717 X-Spam-Level: X-Spam-Status: No, score=-102.717 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dC805mt1cps4 for ; Fri, 2 Dec 2011 11:59:37 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDE411E8083 for ; Fri, 2 Dec 2011 11:59:37 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 2 Dec 2011 11:59:36 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 2 Dec 2011 11:59:35 -0800 Thread-Topic: MARF document last calls Thread-Index: AcyxLOpN2haTgFYyQBu4WeSxsv/l2A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C153AAEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] MARF document last calls X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 19:59:38 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C153AAEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Both of the drafts we've seen discussed in the last couple of days have gon= e through a working group last call (in one case, twice), and what little f= eedback we got had been incorporated. Then we start IETF-wide last call, a= nd now we get another round of substantive comments from working group part= icipants. This might cause the AD to send it back to the working group for= more editing and another WGLC. I'm sure I don't need to tell you that this is a little frustrating for the= co-chairs. By the time a document goes to IETF-wide last call, we should be supporting= it, not still picking at it. If you think it's too early for us to have s= ent it to the IESG, that means we didn't have any input from the rest of yo= u to indicate more work was needed. Please take the time to review and comment on documents before or at least = during the WGLC. Don't wait. Thanks, -MSK, as co-chair --_000_F5833273385BB34F99288B3648C4F06F19C6C153AAEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Both of= the drafts we’ve seen discussed in the last couple of days have gone= through a working group last call (in one case, twice), and what little fe= edback we got had been incorporated.  Then we start IETF-wide last cal= l, and now we get another round of substantive comments from working group = participants.  This might cause the AD to send it back to the working = group for more editing and another WGLC.

 

I’m sure I don’t nee= d to tell you that this is a little frustrating for the co-chairs.

 

By the= time a document goes to IETF-wide last call, we should be supporting it, n= ot still picking at it.  If you think it’s too early for us to h= ave sent it to the IESG, that means we didn’t have any input from the= rest of you to indicate more work was needed.

 

Please take the time to re= view and comment on documents before or at least during the WGLC.  Don= ’t wait.

 

Thanks,

-MSK, as co-cha= ir

 

= --_000_F5833273385BB34F99288B3648C4F06F19C6C153AAEXCHC2corpclo_-- From shmuel+gen@patriot.net Fri Dec 2 12:35:32 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4322311E80E5 for ; Fri, 2 Dec 2011 12:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 iaFadBU98R3q for ; Fri, 2 Dec 2011 12:35:31 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9767011E8083 for ; Fri, 2 Dec 2011 12:35:31 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.114]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 72B82F5809C for ; Fri, 2 Dec 2011 15:22:49 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Fri, 02 Dec 2011 15:36:39 -0500 To: marf@ietf.org In-Reply-To: <6.2.5.6.2.20111202075917.09d8d070@elandnews.com> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111202202249.72B82F5809C@smtp.patriot.net> Subject: Re: [marf] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 20:35:32 -0000 In <6.2.5.6.2.20111202075917.09d8d070@elandnews.com>, on 12/02/2011 at 11:02 AM, S Moonesamy said: >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: Why? The sense of the text is that it should not be omitted if the data are available. Thr part about only once is secondary and is alread implied. How about "Original-Envelope-Id: As specified in [ARF]. This field SHOULD be included if available to the entity generating the report." INHO it is appropriate to echo the restriction in [ARF], but that's less important. >I suggest having a reference to draft-ietf-appsawg-rfc3462bis-04 Is that legitimate in a Standards Track RFC? >I suggest removing the "something like". What is the justification for precluding other types of digital signatures? Wouldn't it be better to remain agnostic? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Fri Dec 2 12:37:05 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4AF11E80EB for ; Fri, 2 Dec 2011 12:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.713 X-Spam-Level: X-Spam-Status: No, score=-102.713 tagged_above=-999 required=5 tests=[AWL=-0.114, 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 qC28r-6FiUab for ; Fri, 2 Dec 2011 12:37:05 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 641EC11E8083 for ; Fri, 2 Dec 2011 12:37:02 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 2 Dec 2011 12:37:02 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 2 Dec 2011 12:37:01 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Fri, 2 Dec 2011 12:37:00 -0800 Thread-Topic: [marf] APPSDIR review of draft-ietf-marf-authfailure-report-05 Thread-Index: AcyxMfGeyaN92iWsQCOIRblxa0BQ8AAABHjw Message-ID: References: <6.2.5.6.2.20111202075917.09d8d070@elandnews.com> <20111202202249.72B82F5809C@smtp.patriot.net> In-Reply-To: <20111202202249.72B82F5809C@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 20:37:05 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Friday, December 02, 2011 12:37 PM > To: marf@ietf.org > Subject: Re: [marf] APPSDIR review of draft-ietf-marf-authfailure- > report-05 >=20 > In <6.2.5.6.2.20111202075917.09d8d070@elandnews.com>, on 12/02/2011 > at 11:02 AM, S Moonesamy said: >=20 > >I suggest having a reference to draft-ietf-appsawg-rfc3462bis-04 >=20 > Is that legitimate in a Standards Track RFC? Yes, it was approved for publication yesterday. It will have an actual RFC= number long before this one gets that far. From msk@cloudmark.com Fri Dec 2 12:39:31 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071C621F8BBA; Fri, 2 Dec 2011 12:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.708 X-Spam-Level: X-Spam-Status: No, score=-102.708 tagged_above=-999 required=5 tests=[AWL=-0.109, 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 6VclUwAs-goD; Fri, 2 Dec 2011 12:39:30 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAD621F8BB2; Fri, 2 Dec 2011 12:39:30 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 2 Dec 2011 12:39:29 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "draft-ietf-marf-authfailure-report.all@tools.ietf.org" Date: Fri, 2 Dec 2011 12:39:28 -0800 Thread-Topic: [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 Thread-Index: AcyxJRu4FPBkpIWvS9iC1gLttLPGoAACg6GQ Message-ID: References: <6.2.5.6.2.20111202075917.09d8d070@elandnews.com> In-Reply-To: <6.2.5.6.2.20111202075917.09d8d070@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 20:39:31 -0000 Hi SM, thanks for the review. > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of S Moonesamy > Sent: Friday, December 02, 2011 11:03 AM > To: apps-discuss@ietf.org; draft-ietf-marf-authfailure-report.all@tools.i= etf.org > Cc: marf@ietf.org > Subject: [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-rep= ort-05 >=20 > This draft is almost ready for publication as a Proposed Standard. >=20 > Major issues: >=20 > None. Whew! > Minor Issues: >=20 > In the Abstract Section: >=20 > "This memo registers an extension report type to ARF for use in > reporting messages that fail one or more authentication checks" >=20 > In the Introduction Section: >=20 > "There is now also a desire to extend the ARF format to include > reporting of messages that fail to authenticate using known > authentication methods" >=20 > "Thus, this memo presents such extensions to the Abuse > Reporting Format to allow for detailed reporting of message > authentication failures." >=20 > In Section 3: >=20 > "The current report format defined in [ARF] lacks some specific > features required to do effective sender authentication reporting." >=20 > 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. Agreed. There will probably be a few people concerned about the "authentication vs.= authorization" matter, but I think RFC5451 dealt with this reasonably well= , and the field in general has come to be known as "email authentication". = But you're right that "sender" is misleading in terms of roles, especially= in the case of DKIM. This draft has been around for a while and I guess t= his text hasn't matured as fast as its brethren. If it would help, we could add a reference to RFC5451 Section 1.5.2, which = talks about the differences and their effective union in this area. > 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. I suppose it's worded that way because we created a new report type but had= to make a number of changes to IANA registries to do so, hence the plural.= But it really is one omnibus extension action. I don't have a preference= as to wording; if the plural is confusing, we can change it. > In Section 3.1: >=20 > "Original-Envelope-Id: As specified in [ARF]. This field SHOULD be > included exactly once if available to the entity generating the > report." >=20 > 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: >=20 > As specified in [ARF]. This field is included only once if available = to the > entity generating the report. The point of saying this is that RFC5965 allows for the absence or presence= of the field, but proscribes multiple instances of it. We want to say, fo= r this report type, that Original-Envelope-ID should be there, further limi= ting the "absence" case. Perhaps changing the SHOULD to a MUST above is better? > "Original-Mail-From:" >=20 > Please see the comment above about "Original-Envelope-Id". Ditto for me too. > "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." >=20 > Please see the comment above about "Original-Envelope-Id". Ditto for me too. > Why is there a "SHOULD" for SPF? The Source-IP is a key piece of information for reconstructing why an SPF e= valuation failed. It needs to be there if it's available, or the failure r= eport is basically incomplete. > "Reported-Domain: As specified in [ARF]. This field MUST appear at > least once." >=20 > Is it the format which is being imported from RFC 5965 or is it also > what is specified for the field? It is the same, except that RFC5965 makes it entirely optional. For this r= eport type, we want to see it at least once. > '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]).= ' >=20 > I suggest having a reference to draft-ietf-appsawg-rfc3462bis-04 > instead of RFC 3462 and removing the "(contrary to [REPORT])". I agree with the reference change, however the "contrary" part is correct b= ecause [REPORT] says the third MIME part in a report is optional, while for= this specific instance of it, we want it to be there. If it would help fo= r illustration, we could say "(contrary to [REPORT], which makes it optiona= l)". > In Section 3.2.1: >=20 > "Auth-Failure: Indicates the type of authentication failure that is > being reported. The list of valid values is enumerated in > Section 3.3." >=20 > What is being reported is the failure from an email authentication > method and not an "authentication failure". Fair enough. > In Section 3.2.2: >=20 > "policy: The message was not delivered to the intended inbox due > to authentication failure." >=20 > Please refer to my comment about the usage of "authentication failure". Yes. > Nits: >=20 > In Section 3.2.4: >=20 > '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=3D" tag; see Section 3.7 of [DKIM]= .' >=20 > I suggest replacing the word "bytes" with "octets" (RFC 6376). OK. > "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.)" >=20 > 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. We actually had it the other way (as you suggest), and then changed it to t= his because we thought this description was more effective, i.e., having th= e strongest requirement first. > Section 5 is the IANA Considerations Section. The draft does not > contain a Section 7.6. Looks like they're hard references rather than soft ones. I'll get the aut= hor to fix it. > In Section 3.2.5: >=20 > "DKIM-ADSP-DNS: Includes the ADSP record discovered and applied by the > entity generating this report" >=20 > I suggest: >=20 > DKIM-ADSP-DNS It is the ADSP record used to obtain the ADSP result. How about: DKIM-ADSP-DNS: Includes the ADSP policy used to obtain the verifier's ADSP= result. ("record" suggests an RRTYPE, and there isn't one specific to ADSP) > I did not include a "MUST" as there is already one in Section 3.3 > (adsp). We didn't either. :-) > In Section 3.3: >=20 > "The list of defined authentication failure types" >=20 > Please refer to my previous comments about the usage of "authentication > failure". Agree. > "Supplementary data MAY be included in the form of [MAIL]-compliant > comments." >=20 > Why is there a "MAY"? SHOULD [NOT] and MUST [NOT] don't apply... :-) Is there a problem with "MAY" there? > There should be a normative reference to RFC 5234 given the ABNF in > Section 4. Wow, I don't know how I missed that one. We'll add it. > In Section 6.2: >=20 > "Perhaps the simplest means of mitigating this threat is to assert > that these reports should themselves be signed with something like > DKIM." >=20 > I suggest removing the "something like". I disagree, since one could also in theory use PGP or S/MIME for similar ef= fect. DKIM is just the most common example, and is actually in practical u= se in ARF terms. > From the example in Appendix B.1: >=20 > "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" >=20 > Isn't the Return-Path: mail header inserted before the Received: mail > headers? Quite right. > "For more information about this format please see > http://datatracker.ietf.org/doc/draft-ietf-marf-authfailure-report" >=20 > I suggest adding a comment for the RFC Editor to reference "this RFC". Yes, that would be the right thing to do. > "Policy-Action: none" >=20 > That field has not been defined. I suggest that the working group > reviews the example for correctness. Right, it should be removed. And given some other comments made within the= WG, we'll be revisiting the example before it goes to the IESG. Thanks again, -MSK From sm@elandsys.com Fri Dec 2 14:33:14 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59EC21F8B55; Fri, 2 Dec 2011 14:33:14 -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 WiKIR08BFrJD; Fri, 2 Dec 2011 14:33:13 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1991111E811A; Fri, 2 Dec 2011 14:33:13 -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 pB2MWumI026296; Fri, 2 Dec 2011 14:33:01 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1322865184; bh=w5/TQiK5YY1UywptS3iuX6cg0Qg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=EAw5ldH5pTegllBysRZxo1yrgYBd3PCzmXMNsOZwWyVDnUX6nIWTlMonxUtbHNVja rdk7WvA9zvyaIwrgOF+jCrHSPGc07GDWeUkdAIZubsiFG2UHBVxWSiJpeGMZX83y3+ jL34XDQOxxseT1UcBtQOYYLqlch83gswQShb+nxI= Message-Id: <6.2.5.6.2.20111202125832.08744c00@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 02 Dec 2011 14:25:44 -0800 To: apps-discuss@ietf.org, draft-ietf-marf-authfailure-report.all@tools.ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20111202075917.09d8d070@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Fri, 02 Dec 2011 14:33:35 -0800 Cc: marf@ietf.org Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 22:33:14 -0000 Hi Murray, At 12:39 02-12-2011, Murray S. Kucherawy wrote: >There will probably be a few people concerned about the >"authentication vs. authorization" matter, but I think RFC5451 dealt >with this reasonably well, and the field Agreed. >If it would help, we could add a reference to RFC5451 Section 1.5.2, >which talks about the differences and their effective union in this area. That may help if you want to avoid getting into a discussion about authentication v/s authorization. The draft already references RFC 5451 normatively. A reference could be added in the Introduction Section. >I suppose it's worded that way because we created a new report type >but had to make a number of changes to IANA registries to do so, >hence the plural. But it really is one omnibus extension action. I >don't have a preference as to wording; if the plural is confusing, >we can change it. It can be argued either way. The Abstract Section mentions "an extension report type to ARF". >The point of saying this is that RFC5965 allows for the absence or >presence of the field, but proscribes multiple instances of it. We >want to say, for this report type, that Original-Envelope-ID should >be there, further limiting the "absence" case. > >Perhaps changing the SHOULD to a MUST above is better? Yes. As an editorial comment, Section 3.2 of RFC 5965 uses two key words for the six header fields. Section 3.1 of this draft uses ten key words for six header fields. Imperatives should not only be used with care and sparingly; it also helps if the reader can easily identify what is required versus what is recommended. >The Source-IP is a key piece of information for reconstructing why >an SPF evaluation failed. It needs to be there if it's available, >or the failure report is basically incomplete. Your reply clarifies when the "SHOULD" does not apply. If it is a key piece of information which is necessary for interoperability, specify it as a requirement. >It is the same, except that RFC5965 makes it entirely optional. For >this report type, we want to see it at least once. There could be an explanation about that in the draft. >I agree with the reference change, however the "contrary" part is >correct because [REPORT] says the third MIME part in a report is >optional, while for this specific instance of it, we want it to be >there. If it would help for illustration, we could say "(contrary >to [REPORT], which makes it optional)". Ok. >We actually had it the other way (as you suggest), and then changed >it to this because we thought this description was more effective, >i.e., having the strongest requirement first. Ok. >How about: > > DKIM-ADSP-DNS: Includes the ADSP policy used to obtain the > verifier's ADSP result. > >("record" suggests an RRTYPE, and there isn't one specific to ADSP) I used "record" as that is the term I found in RFC 5617. The above sounds Ok. >SHOULD [NOT] and MUST [NOT] don't apply... :-) > >Is there a problem with "MAY" there? No. :-) >I disagree, since one could also in theory use PGP or S/MIME for >similar effect. DKIM is just the most common example, and is >actually in practical use in ARF terms. Ok. >Right, it should be removed. And given some other comments made >within the WG, we'll be revisiting the example before it goes to the IESG. Please note that the review is semi-formal. The Application Area Directors may or may not agree with me about the issues identified in the review. Regards, S. Moonesamy From shmuel+gen@patriot.net Sat Dec 3 18:57:00 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6042021F91AB for ; Sat, 3 Dec 2011 18:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 qDqvZ4WG1Ujv for ; Sat, 3 Dec 2011 18:56:59 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id BE65B21F8E4E for ; Sat, 3 Dec 2011 18:56:59 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.217]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 95FECF58089 for ; Sat, 3 Dec 2011 21:44:12 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sat, 03 Dec 2011 21:56:34 -0500 To: marf@ietf.org In-Reply-To: <6.2.5.6.2.20111202125832.08744c00@resistor.net> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111204024413.95FECF58089@smtp.patriot.net> Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 02:57:00 -0000 In <6.2.5.6.2.20111202125832.08744c00@resistor.net>, on 12/02/2011 at 02:25 PM, S Moonesamy said: >It can be argued either way. The Abstract Section mentions "an >extension report type to ARF". How about making it singular but adding a phrase "affecting multiple registries"? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Sun Dec 4 11:07:08 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6696121F8997 for ; Sun, 4 Dec 2011 11:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.675 X-Spam-Level: X-Spam-Status: No, score=-102.675 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 rRAVtI0eSkXI for ; Sun, 4 Dec 2011 11:07:07 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id CE3B121F886A for ; Sun, 4 Dec 2011 11:07:07 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 4 Dec 2011 11:06:56 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sun, 4 Dec 2011 11:06:56 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Sun, 4 Dec 2011 11:06:59 -0800 Thread-Topic: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 Thread-Index: AcyyMHQBdp/BNRr0R0KD2Tga8CoZsQAh2dxA Message-ID: References: <6.2.5.6.2.20111202125832.08744c00@resistor.net> <20111204024413.95FECF58089@smtp.patriot.net> In-Reply-To: <20111204024413.95FECF58089@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 19:07:08 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Saturday, December 03, 2011 6:57 PM > To: marf@ietf.org > Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-auth= failure-report-05 >=20 > In <6.2.5.6.2.20111202125832.08744c00@resistor.net>, on 12/02/2011 > at 02:25 PM, S Moonesamy said: >=20 > >It can be argued either way. The Abstract Section mentions "an > >extension report type to ARF". >=20 > How about making it singular but adding a phrase "affecting multiple > registries"? That would probably be fine too. From hfontana@ecertsystems.com Mon Dec 5 09:20:42 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F6411E80A4 for ; Mon, 5 Dec 2011 09:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.638 X-Spam-Level: X-Spam-Status: No, score=0.638 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] 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 Nb0Qfj+enzRI for ; Mon, 5 Dec 2011 09:20:42 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B449411E80A2 for ; Mon, 5 Dec 2011 09:20:41 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1705907vbb.31 for ; Mon, 05 Dec 2011 09:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hkATKhfSxWpfT4SXze8Er6bx3vw3d2oA4+41n1qR5ZE=; b=RhNUBODIbFQFNThh4r3+rkfqskE+vYUiWKflquGSy7h4PQYQMX8sVANfFqFyN1Ku8e 4Zl/OSlb2nliuIX1CztyWkmK3V91AWr8eDakc3vHKFRGx8DYeIEfTRR40dOJxBAT71wr +gPtfUQP0bRBFC+m3jfqDe3hvjRTWMeq9POJQ= Received: by 10.52.77.69 with SMTP id q5mr5928753vdw.11.1323105640911; Mon, 05 Dec 2011 09:20:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.28.7 with HTTP; Mon, 5 Dec 2011 09:20:19 -0800 (PST) In-Reply-To: <4ED8CADD.3070809@tana.it> References: <20111202000021.21241.16968.idtracker@ietfa.amsl.com> <4ED8CADD.3070809@tana.it> From: Hilda Fontana Date: Mon, 5 Dec 2011 09:20:19 -0800 Message-ID: To: Alessandro Vesely Content-Type: multipart/alternative; boundary=20cf307f3834ba129104b35b89d2 Cc: marf@ietf.org Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:20:43 -0000 --20cf307f3834ba129104b35b89d2 Content-Type: text/plain; charset=ISO-8859-1 Thanks Alessandro I'll take a look On Fri, Dec 2, 2011 at 4:55 AM, Alessandro Vesely wrote: > On 02/Dec/11 01:00, internet-drafts@ietf.org wrote: > > Filename : draft-ietf-marf-authfailure-report-05.txt > > I still have some problems with the example. It seems that ".com" and > ".net" were swapped at least in one place, and in any case it is > difficult to avoid confusion with them. Perhaps it's me, but wouldn't > it be possible to replace the domain names (tentatively) like so? > > s/example.com/originator.example/ > s/example.net/verifier-reporter.example/ > > Specific nits in the text/rfc822-headers (3rd) part are as follows: > > * There is no "To:" header field, > > * the topmost Received has ".com" and ".net" swapped, > > * there are more than three minutes between internal servers > handling, and they are inconsistent with the Date field. I'd > change those lines with, say, > > Received: from anexample.example.com ([192.0.2.1]) > by mta1011.mail.tp2.example.net with ESMTP > Sat, 08 Oct 2011 04:16:24 -0700 (PDT) > Received: from internal-client-001.example.com > by mail.example.com (an alias for anexample) > with SMTP id o3F3BwdY028431; > Sat, 08 Oct 2011 04:16:23 -0700 (PDT) > Date: Sat, 8 Oct 2011 09:16:23 -0400 (EDT) > > * the DKIM-Signature has d=example.net rather than d=example.com, and > > * the A-R field misses a semicolon at the end of the first line while > the second line conflates two methods. I'd rewrite it taking three > lines, e.g. > > Authentication-Results: mta1011.mail.tp2.example.net; > spf=pass smtp.mailfrom=anexample.example.com; > dkim=fail (bodyhash) header.d=examle.com; > > For the second part, this should instead be > > Authentication-Results: mta1011.mail.tp2.example.net; > dkim=fail (bodyhash) header.d=examle.com; > > Also in the second part, where would Reported-URI be derived from? > > Then, the report would be sent from the verifier/reporter back to > example.com. Instead, the outermost "Received:" field is "from > mail.example.com by mx.example.net". The IP address 192.0.2.1 doesn't > seem to belong here. Do we need an outermost Received field? If the > intent is to exemplify a generated but not yet sent report, it can be > omitted as well as Return-Path and Authentication-Results. If not, > I'd also add a DKIM-Signature. > > One more nit, there is an unbalanced parenthesis in the last line of > the second paragraph of 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]. > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > -- Hilda L Fontana VP, Technology eCert, Inc. One Market Street, Suite 3600 San Francisco, CA 94105 p: 626.676.8852 f: 415.651.8932 **eCert - Trust the MessageTM *www.ecertsystems.com* * * ---------------------------------------- CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments is CONFIDENTIAL and is intended only for the use of the addressee. Any unauthorized use, disclosure, distribution, dissemination, or copying is strictly prohibited and may be unlawful. If you are not the intended recipient, you are prohibited from any further viewing of the e-mail or any attachments or from making any use of the e-mail or attachments. If you believe you have received this e-mail in error, please notify us immediately and permanently delete the e-mail, any attachments, and all copies from any drives or storage media and destroy any printouts of the e-mail or attachments and any copies of such printouts. Thank you for your cooperation. --20cf307f3834ba129104b35b89d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Alessandro I'll take a look

O= n Fri, Dec 2, 2011 at 4:55 AM, Alessandro Vesely <vesely@tana.it> wrote:
On 02/Dec/11 01:00, internet-dr= afts@ietf.org wrote:
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-marf-authfailure-repo= rt-05.txt

I still have some problems with the example. =A0It seems that ".com&qu= ot; and
".net" were swapped at least in one place, and in any case it is<= br> difficult to avoid confusion with them. =A0Perhaps it's me, but wouldn&= #39;t
it be possible to replace the domain names (tentatively) like so?

=A0s/= example.com/originator.example/
=A0s/example.net/verifier-reporter.example/

Specific nits in the text/rfc822-headers (3rd) part are as follows:

* There is no "To:" header field,

* the topmost Received has ".com" and ".net" swapped,
* there are more than three minutes between internal servers
=A0handling, and they are inconsistent with the Date field. =A0I'd
=A0change those lines with, say,

=A0 Received: from anexample.example.com ([192.0.2.1])
=A0 =A0by mta1011.mail.tp2.example.net with ESMTP
=A0 =A0Sat, 08 Oct 2011 04:16:24 -0700 (PDT)
=A0 Received: from internal-client-001.example.com
=A0 =A0by mail.examp= le.com (an alias for anexample)
=A0 =A0with SMTP id o3F3BwdY028431;
=A0 =A0Sat, 08 Oct 2011 04:16:23 -0700 (PDT)
=A0 Date: Sat, 8 Oct 2011 09:16:23 -0400 (EDT)

* the DKIM-Signature has d=3Dexample.net rather than d=3Dexample.com, and

* the A-R field misses a semicolon at the end of the first line while
=A0the second line conflates two methods. =A0I'd rewrite it taking thr= ee
=A0lines, e.g.

=A0 Authentication-Results: mta1011.mail.tp2.example.net;
=A0 =A0spf=3Dpass smtp.mailfrom=3Danexample.example.com;
=A0 =A0dkim=3Dfail (bodyhash) header.d=3Dexamle.com;

For the second part, this should instead be

=A0 Authentication-Results: mta1011.mail.tp2.example.net;
=A0 =A0dkim=3Dfail (bodyhash) header.d=3Dexamle.com;

Also in the second part, where would Reported-URI be derived from?

Then, the report would be sent from the verifier/reporter back to
example.com. =A0Instea= d, the outermost "Received:" field is "from
mail.example.com = by mx.example.net&q= uot;. =A0The IP address 192.0.2.1 doesn't
seem to belong here. =A0Do we need an outermost Received field? =A0If the intent is to exemplify a generated but not yet sent report, it can be
omitted as well as Return-Path and Authentication-Results. =A0If not,
I'd also add a DKIM-Signature.

One more nit, there is an unbalanced parenthesis in the last line of
the second paragraph of Section 3.2.4

=A0DKIM-Canonicalized-Body: =A0A base64 encoding of the canonicalized body<= br> =A0 =A0of the message as generated by the verifier. =A0The encoded content=
=A0 =A0MUST be limited to those bytes that contribute to the DKIM body
=A0 =A0hash (i.e., the value of the "l=3D" tag; see Section 3.7 = of [DKIM].
_________________________________________= ______
marf mailing list
marf@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/marf



--
Hilda L Fontana
VP, Technology=A0
eCert, Inc.
One Market Street, Suite 3600
San Francisco, CA 94105
p: 626.676.8852
f:=A0 415.651.8932
=A0
=A0
eCert - Trust=A0the MessageTM=A0
=A0
----------------------------------------
=A0
CONFIDENTIALITY NOTICE
=A0
The information contained in this= =20 e-mail and any attachments is CONFIDENTIAL and is intended only for the=20 use of the addressee. Any unauthorized use, disclosure, distribution,=20 dissemination, or copying is strictly prohibited and may be unlawful. If you are not the intended recipient, you are prohibited from any further viewing of the e-mail or any attachments or from making any use of the=20 e-mail or attachments. If you believe you have received this e-mail in=20 error, please notify us immediately and permanently delete the e-mail,=20 any attachments, and all copies from any drives or storage media and=20 destroy any printouts of the e-mail or attachments and any copies of=20 such printouts. Thank you for your cooperation.
=A0

--20cf307f3834ba129104b35b89d2-- From hfontana@ecertsystems.com Mon Dec 5 09:25:10 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0816711E80B4 for ; Mon, 5 Dec 2011 09:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=1.807, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 caij1CMyCm6y for ; Mon, 5 Dec 2011 09:25:09 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC8211E80B1 for ; Mon, 5 Dec 2011 09:25:08 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1710740vbb.31 for ; Mon, 05 Dec 2011 09:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qoEL6wdUjNzYiqNN2OyPW6VekYFrVR66jlHolQ/73Z8=; b=dCVd16Zzh6HT11PS7S/ZxcECNjRKvOa1bZl7IUz+8QHuA2BlXwddHDtu6/QqPFL3iS IGCIViDirKZl0Jp2f80H1Rj0akIO4P5L2qzg51NC6RDu45OWxoeyJW6vsENjWdF5r4dO 6Ug8C+C5bqxZRxl/rM8ClPXq4POyXajbMAwgk= Received: by 10.52.77.69 with SMTP id q5mr5945494vdw.11.1323105908438; Mon, 05 Dec 2011 09:25:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.28.7 with HTTP; Mon, 5 Dec 2011 09:24:46 -0800 (PST) In-Reply-To: References: <6.2.5.6.2.20111202125832.08744c00@resistor.net> <20111204024413.95FECF58089@smtp.patriot.net> From: Hilda Fontana Date: Mon, 5 Dec 2011 09:24:46 -0800 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=20cf307f3834ac360604b35b9950 Cc: Message Abuse Report Format working group Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:25:10 -0000 --20cf307f3834ac360604b35b9950 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Dec 4, 2011 at 11:06 AM, Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Shmuel Metz > > Sent: Saturday, December 03, 2011 6:57 PM > > To: marf@ietf.org > > Subject: Re: [marf] [apps-discuss] APPSDIR review of > draft-ietf-marf-authfailure-report-05 > > > > In <6.2.5.6.2.20111202125832.08744c00@resistor.net>, on 12/02/2011 > > at 02:25 PM, S Moonesamy said: > > > > >It can be argued either way. The Abstract Section mentions "an > > >extension report type to ARF". > > > > How about making it singular but adding a phrase "affecting multiple > > registries"? > > >That would probably be fine too. > ok so ... an extension report type to ARF affecting multiple entries for use in reporting messages that fail one or more authentication checks performed on receipt of a message... would that work? > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > --20cf307f3834ac360604b35b9950 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Dec 4, 2011 at 11:06 AM, Murray S. Kuche= rawy <msk@cloudma= rk.com> wrote:
> -----Original Message-----
> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Shmuel Metz
> Sent: Saturday, December 03, 2011 6:57 PM
> To: marf@ietf.org
> Subject: Re: [marf] [apps-discuss] APPSDIR rev= iew of draft-ietf-marf-authfailure-report-05
>
> In <6.2.5.6.2.20111202125832.08744c00@resistor.net>, on 12/02/2011 > =A0 =A0at 02:25 PM, S Moonesamy <sm+ietf@elandsys.com> said:
>
> >It can be argued either way. =A0The Abstract Section mentions &quo= t;an
> >extension report type to ARF".
>
> How about making it singular but adding a phrase "affecting multi= ple
> registries"?

>That would probably be fine too.

ok so= =A0
... an extension report type to ARF
affecting multiple entries = for use in reporting messages
that fail one or more authentication chec= ks performed
on receipt of a message...

would that work?

_______________________________________________
marf mailing list
marf@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/marf

--20cf307f3834ac360604b35b9950-- From msk@cloudmark.com Mon Dec 5 10:00:46 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84BF11E8083 for ; Mon, 5 Dec 2011 10:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.661 X-Spam-Level: X-Spam-Status: No, score=-102.661 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 OsM2LDgJkGlW for ; Mon, 5 Dec 2011 10:00:45 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 62E4F11E809A for ; Mon, 5 Dec 2011 10:00:45 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 5 Dec 2011 10:00:45 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 5 Dec 2011 10:00:44 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 5 Dec 2011 10:00:44 -0800 Thread-Topic: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 Thread-Index: Acyzctb1CXQQGS4SSTS8jL6bfbUa6QABOaMg Message-ID: References: <6.2.5.6.2.20111202125832.08744c00@resistor.net> <20111204024413.95FECF58089@smtp.patriot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C153E4EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:00:46 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C153E4EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suggest putting commas around "affecting multiple registries", but otherw= ise it's fine. From: Hilda Fontana [mailto:hfontana@ecertsystems.com] Sent: Monday, December 05, 2011 9:25 AM To: Murray S. Kucherawy Cc: Message Abuse Report Format working group Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfa= ilure-report-05 On Sun, Dec 4, 2011 at 11:06 AM, Murray S. Kucherawy > wrote: > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bo= unces@ietf.org] On Behalf Of Shmuel Metz > Sent: Saturday, December 03, 2011 6:57 PM > To: marf@ietf.org > Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-auth= failure-report-05 > > In <6.2.5.6.2.20111202125832.08744c00@resistor.net>, on 12/02/2011 > at 02:25 PM, S Moonesamy > said: > > >It can be argued either way. The Abstract Section mentions "an > >extension report type to ARF". > > How about making it singular but adding a phrase "affecting multiple > registries"? >That would probably be fine too. ok so ... an extension report type to ARF affecting multiple entries for use in reporting messages that fail one or more authentication checks performed on receipt of a message... would that work? _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf --_000_F5833273385BB34F99288B3648C4F06F19C6C153E4EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I suggest= putting commas around “affecting multiple registries”, but oth= erwise it’s fine.

 

From:= Hil= da Fontana [mailto:hfontana@ecertsystems.com]
Sent: Monday, Dece= mber 05, 2011 9:25 AM
To: Murray S. Kucherawy
Cc: Messa= ge Abuse Report Format working group
Subject: Re: [marf] [apps-di= scuss] APPSDIR review of draft-ietf-marf-authfailure-report-05

 

On Sun, Dec 4, 2011 at 11:06 AM, Murray S. Kucherawy <msk@cloudmark.com> wrote:

> -----Original Message-----
> From= : marf-bounces@ietf.org [mailt= o:marf-bounces@ietf.org] On Be= half Of Shmuel Metz

> Sent= : Saturday, December 03, 2011 6:57 PM
> To: marf@ietf.org

> Subject: Re: [marf] [apps-discuss] APPSDIR= review of draft-ietf-marf-authfailure-report-05
>
> In <6.2.5.6.2.20= 111202125832.08744c00@resistor.net>, on 12/02/2011
>   &n= bsp;at 02:25 PM, S Moonesamy <= sm+ietf@elandsys.com> said:
>
> >It can be argued eit= her way.  The Abstract Section mentions "an
> >extension= report type to ARF".
>
> How about making it singular but= adding a phrase "affecting multiple
> registries"?

>That would probably be fine too.=


ok so 
... an extension re= port type to ARF
affecting multiple entries for use in reporting messag= es
that fail one or more authentication checks performed
on receipt= of a message...

would that work?


__= _____________________________________________
marf mailing list
marf@ietf.org
https://www.ietf.org/mailman= /listinfo/marf

 

= --_000_F5833273385BB34F99288B3648C4F06F19C6C153E4EXCHC2corpclo_-- From msk@cloudmark.com Mon Dec 5 13:22:04 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBDA11E80AC for ; Mon, 5 Dec 2011 13:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.657 X-Spam-Level: X-Spam-Status: No, score=-102.657 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 UJ4xewthR7Io for ; Mon, 5 Dec 2011 13:22:03 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id EF97711E8082 for ; Mon, 5 Dec 2011 13:22:00 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 5 Dec 2011 13:22:00 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 5 Dec 2011 13:22:00 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 5 Dec 2011 13:21:57 -0800 Thread-Topic: Protocol Action: 'The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages' to Full Standard (draft-ietf-appsawg-rfc3462bis-04.txt) Thread-Index: Acyzixqnw9vSUwsYQ2204cCNNurxNAACK9lQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_F5833273385BB34F99288B3648C4F06F19C6C153F2EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] FW: Protocol Action: 'The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages' to Full Standard (draft-ietf-appsawg-rfc3462bis-04.txt) X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:22:04 -0000 --_002_F5833273385BB34F99288B3648C4F06F19C6C153F2EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is the removal of the restriction on multipart/report (and thus, ARF) = that forces each message to contain a single report. It's the first step t= oward the SpamRep convergence charter requirement we have. --_002_F5833273385BB34F99288B3648C4F06F19C6C153F2EXCHC2corpclo_ Content-Type: message/rfc822 Received: from EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) by malice.corp.cloudmark.com (172.22.10.71) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 5 Dec 2011 12:18:51 -0800 Received: from mail.cloudmark.com (208.83.136.59) by ht1.cloudmark.com (172.22.10.80) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 5 Dec 2011 12:18:50 -0800 Received: from mail.ietf.org ?(mail.ietf.org [12.22.58.30]) by mail.cloudmark.com (8.14.3/8.14.3) with ESMTP id pB5KIoLw007127 for ; Mon, 5 Dec 2011 12:18:50 -0800 (envelope-from ietf-announce-bounces@ietf.org) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6B011E80F0; Mon, 5 Dec 2011 12:18:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E75511E80ED for ; Mon, 5 Dec 2011 12:18:33 -0800 (PST) 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 XBa3c3oHIi7B; Mon, 5 Dec 2011 12:18:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B8611E80CD; Mon, 5 Dec 2011 12:18:32 -0800 (PST) From: The IESG To: IETF-Announce CC: RFC Editor Sender: "ietf-announce-bounces@ietf.org" Date: Mon, 5 Dec 2011 12:18:32 -0800 Subject: Protocol Action: 'The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages' to Full Standard (draft-ietf-appsawg-rfc3462bis-04.txt) Thread-Topic: Protocol Action: 'The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages' to Full Standard (draft-ietf-appsawg-rfc3462bis-04.txt) Thread-Index: Acyzixqnw9vSUwsYQ2204cCNNurxNA== Message-ID: <20111205201832.19361.33750.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: EXCH-HTCAS901.corp.cloudmark.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-Exchange-Organization-SenderIdResult: Pass X-MS-Exchange-Organization-SCL: -1 X-MS-Exchange-Organization-PRD: ietf.org X-MS-TNEF-Correlator: received-spf: Pass (EXCH-HTCAS901.corp.cloudmark.com: domain of ietf-announce-bounces@ietf.org designates 12.22.58.30 as permitted sender) receiver=EXCH-HTCAS901.corp.cloudmark.com; client-ip=12.22.58.30; helo=mail.cloudmark.com; dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1323116316; bh=ZrBWTJIYaDrHUVoUDShRr5Y8mRFCs3+Lx3dXQKhiiKM=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=f2xz8STm5pH8ZLwM/miCnCuPps527MgJz90J0QoAHsU4wtV9O8o3gEHPJ+OkL6XoT OyX0T2uf7w06WQpmE1MLfDFNOY1F9Gm6aXu9B8s9L6LoOF3nKVmu2HsKEy9Sbftxlu 6H4hM4rFYBOIMeighr7O+KSx8Gj6OHCodODrWle0= errors-to: ietf-announce-bounces@ietf.org delivered-to: ietf-announce@ietfa.amsl.com x-spam-flag: NO x-virus-scanned: amavisd-new at amsl.com 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] x-original-to: ietf-announce@ietfa.amsl.com x-beenthere: ietf-announce@ietf.org x-mailman-version: 2.1.12 list-id: "IETF announcement list. No discussions." list-archive: list-post: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 The IESG has approved the following document: - 'The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages' (draft-ietf-appsawg-rfc3462bis-04.txt) as a Full Standard This document is the product of the Applications Area Working Group. The IESG contact persons are Pete Resnick and Peter Saint-Andre. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc3462bis/ Technical Summary=20 The multipart/report media type is a general "family" or "container" type=20 for electronic mail reports of any kind. Although this memo defines only=20 the use of the multipart/report media type with respect to delivery status= =20 reports, mail processing programs will benefit if a single media type is=20 used for all kinds of reports.=20 Practical experience has shown that the general requirement of having=20 that media type constrained to be used only as the outermost MIME=20 type of a message, while well-intentioned, has provided little operational= =20 benefit and actually limits such things as the transmission of multiple=20 administrative reports within a single overall message container. In=20 particular, it prevents one from forwarding a report as part of another=20 multipart MIME message.=20 This update removes that constraint. No other changes apart from=20 some editorial ones are made.=20 Working Group Summary=20 There was initially concern that the original requirement that multipart/re= port=20 be a top-level-only media type was done for a good reason, and that the=20 requirement should not be removed entirely. After some discussion, it seeme= d=20 that the right approach was to retain the requirement in the context of new= ly=20 generated DSNs, but to lift it in the more general case. This version of th= e=20 document does just that, by reference to the original DSN specifications, a= nd=20 that formulation has broad consensus.=20 Document Quality=20 Multipart/report is very widely implemented and deployed, and, in fact, it = has=20 been used in the form described herein, with the top-level constraint ignor= ed,=20 for years. Ned Freed, who is the expert reviewer for media types, has revie= wed=20 this update and is happy with it. The interoperability report that was used= to take 3462 to Draft was: http://www.ietf.org/iesg/implementation/report-rfc1891-1894.txt Personnel Barry Leiba is the Document Shepherd. Pete Resnick is the AD. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --_002_F5833273385BB34F99288B3648C4F06F19C6C153F2EXCHC2corpclo_-- From vesely@tana.it Tue Dec 6 00:50:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5AF21F8B39 for ; Tue, 6 Dec 2011 00:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 5pZX0vfusWFV for ; Tue, 6 Dec 2011 00:50:29 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6421F8B3A for ; Tue, 6 Dec 2011 00:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323161425; bh=ImMo3IHnk/d1MP9u0nU6XWcNUm3EX/PydLSj7uHj0RE=; l=603; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=StB6eYjJ7tEjQGWExcGTQ+Xp2zRJv8jpqKe+9HdADLOyMBGPxqOyFqnvPMBHDIbxh Od1RERNFPNkJvc7dVqIt+jAw5cgKVhGcmoOiBWV0zANlf1EXYIOT8DXkGUFmv52TeL ofH/L/Q7yik8od1fdU+Bjbqknp7m0XzbCSiHXTEc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 06 Dec 2011 09:50:25 +0100 id 00000000005DC039.000000004EDDD751.00005560 Message-ID: <4EDDD751.3070409@tana.it> Date: Tue, 06 Dec 2011 09:50:25 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Hilda Fontana References: <6.2.5.6.2.20111202125832.08744c00@resistor.net> <20111204024413.95FECF58089@smtp.patriot.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: marf@ietf.org Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 08:50:30 -0000 On 05/Dec/11 18:24, Hilda Fontana wrote: > > > ok so > ... an extension report type to ARF > affecting multiple entries for use in reporting messages > that fail one or more authentication checks performed > on receipt of a message... > > would that work? Excuse me if this question is trivial, but doesn't the verb "to report a message" imply that the message was received? This is also present in the current wording: reporting messages that fail one or more authentication checks performed on receipt of a message Would "performed on their reception" be grammatically better? From shmuel+gen@patriot.net Tue Dec 6 03:05:29 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEF421F8B1B for ; Tue, 6 Dec 2011 03:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 t4whuO+PKuGK for ; Tue, 6 Dec 2011 03:05:28 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id DC44721F89B8 for ; Tue, 6 Dec 2011 03:05:28 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.222]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 0F333F58093 for ; Tue, 6 Dec 2011 05:52:40 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 06 Dec 2011 05:55:27 -0500 To: marf@ietf.org In-Reply-To: <4EDDD751.3070409@tana.it> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111206105241.0F333F58093@smtp.patriot.net> Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 11:05:29 -0000 In <4EDDD751.3070409@tana.it>, on 12/06/2011 at 09:50 AM, Alessandro Vesely said: >Excuse me if this question is trivial, but doesn't the verb "to >report a message" imply that the message was received? How about Abstract This memo registers an extension report type to ARF, affecting multiple IETF registries, for use in reporting attempts to send messages that fail one or more authentication checks performed on receipt of a message, with the option to include forensic information describing the specifics of the failure. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Tue Dec 6 10:04:59 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D0421F8BAA for ; Tue, 6 Dec 2011 10:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 q80I3wiFSpTF for ; Tue, 6 Dec 2011 10:04:58 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id E354321F8B94 for ; Tue, 6 Dec 2011 10:04:58 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 6 Dec 2011 10:04:58 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 6 Dec 2011 10:04:58 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 6 Dec 2011 10:04:57 -0800 Thread-Topic: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 Thread-Index: Acyz9B4LIchE988HSN6BHymGllLgkwATRynw Message-ID: References: <6.2.5.6.2.20111202125832.08744c00@resistor.net> <20111204024413.95FECF58089@smtp.patriot.net> <4EDDD751.3070409@tana.it> In-Reply-To: <4EDDD751.3070409@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 18:04:59 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Tuesday, December 06, 2011 12:50 AM > To: Hilda Fontana > Cc: marf@ietf.org > Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-auth= failure-report-05 >=20 > On 05/Dec/11 18:24, Hilda Fontana wrote: > > ... an extension report type to ARF > > affecting multiple entries for use in reporting messages that fail one > > or more authentication checks performed on receipt of a message... > > > > would that work? >=20 > Excuse me if this question is trivial, but doesn't the verb "to report > a message" imply that the message was received? This is also present > in the current wording: >=20 > reporting messages that fail one or more authentication checks > performed on receipt of a message >=20 > Would "performed on their reception" be grammatically better? "to report a message" indicates intent, and "on receipt of a message" state= s clearly when it is intended that this be used. Otherwise, you could repo= rt a message long after receipt occurs (for some reason). If we're really keen to common factor the language, we could use: "...an extension report type to ARF, affecting multiple registries, for use= in generating receipt-time reports about messages that fail one or more em= ail authentication checks." From msk@cloudmark.com Tue Dec 6 12:38:36 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1452721F8500 for ; Tue, 6 Dec 2011 12:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0FeASOWpdKUp for ; Tue, 6 Dec 2011 12:38:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9638621F8477 for ; Tue, 6 Dec 2011 12:38:24 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 6 Dec 2011 12:38:24 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 6 Dec 2011 12:38:24 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 6 Dec 2011 12:38:23 -0800 Thread-Topic: Working group status Thread-Index: Acy0Vv9jEXqZme6XThmAj8RIK6mRGQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C1542AEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:38:36 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C1542AEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Your co-chairs have been re-evaluating our progress as a working group, con= cerned with our declining productivity and lack of substantive and timely d= ocument reviews. We're wondering if there's still interest in continuing t= his work, or if we should start the process of spinning down. Here's where we're at on our current deliverables: - ARF applicability statement: exists, but no recent activity - Auth-failure report format: Completed two Last Calls; awaiting a= (hopefully final) round of edits - DKIM reporting: exists, but no recent activity - Redaction draft: In IETF last call until 12/15 - Reporting discovery: exists, but no recent activity - SPF reporting: exists, but no recent activity - SpamRep convergence plan: none We feel that SpamRep has fallen out of favour on the OMA side. Their worki= ng group's chair considers the activity "stalled" as there have been no imp= lementation reports since they published their candidate specification. It= doesn't make much sense for us to expend energy to figure out a convergenc= e plan given this, plus we have not been successful at identifying a champi= on in MARF for that work. Thus, we don't believe it's practical for MARF t= o pursue this deliverable. So by way of taking the pulse of the working group, here are some questions= about what's left: For draft-ietf-marf-as: Do we feel we want to simply endorse the use of ARF as it is defined in RFC= 5965 and RFC6449, or do we wish to give different operational advice than w= hat they say? In the absence of any of the latter, the former is low-hangi= ng fruit, which means we can close out that charter item rather easily. Bu= t it has to reflect consensus either way. For draft-ietf-marf-authfailure-report: This last round of edits should be enough to send it to the IESG. For draft-ietf-marf-dkim-reporting: I would like to revisit this once more, especially based on J= ohn and Steve's feedback from about a month ago. I'll do so in a separate = thread. I've found this work to be very helpful in the last several years = and it would be helpful to write down a way to do what it's trying to do, e= ven if different from what was originally developed. Is there interest in h= elping me to do so? If the working group doesn't wish to pursue this at all, it can = be returned to an individual submission for publication via that route. For draft-ietf-marf-reporting-discovery: Does the working group feel this work is useful to pursue? If so, is there= someone willing to step forward and act as editor? For draft-ietf-marf-spf-reporting: Does the working group feel this work is useful to pursue? If not, we will= suggest it be added to the proposed charter for SPFBIS or a future version= of it. Thanks, -MSK, as co-chair --_000_F5833273385BB34F99288B3648C4F06F19C6C1542AEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,<= /o:p>

 

You= r co-chairs have been re-evaluating our progress as a working group, concer= ned with our declining productivity and lack of substantive and timely docu= ment reviews.  We’re wondering if there’s still interest i= n continuing this work, or if we should start the process of spinning down.=

 

Here’s where we’re at on our current deliverables:

 

<= span style=3D'mso-list:Ignore'>--      &nbs= p;   Auth-failure report format: Complete= d two Last Calls; awaiting a (hopefully final) round of edits

-       &n= bsp;  DKIM reporting: exists, but no recent ac= tivity

-    =       Redaction draft: In = IETF last call until 12/15

-&nb= sp;         Reporting discovery: exists, but no recent activity

-         = ; SPF reporting: exists, but no recent activity

-     &nbs= p;    SpamRep convergence plan: none=

 

We feel that SpamRep has fallen out of favour on the OMA side.  The= ir working group’s chair considers the activity “stalled”= as there have been no implementation reports since they published their ca= ndidate specification.  It doesn’t make much sense for us to exp= end energy to figure out a convergence plan given this, plus we have not be= en successful at identifying a champion in MARF for that work.  Thus, = we don’t believe it’s practical for MARF to pursue this deliver= able.

 

So by way of taking the pulse of the working group, here are some q= uestions about what’s left:

&= nbsp;

For draft-ietf-marf-as:

<= p class=3DMsoNormal>Do we feel we want to simply endorse the use of ARF as = it is defined in RFC5965 and RFC6449, or do we wish to give different opera= tional advice than what they say?  In the absence of any of the latter= , the former is low-hanging fruit, which means we can close out that charte= r item rather easily.  But it has to reflect consensus either way.

 

F= or draft-ietf-marf-authfailure-report:

T= his last round of edits should be enough to send it to the IESG.=

 

For draf= t-ietf-marf-dkim-reporting:

<particip= ant> I would like to revisit this once more, especially based on John an= d Steve’s feedback from about a month ago.  I’ll do so in = a separate thread.  I’ve found this work to be very helpful in t= he last several years and it would be helpful to write down a way to do wha= t it’s trying to do, even if different from what was originally devel= oped. Is there interest in helping me to do so? </participant>

<co-chair> If the working group doesn= 217;t wish to pursue this at all, it can be returned to an individual submi= ssion for publication via that route. </co-chair>

 

For draft-ietf-ma= rf-reporting-discovery:
Does the working group feel this work is useful = to pursue?  If so, is there someone willing to step forward and act as= editor?

 

For draft-ietf-marf-spf-reporting:

Does the working group feel this work is useful to pursue?  If= not, we will suggest it be added to the proposed charter for SPFBIS or a f= uture version of it.

 

Thanks,

-MSK, as = co-chair

 

= --_000_F5833273385BB34F99288B3648C4F06F19C6C1542AEXCHC2corpclo_-- From sklist@kitterman.com Tue Dec 6 12:45:11 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246211F0C58 for ; Tue, 6 Dec 2011 12:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 51hqVpkgZb7J for ; Tue, 6 Dec 2011 12:45:10 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EF3CF1F0C50 for ; Tue, 6 Dec 2011 12:45:08 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2AA7B20E4100; Tue, 6 Dec 2011 15:45:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1323204308; bh=fLL9IpO7o06TwSlQ/DywWFafUG9jRA219N8WXiKbfCU=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lsJWPAh6v0ygiI7LPBeFmnWTljxIy+6KvTLAV04TQ5a5tN/AvoZbiDU3L1WoZ7Hhs 5Y31t8wcGh88D03VQEluCuv7XkomdS9bw8Ol5CuRdzhAKUQJ6Bp9a0sLUGKgFnAO2H JjOzkdR9DSv6ThvjQ8gwXncIMfF4VDJ6Shyx3aio= Received: from [10.59.26.48] (unknown [66.39.207.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D0CB620E4083; Tue, 6 Dec 2011 15:45:07 -0500 (EST) Message-ID: <4EDE7ED2.3090401@kitterman.com> Date: Tue, 06 Dec 2011 15:45:06 -0500 From: Scott Kitterman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 20:45:11 -0000 On 12/06/2011 03:38 PM, Murray S. Kucherawy wrote: > For draft-ietf-marf-spf-reporting: Does the working group feel this > work is useful to pursue? If not, we will suggest it be added to the > proposed charter for SPFBIS or a future version of it. I think it has value. I haven't updated the draft because it didn't seem fruitful. Things I'm waiting for: draft-ietf-marf-authfailure-report: Waiting for the final post-last call draft - since I'm waiting on the SPFbis situation to clarify a bit, my intent was to wait until this draft was also ~final so I'd have a stable base to work from. SPFbis: I'm waiting for the charter discussion to settle out so that I know how to deal with the downref issue to RFC 4408. If the charter lands the way I think it will, I think allowing a downref is justifiable. Given those, I expect I can get another draft out in the next few weeks if the WG is interested in pursuing it. Scott K From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Dec 7 08:48:55 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566D721F8B20 for ; Wed, 7 Dec 2011 08:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.169 X-Spam-Level: X-Spam-Status: No, score=-103.169 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 nxmQ12mwZqng for ; Wed, 7 Dec 2011 08:48:54 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B9E7B21F8512 for ; Wed, 7 Dec 2011 08:48:50 -0800 (PST) Received: by dajz8 with SMTP id z8so1016467daj.31 for ; Wed, 07 Dec 2011 08:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=B9HM+yQn7KzCnj18R0vQH+E9cXpt7Jbra2HpUDmSpXw=; b=SzH1aUMQw7LTwbfx7GqYJpOpeYkz5qiHpcOjchmYswxZDDe4ZMM5+GS2sa7MJqPbmP 68r7AxdlW69n6jlsYFJG5h9soA9Jmj3rLEu1t3pp3Yb/BtUtHqB4XEaBykuFhLFJRAXi G6OHSdKYmmGZz1KwD47EBOpgQDzlnALC10BZA= Received: by 10.68.25.199 with SMTP id e7mr6608551pbg.123.1323276530502; Wed, 07 Dec 2011 08:48:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.11.10 with HTTP; Wed, 7 Dec 2011 08:48:09 -0800 (PST) In-Reply-To: References: From: Frank Ellermann Date: Wed, 7 Dec 2011 17:48:09 +0100 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 16:48:55 -0000 On 6 December 2011 21:38, Murray S. Kucherawy wrote: > For draft-ietf-marf-dkim-reporting: [...] > If the working group doesn=92t wish to pursue this at all, > it can be returned to an individual submission for publication via > that route. It is rather strange to close a WG when an almost-ready I-D exists, a recent example was YAM and 5321bis. OTOH I'm not competent to say much about DKIM ARF, excluding editorial ABNF nits or similar issues. As long as Barry is willing to shepherd your DKIM I-D here go for it. > For draft-ietf-marf-spf-reporting: When you asked who is willing to implement it, did you ever get a response`? Obviously Scott would, otherwise he wouldn't bother to specify it. For any SPF modifier there are general considerations: - If potential users already have the required info as part of an SPF policy in an DNS cache they don't need convoluted additional "discovery" or "query" procedures. That's good. - If potential policy publishers are already very near to practical EDNS0 limits adding more info could make it worse. - For new modifiers it should be clear that their introduction has no effect on existing old SPF policies without this new modifier. As soon as there is more than one RFC talking about "SPF modifiers" there should be a third RFC defining a registry for "SPF modifiers" before it gets out of hand. As far as MARF is concerned, could SPF and DKIM reporting also be merged, or would that upset parts of the intended audience? -Frank From sklist@kitterman.com Wed Dec 7 09:21:54 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE51821F8C89 for ; Wed, 7 Dec 2011 09:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 hKiod+2x9KlS for ; Wed, 7 Dec 2011 09:21:53 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 35F0F21F8C81 for ; Wed, 7 Dec 2011 09:21:53 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4AF6320E4100; Wed, 7 Dec 2011 12:21:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1323278512; bh=RM6dEQx8OkLqLSZsKNn2D0AWWLAvbcP/dTc0qSdibb0=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ibj3xDritrAfqV4QeYSNjAE2A2ub/I0ddGV8vOdyoRQv88Kf7pXclcjtXJFXzzbR5 wSUiqlLTxspY3Azt1NH1UyCZ0HugtEBm5k3hZzY7LZtvejFccrWwi38Y8oh1X8V17q pxb0vtWQxQU/lFssHvIJ0lIhP2yjmlfuIcBIWfTI= Received: from [192.168.42.73] (50.sub-97-186-166.myvzw.com [97.186.166.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 93E3720E4043; Wed, 7 Dec 2011 12:21:51 -0500 (EST) Message-ID: <4EDFA0AD.9020607@kitterman.com> Date: Wed, 07 Dec 2011 12:21:49 -0500 From: Scott Kitterman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 17:21:54 -0000 On 12/07/2011 11:48 AM, Frank Ellermann wrote: > On 6 December 2011 21:38, Murray S. Kucherawy wrote: > >> For draft-ietf-marf-dkim-reporting: > [...] >> If the working group doesn’t wish to pursue this at all, >> it can be returned to an individual submission for publication via >> that route. > > It is rather strange to close a WG when an almost-ready I-D exists, > a recent example was YAM and 5321bis. OTOH I'm not competent to say > much about DKIM ARF, excluding editorial ABNF nits or similar issues. > As long as Barry is willing to shepherd your DKIM I-D here go for it. > >> For draft-ietf-marf-spf-reporting: > > When you asked who is willing to implement it, did you ever get a > response`? Obviously Scott would, otherwise he wouldn't bother to > specify it. For any SPF modifier there are general considerations: > > - If potential users already have the required info as part of an > SPF policy in an DNS cache they don't need convoluted additional > "discovery" or "query" procedures. That's good. > - If potential policy publishers are already very near to practical > EDNS0 limits adding more info could make it worse. > - For new modifiers it should be clear that their introduction has > no effect on existing old SPF policies without this new modifier. > > As soon as there is more than one RFC talking about "SPF modifiers" > there should be a third RFC defining a registry for "SPF modifiers" > before it gets out of hand. As far as MARF is concerned, could SPF > and DKIM reporting also be merged, or would that upset parts of the > intended audience? The current draft includes such a registry. I've seen a number of deployed cases where the data provided would have been very useful. I believe it will be implemented to assist in troubleshooting deployment problems (of which there is no shortage). We had a long discussion earlier in the year (or was it last year) about how the drafts should be split. I think it would have been fine to keep them all in one draft, but that wasn't the working group consensus. Given that, let's not mess with document splits again and just press to closure. Scott K From sm@resistor.net Wed Dec 7 09:46:37 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FC621F8BCD for ; Wed, 7 Dec 2011 09:46:37 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1smjIs-uqsMH for ; Wed, 7 Dec 2011 09:46:34 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDF021F8BB3 for ; Wed, 7 Dec 2011 09:46:34 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pB7HkQsj004896; Wed, 7 Dec 2011 09:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323279991; bh=iDjX+hio5uWVe7Wdnew/e4tyWuJRSjnCjNDaSr+X6Mo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=KpteTx+ngKzaMAXK7h3NkmD8KXWn66GSAJcLZeXKn9hk8NmnHcZl4WW272pm+n1v5 lKCKKw6r+KdEW5orm+sfUxcRwqmHW1gjmpU4NUfpAS6xB1zgxNHHuBw4V/2zTZ+4bz mHmtruLZIl+u9y13gFHykpdALbScE1PxWmAD288U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323279991; bh=iDjX+hio5uWVe7Wdnew/e4tyWuJRSjnCjNDaSr+X6Mo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=JMagbGf66Gw8WruVi8DCGkS8O2RvP0B6YomYSyIZ7ZWTJzbb82K85PWz2CMzTyQ+J 1I0lVIs06s8LH9RmB7F7XkxfFwaBeuvv8coDQexCrCzxXE/7YzFx8m69GiT4b84AYz f/KzD2ZccxZhi00/uFg7J4f/DpehyIekHjRqZrA4= Message-Id: <6.2.5.6.2.20111207091548.09e92c70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Dec 2011 09:43:16 -0800 To: Frank Ellermann From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 17:46:37 -0000 Hi Frank, At 08:48 07-12-2011, Frank Ellermann wrote: >It is rather strange to close a WG when an almost-ready I-D exists, The W generally implies "working". There was a WGLC on draft-ietf-marf-redaction. Six people, including the WG Chairs, commented on the draft. The WG co-chair commented [1] on the lack of substantive and timely document reviews. An almost-ready I-D is not good enough. The WG co-chairs have to demonstrate to the Responsible AD that the work is moving forward and that the deliverables are receiving adequate review to be ready for publication. Obviously, the WG co-chairs can only do that if the WG participants actually participate in the work. Regards, -sm 1. http://www.ietf.org/mail-archive/web/marf/current/msg01527.html From msk@cloudmark.com Wed Dec 7 09:56:58 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0352921F8C1A for ; Wed, 7 Dec 2011 09:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 8MkJEGDFFS5m for ; Wed, 7 Dec 2011 09:56:57 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 95C8021F8C00 for ; Wed, 7 Dec 2011 09:56:57 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Dec 2011 09:56:57 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 7 Dec 2011 09:56:56 -0800 From: "Murray S. Kucherawy" To: Frank Ellermann Date: Wed, 7 Dec 2011 09:56:56 -0800 Thread-Topic: [marf] Working group status Thread-Index: Acy1ABkeq5A0B5aKQeuOJoelJRX+NQACI5pA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 17:56:58 -0000 > -----Original Message----- > From: Frank Ellermann [mailto:hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com] > Sent: Wednesday, December 07, 2011 8:48 AM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: Re: [marf] Working group status >=20 > It is rather strange to close a WG when an almost-ready I-D exists, a > recent example was YAM and 5321bis. OTOH I'm not competent to say much > about DKIM ARF, excluding editorial ABNF nits or similar issues. > As long as Barry is willing to shepherd your DKIM I-D here go for it. The WG wouldn't close if there's active work on any of the drafts. My conc= ern is that there isn't. We have a pattern of asking for review comments, = not getting any, starting a working group last call, maybe getting some, th= en requesting through the AD an IETF-wide last call, and only then do we ge= t some feedback. We don't need a working group if the only meaningful phase of that cycle is= the IETF-wide last call. We get that automatically with AD-sponsored docu= ments. We wouldn't make a formal working group shutdown decision until all documen= ts that have received enough feedback to justify the push to publication ar= e in the IESG queue. But we're not going to wait for a bunch of work to ha= ppen if it looks like it won't. From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Dec 7 10:27:39 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9131821F8BDC for ; Wed, 7 Dec 2011 10:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.157 X-Spam-Level: X-Spam-Status: No, score=-103.157 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, 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 FL1lVm7g4mdZ for ; Wed, 7 Dec 2011 10:27:39 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1948921F8BD3 for ; Wed, 7 Dec 2011 10:27:39 -0800 (PST) Received: by dajz8 with SMTP id z8so1119285daj.31 for ; Wed, 07 Dec 2011 10:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=q2fWQQBAje1Jm0VtJ4v0ix8++aInI5A2un+HNo0PMMk=; b=dOZxvqDUsiq5z5x3ZxilAL/OvxwV3sPzJr7X0HLo7rEqx51arfevgWggIU3wGjxzFL HOU8psVpu8w+Mn2l/BkXkSSo1os0zzcEnyp3qB0YlQ+sH0yV7Obv1Xhqnetd9+ObWh1C lBLzSagq2H02jYoQunAMNKhKjQ+H6gNreszfE= Received: by 10.68.2.138 with SMTP id 10mr7680022pbu.55.1323282458860; Wed, 07 Dec 2011 10:27:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.11.10 with HTTP; Wed, 7 Dec 2011 10:26:53 -0800 (PST) In-Reply-To: <4EDFA0AD.9020607@kitterman.com> References: <4EDFA0AD.9020607@kitterman.com> From: Frank Ellermann Date: Wed, 7 Dec 2011 19:26:53 +0100 Message-ID: To: Scott Kitterman , SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 18:27:39 -0000 On 7 December 2011 18:21, Scott Kitterman wrote: > We had a long discussion earlier in the year (or was it last year) about > how the drafts should be split. =A0I think it would have been fine to kee= p > them all in one draft, but that wasn't the working group consensus. > Given that, let's not mess with document splits again and just press to > closure. ACK, I missed or forgot that, no problem. (Checking the archive, apparently my 1st comment was in August: ) On 7 December 2011 18:43, SM wrote: > An almost-ready I-D is not good enough. =A0The WG co-chairs have to > demonstrate to the Responsible AD that the work is moving forward > and that the deliverables are receiving adequate review to be ready > for publication. Well, there are three folks in the IETF where I'd automatically say yes when they agree on an I-D about "BiDi", RTL or LTR or bottom-up top-down boustrophedon. Likewise I'd trust that JohnL and Murray and Scott know what is good for the purposes of "abuse reporting". IOW, I see no advantages to switch this draft to "individual" now. Are you saying that you disagree, or did you only explain how this is supposed to work? -Frank From sm@resistor.net Wed Dec 7 11:25:58 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DDA21F8BE4 for ; Wed, 7 Dec 2011 11:25:58 -0800 (PST) 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=[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 6722O2LmvWSS for ; Wed, 7 Dec 2011 11:25:57 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC3C21F8BD8 for ; Wed, 7 Dec 2011 11:25:57 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pB7JPoMo022198; Wed, 7 Dec 2011 11:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323285955; bh=vWA6qAz/ePMxAqjmvMbXfnBqExhlQnlJ4XmjUC1+dN8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ZXUoDixI4ONTcZv8KiO/PG/844JjPt+JiOLGdgYVWVBGNJyzJ/Qv2RFbgeNHv/mn+ aYXcFTfEtl8kuX/UpJEoLizqkdR6C4PZssgLe1vJZQrn75PWqecQNCvkc4tdbidVMu cUu+k7XvlK7ilQKN/AXwMLY78LaZSeGPiG8Z959A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323285955; bh=vWA6qAz/ePMxAqjmvMbXfnBqExhlQnlJ4XmjUC1+dN8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=QQjHaqLAqDI79D/JoW1aN+vY8QH9/zzlWZ/qvhfX5ec7yw3ljTwQH/QTFHjO3XqZp Zgt/Ol/K6sWp5eYzJY6gs+LE3fLHa9zK5LR1mqLkTMvxiQHFpg4+A8x5wGyVIy3yFK t6paVOvkkiQ3TH9fmiRx9iNe2usWMwMTpYMOEh3I= Message-Id: <6.2.5.6.2.20111207104947.09eb4070@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Dec 2011 11:23:05 -0800 To: Frank Ellermann From: SM In-Reply-To: References: <4EDFA0AD.9020607@kitterman.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 19:25:58 -0000 Hi Frank, At 10:26 07-12-2011, Frank Ellermann wrote: >Are you saying that you disagree, or did you only explain how this >is supposed to work? Having only three people reviewing a draft is not how this is supposed to work. The work being done in this WG is easy. Each participants can help by putting in some time and effort to read the I-Ds and comment on them. Regards, -sm From msk@cloudmark.com Wed Dec 7 11:58:15 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E1311E80B8 for ; Wed, 7 Dec 2011 11:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 GBtKSPbzIRKD for ; Wed, 7 Dec 2011 11:58:15 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 59EE611E808B for ; Wed, 7 Dec 2011 11:58:15 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Dec 2011 11:58:15 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 7 Dec 2011 11:58:15 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 7 Dec 2011 11:58:13 -0800 Thread-Topic: [marf] Working group status Thread-Index: Acy1DesOt/NGbWEBRB+zdtGX9sy1UAAC22kw Message-ID: References: <4EDFA0AD.9020607@kitterman.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 19:58:15 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of F= rank Ellermann > Sent: Wednesday, December 07, 2011 10:27 AM > To: Scott Kitterman; SM > Cc: marf@ietf.org > Subject: Re: [marf] Working group status >=20 > IOW, I see no advantages to switch this draft to "individual" now. All of the MARF drafts are in one of two buckets: 1) The working group wants to finish what it started, in which case the doc= ument will continue where it is now until it proceeds to the IESG for publi= cation. 2) The working group doesn't care about the topic enough anymore to work on= it, in which case the document can find another home, either in another wo= rking group or as an individual submission, or perhaps in the independent s= tream, or the draft can simply expire. The working group will stay alive until the documents are all squarely in e= ither of those buckets, and all of the stuff in the first one has been sent= through the publication process. We're doing the "sorting" part now. -MSK From msk@cloudmark.com Wed Dec 7 12:01:09 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275041F0C43 for ; Wed, 7 Dec 2011 12:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Yy5OilXx+8yS for ; Wed, 7 Dec 2011 12:01:08 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 513B11F0C47 for ; Wed, 7 Dec 2011 12:01:08 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Dec 2011 12:01:07 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 7 Dec 2011 12:01:08 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 7 Dec 2011 12:01:07 -0800 Thread-Topic: Applicability statement Thread-Index: Acy1GvT8ZfbWBxGvR8q8kKT8hio3rg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C1547AEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Applicability statement X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 20:01:09 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C1547AEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a call for comments about draft-ietf-marf-as, and specifically for = review of RFC6449. The main question: Does the working group completely agree with what's in R= FC6449 (which is essentially a product of MAAWG and not the EITF), or do we= have any supplementary (even conflicting) operational experience or advice= for the community? This is what will go in an applicability statement. Either way, please comment on this thread. The replies here will feed inpu= t to draft-ietf-marf-as. Also, the document unfortunately needs a new editor. If anyone is interest= ed, please speak up. -MSK, as co-chair --_000_F5833273385BB34F99288B3648C4F06F19C6C1547AEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a call f= or comments about draft-ietf-marf-as, and specifically for review of RFC644= 9.

 

The main question: Does the working group completely agree with what&#= 8217;s in RFC6449 (which is essentially a product of MAAWG and not the EITF= ), or do we have any supplementary (even conflicting) operational experienc= e or advice for the community?  This is what will go in an applicabili= ty statement.

 

Either way, please comment on this thread.  The replie= s here will feed input to draft-ietf-marf-as.

 

Also, the document unfortun= ately needs a new editor.  If anyone is interested, please speak up.

 

-MSK, as co-chair

 

=
= --_000_F5833273385BB34F99288B3648C4F06F19C6C1547AEXCHC2corpclo_-- From msk@cloudmark.com Wed Dec 7 12:12:03 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBA511E80C3 for ; Wed, 7 Dec 2011 12:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YEXOlkezJlSz for ; Wed, 7 Dec 2011 12:12:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4668D21F8AD6 for ; Wed, 7 Dec 2011 12:12:01 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Dec 2011 12:12:00 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 7 Dec 2011 12:12:00 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 7 Dec 2011 12:12:00 -0800 Thread-Topic: DKIM reporting Thread-Index: Acy1HHo7mmQPiEBWTcKsqUJYguRd/Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C1547CEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] DKIM reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 20:12:03 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C1547CEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [as participant] As I've mentioned before, the idea of doing forensic reporting of messages = that fail DKIM verification has been a very valuable tool in terms of inter= operability testing between DKIM implementations. It's got value as well i= n showing signers how their mail is being altered in transit even when the = signer and verifier are working properly (i.e., unanticipated mangling en r= oute). What's in draft-ietf-marf-dkim-reporting is essentially what I've developed= and implemented almost since the beginning of the DKIM effort. The DKIM w= orking group didn't pick it up, but since the forensic reports themselves a= re actually ARF-based, I brought the work here. It used to be part of draf= t-ietf-marf-authfailure-report but was broken out into its own document at = (I think) our meeting in Maastricht. I haven't had much in the way of feedback on it except through targeted req= uests for reviews. When I finally got those, the suggestions I got were ra= dically different from what I've implemented. Given that, I'd like to invi= te the working group to consider it from the ground up in order to build so= mething that has consensus. So let's talk requirements. The idea is to enable a signer to request that= a verifier, on finding a message that fails verification testing, send a m= essage back showing the canonicalized forms of the header and body, the ide= a being that the signer would keep a copy of the same and thus be able to s= ee what changed in transit. The mechanism of advertising that this is want= ed needs to be simple and not add much burden to the existing system. (Tha= t's why I grafted it on to the key record in the DNS, which has to be retri= eved anyway.) The authfailure-report draft creates the syntax for the repo= rt, so this draft only needs to be able to communicate the request for the = report and its parameters. There are some obvious security considerations, such as being able to cause= a storm of report mail if a lot of mail goes out all of which fails to val= idate. The interval stuff is in there to make it possible for the signer t= o mitigate such damage. There's an adjunct ADSP angle, which requests a report if ADSP says "this s= hould be signed by the author domain" and it wasn't, even if all the signat= ures passed. The same requirements apply. I think it's really as simple as that. So if you don't like the dkim-reporting draft as it's written, how would yo= u design something within those requirements? I think Steve and John commented on this before. I'll go dig up their old = emails and comment on them as well, but I'll try to do so on this thread so= it's all in one place. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C1547CEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[as participant]=

 

As I’ve mentioned before, the idea of doing forensic reporting of = messages that fail DKIM verification has been a very valuable tool in terms= of interoperability testing between DKIM implementations.  It’s= got value as well in showing signers how their mail is being altered in tr= ansit even when the signer and verifier are working properly (i.e., unantic= ipated mangling en route).

 

What’s in draft-ietf-marf-dkim-reporting= is essentially what I’ve developed and implemented almost since the = beginning of the DKIM effort.  The DKIM working group didn’t pic= k it up, but since the forensic reports themselves are actually ARF-based, = I brought the work here.  It used to be part of draft-ietf-marf-authfa= ilure-report but was broken out into its own document at (I think) our meet= ing in Maastricht.

 

=

I haven’t had much in the way of feedback on it = except through targeted requests for reviews.  When I finally got thos= e, the suggestions I got were radically different from what I’ve impl= emented.  Given that, I’d like to invite the working group to co= nsider it from the ground up in order to build something that has consensus= .

 

So let’s talk requirements.  The idea is to enable a signer = to request that a verifier, on finding a message that fails verification te= sting, send a message back showing the canonicalized forms of the header an= d body, the idea being that the signer would keep a copy of the same and th= us be able to see what changed in transit.  The mechanism of advertisi= ng that this is wanted needs to be simple and not add much burden to the ex= isting system.  (That’s why I grafted it on to the key record in= the DNS, which has to be retrieved anyway.)  The authfailure-report d= raft creates the syntax for the report, so this draft only needs to be able= to communicate the request for the report and its parameters.


There are some obvious security considerations, = such as being able to cause a storm of report mail if a lot of mail goes ou= t all of which fails to validate.  The interval stuff is in there to m= ake it possible for the signer to mitigate such damage.

 

There’s an = adjunct ADSP angle, which requests a report if ADSP says “this should= be signed by the author domain” and it wasn’t, even if all the= signatures passed.  The same requirements apply.

 

I think it’s= really as simple as that.

 

So if you don’t like the dkim-reporting = draft as it’s written, how would you design something within those re= quirements?

 

I think Steve and John commented on this before.  I̵= 7;ll go dig up their old emails and comment on them as well, but I’ll= try to do so on this thread so it’s all in one place.

=

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C6C1547CEXCHC2corpclo_-- From msk@cloudmark.com Wed Dec 7 12:14:15 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F00F21F8B16 for ; Wed, 7 Dec 2011 12:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Giu1Vxxwzcce for ; Wed, 7 Dec 2011 12:14:15 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9DD21F8AD8 for ; Wed, 7 Dec 2011 12:14:15 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Dec 2011 12:14:14 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 7 Dec 2011 12:14:14 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 7 Dec 2011 12:14:13 -0800 Thread-Topic: Reporting discovery Thread-Index: Acy1HMmf4Eb60ioaTkyLTjrl+eFQCg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C1547DEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Reporting discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 20:14:15 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C1547DEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a call for comments on draft-ietf-marf-reporting-discovery. Is there any interest in the working group in pursuing publication of this = document? -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C1547DEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a call f= or comments on draft-ietf-marf-reporting-discovery.


Is there any interest in the working group in pursuing pub= lication of this document?

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C6C1547DEXCHC2corpclo_-- From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Dec 7 17:29:40 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1428121F8663 for ; Wed, 7 Dec 2011 17:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, 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 8rXGoR89LepS for ; Wed, 7 Dec 2011 17:29:39 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A366121F85FF for ; Wed, 7 Dec 2011 17:29:39 -0800 (PST) Received: by dajz8 with SMTP id z8so1553115daj.31 for ; Wed, 07 Dec 2011 17:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=cX34L5wEl7d1/MBfDwHT8SFCeDWQq0ax2108IO//j7E=; b=ZXxo2U8tJJowchWUuh1BVVx5IN/X0zZ9t4yy+XD75NZ4ix07en4yD/GsvNz1DYlAUZ qXEYngPgSD3WqetPuHAqsDZkZYf4NnJFj2JjyRBRwfpNnomKx5LubXjgTw+36YWogCmb xO7z6b02hpXlKt61aDwmQuOnqVPJBZaOovMbA= Received: by 10.68.12.165 with SMTP id z5mr10429896pbb.72.1323307778340; Wed, 07 Dec 2011 17:29:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.11.10 with HTTP; Wed, 7 Dec 2011 17:28:56 -0800 (PST) In-Reply-To: References: From: Frank Ellermann Date: Thu, 8 Dec 2011 02:28:56 +0100 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] DKIM reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 01:29:40 -0000 On 7 December 2011 21:12, Murray S. Kucherawy wrote: > I haven=92t had much in the way of feedback on it except through targeted > requests for reviews. Some quick observations: s/4871/6376/, s/sender/signer/ (or whatever is state of the art in DKIM terminology), and maybe say "alleged author" if that is the correct ADSP term. It was straight forward to find _where_ the marf-reporting-discovery will find its TXT, for marf-dkim-reporting it took me some time to check RFCs 6376 + 5617. I think (could be wrong) that I understand the ADSP part, but I'm less sure about the DKIM part. The SPF draft has an example where example.org wants reports at another domain r=3Dpostmaster@example.net That makes me nervous, the opposition could publish malicious DNS records for some kind of indirect attack. I don't see why that's necessary for SPF or ADSP. It might be different for broken or forged DKIM signatures, but generally I think that anybody "doing something" with mail at a domain where they can add TXT records can also arrange a postmaster@ or similar mailbox at this domain. For ri=3D1 (non-zero) how long are receivers expected to wait for another incident? If you want ri=3D9, and I get only 8 broken signatures within a day, does this mean that you want no report because 8 is less than 9? Or do you want no second report before I got 2*9 broken signatures, no matter how long it takes? It is not clear for me why receivers would ever wish to follow detailed instructions about their reports, even including MUSTs and MUST NOTs in section 5. For ADSP ro=3Du I'm not sure what it is, is this simply "all minus ro=3Ds"? Should the ADSP ro=3Du explanation (5.2) say "and" instead of "but"? The rf=3Dsmtp + rs=3D... magic is apparently something in the direction of the SPF exp=3D magic. Or maybe not, please add more than one example for rf=3Dsmtp + rs=3D... tricks (or a pointer if this is explained elsewhere.) For ADSP + DKIM the marf-reporting stuff should fit into the relevant TXT records, for SPF I'm not sure. If you (=3D the WG) intend to create a general _report discovery mechanism it would be confusing to create additional specific ADSP + DKIM + SPF mechanisms, and vice versa, but I have no idea or opinion what's better (specific vs. general _report). -Frank From shmuel+gen@patriot.net Wed Dec 7 19:01:50 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F4421F8AFE for ; Wed, 7 Dec 2011 19:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_NJABL_PROXY=1.643] 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 5cDQwiiqBJf4 for ; Wed, 7 Dec 2011 19:01:50 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 287A521F8AFD for ; Wed, 7 Dec 2011 19:01:49 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.8]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 70D16F5808C for ; Wed, 7 Dec 2011 21:48:45 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 07 Dec 2011 16:14:43 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111208024848.70D16F5808C@smtp.patriot.net> Subject: Re: [marf] Reporting discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 03:01:50 -0000 In , on 12/07/2011 at 12:14 PM, "Murray S. Kucherawy" said: >This is a call for comments on draft-ietf-marf-reporting-discovery. There were comments about -1 in August, which certainly indicates interest. Is there a new version? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Wed Dec 7 21:18:16 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FCD11E80A2 for ; Wed, 7 Dec 2011 21:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.614 X-Spam-Level: X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 zabzYdxrirUo for ; Wed, 7 Dec 2011 21:18:16 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BB94411E8096 for ; Wed, 7 Dec 2011 21:18:10 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Dec 2011 21:18:10 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 7 Dec 2011 21:18:10 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 7 Dec 2011 21:18:09 -0800 Thread-Topic: [marf] Reporting discovery Thread-Index: Acy1Vb+ZgaPe04brTgevrRbkfMovggAEsAbg Message-ID: References: <20111208024848.70D16F5808C@smtp.patriot.net> In-Reply-To: <20111208024848.70D16F5808C@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Reporting discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 05:18:16 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= hmuel Metz > Sent: Wednesday, December 07, 2011 1:15 PM > To: marf@ietf.org > Subject: Re: [marf] Reporting discovery >=20 > >This is a call for comments on draft-ietf-marf-reporting-discovery. >=20 > There were comments about -1 in August, which certainly indicates > interest. Is there a new version? There is not. Since the thread that initiated conversation about that draft back in Augus= t started with skepticism about its utility, and since that same thread rev= ealed only a single implementation, I suspect we need to consider making it= Experimental unless there's some uptake in interest and some more implemen= tations. We also, unfortunately, need an editor. -MSK From msk@cloudmark.com Wed Dec 7 22:01:33 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6DD21F8AF9 for ; Wed, 7 Dec 2011 22:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.014 X-Spam-Level: X-Spam-Status: No, score=-102.014 tagged_above=-999 required=5 tests=[AWL=-0.615, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, 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 NFYGNJwThnw7 for ; Wed, 7 Dec 2011 22:01:32 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DB27721F8593 for ; Wed, 7 Dec 2011 22:01:32 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 7 Dec 2011 22:01:32 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 7 Dec 2011 22:01:32 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 7 Dec 2011 22:01:30 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt Thread-Index: Acyw8cY+Q0bgapCiRSagIrNGfeQ4rQEfHuIQ Message-ID: References: <20111202000021.21241.16968.idtracker@ietfa.amsl.com> <4ED8CADD.3070809@tana.it> In-Reply-To: <4ED8CADD.3070809@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_F5833273385BB34F99288B3648C4F06F19C6C154A6EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 06:01:33 -0000 --_002_F5833273385BB34F99288B3648C4F06F19C6C154A6EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, December 02, 2011 4:56 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt >=20 > I still have some problems with the example. [...] Thanks for your suggestions. Here's a full replacement example I think will work. Let me know if I've m= issed anything. -MSK --_002_F5833273385BB34F99288B3648C4F06F19C6C154A6EXCHC2corpclo_ Content-Type: text/plain; name="afrf-example.txt" Content-Description: afrf-example.txt Content-Disposition: attachment; filename="afrf-example.txt"; size=2803; creation-date="Thu, 08 Dec 2011 06:01:25 GMT"; modification-date="Thu, 08 Dec 2011 06:00:27 GMT" Content-Transfer-Encoding: base64 UmV0dXJuLVBhdGg6IGZlZWRiYWNrQGFyZi5tYWlsLnJlY2VpdmVyLmV4YW1wbGUKTWVzc2FnZS1J RDogPDQzMzY4OS44MTEyMS5leGFtcGxlQG10YS5tYWlsLnJlY2VpdmVyLmV4YW1wbGU+CkZyb206 ICJTb21lSVNQIE1haWwgQW50aXNwYW0gRmVlZGJhY2siIDxmZWVkYmFja0BtYWlsLnJlY2VpdmVy LmV4YW1wbGU+ClRvOiBhcmYtZmFpbHVyZUBzZW5kZXIuZXhhbXBsZQpTdWJqZWN0OiBGVzogWW91 IGhhdmUgYSBuZXcgYmlsbCBmcm9tIHlvdXIgYmFuawpEYXRlOiBTYXQsIDggT2N0IDIwMTEgMTQ6 MTU6NTkgLTA2MDAgKENTVCkKTUlNRS1WZXJzaW9uOiAxLjAKQ29udGVudC1UeXBlOiBtdWx0aXBh cnQvcmVwb3J0OwogIGJvdW5kYXJ5PSItLS0tLS0tLS0tLS1Cb3VuZGFyeS0wMD1fM0JDUjRZN2tY OTN5UDl1VVBSaGciOwogIHJlcG9ydC10eXBlPWZlZWRiYWNrLXJlcG9ydApDb250ZW50LVRyYW5z ZmVyLUVuY29kaW5nOiA3Yml0CgotLS0tLS0tLS0tLS0tLUJvdW5kYXJ5LTAwPV8zQkNSNFk3a1g5 M3lQOXVVUFJoZwpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIgpD b250ZW50LURpc3Bvc2l0aW9uOiBpbmxpbmUKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2Jp dAoKVGhpcyBpcyBhbiBhdXRoZW50aWNhdGlvbiBmYWlsdXJlIHJlcG9ydCBmb3IgYW4gZW1haWwg bWVzc2FnZQpyZWNlaXZlZCBmcm9tIGEuc2VuZGVyLmV4YW1wbGUgb24gOCBPY3QgMjAxMSAyMDox NTo1OCArMDAwMCAoR01UKS4KRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhpcyBmb3JtYXQg cGxlYXNlIHNlZSBbdGhpcyBtZW1vXS4KCi0tLS0tLS0tLS0tLS0tQm91bmRhcnktMDA9XzNCQ1I0 WTdrWDkzeVA5dVVQUmhnCkNvbnRlbnQtVHlwZTogbWVzc2FnZS9mZWVkYmFjay1yZXBvcnQKQ29u dGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdAoKRmVlZGJhY2stVHlwZTogYXV0aC1mYWlsdXJl ClVzZXItQWdlbnQ6IFNvbWVpc3AhTWFpbC1GZWVkYmFjay8xLjAKVmVyc2lvbjogMQpPcmlnaW5h bC1NYWlsLUZyb206IGFuZXhhbXBsZS5yZXBseUBhLnNlbmRlci5leGFtcGxlCk9yaWdpbmFsLUVu dmVsb3BlLUlkOiBvM0Y1Mmd4TzAyOTE0NApBdXRoZW50aWNhdGlvbi1SZXN1bHRzOiBtdGExMDEx Lm1haWwudHAyLnJlY2VpdmVyLmV4YW1wbGU7CiBka2ltPWZhaWwgKGJvZHloYXNoKSBoZWFkZXIu ZD1zZW5kZXIuZXhhbXBsZQpBdXRoLUZhaWx1cmU6IGJvZHloYXNoCkRLSU0tQ2Fub25pY2FsaXpl ZC1Cb2R5OiBWR2hwY3lCcGN5QmhJRzFsYzNOaFoyVWdZbTlrZQogU0IwYUdGMElHZHZkQ0J0YjJS cFptbGxaQ0JwYmlCMGNtRnVjMmwwTGdvPQpBcnJpdmFsLURhdGU6IDggT2N0IDIwMTEgMTM6MTY6 MjQgKzAwMDAoR01UKQpTb3VyY2UtSVA6IDE5Mi4wLjIuMQpSZXBvcnRlZC1Eb21haW46IGEuc2Vu ZGVyLmV4YW1wbGUKUmVwb3J0ZWQtVVJJOiBodHRwOi8vd3d3LnNlbmRlci5leGFtcGxlLwoKLS0t LS0tLS0tLS0tLS1Cb3VuZGFyeS0wMD1fM0JDUjRZN2tYOTN5UDl1VVBSaGcKQ29udGVudC1UeXBl OiB0ZXh0L3JmYzgyMi1oZWFkZXJzCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQKCkF1 dGhlbnRpY2F0aW9uLVJlc3VsdHM6IG10YTEwMTEubWFpbC50cDIucmVjZWl2ZXIuZXhhbXBsZTsK IGRraW09ZmFpbCAoYm9keWhhc2gpIGhlYWRlci5kPXNlbmRlci5leGFtcGxlOwogc3BmPXBhc3Mg c210cC5tYWlsZnJvbT1hbmV4YW1wbGUucmVwbHlAYS5zZW5kZXIuZXhhbXBsZQpSZWNlaXZlZDog ZnJvbSBzbXRwLW91dC5zZW5kZXIuZXhhbXBsZQogYnkgbXRhMTAxMS5tYWlsLnRwMi5yZWNlaXZl ci5leGFtcGxlCiB3aXRoIFNNVFAgaWQgb0I4NVc4eFYwMDAxNjk7CiBTYXQsIDA4IE9jdCAyMDEx IDEzOjE1OjU4IC0wNzAwIChQRFQpCkRLSU0tU2lnbmF0dXJlOiB2PTE7IGM9cmVsYXhlZC9zaW1w bGU7IGE9cnNhLXNoYTI1NjsKIHM9dGVzdGtleTsgZD1zZW5kZXIuZXhhbXBsZTsgaD1Gcm9tOlRv OlN1YmplY3Q6RGF0ZTsKIGJoPTJqVVNPSDlOaHRWR0NRV05yOUJySUFQcmVLUWpPNlNuN1hJa2ZK Vk96djg9OwogYj1BdVVvRkVmRHhURGtIbExYU1pFcFpqNzlMSUNFcHM2ZWRhN1czZGVUVkZPazR5 QVVvcU9CCiA0bnVqYzdZb3BkRzVkV0xTZE5nNnhOQVpwT1ByK2tIeHQxSXJFK05haE02TC9MYnZh SHV0CiBLVmRrTExrcFZhVlZRUHplUkRJMDA5U08ySWw1THU3ckROSDZtWmNrQmRySXgwb3JFdFpW CiA0Ym1wL1l6aHd2Y3ViVTQ9ClJlY2VpdmVkOiBmcm9tIG1haWwuc2VuZGVyLmV4YW1wbGUKIGJ5 IHNtdHAtb3V0LnNlbmRlci5leGFtcGxlCiB3aXRoIFNNVFAgaWQgbzNGNTJneE8wMjkxNDQ7CiBT YXQsIDA4IE9jdCAyMDExIDEzOjE1OjMxIC0wNzAwIChQRFQpClJlY2VpdmVkOiBmcm9tIGludGVy bmFsLWNsaWVudC0wMDEuc2VuZGVyLmV4YW1wbGUKIGJ5IG1haWwuc2VuZGVyLmV4YW1wbGUKIHdp dGggU01UUCBpZCBvM0YzQndkWTAyODQzMTsKIFNhdCwgMDggT2N0IDIwMTEgMTM6MTU6MjQgLTA3 MDAgKFBEVCkKRGF0ZTogU2F0LCA4IE9jdCAyMDExIDE2OjE1OjI0IC0wNDAwIChFRFQpClJlcGx5 LVRvOiBhbmV4YW1wbGUucmVwbHlAYS5zZW5kZXIuZXhhbXBsZQpGcm9tOiBhbmV4YW1wbGVAYS5z ZW5kZXIuZXhhbXBsZQpUbzogc29tZXVzZXJAcmVjZWl2ZXIuZXhhbXBsZQpTdWJqZWN0OiBZb3Ug aGF2ZSBhIG5ldyBiaWxsCk1lc3NhZ2UtSUQ6IDw4NzkxMzkxMC4xMzE4MDk0NjA0NTQ2QG91dC5z ZW5kZXIuZXhhbXBsZT4KCi0tLS0tLS0tLS0tLS0tQm91bmRhcnktMDA9XzNCQ1I0WTdrWDkzeVA5 dVVQUmhnLS0KCg== --_002_F5833273385BB34F99288B3648C4F06F19C6C154A6EXCHC2corpclo_-- From sm@resistor.net Wed Dec 7 22:56:21 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F59321F8531 for ; Wed, 7 Dec 2011 22:56:21 -0800 (PST) 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=[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 KzZmRbxY5GPE for ; Wed, 7 Dec 2011 22:56:20 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3FC21F8545 for ; Wed, 7 Dec 2011 22:56:19 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pB86uDRo011473 for ; Wed, 7 Dec 2011 22:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323327377; bh=1hzfaihJt002zVxWSnKTbzL6xvpJ7pI+oI+sFjOovVI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ORanl1tUrVAvt4SgBWYlVOT10r9ausPs6NJBMMT/5MqpmvXJojTQz62CojN+kLvrA t+EjicZCqkBFa5vrgvfhtP3K8PQyVStTHUG58HOXkwbRYCKraceRLA/vxsAf7+ML8Z jF29jSdRjgDf5BX5e+cz601f65tPObya09aYd9UM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323327377; bh=1hzfaihJt002zVxWSnKTbzL6xvpJ7pI+oI+sFjOovVI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=cEdnoQpPsUvU5GuYG3i3TAZHlY3tT2Dpa4Tdc6PIGvKdqBzBtuvsYiWqb5W6edoJz 7xZq2BbIQgnuzn9vtGL8VSqUj7zAn9K30mfB21IIn46XrGEcaxnD3MEpYWH71/+Xv7 NZ2BrOU2gIzFalu2wuHOCUr2TJlmfqgH9FoU2W/c= Message-Id: <6.2.5.6.2.20111207223741.09b495d8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 07 Dec 2011 22:54:35 -0800 To: marf@ietf.org From: SM In-Reply-To: References: <20111202000021.21241.16968.idtracker@ietfa.amsl.com> <4ED8CADD.3070809@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 06:56:21 -0000 Hi Murray, At 22:01 07-12-2011, Murray S. Kucherawy wrote: >Here's a full replacement example I think will work. Let me know if >I've missed anything. This is a quick pass. "Arrival-Date: 8 Oct 2011 13:16:24 +0000(GMT)" I suggest dropping the GMT in that line. BTW, I did not think about the Version field previously. As a quick comment, if the report interoperate with the base specifications, that should not be a problem. According to the Auth-Failure field, this report is DKIM related. It qualifies as a DKIM report (3.2.3). The DKIM-Domain and DKIM-Identity fields are required. There isn't a requirement level in the draft though. Regards, -sm From vesely@tana.it Thu Dec 8 00:29:21 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F61C21F8AAF for ; Thu, 8 Dec 2011 00:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 BKYVANMBuRjL for ; Thu, 8 Dec 2011 00:29:20 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9D23C21F8AAC for ; Thu, 8 Dec 2011 00:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323332958; bh=oakBDtUnYmpPESg9NxlXm2p20bF8ll+rTz16JXdV5j4=; l=1593; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=SJiBv27FdYH7bEBemKpf7Cg2cDVWosZH5boz3sxJmIihlTCW5CvP52q6gqUcpLB7h ADIz9CmWltqvzLTyfnjOg8U0hnzKVR0Czr/VGnxd51wSccU9eZLh0hbcqkHBhPebDW exsyKGgd+pOyxaj3FvAxJ5P3TcSlfX+4DrZbIkl4= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 08 Dec 2011 09:29:18 +0100 id 00000000005DC042.000000004EE0755E.000009E6 Message-ID: <4EE0755E.6020305@tana.it> Date: Thu, 08 Dec 2011 09:29:18 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <4EDE7ED2.3090401@kitterman.com> In-Reply-To: <4EDE7ED2.3090401@kitterman.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [marf] Moving spf-reporting to spfbis, was Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 08:29:21 -0000 On 06/Dec/11 21:45, Scott Kitterman wrote: > On 12/06/2011 03:38 PM, Murray S. Kucherawy wrote: >> For draft-ietf-marf-spf-reporting: Does the working group feel this >> work is useful to pursue? If not, we will suggest it be added to the >> proposed charter for SPFBIS or a future version of it. I'm not clear on what is the intersection MARF ∩ SPFBIS, but if it is consistent enough the move can be done even in case we consider this work to be useful to pursue. > I think it has value. I haven't updated the draft because it didn't > seem fruitful. Things I'm waiting for: > > draft-ietf-marf-authfailure-report: Waiting for the final post-last call > draft - since I'm waiting on the SPFbis situation to clarify a bit, my > intent was to wait until this draft was also ~final so I'd have a stable > base to work from. Since the other WG seems to be going to last longer than this, waiting there may be more consistent. > SPFbis: I'm waiting for the charter discussion to settle out so that I > know how to deal with the downref issue to RFC 4408. If the charter > lands the way I think it will, I think allowing a downref is justifiable. Some coordination can be fruitful here. For example, if there will be methods to report certain circumstances to the domain owners, then some features of SPF that are only used for monitoring those circumstances could be safely deprecated. Contribution to such monitoring is spontaneous and consenting in either case, but decoupling it from SPF checking may remove an impediment toward broader adoption. jm2c From vesely@tana.it Thu Dec 8 00:29:32 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AB821F8AB9 for ; Thu, 8 Dec 2011 00:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.644 X-Spam-Level: X-Spam-Status: No, score=-4.644 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 NVFWc5NT-lc2 for ; Thu, 8 Dec 2011 00:29:31 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDBB21F8AAA for ; Thu, 8 Dec 2011 00:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323332971; bh=1BypSiuaFNl/DnHVKWbiPw08X0WmZLf/HmZ2hauTXQM=; l=1144; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=THtK1pM4Y5V4P2RtHOBQc5GyAuLbImftTWbjCCpszTOtPBHppaM7kl8hG2J0L+4sa 7q1MNqr6l+MEeQ8oJEJXFqN0TssuJXiQDEyt5iFMb2IhMxCvMEEZIjPhNG7Oe+P6Ih g1imgM3z+JsDkAH8bxUFbPPk//nRzFwX7J6tmmqM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 08 Dec 2011 09:29:30 +0100 id 00000000005DC042.000000004EE0756A.00000A02 Message-ID: <4EE0756A.5030308@tana.it> Date: Thu, 08 Dec 2011 09:29:30 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111208024848.70D16F5808C@smtp.patriot.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Reporting discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 08:29:32 -0000 On 08/Dec/11 06:18, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Shmuel Metz >> >>> This is a call for comments on draft-ietf-marf-reporting-discovery. >> >> There were comments about -1 in August, which certainly indicates >> interest. Is there a new version? > > There is not. > > Since the thread that initiated conversation about that draft back > in August started with skepticism about its utility, and since that > same thread revealed only a single implementation, I suspect we > need to consider making it Experimental unless there's some uptake > in interest and some more implementations. I think that Experimental accurately reflects a key aspect of the semantics. Feedback loops the way they're currently done suit huge mailbox providers only. In that sense, feedback loop doesn't scale, and that's why reporting discovery was started. However, there are enhancements to Whois databases being brought about by all RIRs. These are two competing methods for attaining the same result. > We also, unfortunately, need an editor. I'd be happy to do it, if no better editors volunteer for that. From vesely@tana.it Thu Dec 8 00:29:39 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C74921F8B16 for ; Thu, 8 Dec 2011 00:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 geiyWYQuRo-A for ; Thu, 8 Dec 2011 00:29:39 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id DE8C821F8AAA for ; Thu, 8 Dec 2011 00:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323332978; bh=LaJ1QDlpfeWEEzo7g9uxqeZYHhB+MCsSIkaD6wW1vLg=; l=859; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DAqtajfmknMxTKiVyL71gr9clIXDklG5DQ14dIllvm+I6fYzfsTQEITBO9cHNzNzS OaVEJC3M8qvRO95MNPMxZOuH6fGmlcQRRPKk71oZR6W0fVqVM5Q+zY0WXS9gyefNoP 5fV+TOKMhDxFLhIBq+wuwCUKSsC0no8k2wWeYx14= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 08 Dec 2011 09:29:38 +0100 id 00000000005DC042.000000004EE07572.00000C6F Message-ID: <4EE07572.8020108@tana.it> Date: Thu, 08 Dec 2011 09:29:38 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [marf] Applicability statement X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 08:29:39 -0000 On 07/Dec/11 21:01, Murray S. Kucherawy wrote: > This is a call for comments about draft-ietf-marf-as, and specifically > for review of RFC6449. > > The main question: Does the working group completely agree with what’s > in RFC6449 (which is essentially a product of MAAWG and not the EITF), > or do we have any supplementary (even conflicting) operational > experience or advice for the community? This is what will go in an > applicability statement. I have some opinions on spam reporting, but not much experience since such mechanisms are either new or only for huge mailbox providers. I wrote some stuff in draft-vesely-marf-abuse-reporting, which I'd merge with JD's work if there's consensus on that. > Also, the document unfortunately needs a new editor. If anyone is > interested, please speak up. I'd be willing to do that. From sklist@kitterman.com Thu Dec 8 06:52:44 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9841021F8ACE for ; Thu, 8 Dec 2011 06:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 zB4MJ+kcuvJs for ; Thu, 8 Dec 2011 06:52:44 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 25E3521F8538 for ; Thu, 8 Dec 2011 06:52:44 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0B7A520E4100; Thu, 8 Dec 2011 09:52:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1323355962; bh=8eWp0XfPvwvHcnF4VUCa7vCHBJYrl5oyG5AmB03hKZw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Vwv59LXvnQmi3brWuzeCe4U1D9cB5kCmqHBE/ffn2m+6SqbTyG+LHU74uL25KJ+ZP EIE5LzZ/xfKklErEvFePlOEflWfqPbjnUWK2FWova5gi+b5vF8vEqGJtMYls6RRkQc pi+2b31+yI1b09LYih78WgW/l+kFqOZWIXb5VaVc= Received: from [10.59.26.48] (unknown [66.39.207.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B5D4F20E4091; Thu, 8 Dec 2011 09:52:41 -0500 (EST) Message-ID: <4EE0CF38.5030203@kitterman.com> Date: Thu, 08 Dec 2011 09:52:40 -0500 From: Scott Kitterman User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] DKIM reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 14:52:44 -0000 On 12/07/2011 08:28 PM, Frank Ellermann wrote: > The SPF draft has an example where example.org wants reports at another > domain r=postmaster@example.net That makes me nervous, the opposition > could publish malicious DNS records for some kind of indirect attack. One of the comments that I'll resolve in the next update to the draft will do away with that. We debated it back and forth and reached essentially this conclusion. Scott K From dotzero@gmail.com Thu Dec 8 06:54:09 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DD421F86A6 for ; Thu, 8 Dec 2011 06:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] 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 jIxQcGV+8Yln for ; Thu, 8 Dec 2011 06:54:09 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC7DF21F86A0 for ; Thu, 8 Dec 2011 06:54:08 -0800 (PST) Received: by ggnk5 with SMTP id k5so2419608ggn.31 for ; Thu, 08 Dec 2011 06:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yNksNtZPfWkvgJR2Z/Vyd7WJ415nQLlZK0Rlwkgi9jM=; b=IekGQEs0FEDg2pSpjFDo6N54aTlZesqnoShpWCGy3UWVek6ApehJvKPClDy/qDHM/2 wZ0kpfyBEdCCXpXqXIh7onLK9pvprUX0Pu2dhqx1sFTm6wumJHuMIIV2r0uJKRqRpyGk ZdRqiE+aLic3qZooTOKruXHBGimjKNZvLCFtA= MIME-Version: 1.0 Received: by 10.68.38.68 with SMTP id e4mr16104629pbk.107.1323356045949; Thu, 08 Dec 2011 06:54:05 -0800 (PST) Received: by 10.142.223.5 with HTTP; Thu, 8 Dec 2011 06:54:05 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Dec 2011 09:54:05 -0500 Message-ID: From: Dotzero To: Frank Ellermann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] DKIM reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 14:54:09 -0000 I plead mea culpa in only sort of following the marf work without providing input. This is of interest to me but I'm feeling that I am spread kind of thin these days. I will try to give a deeper read and give more meaningful input based on Murray's request. One comment inline. Mike On Wed, Dec 7, 2011 at 8:28 PM, Frank Ellermann wrote: > On 7 December 2011 21:12, Murray S. Kucherawy wrote: > >> I haven=92t had much in the way of feedback on it except through targete= d >> requests for reviews. > > Some quick observations: =A0s/4871/6376/, s/sender/signer/ (or whatever i= s > state of the art in DKIM terminology), and maybe say "alleged author" if > that is the correct ADSP term. =A0It was straight forward to find _where_ > the marf-reporting-discovery will find its TXT, for marf-dkim-reporting > it took me some time to check RFCs 6376 + 5617. =A0I think (could be wron= g) > that I understand the ADSP part, but I'm less sure about the DKIM part. > > The SPF draft has an example where example.org wants reports at another > domain r=3Dpostmaster@example.net =A0That makes me nervous, the oppositio= n > could publish malicious DNS records for some kind of indirect attack. > > I don't see why that's necessary for SPF or ADSP. =A0It might be differen= t > for broken or forged DKIM signatures, but generally I think that anybody > "doing something" with mail at a domain where they can add TXT records > can also arrange a postmaster@ or similar mailbox at this domain. > Some organizations (such as my own) use a 3rd party service for handling authentication FBL emails. We don't use ADSP and the mail flows involved are (all) DKIM signed. I recognize the risk you indicate but I think there are much easier attack vectors than this. > For ri=3D1 (non-zero) how long are receivers expected to wait for another > incident? =A0If you want ri=3D9, and I get only 8 broken signatures withi= n > a day, does this mean that you want no report because 8 is less than 9? > > Or do you want no second report before I got 2*9 broken signatures, no > matter how long it takes? =A0It is not clear for me why receivers would > ever wish to follow detailed instructions about their reports, even > including MUSTs and MUST NOTs in section 5. > > For ADSP ro=3Du I'm not sure what it is, is this simply "all minus ro=3Ds= "? > Should the ADSP ro=3Du explanation (5.2) say "and" instead of "but"? > > The rf=3Dsmtp + rs=3D... magic is apparently something in the direction o= f > the SPF exp=3D magic. =A0Or maybe not, please add more than one example f= or > rf=3Dsmtp + rs=3D... tricks (or a pointer if this is explained elsewhere.= ) > > For ADSP + DKIM the marf-reporting stuff should fit into the relevant > TXT records, for SPF I'm not sure. =A0If you (=3D the WG) intend to creat= e > a general _report discovery mechanism it would be confusing to create > additional specific ADSP + DKIM + SPF mechanisms, and vice versa, but I > have no idea or opinion what's better (specific vs. general _report). > > -Frank > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From msk@cloudmark.com Thu Dec 8 10:21:20 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAFB21F8B8A for ; Thu, 8 Dec 2011 10:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.982 X-Spam-Level: X-Spam-Status: No, score=-101.982 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, SARE_LWSHORTT=1.24, 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 ADriRM7k8V-h for ; Thu, 8 Dec 2011 10:21:19 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A47B821F8B87 for ; Thu, 8 Dec 2011 10:21:19 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 8 Dec 2011 10:21:19 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 8 Dec 2011 10:21:19 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 8 Dec 2011 10:21:18 -0800 Thread-Topic: [marf] Moving spf-reporting to spfbis, was Working group status Thread-Index: Acy1g32yDYorAvrMTMCYZbjsqKGCOwAUcWhw Message-ID: References: <4EDE7ED2.3090401@kitterman.com> <4EE0755E.6020305@tana.it> In-Reply-To: <4EE0755E.6020305@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] Moving spf-reporting to spfbis, was Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 18:21:20 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtYXJmLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptYXJmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGVzc2FuZHJv IFZlc2VseQ0KPiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMDgsIDIwMTEgMTI6MjkgQU0NCj4g VG86IG1hcmZAaWV0Zi5vcmcNCj4gU3ViamVjdDogW21hcmZdIE1vdmluZyBzcGYtcmVwb3J0aW5n IHRvIHNwZmJpcywgd2FzIFdvcmtpbmcgZ3JvdXANCj4gc3RhdHVzDQo+IA0KPiBJJ20gbm90IGNs ZWFyIG9uIHdoYXQgaXMgdGhlIGludGVyc2VjdGlvbiBNQVJGIOKIqSBTUEZCSVMsIGJ1dCBpZiBp dCBpcw0KPiBjb25zaXN0ZW50IGVub3VnaCB0aGUgbW92ZSBjYW4gYmUgZG9uZSBldmVuIGluIGNh c2Ugd2UgY29uc2lkZXIgdGhpcw0KPiB3b3JrIHRvIGJlIHVzZWZ1bCB0byBwdXJzdWUuDQoNClRo ZSBTUEYgcmVwb3J0aW5nIGRyYWZ0IGluY2x1ZGVzIHdvcmsgcmVnYXJkaW5nIGZlZWRiYWNrIGxv b3BzIHdpdGggcmVzcGVjdCB0byBTUEYgZmFpbHVyZXMuICBCZWNhdXNlIG9mIHRoaXMgaXQgY291 bGQgbGVnaXRpbWF0ZWx5IGJlIHBsYWNlZCBpbiBlaXRoZXIgd29ya2luZyBncm91cC4gIEkgZG9u J3Qgc2VlIGEgY2xlYXIgd2F5IHRvIHNwbGl0IGl0IGludG8gdHdvIGRvY3VtZW50cywgb25lIGdv aW5nIHRvIGVhY2ggd29ya2luZyBncm91cCwgd2l0aG91dCBtYWtpbmcgaXQgcGFydGljdWxhcmx5 IHVnbHkuICBUaGVuIGFnYWluLCBJIGhhdmVuJ3QgdGhvdWdodCBhYm91dCBpdCB2ZXJ5IG11Y2gg eWV0Lg0KDQo+ID4gU1BGYmlzOiAgSSdtIHdhaXRpbmcgZm9yIHRoZSBjaGFydGVyIGRpc2N1c3Np b24gdG8gc2V0dGxlIG91dCBzbyB0aGF0DQo+ID4gSSBrbm93IGhvdyB0byBkZWFsIHdpdGggdGhl IGRvd25yZWYgaXNzdWUgdG8gUkZDIDQ0MDguICBJZiB0aGUgY2hhcnRlcg0KPiA+IGxhbmRzIHRo ZSB3YXkgSSB0aGluayBpdCB3aWxsLCBJIHRoaW5rIGFsbG93aW5nIGEgZG93bnJlZiBpcw0KPiA+ IGp1c3RpZmlhYmxlLg0KPiANCj4gU29tZSBjb29yZGluYXRpb24gY2FuIGJlIGZydWl0ZnVsIGhl cmUuICBGb3IgZXhhbXBsZSwgaWYgdGhlcmUgd2lsbCBiZQ0KPiBtZXRob2RzIHRvIHJlcG9ydCBj ZXJ0YWluIGNpcmN1bXN0YW5jZXMgdG8gdGhlIGRvbWFpbiBvd25lcnMsIHRoZW4gc29tZQ0KPiBm ZWF0dXJlcyBvZiBTUEYgdGhhdCBhcmUgb25seSB1c2VkIGZvciBtb25pdG9yaW5nIHRob3NlIGNp cmN1bXN0YW5jZXMNCj4gY291bGQgYmUgc2FmZWx5IGRlcHJlY2F0ZWQuICBDb250cmlidXRpb24g dG8gc3VjaCBtb25pdG9yaW5nIGlzDQo+IHNwb250YW5lb3VzIGFuZCBjb25zZW50aW5nIGluIGVp dGhlciBjYXNlLCBidXQgZGVjb3VwbGluZyBpdCBmcm9tIFNQRg0KPiBjaGVja2luZyBtYXkgcmVt b3ZlIGFuIGltcGVkaW1lbnQgdG93YXJkIGJyb2FkZXIgYWRvcHRpb24uDQoNCldlIGhhdmUgYSBm ZXcgb3B0aW9ucyBoZXJlOg0KDQphKSBEb3duZ3JhZGUgc3BmLXJlcG9ydGluZyB0byBFeHBlcmlt ZW50YWwuDQoNCmIpIFB1cnN1ZSBzcGYtcmVwb3J0aW5nIHB1YmxpY2F0aW9uIG9uIHRoZSBTdGFu ZGFyZHMgVHJhY2ssIGFja25vd2xlZGdpbmcgdGhlIGRvd25yZWYuDQoNCmMpIFB1cnN1ZSBzcGYt cmVwb3J0aW5nIHB1YmxpY2F0aW9uIG9uIHRoZSBTdGFuZGFyZHMgVHJhY2ssIHJlZmVyZW5jaW5n IFNQRmJpcyBpbnN0ZWFkIG9mIFJGQzQ0MDguICBUaGlzIHdpbGwgY2F1c2Ugc3BmLXJlcG9ydGlu ZyB0byBiZSBoZWxkIGJ5IHRoZSBSRkMgRWRpdG9yIHVudGlsIFNQRmJpcyBwdWJsaXNoZXMsIGJ1 dCBpdCdzIHN0aWxsIGEgcGF0aCBmb3J3YXJkLg0KDQpJdCBhbGwgZGVwZW5kcyBvbiBob3cgbXVj aCB1cHRha2Ugd2UgZ2V0IGluIHRoZSBzaG9ydCB0ZXJtLiAgSWYgdGhlcmUgaXNuJ3QgYW55LCB3 ZSBtaWdodCBnaXZlIChhKSBzb21lIHNlcmlvdXMgY29uc2lkZXJhdGlvbi4gIFNhbWUgZm9yIGRr aW0tcmVwb3J0aW5nLg0KDQoNCg== From msk@cloudmark.com Thu Dec 8 10:23:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F032221F84AE for ; Thu, 8 Dec 2011 10:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 3uYGGpT6Iayh for ; Thu, 8 Dec 2011 10:23:29 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 83DAC21F8492 for ; Thu, 8 Dec 2011 10:23:29 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 8 Dec 2011 10:23:29 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 8 Dec 2011 10:23:29 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 8 Dec 2011 10:23:28 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt Thread-Index: Acy1doOmv8bNFyRgSO2IB7xMQop4ZwAX90ew Message-ID: References: <20111202000021.21241.16968.idtracker@ietfa.amsl.com> <4ED8CADD.3070809@tana.it> <6.2.5.6.2.20111207223741.09b495d8@resistor.net> In-Reply-To: <6.2.5.6.2.20111207223741.09b495d8@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 18:23:30 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= M > Sent: Wednesday, December 07, 2011 10:55 PM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt >=20 > Hi Murray, > At 22:01 07-12-2011, Murray S. Kucherawy wrote: > >Here's a full replacement example I think will work. Let me know if > >I've missed anything. >=20 > This is a quick pass. >=20 > "Arrival-Date: 8 Oct 2011 13:16:24 +0000(GMT)" >=20 > I suggest dropping the GMT in that line. Why? The others all have timezones. There should be a space before the op= ening parenthesis though. > According to the Auth-Failure field, this report is DKIM related. It > qualifies as a DKIM report (3.2.3). The DKIM-Domain and DKIM-Identity > fields are required. There isn't a requirement level in the draft > though. Right; added. Thanks, -MSK From sm@resistor.net Thu Dec 8 13:29:27 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB45121F8A62 for ; Thu, 8 Dec 2011 13:29:27 -0800 (PST) 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=[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 HIbZECIVGIAv for ; Thu, 8 Dec 2011 13:29:27 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F8321F86A0 for ; Thu, 8 Dec 2011 13:29:26 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pB8LTID7024079 for ; Thu, 8 Dec 2011 13:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323379766; bh=TRxCjWXY1Oy4xVi6wGYFudVCmDPAlaz+bPTpun5qMjU=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=XZS4w1BjpcJlMxVzYBYRgk5Zb5txpJbzpF4wJWR8WH8Z7PEU49UJx16hz0GykxYhA CqUf9YCo5AGg7n3Lg84w3ePmDjAiroNKunwMp271zlRfkLvn177SticqkwDVcZ9TPN P6fplSoKjaOJqp8K5bQRNSkoqVnL7L0zbQ+UjGKs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323379766; bh=TRxCjWXY1Oy4xVi6wGYFudVCmDPAlaz+bPTpun5qMjU=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=DPi2vDTIIJLlmgH159a6jI5Q9TepDg9XibCFAw5WJ/Y3F8hvS548KZ2m+DWpD4VDJ NQdgQ42BU322gC4cUB2UobSyg1iNhzVk6axvcX9mbgVngzLxMrdEJzMfV1HWiwdr/E ktGbEHWh7zjdPW6ENS1POxj+RQMOtQTOuB5lKI48= Message-Id: <6.2.5.6.2.20111208130928.08b1dbb0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 08 Dec 2011 13:11:35 -0800 To: marf@ietf.org From: SM In-Reply-To: References: <20111202000021.21241.16968.idtracker@ietfa.amsl.com> <4ED8CADD.3070809@tana.it> <6.2.5.6.2.20111207223741.09b495d8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 21:29:27 -0000 Hi Murray, At 10:23 08-12-2011, Murray S. Kucherawy wrote: >Why? The others all have timezones. There should be a space before >the opening parenthesis though. It was easier than pointing out the missing space. :-) Regards, -sm From vesely@tana.it Fri Dec 9 04:00:48 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014BD21F87D3 for ; Fri, 9 Dec 2011 04:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.659 X-Spam-Level: X-Spam-Status: No, score=-4.659 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 Zn9B01xC5k2w for ; Fri, 9 Dec 2011 04:00:47 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id DB44B21F8753 for ; Fri, 9 Dec 2011 04:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323432041; bh=mO+9SUGqprQIyVl9KV5AEoDnfFp0PquDBN4BnxxTFAQ=; l=2518; h=Message-ID:Date:From:Mime-Version:To:References:In-Reply-To; b=fFPkd5e0KQnzDLZRk/rVuh0akRn39Q3xA4LLpP/ZYdmUkT30h3o/rVsIUCk/EOJou 507xF7Q2uksLRZRe8r2r5Hv1TOzyUwr/O31tkRuaXi8nvrjQa9aBZP6248CQ0yatlY pVT/NTOmWy1dLiV8G5AGNODP/qaCbU4NBPb566bw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 09 Dec 2011 13:00:41 +0100 id 00000000005DC042.000000004EE1F869.00004F03 Message-ID: <4EE1F869.9000107@tana.it> Date: Fri, 09 Dec 2011 13:00:41 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-20227-1323432041-0001-2" To: marf@ietf.org References: <20111202000021.21241.16968.idtracker@ietfa.amsl.com> <4ED8CADD.3070809@tana.it> In-Reply-To: Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-05.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 12:00:48 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-20227-1323432041-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 08/Dec/11 07:01, Murray S. Kucherawy wrote: > Here's a full replacement example I think will work. Let me know > if I've missed anything. I attach a patch --=_north-20227-1323432041-0001-2 Content-Type: text/plain; name="afrf-example.patch.txt"; charset=iso-8859-1 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="afrf-example.patch.txt" LS0tIGFmcmYtZXhhbXBsZS50eHQJRnJpIERlYyAwOSAxMjo1NDoyNyAyMDExDQorKysgYXJm ci1leGFtcGxlLnR4dAlGcmkgRGVjIDA5IDEyOjU4OjMxIDIwMTENCkBAIC0xLDkgKzEsOCBA QA0KLVJldHVybi1QYXRoOiBmZWVkYmFja0BhcmYubWFpbC5yZWNlaXZlci5leGFtcGxlDQog TWVzc2FnZS1JRDogPDQzMzY4OS44MTEyMS5leGFtcGxlQG10YS5tYWlsLnJlY2VpdmVyLmV4 YW1wbGU+DQogRnJvbTogIlNvbWVJU1AgTWFpbCBBbnRpc3BhbSBGZWVkYmFjayIgPGZlZWRi YWNrQG1haWwucmVjZWl2ZXIuZXhhbXBsZT4NCiBUbzogYXJmLWZhaWx1cmVAc2VuZGVyLmV4 YW1wbGUNCiBTdWJqZWN0OiBGVzogWW91IGhhdmUgYSBuZXcgYmlsbCBmcm9tIHlvdXIgYmFu aw0KLURhdGU6IFNhdCwgOCBPY3QgMjAxMSAxNDoxNTo1OSAtMDYwMCAoQ1NUKQ0KK0RhdGU6 IFNhdCwgOCBPY3QgMjAxMSAxNToxNTo1OSAtMDUwMCAoQ0RUKQ0KIE1JTUUtVmVyc2lvbjog MS4wDQogQ29udGVudC1UeXBlOiBtdWx0aXBhcnQvcmVwb3J0Ow0KICAgYm91bmRhcnk9Ii0t LS0tLS0tLS0tLUJvdW5kYXJ5LTAwPV8zQkNSNFk3a1g5M3lQOXVVUFJoZyI7DQpAQCAtMzMs MTAgKzMyLDkgQEANCiBBdXRoLUZhaWx1cmU6IGJvZHloYXNoDQogREtJTS1DYW5vbmljYWxp emVkLUJvZHk6IFZHaHBjeUJwY3lCaElHMWxjM05oWjJVZ1ltOWtlDQogIFNCMGFHRjBJR2R2 ZENCdGIyUnBabWxsWkNCcGJpQjBjbUZ1YzJsMExnbz0NCi1BcnJpdmFsLURhdGU6IDggT2N0 IDIwMTEgMTM6MTY6MjQgKzAwMDAoR01UKQ0KK0Fycml2YWwtRGF0ZTogOCBPY3QgMjAxMSAy MDoxNTo1OCArMDAwMChHTVQpDQogU291cmNlLUlQOiAxOTIuMC4yLjENCiBSZXBvcnRlZC1E b21haW46IGEuc2VuZGVyLmV4YW1wbGUNCi1SZXBvcnRlZC1VUkk6IGh0dHA6Ly93d3cuc2Vu ZGVyLmV4YW1wbGUvDQogDQogLS0tLS0tLS0tLS0tLS1Cb3VuZGFyeS0wMD1fM0JDUjRZN2tY OTN5UDl1VVBSaGcNCiBDb250ZW50LVR5cGU6IHRleHQvcmZjODIyLWhlYWRlcnMNCkBAIC02 OCw3ICs2Niw3IEBADQogUmVwbHktVG86IGFuZXhhbXBsZS5yZXBseUBhLnNlbmRlci5leGFt cGxlDQogRnJvbTogYW5leGFtcGxlQGEuc2VuZGVyLmV4YW1wbGUNCiBUbzogc29tZXVzZXJA cmVjZWl2ZXIuZXhhbXBsZQ0KLVN1YmplY3Q6IFlvdSBoYXZlIGEgbmV3IGJpbGwNCitTdWJq ZWN0OiBZb3UgaGF2ZSBhIG5ldyBiaWxsIGZyb20geW91ciBiYW5rDQogTWVzc2FnZS1JRDog PDg3OTEzOTEwLjEzMTgwOTQ2MDQ1NDZAb3V0LnNlbmRlci5leGFtcGxlPg0KIA0KIC0tLS0t LS0tLS0tLS0tQm91bmRhcnktMDA9XzNCQ1I0WTdrWDkzeVA5dVVQUmhnLS0NCg== --=_north-20227-1323432041-0001-2-- From vesely@tana.it Fri Dec 9 04:15:43 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BB221F8753 for ; Fri, 9 Dec 2011 04:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.664 X-Spam-Level: X-Spam-Status: No, score=-4.664 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 OXCfQiNrOcK1 for ; Fri, 9 Dec 2011 04:15:42 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8814421F86A1 for ; Fri, 9 Dec 2011 04:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323432941; bh=Kgd/D5OushHPBUYUT2MrLB8+3BqNW5+ca3dE4+8z/fA=; l=1001; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=B/WVdG/8mOzOBD5IDzaRg+f2hWElaEk3wbHphYcvhChdhruMekc9kBik8OmfNMpuq tzmmdoO6sHmuC2SEIfZaWsUnyNBhc3kiG3E2+T9JZna7WycL4SrbpqiO0revjem9Iq mr61yhI5GQKqttQhJop7IZafuZGf59jOmn8rarBU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 09 Dec 2011 13:15:41 +0100 id 00000000005DC042.000000004EE1FBED.0000137D Message-ID: <4EE1FBED.4070606@tana.it> Date: Fri, 09 Dec 2011 13:15:41 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] DKIM reporting X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 12:15:43 -0000 On 08/Dec/11 15:54, Dotzero wrote: >> >> The SPF draft has an example where example.org wants reports at another >> domain r=postmaster@example.net That makes me nervous, the opposition >> could publish malicious DNS records for some kind of indirect attack. >> >> I don't see why that's necessary for SPF or ADSP. It might be different >> for broken or forged DKIM signatures, but generally I think that anybody >> "doing something" with mail at a domain where they can add TXT records >> can also arrange a postmaster@ or similar mailbox at this domain. This seems to be the same conclusion that the thread started by Murray in August reached http://www.ietf.org/mail-archive/web/marf/current/msg01246.html > Some organizations (such as my own) use a 3rd party service for > handling authentication FBL emails. We don't use ADSP and the mail > flows involved are (all) DKIM signed. I recognize the risk you > indicate but I think there are much easier attack vectors than this. From alexey.melnikov@isode.com Sat Dec 10 14:48:39 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB8221F853A; Sat, 10 Dec 2011 14:48:39 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RJdrbpilP9Y; Sat, 10 Dec 2011 14:48:38 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 92E6221F8538; Sat, 10 Dec 2011 14:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1323557314; d=isode.com; s=selector; i=@isode.com; bh=GfJRspP9hCE8t2r0D5jpZxyFYW1kh9bB/90xsrdK4Tw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ot33KhLo+R2vwcBtank+YsGT5+YBZCwUKV+k3oogDR+Wke+jkcJlmoFFDm3b7hze5f3cRc pq7L9W0BVudU9fn6m/+7N5ANINKcfRCkhjYcdKBrfU3axm+Bo0GHcdw17yrQQdqvTTMHRq knUQNaMPYRVKR5YWKVPLgys7vDTLsaM=; Received: from [188.29.165.210] (188.29.165.210.threembb.co.uk [188.29.165.210]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 10 Dec 2011 22:48:33 +0000 Message-ID: <4EE3E1C2.6000103@isode.com> Date: Sat, 10 Dec 2011 22:48:34 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: ietf@ietf.org References: <20111201162104.1088.81619.idtracker@ietfa.amsl.com> In-Reply-To: <20111201162104.1088.81619.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 10 Dec 2011 15:09:29 -0800 Cc: marf@ietf.org Subject: Re: [marf] Last Call: (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Informational RFC X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 22:48:39 -0000 On 01/12/2011 16:21, The IESG wrote: > The IESG has received a request from the Messaging Abuse Reporting Format > WG (marf) to consider the following document: > - 'Redaction of Potentially Sensitive Data from Mail Abuse Reports' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-12-15. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > Email messages often contain information which might be considered > private or sensitive, per either regulation or social norms. When > such a message becomes the subject of a report intended to be shared > with other entities, the report generator may wish to redact or elide > the sensitive portions of the message. This memo suggests one method > for doing so effectively. I've reviewed the document and I think it is ready for publication. I don't have a strong preference between Informational and Experimental. Best Regards, Alexey From internet-drafts@ietf.org Tue Dec 13 07:54:47 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FBA21F8AF9; Tue, 13 Dec 2011 07:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 CJM29Ou8o1Yp; Tue, 13 Dec 2011 07:54:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159A521F85B9; Tue, 13 Dec 2011 07:54:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111213155447.6032.90863.idtracker@ietfa.amsl.com> Date: Tue, 13 Dec 2011 07:54:47 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 15:54:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Authentication Failure Reporting using the Abuse Report = Format Author(s) : Hilda L. Fontana Filename : draft-ietf-marf-authfailure-report-06.txt Pages : 20 Date : 2011-12-12 This memo registers an extension report type to ARF, affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email authentication checks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-06.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-06.txt From msk@cloudmark.com Tue Dec 13 10:51:48 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994D821F8B17 for ; Tue, 13 Dec 2011 10:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 9p2JGc8djw0c for ; Tue, 13 Dec 2011 10:51:48 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3A69F21F8B1B for ; Tue, 13 Dec 2011 10:51:48 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 13 Dec 2011 10:51:48 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 13 Dec 2011 10:51:47 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 13 Dec 2011 10:51:46 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt Thread-Index: Acy5r468TdAMs+p+TnKFG/4OYimNbQAGKGSQ Message-ID: References: <20111213155447.6032.90863.idtracker@ietfa.amsl.com> In-Reply-To: <20111213155447.6032.90863.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 18:51:48 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Tuesday, December 13, 2011 7:55 AM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Authentication Failure Reporting using the Abuse Repor= t Format > Author(s) : Hilda L. Fontana > Filename : draft-ietf-marf-authfailure-report-06.txt > Pages : 20 > Date : 2011-12-12 >=20 > This memo registers an extension report type to ARF, affecting > multiple registries, for use in generating receipt-time reports about > messages that fail one or more email authentication checks. I'll be sending this to the IESG shortly. Last chance to complain about so= mething. -MSK From sm@resistor.net Tue Dec 13 11:20:57 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A0A21F877F for ; Tue, 13 Dec 2011 11:20:57 -0800 (PST) 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=[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 JWCM1UDmxFuE for ; Tue, 13 Dec 2011 11:20:53 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E52EE21F8672 for ; Tue, 13 Dec 2011 11:20:53 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pBDJKdLL009103 for ; Tue, 13 Dec 2011 11:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323804050; bh=mCHMA3HI5tB2TgQVZPYJxoVIAlFAZuAkQCKuQAe6H8E=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ADupbmTdwifMYsUAhanowdlRiay3OHakGP4I/lyUAj557Xgt2LwZum72uS5R/jqBr pv8JN2afpzVAxbDMaFudd4jNUBbyhqhassJnTiQU5SlyZRMdJeANX5KqmIxQsWKGJv 0TSX291BhQatZQkW1T/akmTiQfMelY/C6PTNCXmA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323804050; bh=mCHMA3HI5tB2TgQVZPYJxoVIAlFAZuAkQCKuQAe6H8E=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=WbkuauGqkbiHajZXDgrxHfvjVEuyIsRDXZzKIjOM8NlwUx+2InmNYxZgVK7wFSbL+ e/iB0a//Ab75u0GYaIT6EKSGzy3FRweXrmFSXKH/nHnVtcKoPzPgQg1H4T68wkEL/V WXnRmILZTKvloEFa+UDYFX8f66sWxgTk+fC4SRUs= Message-Id: <6.2.5.6.2.20111213110542.0adfd8e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Dec 2011 11:16:00 -0800 To: marf@ietf.org From: SM In-Reply-To: References: <20111213155447.6032.90863.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 19:20:57 -0000 At 10:51 13-12-2011, Murray S. Kucherawy wrote: >I'll be sending this to the IESG shortly. Last chance to complain >about something. See http://www.ietf.org/mail-archive/web/marf/current/msg01550.html Could we have a list of issues that have been addressed in this version? Otherwise, I'll have to do a line by line review of my previous comments. Regards, -sm From sklist@kitterman.com Tue Dec 13 11:32:28 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CAA21F8AB9 for ; Tue, 13 Dec 2011 11:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 k7mrGe7K2uEK for ; Tue, 13 Dec 2011 11:32:25 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D4B4421F87D9 for ; Tue, 13 Dec 2011 11:32:24 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2CB1820E40D8; Tue, 13 Dec 2011 14:31:57 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1323804717; bh=aWracACxnUFTFdOnUo/LA+vY3K0GR7WzBph9cS6B92s=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=lPOv6Y3nlMywGNh82J7q7LmBJjl31m9fmXYpbQhSZXpJp8rxHZbEBiYPCLnpbLDDm 9+ZGUOlRSboZeLvSyw2NTlpfA7yclwBSE4mD2ytGkeC90EoWa18hENpvNpqmLySpYj OR0OcMkpdykPM305LKNUA60t+tgVZhe6hEyX8bEo= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id ED54820E4081; Tue, 13 Dec 2011 14:31:56 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Tue, 13 Dec 2011 14:31:50 -0500 Message-ID: <8336672.KgCOkZzttx@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: References: <20111213155447.6032.90863.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 19:32:28 -0000 On Tuesday, December 13, 2011 10:51:46 AM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org Sent: Tuesday, December 13, 2011 7:55 AM > > To: i-d-announce@ietf.org > > Cc: marf@ietf.org > > Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Messaging Abuse Reporting > > Format Working Group of the IETF. > > > > Title : Authentication Failure Reporting using the Abuse > > Report Format Author(s) : Hilda L. Fontana > > Filename : draft-ietf-marf-authfailure-report-06.txt > > Pages : 20 > > Date : 2011-12-12 > > > > This memo registers an extension report type to ARF, affecting > > multiple registries, for use in generating receipt-time reports > > about > > messages that fail one or more email authentication checks. > > I'll be sending this to the IESG shortly. Last chance to complain about > something. I didn't have time to do a check against all the comments I've seen, but reading it through I didn't see anything and what I remember of my complaints appear to be addressed. Scott K From msk@cloudmark.com Tue Dec 13 11:34:19 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2084A21F8ADE for ; Tue, 13 Dec 2011 11:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 CrkI-3nVJhgJ for ; Tue, 13 Dec 2011 11:34:18 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id AF95021F891D for ; Tue, 13 Dec 2011 11:34:18 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 13 Dec 2011 11:34:15 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 13 Dec 2011 11:34:14 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 13 Dec 2011 11:34:13 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt Thread-Index: Acy5zFvPhhsKostIQgy+Sk/JBa99mQAAaMrQ Message-ID: References: <20111213155447.6032.90863.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111213110542.0adfd8e8@resistor.net> In-Reply-To: <6.2.5.6.2.20111213110542.0adfd8e8@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 19:34:19 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= M > Sent: Tuesday, December 13, 2011 11:16 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt >=20 > At 10:51 13-12-2011, Murray S. Kucherawy wrote: > >I'll be sending this to the IESG shortly. Last chance to complain > >about something. >=20 > See > http://www.ietf.org/mail-archive/web/marf/current/msg01550.html I never got an answer to my "Why?" question. Absent that, we left it in. > Could we have a list of issues that have been addressed in this > version? Otherwise, I'll have to do a line by line review of my > previous comments. The datatracker can show you a diff between the two versions, no? I went back and made sure your stuff was covered. -MSK From sm@resistor.net Tue Dec 13 11:49:08 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9941E21F889A for ; Tue, 13 Dec 2011 11:49:08 -0800 (PST) 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=[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 LArgDPWikKIj for ; Tue, 13 Dec 2011 11:49:07 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9324621F8753 for ; Tue, 13 Dec 2011 11:49:07 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pBDJn2cH026322 for ; Tue, 13 Dec 2011 11:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323805747; bh=+GbXu5sBi2hxY3oz+beECfWRyUcw2yOppe4EZjwPjp4=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=NCMGCExgexIJsZ/geffBBhVzwTt6TocTppLf0qqgmbEmkHOsbsN+7ePemS0a2+Ngo f4aUW9gbnvmn83WwpMniEp3Vu/QGoNMydTestymVMS+wR/Wuzo5CaUdGJL7KKlAh5y whW7F6D/+JZNmynVweohbznC3Qa5syJEM7I7raJ4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323805747; bh=+GbXu5sBi2hxY3oz+beECfWRyUcw2yOppe4EZjwPjp4=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=tcaJirTPnEZVVQ7mTxBBKCqN3/GqUkpeyaVy74PT1kTuMV3eNAsKAPF8EECDBhUR8 pZzsRytuuK3kYERvI/kJq2RzirXl2QhSgGLSy3SWEYJCh1/73Fzz/Raraf0HlvZtMZ MpDYHSv4SL5Ol98aXILeL0v6ioj2r9k10xo2t74g= Message-Id: <6.2.5.6.2.20111213113948.0adeaf60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Dec 2011 11:47:45 -0800 To: marf@ietf.org From: SM In-Reply-To: References: <20111213155447.6032.90863.idtracker@ietfa.amsl.com> <6.2.5.6.2.20111213110542.0adfd8e8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-06.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 19:49:08 -0000 At 11:34 13-12-2011, Murray S. Kucherawy wrote: >The datatracker can show you a diff between the two versions, no? Yes. A Changelog would have helped to track the issues which were closed. >I went back and made sure your stuff was covered. Thanks. Regards, -sm From johnl@taugh.com Tue Dec 13 19:37:17 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34C311E8096 for ; Tue, 13 Dec 2011 19:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 p3a5NLVHxSLO for ; Tue, 13 Dec 2011 19:37:17 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B1A1811E8089 for ; Tue, 13 Dec 2011 19:37:16 -0800 (PST) Received: (qmail 54133 invoked from network); 14 Dec 2011 03:37:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=d374.4ee819eb.k1112; bh=8yrvWgvF+YYojPcQvWvmuDcoED3Qyc/wE81WHrWLrNs=; b=2owKOW89ciMgoNOvXlsbPgjqUC+81sqG3rxNS6RsAp8xZ01skrBtA2AP8yASm1Zs9nwhnjgkGU3dAzb1fyoQMAuIZiOpNNfvWkCvUWCsSJQcPmuj5IDSbAdMmmrQkMblq1fEmjlps+j1c3N5K3dlvXwUVUXV0BJKicbahipcAK8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=d374.4ee819eb.k1112; bh=8yrvWgvF+YYojPcQvWvmuDcoED3Qyc/wE81WHrWLrNs=; b=J4FHbRU3liC1L9KFSjD6sasmKVl7I7OhVfY9+ccHbLjb/2O2ipvh6BKInwh+Hw/hQtKNNxkNl8UKeW4nyKm7ZJk18eQgoItj1dcWAdWg6PNsfUEC6sXy2pORZzkLMybPKfG7o/3eI0xDZ6cCc+2PPdhmJ3TktSa6x43rtu85vHs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Dec 2011 03:36:53 -0000 Date: 13 Dec 2011 22:37:15 -0500 Message-ID: From: "John R Levine" To: "ARF mailing list" User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [marf] comments on draft-ietf-marf-authfailure-report-06 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 03:37:17 -0000 I see there's a new version of authfailure-report. Overall it's getting there, but it still has some severe confusion about RFC 2119 language. In 2119-ese, MUST means that if you don't do that, it won't interoperate at all so don't even try. In section 3.1 of the draft: Authentication-Results: Syntax as specified in [ARF]. Furthermore, [ARF] specifies this field is OPTIONAL and appears at most once; for this extension, this field MUST be present if that value is available. It MUST be formatted according to [AUTH-RESULTS], and MUST reflect only a single email authentication method failure. The ARF RFC doesn't define Authentication-results, RFC 5451 does. I don't understand what "MUST be present if that value is available" means. Referring to 2119, it would mean that if you have cruddy software that doesn't record the auth results so the value isn't available, it's OK to send a report without it, but if do you have it available but don't want to send it, you can't send a report at all, which is silly. I understand that some people really really REALLY want their reports to be unredacted, but as we discussed a month or two ago, reporters will send what they're willing to send and no more, regardless of what an RFC says. In fact, an auth failure report without this info is often entirely usable, so just delete this paragraph. To report multiple failures for a single message, multiple reports MUST be generated. That sentence says that if you have multiple failures you have to report all of them, or else don't report anything. Move it to just above section 3.1 and change it to: A single report describes a single authentication failure. Multiple reports MAY be used to report multiple failures for a single message. Then there are several sections like this one with the same MUST language: Original-Envelope-Id: Syntax as specified in [ARF]. Furthermore, [ARF] specifies this field is OPTIONAL and appears at most once; for this extension, this field MUST be present if that value is available. The next three similar paragraphs cover Original-Mail-From, Source-IP, and Reported-Domain. Same problem, same solution, delete all four of them. I suppose you could say something like it is RECOMMENDED to include these items to help better diagnose the authentication failure. In Section 4, the ABNF, the definition of auth-failure both says that a token is one of a list of types and that it's imported from [MIME]. Importing seems wrong since that suggests it can be any tokenish string, but there's nothing that says that unknown auth-failure types are ignored. Suggest removing the references to token and instead enumerate the failure types, similar to the list of delivery results just below it. dkim-selector is also defined as a token, but actually it's a sub-domain. Import it from [DKIM]. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From msk@cloudmark.com Tue Dec 13 21:45:51 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9674521F84DB for ; Tue, 13 Dec 2011 21:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 S-drv9yX5LdD for ; Tue, 13 Dec 2011 21:45:50 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D748421F8463 for ; Tue, 13 Dec 2011 21:45:50 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 13 Dec 2011 21:45:50 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 13 Dec 2011 21:45:49 -0800 From: "Murray S. Kucherawy" To: ARF mailing list Date: Tue, 13 Dec 2011 21:45:50 -0800 Thread-Topic: [marf] comments on draft-ietf-marf-authfailure-report-06 Thread-Index: Acy6EbIEkQhZjiXKQHq9FaNFp38YcwADk8Yg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 05:45:51 -0000 For the sake of expediency, I'm helping Hilda with some of these edits. > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= ohn R Levine > Sent: Tuesday, December 13, 2011 7:37 PM > To: ARF mailing list > Subject: [marf] comments on draft-ietf-marf-authfailure-report-06 >=20 > I see there's a new version of authfailure-report. Overall it's > getting there, but it still has some severe confusion about RFC 2119 > language. In 2119-ese, MUST means that if you don't do that, it won't > interoperate at all so don't even try. >=20 > In section 3.1 of the draft: >=20 > Authentication-Results: Syntax as specified in [ARF]. Furthermore, > [ARF] specifies this field is OPTIONAL and appears at most once; > for this extension, this field MUST be present if that value is > available. It MUST be formatted according to [AUTH-RESULTS], and > MUST reflect only a single email authentication method failure. >=20 > The ARF RFC doesn't define Authentication-results, RFC 5451 does. >=20 > I don't understand what "MUST be present if that value is available" > means. I imagine it's copied from the others. The point there is that for SPF (fo= r example), the client IP is needed to paint the whole picture, but for a D= KIM report it isn't, and in either case it may not be available. Same for = the other parameters; different filtering points in the handling chain have= access to different subsets of them. > Referring to 2119, it would mean that if you have cruddy software that > doesn't record the auth results so the value isn't available, it's OK > to send a report without it, but if do you have it available but don't > want to send it, you can't send a report at all, which is silly. I > understand that some people really really REALLY want their reports to > be unredacted, but as we discussed a month or two ago, reporters will > send what they're willing to send and no more, regardless of what an > RFC says. In fact, an auth failure report without this info is often > entirely usable, so just delete this paragraph. Do you really mean "delete this paragraph"? Because we do want the field t= o be there. RFC5451 gives a standard way to report this result, so it make= s sense to either require that it be there, or don't send a report at all. What about: "Syntax as specified in . Furthermore, specifies this field is OPTIONAL and appears at most onc= e; for this extension, this field MUST be present, but MUST reflect only a single authentication method's result." > To report multiple failures for a single message, multiple reports > MUST be generated. >=20 > That sentence says that if you have multiple failures you have to > report all of them, or else don't report anything. Move it to just > above section 3.1 and change it to: >=20 > A single report describes a single authentication failure. > Multiple reports MAY be used to report multiple failures for a > single message. That works. > Then there are several sections like this one with the same MUST > language: >=20 > Original-Envelope-Id: Syntax as specified in [ARF]. Furthermore, > [ARF] specifies this field is OPTIONAL and appears at most once; > for this extension, this field MUST be present if that value is > available. >=20 > The next three similar paragraphs cover Original-Mail-From, Source-IP, > and Reported-Domain. Same problem, same solution, delete all four of the= m. > I suppose you could say something like it is RECOMMENDED to include > these items to help better diagnose the authentication failure. I'd prefer that last approach. I didn't like the MUST either, but I appear= ed to be in the minority. > In Section 4, the ABNF, the definition of auth-failure both says that a > token is one of a list of types and that it's imported from [MIME]. > Importing seems wrong since that suggests it can be any tokenish > string, but there's nothing that says that unknown auth-failure types > are ignored. > Suggest removing the references to token and instead enumerate the > failure types, similar to the list of delivery results just below it. That works. > dkim-selector is also defined as a token, but actually it's a sub- > domain. > Import it from [DKIM]. Actually it's even easier to just import "selector" from [DKIM]. -MSK From sklist@kitterman.com Tue Dec 13 22:01:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA35321F8AD2 for ; Tue, 13 Dec 2011 22:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ncU5PKoZL+GA for ; Tue, 13 Dec 2011 22:01:29 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BE30321F8ACE for ; Tue, 13 Dec 2011 22:01:29 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 421D320E40D8; Wed, 14 Dec 2011 01:01:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1323842466; bh=TKSYGxvR6+7n0BG3ogiI7pmB0UQ75mZWiWahT48LYHQ=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:Content-Type; b=T9kT3LXU+zuq5/RwGCAW0DwVNGDGSq2Hh+DfFPeQ38iUzCLwhZyfRfJjeUR/XbFvp uHqlUavdIkNne68KROKdV8WkyrDQrgDpexYkOU7GOAhpUCNJ/6vKLVW27K+STdoQ1m ICwENNdxbP8T7OURb8/b4n+vYmpHNYXUONh01zfk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 26D9F20E4081; Wed, 14 Dec 2011 01:01:05 -0500 (EST) From: Scott Kitterman To: marf@ietf.org Date: Wed, 14 Dec 2011 01:01:05 -0500 Message-ID: <3379412.7XsuK7WMsi@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [marf] Fwd: I-D Action: draft-ietf-marf-spf-reporting-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 06:01:30 -0000 This is still the most recent version of the SPF reporting draft. I went back and looked and the only open item I'm aware of dealing with the RFC 4408 downref. It turns out the discussion about if r= should use a full email address or just a localpart were before this draft, so I think the draft reflects what I viewed as the predominate view (I'm quite prepared to find out I was wrong). While people are in the fram of mind of review MARF drafts, please give this one a once over and let me know if anything else needs to be addressed. Scott K ---------- Forwarded Message ---------- Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-02.txt Date: Monday, October 24, 2011, 08:29:30 AM From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: marf@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF. Title : SPF Authentication Failure Reporting using the Abuse Report Format Author(s) : Scott Kitterman Filename : draft-ietf-marf-spf-reporting-02.txt Pages : 14 Date : 2011-10-24 This memo presents extensions to the Abuse Reporting Format (ARF), and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-02.txt _______________________________________________ marf mailing list marf@ietf.org https://www.ietf.org/mailman/listinfo/marf ----------------------------------------- From vesely@tana.it Wed Dec 14 04:55:08 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308B221F8B37 for ; Wed, 14 Dec 2011 04:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 CC5NIhVc3b89 for ; Wed, 14 Dec 2011 04:55:07 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 270F521F8B3F for ; Wed, 14 Dec 2011 04:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323867304; bh=nTCgdwSTiJSQt4IgEhLiilsas7tSpppOaNEqQPp4GIw=; l=4096; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=MMO1hgNJ/zJZoPc41k3nitB7s/z3pAZXlSwztgeDRHMxqEL73g3MYTrbMhBPto8oM Bh+BPWMZ7cJRHaoRIMAx3vjbvVBtFMGmZGMaLt1YoyYCn4k4epmVeZqIUFjbAlM9bZ cuQTUBxHGXoHb4Mc6VE03OcdI7C6KL6ZZyYGd+9I= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 14 Dec 2011 13:55:04 +0100 id 00000000005DC033.000000004EE89CA8.0000701D Message-ID: <4EE89CA7.6080301@tana.it> Date: Wed, 14 Dec 2011 13:55:03 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 12:55:08 -0000 On 14/Dec/11 06:45, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of John R Levine > > [...] RFC5451 gives a standard way to report this result, so it > makes sense to either require that it be there, or don't send a > report at all. > > What about: > > "Syntax as specified in . > Furthermore, specifies this field is OPTIONAL > and appears at most once; for this extension, this field MUST be > present, but MUST reflect only a single authentication method's > result." +1, let me try to further improve that: The syntax is as specified in . While specifies this field is OPTIONAL and appears at most once, for this extension this field MUST be present: it MUST reflect the single email authentication method failure that is being reported, and only that. >> Move [the rest of the paragraph] to just above section 3.1 and >> change it to: >> >> A single report describes a single authentication failure. >> Multiple reports MAY be used to report multiple failures for >> a single message. > > That works. +1, but that way we loose the correlation with the A-R field. In addition, the document structure is not clear-cut. Section 3.1 has a title of *New ARF Feedback Type* while it is actually redefining header fields. Indeed, its anchor is "arf-fields". The first two-liner paragraph is the only justification for the section's title. It says "See Section 3.3 for details", which is probably a typo as that reference is deceptive here --Section 3.3 defines the possible values of the new header field Auth-Failure, whose name spells the same as the new value of Feedback-Type being thus introduced. I'd propose to slightly reorganize Section 3 like so: * Change the title of current Section 3 (anchor="arf-extend") to something like "Definition of the Extension", i.e. not just the fields. * Move the last subsection of Section 2 as the first one here, changing its title and wording, e.g. as follows:
There are technologies in email security that provide authentication services and some that do authorization. These are often conflated. A discussion of this that is useful for establishing context can be found in Section 1.5.2 in . The failures that can be reported using this extension correspond to ' methods appearing in the "Email Authentication Methods" IANA registry, or parts thereof. A single report describes a single authentication failure. Multiple reports MAY be used to report multiple failures for a single message.
* Change the title of the current Section 3.1 (anchor="arf-fields", which would be renumbered to 3.2) to something like "Modified Header Fields". * Insert a new bullet for the type, e.g. Reports formatted according to this extension MUST have the new type "auth-failure". Please remove the last bullet from that list, Delivery-Result. There is already a paragraph devoted to it in the current Section 3.2.2 (anchor="arf-headers-2"), where it belongs. For the other bullets, IMHO it makes more sense to specify precisely what value for what method should be reported in which header field, than trying to change their 2119 status. In case we wish to defer precise specifications to method-specific RFCs, we should defer to them any related 2119 considerations as well. Reported-URI is never mentioned in the document, except in the example. Please remove it from there too. Lastly, in the *IANA Considerations* section the names are not exact: In Section 5.1, s/Feedback Report Feedback Type Registry/"Feedback Report Type Values" registry/ and s/Feedback Type:/Feedback Type Name:/. In Section 5.2, s/Feedback Report Header Names Registry/"Feedback Report Header Fields" registry/. From vesely@tana.it Wed Dec 14 09:01:16 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C613321F8B63 for ; Wed, 14 Dec 2011 09:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.99 X-Spam-Level: X-Spam-Status: No, score=-3.99 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 Rhte7OjZSVAM for ; Wed, 14 Dec 2011 09:01:16 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1010D21F8B5A for ; Wed, 14 Dec 2011 09:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323882071; bh=cszrBcJLvntB5bnZo4GCQNdHNd1EBgM60KIPPdzGjaE=; l=1795; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=bQPWAl/9YnCGkJtFKxUl5LaV/XAHaMFdQeFBCzD9pMUfNu3TjZtck2ANBQl8KYhsn pky7h2Q49KwjLu9HORsb3PFF4rzsvA2OkTPJYsGMsM8SGcXzI82HPbP2lbfKVao/EM TEx7GqvQ70pEBqX8S9r4SbBV9ueRO/Ayz7K/TJzs= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 14 Dec 2011 18:01:11 +0100 id 00000000005DC039.000000004EE8D657.00006464 Message-ID: <4EE8D657.70408@tana.it> Date: Wed, 14 Dec 2011 18:01:11 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <4EDE7ED2.3090401@kitterman.com> <4EE0755E.6020305@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Moving spf-reporting to spfbis, was Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 17:01:16 -0000 On 08/Dec/11 19:21, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely > >>> SPFbis: I'm waiting for the charter discussion to settle out so that >>> I know how to deal with the downref issue to RFC 4408. If the charter >>> lands the way I think it will, I think allowing a downref is >>> justifiable. >> >> Some coordination can be fruitful here. For example, if there will be >> methods to report certain circumstances to the domain owners, then some >> features of SPF that are only used for monitoring those circumstances >> could be safely deprecated. Contribution to such monitoring is >> spontaneous and consenting in either case, but decoupling it from SPF >> checking may remove an impediment toward broader adoption. > > We have a few options here: > > a) Downgrade spf-reporting to Experimental. > > b) Pursue spf-reporting publication on the Standards Track, > acknowledging the downref. > > c) Pursue spf-reporting publication on the Standards Track, > referencing SPFbis instead of RFC4408. This will cause > spf-reporting to be held by the RFC Editor until SPFbis publishes, > but it's still a path forward. I'd vote for option (c). SPFbis is not expected to bring fundamental changes to the protocol. However, together with spf-reporting it can compose enough of an innovation to imply some sort of revision by most alive implementations. Early adopters of authfailure-report can already see that SPF is one of the methods provided for, and code or plan accordingly. > It all depends on how much uptake we get in the short term. If > there isn't any, we might give (a) some serious consideration. > Same for dkim-reporting. I'd figure dkim-reporting can get out more or less together with authfailure-report. From sklist@kitterman.com Wed Dec 14 09:12:19 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7797C21F8B1C for ; Wed, 14 Dec 2011 09:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 e2A58pWT037y for ; Wed, 14 Dec 2011 09:12:18 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id B503721F8B10 for ; Wed, 14 Dec 2011 09:12:18 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 120AAD04053; Wed, 14 Dec 2011 11:12:18 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1323882738; bh=UGADM8/ANnrLTrtjoMIbBnqH8NRUlj6hdmo2PskZA8M=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=TdMeigISl0nTLFzU3ToSLm8S3xZJgtCNW2IRyTrsXv/wd/Ae0NCDhRaNEWyE1uriE 8dE2IqDQ8hCnjuK6U8oKCHbXPSsld8JixZj39eBJtIe8Dkuko8CriuyrfIES0JTvir MHbNnD1fINe5lmL3C8izoX4uxnRfK/Fslz6zvUlk= Received: from 25.sub-97-11-35.myvzw.com (25.sub-97-11-35.myvzw.com [97.11.35.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 16E42D0400B; Wed, 14 Dec 2011 11:12:16 -0600 (CST) References: <4EDE7ED2.3090401@kitterman.com> <4EE0755E.6020305@tana.it> <4EE8D657.70408@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: <4EE8D657.70408@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 14 Dec 2011 12:12:26 -0500 To: marf@ietf.org Message-ID: <13cc94fb-60d6-4bc4-8912-d3dd3fd4dcae@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Moving spf-reporting to spfbis, was Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 17:12:19 -0000 Alessandro Vesely wrote: >On 08/Dec/11 19:21, Murray S. Kucherawy wrote: >>> From: ietf.org On Behalf Of Alessandro Vesely >> >>>> SPFbis: I'm waiting for the charter discussion to settle out so >that >>>> I know how to deal with the downref issue to RFC 4408. If the >charter >>>> lands the way I think it will, I think allowing a downref is >>>> justifiable. >>> >>> Some coordination can be fruitful here. For example, if there will >be >>> methods to report certain circumstances to the domain owners, then >some >>> features of SPF that are only used for monitoring those >circumstances >>> could be safely deprecated. Contribution to such monitoring is >>> spontaneous and consenting in either case, but decoupling it from >SPF >>> checking may remove an impediment toward broader adoption. >> >> We have a few options here: >> >> a) Downgrade spf-reporting to Experimental. >> >> b) Pursue spf-reporting publication on the Standards Track, >> acknowledging the downref. >> >> c) Pursue spf-reporting publication on the Standards Track, >> referencing SPFbis instead of RFC4408. This will cause >> spf-reporting to be held by the RFC Editor until SPFbis publishes, >> but it's still a path forward. > >I'd vote for option (c). SPFbis is not expected to bring fundamental >changes to the protocol. However, together with spf-reporting it can >compose enough of an innovation to imply some sort of revision by most >alive implementations. > >Early adopters of authfailure-report can already see that SPF is one >of the methods provided for, and code or plan accordingly. > >> It all depends on how much uptake we get in the short term. If >> there isn't any, we might give (a) some serious consideration. >> Same for dkim-reporting. > >I'd figure dkim-reporting can get out more or less together with >authfailure-report. My plan is to work towards option (b) unless there's some better consensus developed around one of the other choices. Option (a) would require an update later after 4408bis is published. Since there's almost no chance (given the way the SPFbis charter discussions are going) that 4408bis will be materially different relative to this group's work, I think such an update wouldn't be a low value added use of time. Similarly, I think waiting for 4408bis to publish would be pointless waiting. I'm aware of likely implementors and waiting won't help them either. Scott K From dotzero@gmail.com Wed Dec 14 09:59:58 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487EE21F8B4C for ; Wed, 14 Dec 2011 09:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 AH2qe5AGtQyG for ; Wed, 14 Dec 2011 09:59:57 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1B8B21F8B02 for ; Wed, 14 Dec 2011 09:59:57 -0800 (PST) Received: by dajz8 with SMTP id z8so1103901daj.31 for ; Wed, 14 Dec 2011 09:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2wLyaTD0ZC6h8M/t4OaEyB6S6qQYmt74CedKLbLZdyE=; b=KSPVB16sg3iA6vhkKryJPUbVcKPqCdWuIgTqGe5nkGpjIbOeT1ry/kTIagx09rFykP JfEzKe9t13IvPu851ycmV2jfd0SPgSBtWpoV8Vzzd5tNAgMsV/2R6XgjNjw1Gpec18Gn PnSUj4E8YDciFgmICXiRYSt+Rwa0304H+AdlY= MIME-Version: 1.0 Received: by 10.68.120.72 with SMTP id la8mr4718379pbb.56.1323885597496; Wed, 14 Dec 2011 09:59:57 -0800 (PST) Received: by 10.143.82.20 with HTTP; Wed, 14 Dec 2011 09:59:57 -0800 (PST) In-Reply-To: <13cc94fb-60d6-4bc4-8912-d3dd3fd4dcae@email.android.com> References: <4EDE7ED2.3090401@kitterman.com> <4EE0755E.6020305@tana.it> <4EE8D657.70408@tana.it> <13cc94fb-60d6-4bc4-8912-d3dd3fd4dcae@email.android.com> Date: Wed, 14 Dec 2011 12:59:57 -0500 Message-ID: From: Dotzero To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Moving spf-reporting to spfbis, was Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 17:59:58 -0000 On Wed, Dec 14, 2011 at 12:12 PM, Scott Kitterman wr= ote: > > > My plan is to work towards option (b) unless there's some better consensu= s developed around one of the other choices. > > Option (a) would require an update later after 4408bis is published. Sinc= e there's almost no chance (given the way the SPFbis charter discussions ar= e going) that 4408bis will be materially different relative to this group's= work, I think such an update wouldn't be a low value added use of time. > > Similarly, I think waiting for 4408bis to publish would be pointless wait= ing. I'm aware of likely implementors and waiting won't help them either. > > Scott K > This makes the msot sense to me. Mike From shmuel+gen@patriot.net Wed Dec 14 10:04:51 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0AD1F0C5E for ; Wed, 14 Dec 2011 10:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_20=-0.74] 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 22JbRr3RAvv0 for ; Wed, 14 Dec 2011 10:04:51 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 507EA1F0C52 for ; Wed, 14 Dec 2011 10:04:51 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.226]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 25EAAF580A9 for ; Wed, 14 Dec 2011 12:51:49 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 14 Dec 2011 13:06:50 -0500 To: marf@ietf.org In-Reply-To: <13cc94fb-60d6-4bc4-8912-d3dd3fd4dcae@email.android.com> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111214175150.25EAAF580A9@smtp.patriot.net> Subject: Re: [marf] Moving spf-reporting to spfbis, was Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 18:04:52 -0000 In <13cc94fb-60d6-4bc4-8912-d3dd3fd4dcae@email.android.com>, on 12/14/2011 at 12:12 PM, Scott Kitterman said: >My plan is to work towards option (b) unless there's some better >consensus developed around one of the other choices. Well, my preference is (c), but I understand your reasoning in favor of (b). -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From sklist@kitterman.com Wed Dec 14 10:07:50 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE06D1F0C52 for ; Wed, 14 Dec 2011 10:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 BuCj+9zKKYZ3 for ; Wed, 14 Dec 2011 10:07:42 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 13FE91F0C5D for ; Wed, 14 Dec 2011 10:07:42 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 9915820E40D8; Wed, 14 Dec 2011 13:07:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1323886059; bh=txeLJ2Z9lsrf8ZhuLSWjUwdpaP3Bp1hY/EfPI9Pwogs=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=E8OOMzO1frGQad4RPdnwvXDoPnulDgb3q+cwRhXCNt6k2t1/a8jTa2fgsL4zu9Njp mUw5uIw0EbSEKh+/928dYoSIu93nc5Vf027bzNi6nZheRmK5gzDsTMhKlPpGG9y/c7 7x+d77HcjDSD8EGF1QCTEiM3gDAJmOK0cD62/peI= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 7A88B20E4043; Wed, 14 Dec 2011 13:07:39 -0500 (EST) From: Scott Kitterman To: Message Abuse Report Format working group Date: Wed, 14 Dec 2011 13:07:38 -0500 Message-ID: <1583168.MvJ9QDlkAC@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <20111214175150.25EAAF580A9@smtp.patriot.net> References: <20111214175150.25EAAF580A9@smtp.patriot.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] Moving spf-reporting to spfbis, was Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 18:07:50 -0000 On Wednesday, December 14, 2011 01:06:50 PM Shmuel Metz wrote: > In <13cc94fb-60d6-4bc4-8912-d3dd3fd4dcae@email.android.com>, on > 12/14/2011 > > at 12:12 PM, Scott Kitterman said: > >My plan is to work towards option (b) unless there's some better > >consensus developed around one of the other choices. > > Well, my preference is (c), but I understand your reasoning in favor > of (b). There's no guarantee that the downref will be acceptable. If not, (c) would be my fall back plan if it were just up to me. Scott K From msk@cloudmark.com Wed Dec 14 10:40:31 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC92A1F0C5D for ; Wed, 14 Dec 2011 10:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 WmDb3YshL7Nr for ; Wed, 14 Dec 2011 10:40:31 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7541F0C4F for ; Wed, 14 Dec 2011 10:40:31 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Dec 2011 10:40:31 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 14 Dec 2011 10:40:30 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 14 Dec 2011 10:40:29 -0800 Thread-Topic: [marf] Moving spf-reporting to spfbis, was Working group status Thread-Index: Acy6gf/zawa8c21QT3qeWjUvkfRfPgADcE9A Message-ID: References: <4EDE7ED2.3090401@kitterman.com> <4EE0755E.6020305@tana.it> <4EE8D657.70408@tana.it> In-Reply-To: <4EE8D657.70408@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Moving spf-reporting to spfbis, was Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 18:40:32 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, December 14, 2011 9:01 AM > To: marf@ietf.org > Subject: Re: [marf] Moving spf-reporting to spfbis, was Working group sta= tus >=20 > I'd figure dkim-reporting can get out more or less together with > authfailure-report. Given the small amount of feedback on it so far, most of which suggests a c= omplete revision of the approach, that doesn't seem likely. From msk@cloudmark.com Wed Dec 14 10:55:58 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC4421F85C7 for ; Wed, 14 Dec 2011 10:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 w1Hh183lnfTB for ; Wed, 14 Dec 2011 10:55:58 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 31AAF21F85A8 for ; Wed, 14 Dec 2011 10:55:58 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Dec 2011 10:55:58 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 14 Dec 2011 10:55:57 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 14 Dec 2011 10:55:56 -0800 Thread-Topic: [marf] comments on draft-ietf-marf-authfailure-report-06 Thread-Index: Acy6X6RUqoJAc5VwRNe4MI96VEWPhQAMbvoQ Message-ID: References: <4EE89CA7.6080301@tana.it> In-Reply-To: <4EE89CA7.6080301@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 18:55:58 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, December 14, 2011 4:55 AM > To: marf@ietf.org > Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 > > [Section 2 and Section 3 stuff] Thanks for your suggestions. However, I think the layout of the sections w= hose revisions you proposed are sufficient as-is. After two working group = last calls and too many revisions, I think we're long past the point where = we should be worried about arrangement of the material unless it's actually= seriously wrong. > Reported-URI is never mentioned in the document, except in the example. > Please remove it from there too. I disagree that this is necessary. We're not saying other ARF fields aren'= t allowed here, are we? If they're allowed in ARF, they're allowed here (u= nless we've explicitly said otherwise, and we haven't). > Lastly, in the *IANA Considerations* section the names are not exact: >=20 > In Section 5.1, s/Feedback Report Feedback Type Registry/"Feedback > Report Type Values" registry/ and s/Feedback Type:/Feedback Type > Name:/. >=20 > In Section 5.2, s/Feedback Report Header Names Registry/"Feedback > Report Header Fields" registry/. Quite right; fixed both. If there's nothing else, I plan to get Hilda to post -07 soon and I'll have= it over to the IESG shortly thereafter. We should turn our editing energy= to the remaining documents. -MSK From vesely@tana.it Wed Dec 14 11:04:29 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0631F0C4F for ; Wed, 14 Dec 2011 11:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.576 X-Spam-Level: X-Spam-Status: No, score=-4.576 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 cbrRlu-h8gAC for ; Wed, 14 Dec 2011 11:04:29 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C0E0C1F0C40 for ; Wed, 14 Dec 2011 11:04:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323889467; bh=bpXkqplt71rXQqCiEBhAwdWMHyoPIV6DBtMet01KVY0=; l=1376; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=i/btBqxYY6i4VJiX2/AGIbcQ9cDFo31qcjYvvUm3mt6oMyAOpv0KhF6ognJbzqVzq xtDniuAwHxqsTI60JG5G9Eg/1AJt3II3txaxhprNssj7mMzzJfte/iARu0d/9/M/PQ WWKG2jFZ8TXL2oHDZnWGg0Iol2QOUOEuCLr69oZc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 14 Dec 2011 20:04:27 +0100 id 00000000005DC033.000000004EE8F33B.00001F7C Message-ID: <4EE8F33B.2060008@tana.it> Date: Wed, 14 Dec 2011 20:04:27 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <4EDE7ED2.3090401@kitterman.com> <4EE0755E.6020305@tana.it> <4EE8D657.70408@tana.it> <13cc94fb-60d6-4bc4-8912-d3dd3fd4dcae@email.android.com> In-Reply-To: <13cc94fb-60d6-4bc4-8912-d3dd3fd4dcae@email.android.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] Moving spf-reporting to spfbis, was Working group status X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 19:04:29 -0000 On 14/Dec/11 18:12, Scott Kitterman wrote: > Alessandro Vesely wrote: >>On 08/Dec/11 19:21, Murray S. Kucherawy wrote: >>> >>> We have a few options here: >>> >>> a) Downgrade spf-reporting to Experimental. >>> >>> b) Pursue spf-reporting publication on the Standards Track, >>> acknowledging the downref. >>> >>> c) Pursue spf-reporting publication on the Standards Track, >>> referencing SPFbis instead of RFC4408. This will cause >>> spf-reporting to be held by the RFC Editor until SPFbis publishes, >>> but it's still a path forward. >> >>I'd vote for option (c). SPFbis is not expected to bring fundamental >>changes to the protocol. However, together with spf-reporting it can >>compose enough of an innovation to imply some sort of revision by most >>alive implementations. >> >>Early adopters of authfailure-report can already see that SPF is one >>of the methods provided for, and code or plan accordingly. > > My plan is to work towards option (b) unless there's some better > consensus developed around one of the other choices. > > Option (a) [...] > > Similarly, I think waiting for 4408bis to publish would be > pointless waiting. I'm aware of likely implementors and waiting > won't help them either. In that case, it's fine to go for option (b). I'm going to ask this question on the other list, anyway. From vesely@tana.it Wed Dec 14 11:31:16 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE5021F84AA for ; Wed, 14 Dec 2011 11:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.593 X-Spam-Level: X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 IqJqvDh+U3xQ for ; Wed, 14 Dec 2011 11:31:15 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 659E321F849B for ; Wed, 14 Dec 2011 11:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323891072; bh=dQAf5Fx558ufgDteXbRRbAOHM87db5ge1I/2nZpXptI=; l=1554; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=PFwEc1t2Z6J+D1Z8rJCAK89F/lnvmUTwbYlgVjndFnTsmsZ6KSgjNU8rwYcxn5Yju xKeWa2GMpwT97MFgUSc/Q6PeAOBI8Qtm0A0PpCBI7E+YH5aqSJsb02bieahYRCUaEx iOI1K83q9gVumJHE9vNgwiPw0O7taiDJVXeOOuHg= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 14 Dec 2011 20:31:12 +0100 id 00000000005DC033.000000004EE8F980.00001BF4 Message-ID: <4EE8F980.3010400@tana.it> Date: Wed, 14 Dec 2011 20:31:12 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <4EE89CA7.6080301@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 19:31:16 -0000 On 14/Dec/11 19:55, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >> [Section 2 and Section 3 stuff] > > Thanks for your suggestions. However, I think the layout of the > sections whose revisions you proposed are sufficient as-is. After > two working group last calls and too many revisions, I think we're > long past the point where we should be worried about arrangement of > the material unless it's actually seriously wrong. The proposed layout change is minimal, in spite of my lengthy description of it. As it retains the role of A-R fields, the result is more semantically similar to -06 than accomplishing John's move otherwise --unless you have a better solution, of course. However, Section 3.1's title and its reference to Section 3.3 /are/ seriously wrong. >> Reported-URI is never mentioned in the document, except in the example. >> Please remove it from there too. > > I disagree that this is necessary. We're not saying other ARF > fields aren't allowed here, are we? By omitting to exemplify them we don't imply they are not allowed. ARF mentions "a suspect URI that was found in the message that caused the report to be generated", not a synthesized URI, e.g. obtained by prepending "http://www." to a random domain-like string :-/ > If they're allowed in ARF, they're allowed here (unless we've > explicitly said otherwise, and we haven't). Agreed. But if we are unable to imagine any plausible value for that field, we'd better not to mention it at all, IMHO. From msk@cloudmark.com Wed Dec 14 11:56:50 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C3A21F8A66 for ; Wed, 14 Dec 2011 11:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 v7qYaVdstCCd for ; Wed, 14 Dec 2011 11:56:50 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 61EA121F8A64 for ; Wed, 14 Dec 2011 11:56:50 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Dec 2011 11:56:50 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 14 Dec 2011 11:56:49 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 14 Dec 2011 11:56:48 -0800 Thread-Topic: [marf] comments on draft-ietf-marf-authfailure-report-06 Thread-Index: Acy6lvRrkeOlI+NJTgaOmjfNpoCQewAAkKww Message-ID: References: <4EE89CA7.6080301@tana.it> <4EE8F980.3010400@tana.it> In-Reply-To: <4EE8F980.3010400@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 19:56:50 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Wednesday, December 14, 2011 11:31 AM > To: marf@ietf.org > Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 >=20 > The proposed layout change is minimal, in spite of my lengthy > description of it. As it retains the role of A-R fields, the result is > more semantically similar to -06 than accomplishing John's move > otherwise --unless you have a better solution, of course. However, > Section 3.1's title and its reference to Section 3.3 /are/ seriously > wrong. The creation of this new ARF type comprises a bunch of extension fields and= their definitions, and little else. Therefore, "Extension ARF Fields for = Authentication Failure Reporting" seems perfectly good. Similarly, the doc= ument recognizes five specific types of authentication failures about which= reports can be generated, and thus the title "Authentication Failure Types= " seems a perfectly good title for a section in which to enumerate them. I fail to see how either of these are wrong at all, let alone seriously. My solution is to use John's suggestion and make no other changes, absent a= ny consensus that pushes for what you're suggesting. Otherwise, we can die= nitting on this minor stuff and never get it out the door. > ARF mentions "a suspect URI that was found in the message that caused > the report to be generated", not a synthesized URI, e.g. obtained by > prepending "http://www." to a random domain-like string :-/ The third part of the report only contains the header of the message causin= g the report to be generated, which RFC5965 allows. Presumably, then, the = reported URI came from someplace in the body of the message, which isn't sh= own here (and doesn't need to be, by ARF's definitions). -MSK From vesely@tana.it Thu Dec 15 11:05:27 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C4721F8564 for ; Thu, 15 Dec 2011 11:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.606 X-Spam-Level: X-Spam-Status: No, score=-4.606 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 7kNZfurGg7od for ; Thu, 15 Dec 2011 11:05:26 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 22EDF21F8562 for ; Thu, 15 Dec 2011 11:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1323975925; bh=2qa4xsQnhc+hnMjaEonaDzKQ9bbTW+Jlv6i8x/R2RoQ=; l=3905; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=MjsbzS915HQucoclvwJy6pMO3MkifywvI0mAUMl3fKjJwdmGu4jbOkfNkaFut11Co zZfZ1V76aSWF0f8wflfHg4WkDYjTwM7NzpjhG2ilXC8ICm5Ux3TcdOzMFDeVFhvZlu efSf2bAdTTVuiZ6McLEOIS48PYt0DjN/gILBohd8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 15 Dec 2011 20:05:25 +0100 id 00000000005DC03F.000000004EEA44F5.00001FE0 Message-ID: <4EEA44F4.7060005@tana.it> Date: Thu, 15 Dec 2011 20:05:24 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <4EE89CA7.6080301@tana.it> <4EE8F980.3010400@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 19:05:27 -0000 On 14/Dec/11 20:56, Murray S. Kucherawy wrote: >> From: ietf.org On Behalf Of Alessandro Vesely >> >> Section 3.1's title and its reference to Section 3.3 /are/ seriously >> wrong. > > The creation of this new ARF type comprises a bunch of extension > fields and their definitions, and little else. Therefore, > "Extension ARF Fields for Authentication Failure Reporting" seems > perfectly good. The last two paragraphs of Section 3.1 are not related to any specific field. In addition, since you agreed to move the sentences that describe the failure-to-report relationship "to just above section 3.1" --thereby decoupling them from the A-R field-- Section 3 will host one more statement which is about the overall semantics rather than any specific field. That title is at least misleading. > Similarly, the document recognizes five specific types of > authentication failures about which reports can be generated, and > thus the title "Authentication Failure Types" seems a perfectly > good title for a section in which to enumerate them. Yes it is. I meant the second sentence in the first paragraph of Section 3.1: A new feedback type of "auth-failure" is defined as an extension to Section 8.2 of [ARF]. See Section 3.3 for details. > I fail to see how either of these are wrong at all, let alone seriously. That quoted paragraph says that the details of "auth-failure" consist of the possible values of Auth-Failure. Isn't it wrong? BTW, Section 8.2 of [ARF] is about the *Interpretation* of the report format. You probably mean Section 7.3 (but shouldn't such reference belong to the IANA Considerations section?) After those two lines, the section continues with several fields specifications. Not all fields, just some. A reader may wander why Delivery-Result is listed here while Auth-Failure itself is not. A title of "New ARF Feedback Type" doesn't help. BTW, the specification of Delivery-Result is in Section 3.2.2, not 3.2.1. > My solution is to use John's suggestion and make no other changes, > absent any consensus that pushes for what you're suggesting. > Otherwise, we can die nitting on this minor stuff and never get it > out the door. My purpose is not to delay the publication. I'm replying because I think you misunderstood what I said. If I had been nitting, I would have contested the entanglement of defining a field in Section 3.2.1 postponing the discussion of its content to Section 3.3, while it would have made for easier reading (and writing) to have that field defined and discussed in a single place. >> ARF mentions "a suspect URI that was found in the message that caused >> the report to be generated", not a synthesized URI, e.g. obtained by >> prepending "http://www." to a random domain-like string :-/ > > The third part of the report only contains the header of the > message causing the report to be generated, which RFC5965 allows. > Presumably, then, the reported URI came from someplace in the body > of the message, which isn't shown here (and doesn't need to be, by > ARF's definitions). For that to hold, you may want to add l=53 to the DKIM-Signature, or replace the following field DKIM-Canonicalized-Body: VGhpcyBpcyBhIG1lc3NhZ2UgYm9ke SB0aGF0IGdvdCBtb2RpZmllZCBpbiB0cmFuc2l0LgoKQXQgdGhlIH NhbWUgdGltZSB0aGF0IHRoZSBib2R5aGFzaCBmYWlscyB0byB2ZXJ pZnksIHRoZQptZXNzYWdlIGNvbnRlbnQgaXMgY2xlYXJseSBhYnVz aXZlIG9mIHBoaXNoeSwgYXMgdGhlClN1YmplY3QgYWxyZWFkeSBoa W50cy4gIEluZGVlZCwgdGhpcyBib2R5IGFsc28gY29udGFpbnMKdG hlIGZvbGxvd2luZyB0ZXh0CgogICBQbGVhc2UgZW50ZXIgeW91ciB mdWxsIGJhbmsgY3JlZGVudGlhbHMgYXQKICAgaHR0cDovL3d3dy5z ZW5kZXIuZXhhbXBsZS8KCldlIGFyZSBpbXBseWluZyB0aGF0LCBhb HRob3VnaCBtdWx0aXBsZSBmYWlsdXJlcwpyZXF1aXJlIG11bHRpcG xlIHJlcG9ydHMsIGEgc2luZ2xlIGZhaWx1cmUgY2FuIGJlCnJlcG9 ydGVkIGFsb25nIHdpdGggcGhpc2hpbmcgaW4gYSBzaW5nbGUgcmVw b3J0Lgo= From msk@cloudmark.com Thu Dec 15 14:07:01 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D319221F8512 for ; Thu, 15 Dec 2011 14:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 QcuCAVV+6l-o for ; Thu, 15 Dec 2011 14:07:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 49DEE21F8510 for ; Thu, 15 Dec 2011 14:07:01 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 15 Dec 2011 14:07:00 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 15 Dec 2011 14:07:00 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 15 Dec 2011 14:06:59 -0800 Thread-Topic: [marf] comments on draft-ietf-marf-authfailure-report-06 Thread-Index: Acy7XIMZ2FLYnNbWQdCAT4PKCyUSOgAFuSwQ Message-ID: References: <4EE89CA7.6080301@tana.it> <4EE8F980.3010400@tana.it> <4EEA44F4.7060005@tana.it> In-Reply-To: <4EEA44F4.7060005@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 22:07:01 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Thursday, December 15, 2011 11:05 AM > To: marf@ietf.org > Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 >=20 > The last two paragraphs of Section 3.1 are not related to any specific > field. The section is entitled "New ARF Feedback Type", and those last two paragra= phs are discussing the report type and its structure. Seems legitimate to = me. > In addition, since you agreed to move the sentences that > describe the failure-to-report relationship "to just above section 3.1" > --thereby decoupling them from the A-R field-- Section 3 will host one > more statement which is about the overall semantics rather than any > specific field. That title is at least misleading. We aren't defining a whole new report format here. We're defining a new re= port type that has a few new fields but otherwise has the same format as an= y other ARF message. And the new report type itself is referenced in an ex= isting field. It's all about fields. But if it will get us to publication, how about calling it "ARF Extension f= or Authentication Failure Reporting"? > > Similarly, the document recognizes five specific types of > > authentication failures about which reports can be generated, and thus > > the title "Authentication Failure Types" seems a perfectly good title > > for a section in which to enumerate them. >=20 > Yes it is. I meant the second sentence in the first paragraph of > Section 3.1: >=20 > A new feedback type of "auth-failure" is defined as an extension to > Section 8.2 of [ARF]. See Section 3.3 for details. We can just remove the reference then. > BTW, Section 8.2 of [ARF] is about the *Interpretation* of the report > format. You probably mean Section 7.3 (but shouldn't such reference > belong to the IANA Considerations section?) Yes, "per Section 7.3" is probably more precise. > After those two lines, the section continues with several fields > specifications. Not all fields, just some. A reader may wander why > Delivery-Result is listed here while Auth-Failure itself is not. A > title of "New ARF Feedback Type" doesn't help. I don't agree. Section 3.1 defines the new feedback type and augments [ARF= ]'s field requirements. The latter is part of the former. > BTW, the specification of Delivery-Result is in Section 3.2.2, not > 3.2.1. Right, fixed. > > The third part of the report only contains the header of the message > > causing the report to be generated, which RFC5965 allows. > > Presumably, then, the reported URI came from someplace in the body of > > the message, which isn't shown here (and doesn't need to be, by ARF's > > definitions). >=20 > For that to hold, you may want to add l=3D53 to the DKIM-Signature, or > replace the following field > [...] I updated it (had some typos), and replaced it in -07. Thanks. -MSK From vesely@tana.it Fri Dec 16 02:50:14 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CA521F8B25 for ; Fri, 16 Dec 2011 02:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 20U056lKSOD5 for ; Fri, 16 Dec 2011 02:50:13 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C903821F8B24 for ; Fri, 16 Dec 2011 02:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324032610; bh=CEPNmsWRt7ynQsPAMJdcsNIpxhQJ9WKUxlf0bFGOjTw=; l=592; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=lGLJH5sNny5VJctv5U8SYfMjsbIgVLbpBll7aZwjN8Meuxy/JywtO2qjhTucag6pg WbMlUDnW8AWiJgMXhcbHYuivjVFaW/qfQQrM3MjwSGxBN7KNmewa9v1iG5R51oK0iW XFkbH51Bj/HNIHfM6b1PXYUND0lD5//G540iGgxI= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 16 Dec 2011 11:50:10 +0100 id 00000000005DC039.000000004EEB2262.000030CA Message-ID: <4EEB2264.8080900@tana.it> Date: Fri, 16 Dec 2011 11:50:12 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <4EE89CA7.6080301@tana.it> <4EE8F980.3010400@tana.it> <4EEA44F4.7060005@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 10:50:14 -0000 On 15/Dec/11 23:06, Murray S. Kucherawy wrote: > > We aren't defining a whole new report format here. We're defining > a new report type that has a few new fields but otherwise has the > same format as any other ARF message. And the new report type > itself is referenced in an existing field. It's all about fields. > > But if it will get us to publication, how about calling it "ARF > Extension for Authentication Failure Reporting"? Sounds great! Indeed, as a new type it will have its own semantics, usage, and FBL-setup criteria, albeit we don't want/merit to specify them. From internet-drafts@ietf.org Fri Dec 16 11:55:00 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3F911E8094; Fri, 16 Dec 2011 11:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 hKfhGSI5vfW4; Fri, 16 Dec 2011 11:55:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242EF11E8089; Fri, 16 Dec 2011 11:55:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111216195500.10319.14859.idtracker@ietfa.amsl.com> Date: Fri, 16 Dec 2011 11:55:00 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-07.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 19:55:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Authentication Failure Reporting using the Abuse Report = Format Author(s) : Hilda L. Fontana Filename : draft-ietf-marf-authfailure-report-07.txt Pages : 20 Date : 2011-12-15 This memo registers an extension report type to ARF, affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email authentication checks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-07.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-07.txt From msk@cloudmark.com Mon Dec 19 14:36:06 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E529911E80B1 for ; Mon, 19 Dec 2011 14:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 iMttlBi8Rqjg for ; Mon, 19 Dec 2011 14:36:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8A01711E8080 for ; Mon, 19 Dec 2011 14:36:06 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 19 Dec 2011 14:36:04 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 19 Dec 2011 14:36:05 -0800 From: "Murray S. Kucherawy" To: Alexey Melnikov Date: Mon, 19 Dec 2011 14:36:04 -0800 Thread-Topic: Last Call: (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Informational RFC Thread-Index: Acy3jeId5qxx4bB0ReqRpIfHDVWQ8gHEHUDA Message-ID: References: <20111201162104.1088.81619.idtracker@ietfa.amsl.com> <4EE3E1C2.6000103@isode.com> In-Reply-To: <4EE3E1C2.6000103@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Last Call: (Redaction of Potentially Sensitive Data from Mail Abuse Reports) to Informational RFC X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:36:07 -0000 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of A= lexey Melnikov > Sent: Saturday, December 10, 2011 2:49 PM > To: ietf@ietf.org > Cc: marf@ietf.org > Subject: Re: Last Call: (Redaction of = Potentially Sensitive Data from Mail Abuse Reports) to Informational RFC >=20 > I've reviewed the document and I think it is ready for publication. I > don't have a strong preference between Informational and Experimental. Thanks, Alexey. I've just received word that the method proposed in this document is being = implemented at Swisscom, even before its publication. Pretty cool! If there are some FBL receivers that are likely to make use of ARF messages= that make use of what this document says, maybe it's worth asking for Prop= osed Standard. But I haven't heard of any yet. From iesg-secretary@ietf.org Wed Dec 21 14:29:52 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF44F11E80C9; Wed, 21 Dec 2011 14:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 KL90jCQTztuQ; Wed, 21 Dec 2011 14:29:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4195A11E80C0; Wed, 21 Dec 2011 14:29:52 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111221222952.13218.25898.idtracker@ietfa.amsl.com> Date: Wed, 21 Dec 2011 14:29:52 -0800 Cc: marf@ietf.org Subject: [marf] Last Call: (Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 22:29:53 -0000 The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Authentication Failure Reporting using the Abuse Report Format' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo registers an extension report type to ARF, affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email authentication checks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-authfailure-report/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-authfailure-report/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Wed Dec 21 16:13:28 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBD311E80DA; Wed, 21 Dec 2011 16:13:28 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qsN2lFTiAIJ; Wed, 21 Dec 2011 16:13:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A5021F89BA; Wed, 21 Dec 2011 16:13:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111222001327.6911.63546.idtracker@ietfa.amsl.com> Date: Wed, 21 Dec 2011 16:13:27 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 00:13:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk M. Kucherawy Filename : draft-ietf-marf-as-01.txt Pages : 6 Date : 2011-12-21 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes one common method for utilizing this format for reporting at scale between large mailbox providers, and from large mailbox providers to other mail sending entities. [NOTE TO EDITOR: Murray Kucherawy is listed as an author only to enable him to complete the publication process on behalf of J.D. Falk. Please remove Murray from the author list prior to publication.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-01.txt From msk@cloudmark.com Wed Dec 21 16:19:06 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E178C21F8AC3 for ; Wed, 21 Dec 2011 16:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 69EF5pgGrWbN for ; Wed, 21 Dec 2011 16:19:06 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 82F1E21F8ABE for ; Wed, 21 Dec 2011 16:19:06 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Dec 2011 16:19:04 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 21 Dec 2011 16:19:05 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 21 Dec 2011 16:19:04 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-01.txt Thread-Index: AczAPox2PP0WiSLBRhuDO6N/6Ss4dQAAA8nA Message-ID: References: <20111222001327.6911.63546.idtracker@ietfa.amsl.com> In-Reply-To: <20111222001327.6911.63546.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 00:19:07 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Wednesday, December 21, 2011 4:13 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-as-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Creation and Use of Email Feedback Reports: An > Applicability Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-01.txt > Pages : 6 > Date : 2011-12-21 >=20 > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This document describes one common method for utilizing > this format for reporting at scale between large mailbox providers, > and from large mailbox providers to other mail sending entities. >=20 > [NOTE TO EDITOR: Murray Kucherawy is listed as an author only to > enable him to complete the publication process on behalf of J.D. > Falk. Please remove Murray from the author list prior to > publication.] Minor editorial changes and polishing, and temporarily taking over editoria= l duties for JD as we prepare to send this to the IESG. A full diff is ava= ilable through the datatracker. Alessandro is working on some edits for the WG to consider. I'm planning t= o make a call for consensus on his changes (which will be derived from draf= t-veseley-marf-abuse-reporting) when we see them, and then either way initi= ate a Working Group Last Call on this in the first half of January. -MSK From johnl@iecc.com Wed Dec 21 21:08:20 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1707D1F0C40 for ; Wed, 21 Dec 2011 21:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 xnAvuqOiNAqO for ; Wed, 21 Dec 2011 21:08:19 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB841F0C3F for ; Wed, 21 Dec 2011 21:08:18 -0800 (PST) Received: (qmail 91004 invoked from network); 22 Dec 2011 05:08:14 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Dec 2011 05:08:14 -0000 Date: 22 Dec 2011 05:07:52 -0000 Message-ID: <20111222050752.71582.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 05:08:20 -0000 It's basically fine, but of course that doesn't keep me from suggesting changes. There's two fairly different contexts in which people use ARF. The original one, and still by far the most common, is when two mail systems make a private agreement to exchange abuse reports, usually reports due to recipients manually reporting messages as spam. The other one is sending reports between parties that don't know each other, with the recipient address typically being abuse@domain, or looked up via RIR WHOIS or the like. The reports may be manual, or automated due to hitting spam traps, or scored high by spam filters, or anything else. At least one large provider (Yahoo) has said that it wants all its reports as ARF, and I've been sending all my reports as ARF for over a year. I can report that it works at least as well as any other form. I'd suggest reorganizing the draft a little to clarify that prior agreement vs. no prior agreement are two different applications, both in current use. If people want, I can suggest specific changes. R's, John From shmuel+gen@patriot.net Thu Dec 22 04:54:59 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24A821F8888 for ; Thu, 22 Dec 2011 04:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 TgHmxKCB9Cfa for ; Thu, 22 Dec 2011 04:54:58 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id ED57B21F84FA for ; Thu, 22 Dec 2011 04:54:57 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.7]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id D9D0CF58089 for ; Thu, 22 Dec 2011 07:41:00 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 22 Dec 2011 07:55:50 -0500 To: marf@ietf.org In-Reply-To: <20111222050752.71582.qmail@joyce.lan> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111222124104.D9D0CF58089@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 12:54:59 -0000 In <20111222050752.71582.qmail@joyce.lan>, on 12/22/2011 at 05:07 AM, "John Levine" said: >At least one large provider (Yahoo) has said that >it wants all its reports as ARF, Which is a problem, because currently ARF is designated for reporting spam sources, not, e.g., spam drop boxes, spam support sites. In effect yahoo is refusing to accept reports for broad categories of abuse. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From johnl@iecc.com Thu Dec 22 11:41:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834EE11E8095 for ; Thu, 22 Dec 2011 11:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 q2Tdf6J1I0QE for ; Thu, 22 Dec 2011 11:41:30 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6F81611E809D for ; Thu, 22 Dec 2011 11:41:28 -0800 (PST) Received: (qmail 52076 invoked from network); 22 Dec 2011 19:41:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Dec 2011 19:41:25 -0000 Date: 22 Dec 2011 19:41:03 -0000 Message-ID: <20111222194103.2476.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20111222124104.D9D0CF58089@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 19:41:30 -0000 >Which is a problem, because currently ARF is designated for reporting >spam sources, not, e.g., spam drop boxes, spam support sites. Drop boxes: Feedback-Type: abuse Reported-URI: mailto:mariamabacha47@yahoo.com Spam support sites: Feedback-Type: abuse Reported-URI: http://randomcustomer.yahoo.com/fakemanlydrugs.html Phishing: Feedback-Type: fraud Reported-URI: http://bankofamerica.randomcustomer.yahoo.com/enteryourlifehistory.html I don't know if Yahoo pays attention to these, but ARF lets you report them. R's, John From johnl@iecc.com Thu Dec 22 11:41:33 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B78911E80A4 for ; Thu, 22 Dec 2011 11:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 izLAUjEsDs0w for ; Thu, 22 Dec 2011 11:41:33 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD8611E8095 for ; Thu, 22 Dec 2011 11:41:28 -0800 (PST) Received: (qmail 52076 invoked from network); 22 Dec 2011 19:41:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Dec 2011 19:41:25 -0000 Date: 22 Dec 2011 19:41:03 -0000 Message-ID: <20111222194103.2476.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20111222124104.D9D0CF58089@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 19:41:33 -0000 >Which is a problem, because currently ARF is designated for reporting >spam sources, not, e.g., spam drop boxes, spam support sites. Drop boxes: Feedback-Type: abuse Reported-URI: mailto:mariamabacha47@yahoo.com Spam support sites: Feedback-Type: abuse Reported-URI: http://randomcustomer.yahoo.com/fakemanlydrugs.html Phishing: Feedback-Type: fraud Reported-URI: http://bankofamerica.randomcustomer.yahoo.com/enteryourlifehistory.html I don't know if Yahoo pays attention to these, but ARF lets you report them. R's, John From shmuel+gen@patriot.net Thu Dec 22 13:42:01 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084AE21F85B9 for ; Thu, 22 Dec 2011 13:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=2.207, BAYES_00=-2.599, GB_I_LETTER=-2] 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 I8W+MthqOh8Z for ; Thu, 22 Dec 2011 13:42:00 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 54F2521F85B1 for ; Thu, 22 Dec 2011 13:42:00 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.131]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id F3A29F5808A for ; Thu, 22 Dec 2011 16:28:42 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 22 Dec 2011 15:53:15 -0500 To: marf@ietf.org In-Reply-To: <20111222194103.2476.qmail@joyce.lan> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111222212842.F3A29F5808A@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 21:42:01 -0000 In <20111222194103.2476.qmail@joyce.lan>, on 12/22/2011 at 07:41 PM, "John Levine" said: >Drop boxes: >Feedback-Type: abuse >Reported-URI: mailto:mariamabacha47@yahoo.com Doesn't that conflict with RFC 5965? 1.1. Purpose The reports defined in this document are intended to inform mail operators about: o email abuse originating from their networks; o potential issues with the perceived quality of outbound mail, such as email service providers sending mail that attracts the attention of automated abuse detection systems. Please note that while the parent "multipart/report" content type defined in [REPORT] is used for all kinds of administrative messages, this format is intended specifically for communications among providers regarding email abuse and related issues, and SHOULD NOT be used for other reports. >I don't know if Yahoo pays attention to these, They used to send the bedbug letter :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From johnl@iecc.com Thu Dec 22 14:10:52 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3366D21F84FD for ; Thu, 22 Dec 2011 14:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 WtgnT5zgXGYJ for ; Thu, 22 Dec 2011 14:10:51 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9145B21F84D5 for ; Thu, 22 Dec 2011 14:10:51 -0800 (PST) Received: (qmail 54693 invoked from network); 22 Dec 2011 22:10:50 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Dec 2011 22:10:50 -0000 Date: 22 Dec 2011 22:10:27 -0000 Message-ID: <20111222221027.7701.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20111222212842.F3A29F5808A@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 22:10:52 -0000 >>Drop boxes: > >>Feedback-Type: abuse >>Reported-URI: mailto:mariamabacha47@yahoo.com > >Doesn't that conflict with RFC 5965? No. R's, John From johnl@iecc.com Thu Dec 22 14:10:52 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3361221F84FA for ; Thu, 22 Dec 2011 14:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 o6-ir8SC4Tsn for ; Thu, 22 Dec 2011 14:10:51 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9142621F8484 for ; Thu, 22 Dec 2011 14:10:51 -0800 (PST) Received: (qmail 54693 invoked from network); 22 Dec 2011 22:10:50 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Dec 2011 22:10:50 -0000 Date: 22 Dec 2011 22:10:27 -0000 Message-ID: <20111222221027.7701.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20111222212842.F3A29F5808A@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 22:10:52 -0000 >>Drop boxes: > >>Feedback-Type: abuse >>Reported-URI: mailto:mariamabacha47@yahoo.com > >Doesn't that conflict with RFC 5965? No. R's, John From shmuel+gen@patriot.net Fri Dec 23 06:11:18 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905B821F8B7D for ; Fri, 23 Dec 2011 06:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[AWL=-1.638, BAYES_40=-0.185, DATE_IN_PAST_06_12=1.069] 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 R-hIQtdSS7nH for ; Fri, 23 Dec 2011 06:11:18 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDF021F8B7C for ; Fri, 23 Dec 2011 06:11:17 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.96]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id DFB6DF5808F for ; Fri, 23 Dec 2011 08:58:00 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Fri, 23 Dec 2011 00:17:53 -0500 To: marf@ietf.org In-Reply-To: <20111222221027.7701.qmail@joyce.lan> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111223135801.DFB6DF5808F@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 14:11:18 -0000 In <20111222221027.7701.qmail@joyce.lan>, on 12/22/2011 at 10:10 PM, "John Levine" said: >No. Abuse complaints from the recipients are not communications among providers. How do they not violate the RFC 5965 text that I quoted from 1.1. Purpose? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Fri Dec 23 08:48:02 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC1121F8540 for ; Fri, 23 Dec 2011 08:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.57 X-Spam-Level: X-Spam-Status: No, score=-4.57 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 4bpPYHddKQs2 for ; Fri, 23 Dec 2011 08:48:01 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 89A3F21F8513 for ; Fri, 23 Dec 2011 08:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324658878; bh=oa+d+vN4TEqveZ3gP2pdr4c1Oir1Sacg5wpDtbkLtmw=; l=429; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Zlg5kBnqgM47LwOJiHgpFpoJOf7Eoj2qkbqngITsyvHPFTboL1Xj1xGK8zi7pPBdM 6nwaq5boFgbqav0elot6/jz1l29uRNnHchF8MU1KCWYsnQOKV5BiclmQckdN80m2Ui 5B1Mt79UbOLr8gOgrKFU2OuXhkPriml7mdiJ586w= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 23 Dec 2011 17:47:58 +0100 id 00000000005DC04D.000000004EF4B0BE.00003387 Message-ID: <4EF4B0BE.60605@tana.it> Date: Fri, 23 Dec 2011 17:47:58 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111223135801.DFB6DF5808F@smtp.patriot.net> In-Reply-To: <20111223135801.DFB6DF5808F@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 16:48:02 -0000 On 23/Dec/11 06:17, Shmuel (Seymour J.) Metz wrote: > In <20111222221027.7701.qmail@joyce.lan>, on 12/22/2011 > at 10:10 PM, "John Levine" said: > >>No. > > Abuse complaints from the recipients are not communications among > providers. How do they not violate the RFC 5965 text that I quoted > from 1.1. Purpose? Isn't it to inform mail operators about email abuse originating from their networks? From vesely@tana.it Fri Dec 23 09:12:26 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA11F21F84DA for ; Fri, 23 Dec 2011 09:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.595 X-Spam-Level: X-Spam-Status: No, score=-4.595 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 wD0+ojVXoKIb for ; Fri, 23 Dec 2011 09:12:26 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2457121F84C2 for ; Fri, 23 Dec 2011 09:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324660345; bh=Ruo/H0xGsKCRW+GVRPJziTg7lONEcL3dgHyD65amGzc=; l=1715; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=EwClU0ho9gQEZo8rMbHyLRhbN/5XSg1h/DiSrLM1yEgao6ACSCE0t9alkEoGnWuft PWYSa0I1J9EO/aKtwgUXnzhUpNBchEi51IYKFqTYZgMcOmrPiX6oy5YVAHp9Ann7+x vdleENz8UqCnBJcKEHX5d4YsKF+VggMtaChZ/pGc= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 23 Dec 2011 18:12:25 +0100 id 00000000005DC04A.000000004EF4B679.00003986 Message-ID: <4EF4B678.2020807@tana.it> Date: Fri, 23 Dec 2011 18:12:24 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111222050752.71582.qmail@joyce.lan> In-Reply-To: <20111222050752.71582.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 17:12:26 -0000 On 22/Dec/11 06:07, John Levine wrote: > > There's two fairly different contexts in which people use ARF. The > original one, and still by far the most common, is when two mail > systems make a private agreement to exchange abuse reports, usually > reports due to recipients manually reporting messages as spam. Another original use case is the unilateral FBL from a mail system to a bulk sender. > The other one is sending reports between parties that don't know each > other, with the recipient address typically being abuse@domain, or > looked up via RIR WHOIS or the like. One of the like methods should be described in the reporting-discovery draft. RIRs' refurbishing of their databases and access methods seems to be arriving earlier than that, at least for ARIN. However, whois databases need the cooperation of network providers to get updated. PTR records suffer of the same complication, worsened by the need to maintain consistency between DNS and rDNS. The other method --the RFC 2142 "abuse" role-- being what it is, if report-discovery will make it it seems it will be the one more universally available to mailbox providers. > The reports may be manual, or automated due to hitting spam traps, > or scored high by spam filters, or anything else. This classification is also worth being made, IMHO. Not sure where and why, though. > I'd suggest reorganizing the draft a little to clarify that prior > agreement vs. no prior agreement are two different applications, both > in current use. If people want, I can suggest specific changes. I wrote some changes, but didn't post the resulting draft. For the time being I copied it in http://www.tana.it/file/ From shmuel+gen@patriot.net Fri Dec 23 10:01:57 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E078121F8AB8 for ; Fri, 23 Dec 2011 10:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] 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 DdwAp+nLtlQm for ; Fri, 23 Dec 2011 10:01:57 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4C73F21F851F for ; Fri, 23 Dec 2011 10:01:57 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.117]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 3A679F58089 for ; Fri, 23 Dec 2011 12:48:40 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Fri, 23 Dec 2011 13:04:34 -0500 To: marf@ietf.org In-Reply-To: <4EF4B0BE.60605@tana.it> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111223174841.3A679F58089@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 18:01:58 -0000 In <4EF4B0BE.60605@tana.it>, on 12/23/2011 at 05:47 PM, Alessandro Vesely said: >Isn't it to inform mail operators about email abuse originating from >their networks? The relevant test is "this format is intended specifically for communications among providers regarding email abuse and related issues, and SHOULD NOT be used for other reports." That would seem to exclude using it for an abuse report from the recipient rather than from his provider. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Fri Dec 23 11:09:15 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BAC21F8AAA for ; Fri, 23 Dec 2011 11:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 unTr6W7D0e56 for ; Fri, 23 Dec 2011 11:09:15 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 096B621F84DD for ; Fri, 23 Dec 2011 11:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324667353; bh=OBZyx3xpNKo7SXl/6S4Q/Eq+D6wvw/G0TSfIPP0fY1Q=; l=1084; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=WKqlJzsVs37fcottd5Fm38BuLuM4ta1T/sb6dtz/3kHpmGdK8vtt4gCkj6/92NYUg s+VlZV/seLhFR9R3eeB7ualZ2U+qpfV0T4kFw+R0b96fkA/iIWmPsSSZROE9zkcRuU 72W21BUDhEMZ7y3N1z52sIGG9TJh2LXv5Kt8pAkM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 23 Dec 2011 20:09:13 +0100 id 00000000005DC035.000000004EF4D1D9.000052C4 Message-ID: <4EF4D1D8.1020702@tana.it> Date: Fri, 23 Dec 2011 20:09:12 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111223174841.3A679F58089@smtp.patriot.net> In-Reply-To: <20111223174841.3A679F58089@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 19:09:15 -0000 On 23/Dec/11 19:04, Shmuel (Seymour J.) Metz wrote: > In <4EF4B0BE.60605@tana.it>, on 12/23/2011 > at 05:47 PM, Alessandro Vesely said: > >> Isn't it to inform mail operators about email abuse originating from >> their networks? > > The relevant test is "this format is intended specifically for > communications among providers regarding email abuse and related > issues, and SHOULD NOT be used for other reports." That would seem to > exclude using it for an abuse report from the recipient rather than > from his provider. Hm... the second bullet clarifies that ESPs are targets rather than senders of reports. Perhaps, s/among/involving/ would yield a better wording if "providers" also includes mailbox providers. In any case, the requirement level ("SHOULD NOT") seems to be referred to "email abuse and related issues" --irrespectively of the original intention. In that sense, I don't think that utilizing ARF for user-to-provider reporting would violate RFC 5965. Note that Section 2 of reporting-discovery has a similar definition. From johnl@iecc.com Fri Dec 23 15:23:08 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8BC21F8B31 for ; Fri, 23 Dec 2011 15:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 yxlEubh4lm78 for ; Fri, 23 Dec 2011 15:23:08 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF1821F8B25 for ; Fri, 23 Dec 2011 15:23:07 -0800 (PST) Received: (qmail 64476 invoked from network); 23 Dec 2011 23:23:05 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Dec 2011 23:23:05 -0000 Date: 23 Dec 2011 23:22:43 -0000 Message-ID: <20111223232243.58910.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20111223174841.3A679F58089@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 23:23:08 -0000 >The relevant test is "this format is intended specifically for >communications among providers regarding email abuse and related >issues, and SHOULD NOT be used for other reports." That would seem to >exclude using it for an abuse report from the recipient rather than >from his provider. Read it in context. It means it's an abuse report, not a DSN. Just to be clear, you're telling me that I don't understand what my own RFC means? R's, John From johnl@iecc.com Fri Dec 23 15:23:08 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D7821F8B35 for ; Fri, 23 Dec 2011 15:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 2jgWW97-E7F7 for ; Fri, 23 Dec 2011 15:23:08 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0AF21F8B2D for ; Fri, 23 Dec 2011 15:23:07 -0800 (PST) Received: (qmail 64476 invoked from network); 23 Dec 2011 23:23:05 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Dec 2011 23:23:05 -0000 Date: 23 Dec 2011 23:22:43 -0000 Message-ID: <20111223232243.58910.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20111223174841.3A679F58089@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 23:23:08 -0000 >The relevant test is "this format is intended specifically for >communications among providers regarding email abuse and related >issues, and SHOULD NOT be used for other reports." That would seem to >exclude using it for an abuse report from the recipient rather than >from his provider. Read it in context. It means it's an abuse report, not a DSN. Just to be clear, you're telling me that I don't understand what my own RFC means? R's, John From shmuel+gen@patriot.net Sat Dec 24 14:25:06 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6352E21F84A4 for ; Sat, 24 Dec 2011 14:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599] 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 fx2hx+8oDJcv for ; Sat, 24 Dec 2011 14:25:05 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id C7B1C21F84A7 for ; Sat, 24 Dec 2011 14:25:05 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.193]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id DCFA0F580B8 for ; Sat, 24 Dec 2011 17:11:43 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sat, 24 Dec 2011 17:25:12 -0500 To: marf@ietf.org In-Reply-To: <20111223232243.58910.qmail@joyce.lan> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111224221144.DCFA0F580B8@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 22:25:06 -0000 In <20111223232243.58910.qmail@joyce.lan>, on 12/23/2011 at 11:22 PM, "John Levine" said: >Just to be clear, you're telling me that I don't understand what my >own RFC means? I'm telling you that what you wrote doesn't express what you meant to express. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Sat Dec 24 23:35:00 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABE721F8446 for ; Sat, 24 Dec 2011 23:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 bhRwlmvz0wqO for ; Sat, 24 Dec 2011 23:34:59 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A1A4221F846B for ; Sat, 24 Dec 2011 23:34:59 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 24 Dec 2011 23:34:56 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 24 Dec 2011 23:34:59 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Sat, 24 Dec 2011 23:35:03 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-01.txt Thread-Index: AczAZ7eQKufBCZWHRnCygB6kGIprZACb/VQg Message-ID: References: <20111222050752.71582.qmail@joyce.lan> In-Reply-To: <20111222050752.71582.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 07:35:00 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAyMSwgMjAxMSA5 OjA4IFBNDQo+IFRvOiBtYXJmQGlldGYub3JnDQo+IENjOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+ IFN1YmplY3Q6IFJlOiBbbWFyZl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tYXJmLWFzLTAxLnR4 dA0KPiANCj4gSSdkIHN1Z2dlc3QgcmVvcmdhbml6aW5nIHRoZSBkcmFmdCBhIGxpdHRsZSB0byBj bGFyaWZ5IHRoYXQgcHJpb3INCj4gYWdyZWVtZW50IHZzLiBubyBwcmlvciBhZ3JlZW1lbnQgYXJl IHR3byBkaWZmZXJlbnQgYXBwbGljYXRpb25zLCBib3RoDQo+IGluIGN1cnJlbnQgdXNlLiAgSWYg cGVvcGxlIHdhbnQsIEkgY2FuIHN1Z2dlc3Qgc3BlY2lmaWMgY2hhbmdlcy4NCg0KWWVzLCBwbGVh c2UuDQoNCi1NU0sNCg== From johnl@iecc.com Sun Dec 25 15:47:10 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD3F21F8468 for ; Sun, 25 Dec 2011 15:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 8unYYiRfg4Vy for ; Sun, 25 Dec 2011 15:47:09 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id C23B621F843D for ; Sun, 25 Dec 2011 15:47:09 -0800 (PST) Received: (qmail 72995 invoked from network); 25 Dec 2011 23:47:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Dec 2011 23:47:07 -0000 Date: 25 Dec 2011 23:46:45 -0000 Message-ID: <20111225234645.91671.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20111224221144.DCFA0F580B8@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 23:47:10 -0000 >>Just to be clear, you're telling me that I don't understand what my >>own RFC means? > >I'm telling you that what you wrote doesn't express what you meant to >express. I'm not aware of anyone else who reads that sentence the way you do, so I'm not inclined to do anything about it. R's, John From johnl@iecc.com Sun Dec 25 15:47:10 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2321F84B1 for ; Sun, 25 Dec 2011 15:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 ibuns62QNAM0 for ; Sun, 25 Dec 2011 15:47:09 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id C24A321F844F for ; Sun, 25 Dec 2011 15:47:09 -0800 (PST) Received: (qmail 72995 invoked from network); 25 Dec 2011 23:47:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Dec 2011 23:47:07 -0000 Date: 25 Dec 2011 23:46:45 -0000 Message-ID: <20111225234645.91671.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20111224221144.DCFA0F580B8@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 23:47:10 -0000 >>Just to be clear, you're telling me that I don't understand what my >>own RFC means? > >I'm telling you that what you wrote doesn't express what you meant to >express. I'm not aware of anyone else who reads that sentence the way you do, so I'm not inclined to do anything about it. R's, John From msk@cloudmark.com Mon Dec 26 09:05:37 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BD921F8C28 for ; Mon, 26 Dec 2011 09:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.283 X-Spam-Level: X-Spam-Status: No, score=-101.283 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_40=-0.185, HTML_MESSAGE=0.001, 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 3AjAhWOrlU53 for ; Mon, 26 Dec 2011 09:05:36 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B1AEB21F8C2B for ; Mon, 26 Dec 2011 09:05:36 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 Dec 2011 09:05:32 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 26 Dec 2011 09:05:35 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 26 Dec 2011 09:05:41 -0800 Thread-Topic: Applicability Statement Thread-Index: AczD8JjwngICgI6lReyqWCR752rfEQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15691EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Applicability Statement X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 17:05:37 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C15691EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've received some good feedback from Alessandro and John about what might = be good to include in the Applicability Statement. I've prepared a diff to= the current -01 version that I'm proposing for the -02 version, but given = the holidays I haven't posted it yet because I want to gauge consensus firs= t. The diff is visible here: http://www.blackops.org/~msk/marf2.html Please let me know if you agree with it or if you have additional changes y= ou'd like to see. I'll post it in the new year. Ideally I'd like to see e= nough discussion to start a Working Group Last Call on it in the middle of = January. Thanks and Happy Holidays, -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C15691EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve recei= ved some good feedback from Alessandro and John about what might be good to= include in the Applicability Statement.  I’ve prepared a diff t= o the current -01 version that I’m proposing for the -02 version, but= given the holidays I haven’t posted it yet because I want to gauge c= onsensus first.


The diff is visible = here: http://www.blacko= ps.org/~msk/marf2.html

 

Please let me know if you agree with it or if = you have additional changes you’d like to see.  I’ll post = it in the new year.  Ideally I’d like to see enough discussion t= o start a Working Group Last Call on it in the middle of January.

 

Thanks = and Happy Holidays,

-MSK

<= /div>= --_000_F5833273385BB34F99288B3648C4F06F19C6C15691EXCHC2corpclo_-- From presnick@qualcomm.com Mon Dec 26 09:13:22 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C1121F8C32 for ; Mon, 26 Dec 2011 09:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 Nbo+1ua7GSj3 for ; Mon, 26 Dec 2011 09:13:21 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id CC88121F8BBC for ; Mon, 26 Dec 2011 09:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1324919601; x=1356455601; h=from:to:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: content-type:mime-version; z=From:=20"Resnick,=20Pete"=20|To: =20"Murray=20S.=20Kucherawy"=20,=20"ma rf@ietf.org"=20|Subject:=20Re:=20[marf]=20 Applicability=20Statement|Thread-Topic:=20[marf]=20Applic ability=20Statement|Thread-Index:=20AQHMw/Fn+oT8E9WmZ0+kb ije0OHTPA=3D=3D|Date:=20Mon,=2026=20Dec=202011=2017:11:28 =20+0000|Message-ID:=20|References:=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|Content-Type:=20multipart/alternat ive=3B=0D=0A=09boundary=3D"_000_btj1e33amt2gx085u5nvablq1 324919261875emailandroidcom_"|MIME-Version:=201.0; bh=FF6Qbp7dY8k2g822wKsWX5bmQnyrtN6fuL77v2TWiJ8=; b=FwiLOoYC2V6DQX1lKTHxblROb2YtMT79tYW/dNC+pjOI7FlaCKPYinS9 8F0yBUph8lkmwVbCbGCB9hTc0xpbixNjUZ2jt3Zcx41m6TfRHNS0PuX+v pDm8Wcerr34x3bLRSg2SdB4X+RNhBDlWeLBQYtx7PE3pIeL06ABtVHh/L M=; X-IronPort-AV: E=McAfee;i="5400,1158,6570"; a="147725692" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 26 Dec 2011 09:13:20 -0800 X-IronPort-AV: E=Sophos;i="4.71,410,1320652800"; d="scan'208,217";a="156856847" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Dec 2011 09:13:20 -0800 Received: from NASANEXD02D.na.qualcomm.com ([fe80::bd79:baa4:2817:19a]) by nasanexhc04.na.qualcomm.com ([::1]) with mapi id 14.01.0339.001; Mon, 26 Dec 2011 09:11:29 -0800 From: "Resnick, Pete" To: "Murray S. Kucherawy" , "marf@ietf.org" Thread-Topic: [marf] Applicability Statement Thread-Index: AQHMw/Fn+oT8E9WmZ0+kbije0OHTPA== Date: Mon, 26 Dec 2011 17:11:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_btj1e33amt2gx085u5nvablq1324919261875emailandroidcom_" MIME-Version: 1.0 Subject: Re: [marf] Applicability Statement X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 17:13:22 -0000 --_000_btj1e33amt2gx085u5nvablq1324919261875emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So, just my personal opinion, but drafts are cheap. Post the new version, a= nd if folks have issues you can always make changes, or back everything out= if needed. I always find it a bit funny that people post drafts of drafts = instead just posting the draft. :-) pr "Murray S. Kucherawy" wrote: I=92ve received some good feedback from Alessandro and John about what migh= t be good to include in the Applicability Statement. I=92ve prepared a dif= f to the current -01 version that I=92m proposing for the -02 version, but = given the holidays I haven=92t posted it yet because I want to gauge consen= sus first. The diff is visible here: http://www.blackops.org/~msk/marf2.html Please let me know if you agree with it or if you have additional changes y= ou=92d like to see. I=92ll post it in the new year. Ideally I=92d like to= see enough discussion to start a Working Group Last Call on it in the midd= le of January. Thanks and Happy Holidays, -MSK --_000_btj1e33amt2gx085u5nvablq1324919261875emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 
So, just my personal opinion, but drafts are cheap. Post the ne=
w version, and if folks have issues you can always make changes, or back ev=
erything out if needed. I always find it a bit funny that people post draft=
s of drafts instead just posting the draft. :-)=0A=
=0A=
pr=0A=
=0A=
"Murray S. Kucherawy" <msk@cloudmark.com> wrote:=0A=
=0A=

I=92ve received some good feedback from Alessandro a= nd John about what might be good to include in the Applicability Statement.=   I=92ve prepared a diff to the current -01 version that I=92m proposi= ng for the -02 version, but given the holidays I haven=92t posted it yet because I want to gauge consensus first.


The diff is visible here: http://www.blackops.org/~msk/marf2.html

 

Please let me know if you agree with it or if you ha= ve additional changes you=92d like to see.  I=92ll post it in the new = year.  Ideally I=92d like to see enough discussion to start a Working = Group Last Call on it in the middle of January.

 

Thanks and Happy Holidays,

-MSK

--_000_btj1e33amt2gx085u5nvablq1324919261875emailandroidcom_-- From shmuel+gen@patriot.net Mon Dec 26 10:45:50 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1059C21F8C32 for ; Mon, 26 Dec 2011 10:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 29Q1esXakAOY for ; Mon, 26 Dec 2011 10:45:49 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 80AB321F8C28 for ; Mon, 26 Dec 2011 10:45:49 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.16]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 1A6C2F580BC for ; Mon, 26 Dec 2011 13:32:25 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 26 Dec 2011 10:15:56 -0500 To: marf@ietf.org In-Reply-To: <20111225234645.91671.qmail@joyce.lan> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111226183226.1A6C2F580BC@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 18:45:50 -0000 In <20111225234645.91671.qmail@joyce.lan>, on 12/25/2011 at 11:46 PM, "John Levine" said: >To: marf@ietf.org >Cc: MARF@ietf.org That's causing duplicate messages. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Mon Dec 26 11:53:48 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFF221F8BB7 for ; Mon, 26 Dec 2011 11:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.585 X-Spam-Level: X-Spam-Status: No, score=-4.585 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 RZy1pZwvUkvS for ; Mon, 26 Dec 2011 11:53:48 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4321F8BAA for ; Mon, 26 Dec 2011 11:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1324929224; bh=qhn+Wv+e1AHjpjM7ljykatQCSjiN95b4fheWHg7taSM=; l=355; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=F3/D8hSYQlfvscp1287SFrS7OsUJep6pSIxMzRVzJqien0xcIqPLD3PpTn+oyQrwX LieW/mitU6oJjg/AYbZWBpYvPIV5FA8+4JgvGc7k+lrOnHInjLJmj46oCtCWn+ANTf F1Rh+miZEzgRYdtmjlunWGlQaejbRUJDS10ia028= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 26 Dec 2011 20:53:44 +0100 id 00000000005DC033.000000004EF8D0C8.00000D18 Message-ID: <4EF8D0C8.2050706@tana.it> Date: Mon, 26 Dec 2011 20:53:44 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111226183226.1A6C2F580BC@smtp.patriot.net> In-Reply-To: <20111226183226.1A6C2F580BC@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 19:53:48 -0000 On 26/Dec/11 16:15, Shmuel (Seymour J.) Metz wrote: > In <20111225234645.91671.qmail@joyce.lan>, on 12/25/2011 > at 11:46 PM, "John Levine" said: > >>To: marf@ietf.org >>Cc: MARF@ietf.org > > That's causing duplicate messages. Probably triggered by Mail-Followup-To: Message Abuse Report Format working group From johnl@iecc.com Mon Dec 26 15:33:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CD921F8C48 for ; Mon, 26 Dec 2011 15:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 zRRtQ7KMda3m for ; Mon, 26 Dec 2011 15:33:29 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7324521F8C42 for ; Mon, 26 Dec 2011 15:33:29 -0800 (PST) Received: (qmail 57511 invoked from network); 26 Dec 2011 23:33:26 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Dec 2011 23:33:26 -0000 Date: 26 Dec 2011 23:33:03 -0000 Message-ID: <20111226233303.2928.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20111226183226.1A6C2F580BC@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 23:33:30 -0000 >That's causing duplicate messages. Surely in 2001 you have software that can deal with it. R's, John PS: Lose the Reply-To:. From johnl@iecc.com Mon Dec 26 15:33:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F55021F8C52 for ; Mon, 26 Dec 2011 15:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, 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 AkGJNi181Q+r for ; Mon, 26 Dec 2011 15:33:29 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7317321F8C35 for ; Mon, 26 Dec 2011 15:33:29 -0800 (PST) Received: (qmail 57511 invoked from network); 26 Dec 2011 23:33:26 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Dec 2011 23:33:26 -0000 Date: 26 Dec 2011 23:33:03 -0000 Message-ID: <20111226233303.2928.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org Cc: MARF@IETF.ORG In-Reply-To: <20111226183226.1A6C2F580BC@smtp.patriot.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2011 23:33:30 -0000 >That's causing duplicate messages. Surely in 2001 you have software that can deal with it. R's, John PS: Lose the Reply-To:. From shmuel+gen@patriot.net Tue Dec 27 13:26:08 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE13321F8ABC for ; Tue, 27 Dec 2011 13:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 90B8gQgys7u7 for ; Tue, 27 Dec 2011 13:26:08 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id E3E3F21F8AB0 for ; Tue, 27 Dec 2011 13:26:07 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.151]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 0800FF580B8 for ; Tue, 27 Dec 2011 16:12:44 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 27 Dec 2011 12:41:07 -0500 To: marf@ietf.org In-Reply-To: <4EF8D0C8.2050706@tana.it> Mail-Copies-To: nobody Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111227211245.0800FF580B8@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-01.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 21:26:08 -0000 In <4EF8D0C8.2050706@tana.it>, on 12/26/2011 at 08:53 PM, Alessandro Vesely said: >Probably triggered by >Mail-Followup-To: Message Abuse Report Format working group > That sounds plausible; I've removed it from my template. Thanks. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From internet-drafts@ietf.org Wed Dec 28 20:25:59 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D864211E809C; Wed, 28 Dec 2011 20:25:59 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zWv3WmUX0MH; Wed, 28 Dec 2011 20:25:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB7911E808C; Wed, 28 Dec 2011 20:25:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111229042559.19236.92553.idtracker@ietfa.amsl.com> Date: Wed, 28 Dec 2011 20:25:59 -0800 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-as-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 04:26:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Messaging Abuse Reporting Format Work= ing Group of the IETF. Title : Creation and Use of Email Feedback Reports: An Applicabi= lity Statement for the Abuse Reporting Format (ARF) Author(s) : J.D. Falk M. Kucherawy Filename : draft-ietf-marf-as-02.txt Pages : 7 Date : 2011-12-28 RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes common methods for utilizing this format for abuse reporting. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-as-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-02.txt From msk@cloudmark.com Wed Dec 28 20:30:33 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2937411E808C for ; Wed, 28 Dec 2011 20:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 CdxlML5kJ-p9 for ; Wed, 28 Dec 2011 20:30:32 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id B556811E8073 for ; Wed, 28 Dec 2011 20:30:32 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 28 Dec 2011 20:30:28 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 28 Dec 2011 20:30:32 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 28 Dec 2011 20:30:39 -0800 Thread-Topic: [marf] I-D Action: draft-ietf-marf-as-02.txt Thread-Index: AczF4gPV+qyHwaQeQqu+3xqDgsELvAAABX+w Message-ID: References: <20111229042559.19236.92553.idtracker@ietfa.amsl.com> In-Reply-To: <20111229042559.19236.92553.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 04:30:33 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Wednesday, December 28, 2011 8:26 PM > To: i-d-announce@ietf.org > Cc: marf@ietf.org > Subject: [marf] I-D Action: draft-ietf-marf-as-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Messaging Abuse Reporting > Format Working Group of the IETF. >=20 > Title : Creation and Use of Email Feedback Reports: An > Applicability Statement for the Abuse Reporting Format (ARF) > Author(s) : J.D. Falk > M. Kucherawy > Filename : draft-ietf-marf-as-02.txt > Pages : 7 > Date : 2011-12-28 >=20 > RFC 5965 defines an extensible, machine-readable format intended for > mail operators to report feedback about received email to other > parties. This document describes common methods for utilizing this > format for abuse reporting. Mailbox Providers of any size, mail > sending entities, and end users can use these methods as a basis to > create procedures that best suit them. This version contains feedback from John and Alessandro that seemed to jive= with recent conversations on the list and also among some private reviewer= s. Please review it and provide feedback, even if it's just of the "I've r= ead this and I agree with what it says" variety. I believe Alessandro has some suggestions to make in addition to what's the= re if the Working Group concurs. I'll let him get that rolling. -MSK From vesely@tana.it Thu Dec 29 04:38:28 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C7921F84A8 for ; Thu, 29 Dec 2011 04:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.607 X-Spam-Level: X-Spam-Status: No, score=-4.607 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 TW-fT8Z7hLlX for ; Thu, 29 Dec 2011 04:38:27 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5E91121F84A6 for ; Thu, 29 Dec 2011 04:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325162293; bh=jB+OIKvaRAvUNepYfEQ3SK0q3Rj8GYb7DanURH/zpRg=; l=4769; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=BhthB6Q/BUKZp66Wvmeca2mtJ1PcoloNE46SPUYI6/kSX34n8cwgwnGPqGjbAv65i uQAmfzBBbRdybp0eOQh3/fVi1hUtvkxwIHE22Ot/TAXv/hRlXqcfbFBX26S5dOd7BJ cy9mqsvAHro+lqxfQEUvTt5tA/uCD7UVB/ASZbyg= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 29 Dec 2011 13:38:13 +0100 id 00000000005DC03F.000000004EFC5F35.00007AF9 Message-ID: <4EFC5F35.8020805@tana.it> Date: Thu, 29 Dec 2011 13:38:13 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111229042559.19236.92553.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 12:38:28 -0000 On 29/Dec/11 05:30, Murray S. Kucherawy wrote: > > I believe Alessandro has some suggestions to make in addition to > what's there if the Working Group concurs. I'll let him get that > rolling. Yes, and also some comments on what is already in the draft, or missing pieces that have been discussed and agreed already but didn't find their place in the draft. Sections 6 and 7 are dedicated to solicited feedback. However, there is a number of points that should be valid also for unsolicited reports. If the order is not important, the common points could be put in a common section. Specifically, for the sending part, Section 6, here's the points I think should be common and why: 1. End-users report to mailbox providers, they shouldn't go searching whois databases and similar stuff. This point is partially repeated already in Section 8, where it says that sending criteria "might include direct complaint submissions from MUAs". Using ARF for MUA-to-MP is not discussed. 2. Reports can be used to instruct filters. 4. "Feedback-Type: abuse" is fine for unsolicited reports too. 5. Ditto for other optional fields. By contrast, points (3) and (6) cover solicited-specific stuff. For the receiving part, Section 7, the points are: 2. ARF over SMTP is fine for unsolicited feedback too. 5. Optional fields may vary in unsolicited feedback too. Note that for point (6), the actions, only Section 4.3.1 of RFC 6449 is useful as-is for unsolicited feedback. The rest of Section 4.3 of that RFC contains (also) solicited-specific advice. Three notes: * Neither the RFC nor the draft mention degrading the offending IP's profile at the firewall. * The RFC says replying to feedback is useless. For unsolicited feedback, especially the first times it's being sent, some sort of acknowledge may be meaningful. * Both senders and receivers should keep a database of contacts and annotate it regularly. The draft only mentions such operations for the solicited case, referring to Section 4.4 of the RFC --point (3). For Section 8, unsolicited complaints, the second paragraph needs to clarify that "Senders" means "mailbox providers who are forwarding their users' complaints". We are not stopping end-users from reporting to whoever they like, e.g. SpamCop, are we? This WG already agreed that ARF messages are automated and the human-readable part is boilerplate. Conversely, technical data for an abuse team has to be sent in non-ARF messages unless it can fit into the provided ARF fields. This concept needs to be stated, though. The beginning of the third paragraph of Section 8 can be changed so as to read like so: Recipients of unsolicited ARF reports SHOULD, in general, handle them the same way as any other abuse reports. However, they can take advantage of the ARF format to automate processing. Lacking [etc.] The converse can be put in the beginning of the last paragraph of Section 8, e.g. like so: Published abuse-mailbox addresses SHOULD NOT reject non-ARF messages, because producing ARF messages may occasionally be unavailable or not-applicable. Nevertheless some large messaging service providers specifically request that [etc.] Finally, I propose to add the following paragraphs to the Security Considerations section: Mailbox Providers SHOULD perform any possible checks to ascertain that the messages reported by their users, that they are about to report in turn, really originated at the domain they intend to forward it to. This includes checking that the reporting user did not inadvertently or maliciously alter the reported message. Mailbox Providers MAY digitally sign received messages on delivery in order to perform this check. Mailbox Providers SHOULD manually inspect the messages reported by their users if their spam score is noticeably low --which might indicate that the user hit the spam-button by mistake. Mailbox Providers should evaluate the trustworthiness of the target abuse team, possibly using external reputation providers. It is not worth to send any information to domains that exist for the sole purpose of spamming. Mailbox Providers MAY redact the reported message, according to its policy and to the reputation of the destination. Redacting techniques are discussed in [REDACT]. The obvious correction for an acknowledged policy contravention is to remove the email address of the original recipient from whatever storage it was retrieved from for sending the reported message, including mailing lists. An abuse team may need to investigate whether email addresses are stored legitimately on their customer's systems, or if any malware is running there. From msk@cloudmark.com Thu Dec 29 10:46:03 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541D721F8B54 for ; Thu, 29 Dec 2011 10:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 G+3+KVBz2V5A for ; Thu, 29 Dec 2011 10:46:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DB9CA21F8B50 for ; Thu, 29 Dec 2011 10:46:01 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 29 Dec 2011 10:45:57 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 29 Dec 2011 10:46:01 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 29 Dec 2011 10:46:07 -0800 Thread-Topic: Document status(es) Thread-Index: AczGWh/zWObWO1IITDuTIVxu7EnLyA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C156ABEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] Document status(es) X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 18:46:03 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C156ABEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings all, The redaction document has completed an IETF-wide Last Call on the grounds = that it is seeking Informational status, and the authfailure-report documen= t is now in IETF Last Call looking for Proposed Standard status. And we're= working on the applicability statement, which will by its nature seek Prop= osed Standard as well. IETF rules say we need to ensure that a normative reference in a proposed s= tandard document can't have a normative reference to a document of lower st= atus. I failed to notice this when doing my shepherd write-up for authfail= ure-report and it's come up during Last Call. That means authfailure-repor= t has two downward references, one to SPF (RFC4408, which is experimental),= and one to the redaction document which is seeking Informational. The WG needs to decide how to resolve this. Barry and I think there are th= ree options: 1) Upgrade the redaction document to Proposed Standard, and include in it a= note that it is a proposal at this point and not a mature protocol, leavin= g the applicability statement and the authfailure-report documents unchange= d; 2) Leave the redaction document as Informational, but reduce it to being an= informative reference in the other documents (with softening of surroundin= g text to match); 3) Stick with the current arrangement and tell the IESG explicitly that we = think it's appropriate the way it is. With respect to the SPF downward reference, we believe this is workable. W= e just need to request a second Last Call on it that points out the normati= ve downward reference. If we change the redaction document's status, we'll= need a second Last Call on that one as well. The authfailure-report and redaction drafts are up for IESG evaluation on J= anuary 5th, so ideally we'll have arrived at our preferred path forward by = then. Comments, please. -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C156ABEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings all,

 

The redaction document has completed an IETF-wide Last Call on the grounds= that it is seeking Informational status, and the authfailure-report docume= nt is now in IETF Last Call looking for Proposed Standard status.  And= we’re working on the applicability statement, which will by its natu= re seek Proposed Standard as well.


I= ETF rules say we need to ensure that a normative reference in a proposed st= andard document can’t have a normative reference to a document of low= er status.  I failed to notice this when doing my shepherd write-up fo= r authfailure-report and it’s come up during Last Call.  That me= ans authfailure-report has two downward references, one to SPF (RFC4408, wh= ich is experimental), and one to the redaction document which is seeking In= formational.

 

The WG needs to decide how to resolve this.  Barry and = I think there are three options:

1) Upgrade the redaction document t= o Proposed Standard, and include in it a note that it is a proposal at this= point and not a mature protocol, leaving the applicability statement and t= he authfailure-report documents unchanged;

 

2) Leave the redaction documen= t as Informational, but reduce it to being an informative reference in the = other documents (with softening of surrounding text to match);

 

3) Stick w= ith the current arrangement and tell the IESG explicitly that we think it&#= 8217;s appropriate the way it is.


Wi= th respect to the SPF downward reference, we believe this is workable. = ; We just need to request a second Last Call on it that points out the norm= ative downward reference.  If we change the redaction document’s= status, we’ll need a second Last Call on that one as well.

 

The aut= hfailure-report and redaction drafts are up for IESG evaluation on January = 5th, so ideally we’ll have arrived at our preferred path f= orward by then.

Comments, please.

&nbs= p;

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F19C6C156ABEXCHC2corpclo_-- From msk@cloudmark.com Thu Dec 29 13:02:30 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7E021F8A7D for ; Thu, 29 Dec 2011 13:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 WCEp+IW9OczY for ; Thu, 29 Dec 2011 13:02:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1F52F21F8A70 for ; Thu, 29 Dec 2011 13:02:30 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 29 Dec 2011 13:02:24 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 29 Dec 2011 13:02:28 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Thu, 29 Dec 2011 13:00:46 -0800 Thread-Topic: Document status(es) Thread-Index: AczGWh/zWObWO1IITDuTIVxu7EnLyAAEs+ar Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Document status(es) X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 21:02:30 -0000 In that last message, I said: "a normative reference in a proposed standard= document can=92t have a normative reference to a document of lower status" This isn't strictly true. Rather, the downward reference has to be highlig= hted in the Last Call announcement itself so that reviewers and the IESG ca= n determine whether or not the downward reference is appropriate and accept= able. That's what was missed for the authfailure-report draft. -MSK= From shmuel+gen@patriot.net Fri Dec 30 04:37:29 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBE121F8507 for ; Fri, 30 Dec 2011 04:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 qwZIJtIIi+q2 for ; Fri, 30 Dec 2011 04:37:28 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 28F2521F8500 for ; Fri, 30 Dec 2011 04:37:24 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.132]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id B74C8F58095 for ; Fri, 30 Dec 2011 07:23:52 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Thu, 29 Dec 2011 14:05:35 -0500 To: marf@ietf.org In-Reply-To: <4EFC5F35.8020805@tana.it> Mail-Copies-To: nobody Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111230122352.B74C8F58095@smtp.patriot.net> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 12:37:29 -0000 In <4EFC5F35.8020805@tana.it>, on 12/29/2011 at 01:38 PM, Alessandro Vesely said: >* Neither the RFC nor the draft mention degrading the offending IP's > profile at the firewall. I assume that you mean RFC 6449 and not RFC 5965. >* The RFC says replying to feedback is useless. I don't see that, although I do see "not necessary". > The obvious correction for an acknowledged policy contravention > is to remove the email address of the original recipient from > whatever storage it was retrieved from for sending the reported > message, including mailing lists. I would say that the obvious for an acknowledged policy contravention is to remove all email address that contravene the policy, not just the one in the ARF report. Failing to do so could lead to blocking of the sending IP or IP block. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Sat Dec 31 02:59:26 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D03521F841C for ; Sat, 31 Dec 2011 02:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 ICXQyPgQD-iZ for ; Sat, 31 Dec 2011 02:59:25 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1556A21F841A for ; Sat, 31 Dec 2011 02:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325329160; bh=6HEp/2ZQ3ou/ZJAwiYdozn29+yaE8xIgYOPXQ/BPkas=; l=1507; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=k4s5s3uyjoWlZqHuA3CV9eCJ6KZuMUdhsi/TLaWbpUK9bO58eAX620rTXpj5K1h+t Ou9AwtG6hN2Dd0NPtMlt4J2M0Su89rc0zgJyEWnHjlx9HQdL2pVNOFyVFOLNDlW5l5 GsB+Zvti6lTxXQ3lgeMhVkbqUiXppTPl6sHnyVFk= Received: from [109.113.80.123] ([109.113.80.123]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 31 Dec 2011 11:59:19 +0100 id 00000000005DC033.000000004EFEEB07.000054FB Message-ID: <4EFEEAF2.9050109@tana.it> Date: Sat, 31 Dec 2011 11:58:58 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [marf] Document status(es) X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 10:59:26 -0000 On 29.12.2011 19:46, Murray S. Kucherawy wrote: > > The redaction document has completed an IETF-wide Last Call on the grounds > that it is seeking Informational status, and the authfailure-report document > is now in IETF Last Call looking for Proposed Standard status. > > Barry and I think there are three options: > > 1) Upgrade the redaction document to Proposed Standard, and include in it a > note that it is a proposal at this point and not a mature protocol, leaving > the applicability statement and the authfailure-report documents unchanged; My understanding is that redaction is sometimes necessary or useful, but even then the WG has no final solutions. We just propose an algorithm, and thus the document is informative. If aiming at PS implies devising a protocol for thoroughly redacting messages, I suggest we don't. > 2) Leave the redaction document as Informational, but reduce it to being an > informative reference in the other documents (with softening of surrounding > text to match); +1, this is meaningful. > 3) Stick with the current arrangement and tell the IESG explicitly that we > think it’s appropriate the way it is. IMHO, by this argument, [RFC4408] could be moved to the normative references section of marf-as. > Comments, please. While I agree that placing references according to the status of referred documents is nice, I don't think it is so essential a facet as to seriously disrupt publication schedules for perfecting it. From vesely@tana.it Sat Dec 31 03:56:21 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1970421F845A for ; Sat, 31 Dec 2011 03:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 CXFfleCdTBi7 for ; Sat, 31 Dec 2011 03:56:20 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5624421F844B for ; Sat, 31 Dec 2011 03:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1325332578; bh=+qFPu4r9t8RlusqB8IAFjLAJHFPCgZo66Yp8c1o7X7Y=; l=2336; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=BtdOVvudHHgHsajlcQGFRlnlFUh3vofvAJNpJrCW/TCvyqSTs21vTMdkEA34BmSs7 nF4e0OwN4tZbp+urSJq70pAkrcSkbRsj1kamRIpmzledtWazMbKTGgUOcVeeqUeTDl FIzSe17Rjhz/cbNsS94fYebBzTDSf260omID03kA= Received: from [109.113.80.123] ([109.113.80.123]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 31 Dec 2011 12:56:14 +0100 id 00000000005DC039.000000004EFEF860.00006116 Message-ID: <4EFEF84D.9080709@tana.it> Date: Sat, 31 Dec 2011 12:55:57 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: marf@ietf.org References: <20111230122352.B74C8F58095@smtp.patriot.net> In-Reply-To: <20111230122352.B74C8F58095@smtp.patriot.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 11:56:21 -0000 On 29.12.2011 20:05, Shmuel (Seymour J.) Metz wrote: > In <4EFC5F35.8020805@tana.it>, on 12/29/2011 > at 01:38 PM, Alessandro Vesely said: > >> * Neither the RFC nor the draft mention degrading the offending IP's >> profile at the firewall. > > I assume that you mean RFC 6449 and not RFC 5965. Yes, RFC 6449 and draft-ietf-marf-as. For example, I have a script that bans an IP for a year, at the firewall level. I call it for intractable spammers. The script checks the IP, and if it finds SMTP listening there, it sends an ARF message there, RCPT TO: , telling them it is about to ban the IP. It rarely works, but sometimes sorts a visible effect. Neither of those methods are mentioned in either the RFC or the draft. >> * The RFC says replying to feedback is useless. > > I don't see that, although I do see "not necessary". Yes, the Third thing in Section 4.3 of the RFC. For unsolicited feedback, consider the first ARF messages that an MTA submits to a given consumer. MTAs should keep a database of consumers that they send feedback to. New entries in the database need to be assessed, and a reply in such cases would be useful. For example, the feedback generator could add a Reply-To field to the header of the ARF messages in case it wishes to receive an acknowledge. >> The obvious correction for an acknowledged policy contravention >> is to remove the email address of the original recipient from >> whatever storage it was retrieved from for sending the reported >> message, including mailing lists. > > I would say that the obvious for an acknowledged policy contravention > is to remove all email address that contravene the policy, not just > the one in the ARF report. Failing to do so could lead to blocking of > the sending IP or IP block. Yes, you already said so on 4 Sep, in the last paragraph of http://www.ietf.org/mail-archive/web/marf/current/msg01289.html I amended that paragraph in my working copy, by adding the sentence that you did not quote. Then I proposed it for the Security Considerations of marf-as. As there is no non-invasive established method to prove subscriptions (yet) I don't think it could make much sense to suggest to carry out such kind of check, e.g. by asking each user to reconfirm subscription. From johnl@iecc.com Sat Dec 31 07:25:35 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B745421F8482 for ; Sat, 31 Dec 2011 07:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.899 X-Spam-Level: X-Spam-Status: No, score=-106.899 tagged_above=-999 required=5 tests=[AWL=-4.300, 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 yVP7xVhtnUAE for ; Sat, 31 Dec 2011 07:25:35 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 201DB21F8480 for ; Sat, 31 Dec 2011 07:25:34 -0800 (PST) Received: (qmail 2173 invoked from network); 31 Dec 2011 15:25:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 31 Dec 2011 15:25:31 -0000 Date: 31 Dec 2011 15:25:09 -0000 Message-ID: <20111231152509.55169.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <4EFC5F35.8020805@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [marf] I-D Action: draft-ietf-marf-as-02.txt X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 15:25:35 -0000 This seems way, way, over-detailed for an Appliability Statement. As I understand it, and AS is intented to answer basic questions about "what do you use this for"? In the case of ARF, the answer is that mostly you use it in private FBLs, but we've found that you can also use it for normal abuse reports. That's it. When we have more experience with using ARF in abuse reports, we might put some of this stuff in a BCP, but since I don't know anyone other than me who has much experience using them in abuse reprots, that seems rather premature. R's, John > Mailbox Providers SHOULD perform any possible checks to ascertain > that the messages reported by their users, that they are about to > report in turn, really originated at the domain they intend to > forward it to. This includes checking that the reporting user did > not inadvertently or maliciously alter the reported message. Mailbox > Providers MAY digitally sign received messages on delivery in order > to perform this check. > > Mailbox Providers SHOULD manually inspect the messages reported by > their users if their spam score is noticeably low --which might > indicate that the user hit the spam-button by mistake. > > Mailbox Providers should evaluate the trustworthiness of the target > abuse team, possibly using external reputation providers. It is not > worth to send any information to domains that exist for the sole > purpose of spamming. Mailbox Providers MAY redact the reported > message, according to its policy and to the reputation of the > destination. Redacting techniques are discussed in [REDACT]. > > The obvious correction for an acknowledged policy contravention is to > remove the email address of the original recipient from whatever > storage it was retrieved from for sending the reported message, > including mailing lists. An abuse team may need to investigate > whether email addresses are stored legitimately on their customer's > systems, or if any malware is running there. From johnl@iecc.com Sat Dec 31 09:34:24 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6228821F845B for ; Sat, 31 Dec 2011 09:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=-3.909, 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 LrZOkqWrA0qa for ; Sat, 31 Dec 2011 09:34:24 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CE5EE21F847F for ; Sat, 31 Dec 2011 09:34:23 -0800 (PST) Received: (qmail 65691 invoked from network); 31 Dec 2011 17:34:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 31 Dec 2011 17:34:21 -0000 Date: 31 Dec 2011 17:33:59 -0000 Message-ID: <20111231173359.90500.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] Document status(es) X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 17:34:24 -0000 >1) Upgrade the redaction document to Proposed Standard, and include in it a note that it is a proposal at this >point and not a mature protocol, leaving the applicability statement and the authfailure-report documents >unchanged; I'd rather do this. It really does propose a standard way to do something, after all. R's, John PS: Yes, it occurred to me that this would be one of the first new PS under the new two-track scheme. From shmuel+gen@patriot.net Sat Dec 31 15:40:55 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751E221F8444 for ; Sat, 31 Dec 2011 15:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.081 X-Spam-Level: X-Spam-Status: No, score=-1.081 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_40=-0.185] 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 OCuIOlb3-mro for ; Sat, 31 Dec 2011 15:40:51 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2007121F8438 for ; Sat, 31 Dec 2011 15:40:50 -0800 (PST) Received: from ECS60015111 (unknown [69.72.27.43]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 2C3C7F5808A for ; Sat, 31 Dec 2011 18:27:18 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sat, 31 Dec 2011 17:43:59 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20111231232719.2C3C7F5808A@smtp.patriot.net> Subject: Re: [marf] Document status(es) X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 23:40:55 -0000 In , on 12/29/2011 at 10:46 AM, "Murray S. Kucherawy" said: >The WG needs to decide how to resolve this. Barry and I think there >are three options: IMHO all three options are viable even though each has issues. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003)