From msk@cloudmark.com Mon Jun 6 11:46: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 9128511E8196 for ; Mon, 6 Jun 2011 11:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpuiBi74X1kS for ; Mon, 6 Jun 2011 11:46:35 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACF911E8179 for ; Mon, 6 Jun 2011 11:46:35 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 6 Jun 2011 11:46:34 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 6 Jun 2011 11:46:33 -0700 Thread-Topic: No meeting in Quebec City Thread-Index: Acwkeg6/LcnbB+d7Q/Cl9oa9VizzqA== 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_F5833273385BB34F99288B3648C4F06F134C91940BEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] No meeting in Quebec City 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, 06 Jun 2011 18:46:35 -0000 --_000_F5833273385BB34F99288B3648C4F06F134C91940BEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Unless there's objection, MARF will not be meeting in Quebec City. We feel= the group needs to spend more writing time than face time right now, so we= 'd rather let other groups that need the room slots use them. -MSK, as chair --_000_F5833273385BB34F99288B3648C4F06F134C91940BEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Unless thereR= 17;s objection, MARF will not be meeting in Quebec City.  We feel the = group needs to spend more writing time than face time right now, so we̵= 7;d rather let other groups that need the room slots use them.

 

-MSK, as c= hair

= --_000_F5833273385BB34F99288B3648C4F06F134C91940BEXCHC2corpclo_-- From vesely@tana.it Tue Jun 21 05:09: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 15D5821F84E2 for ; Tue, 21 Jun 2011 05:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.346 X-Spam-Level: X-Spam-Status: No, score=-5.346 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3pK0bOAHzKv for ; Tue, 21 Jun 2011 05:09:29 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 193A521F84E1 for ; Tue, 21 Jun 2011 05:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1308658167; bh=AbT+r5oAZGSWLXaNWS6wVdXR4V4TOh+rkrGyBw51Zs8=; l=2325; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=VgbWtbFt5WpHc8skD/LcCJTiv4J01LwY+DzlqkYtcJbVURIWLIYMaC/kqP5UolWTt yhaOzb2bD+21fPEJEhAZO83AUF3vMmBpveJSxVMzVZ669lJk364cU+i4myTf7urmfw 8MPVacGwHy9DOhHIm3W/6sgZ2fDmovsBGvbitc1o= 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, 21 Jun 2011 14:09:27 +0200 id 00000000005DC033.000000004E0089F7.000023A1 Message-ID: <4E0089F2.20708@tana.it> Date: Tue, 21 Jun 2011 14:09:22 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: marf@ietf.org References: <1C806C86-8D87-4FC9-9A36-58BB22076AB7@cybernothing.org> In-Reply-To: <1C806C86-8D87-4FC9-9A36-58BB22076AB7@cybernothing.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] draft-jdfalk-marf-as 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, 21 Jun 2011 12:09:30 -0000 On 15/May/11 18:27, J.D. Falk wrote: > http://datatracker.ietf.org/doc/draft-jdfalk-marf-as/ > > I've already noticed a couple of minor things I need to correct, > but I'll wait until there've been more comments before uploading > another version. > > What do y'all thank? Would it be possible to expand treatment of non-FBL data? I heard rumors about FBL being considered illegal in Europe. I'd bet it's not, although EU law requires users' consent. At any rate, for clarity, I'd avoid calling "FBL" the unsolicited feedback generated without prior agreement. Appendix C in the CFBL BCP has some preliminary work on non-FBL. A topic that I think should be worked out a little bit more is the choice between mailbox and access providers. In section 2 of ARF-AS I would say that a report can alternatively be sent to one of a) a sender authenticated with DKIM or SPF, b) the abuse-mailbox found in the RIR WHOIS database for the IP address of the boundary relay, or c) a network provider higher in such allocation hierarchy. In section 3, I'd complement bullet (c) above with the suggestion that a network provider who receives a report relative to an IP that they gave to a mailbox provider, may forward that report to that provider's abuse-mailbox, besides possibly doing their own trending. Bullet (a) should also be cross-checked with WHOIS data, according to the last paragraph of section C1 of CFBL BCP. I'm not sure how. Should abuse-mailbox's parent entries have a (repeatable) "domain" attribute? Domain WHOIS apparently don't have abuse-mailboxes. The CFBL BCP says to ignore abuse-reports sent by mistake. Perhaps, this is where the non-spam ARF type has to be used, sending back the message to the author's mailbox provider so that they can undo any learning they had imparted to their spam filtering systems. Of course, the non-spam report needs to be acknowledged by the user who originally reported the message as spam. In case the user and the remote provider don't agree, either one or both of them deserve being categorized as bogus abuse-report sources. (As silly as this may seem, it may turn out to be a good way to categorize gullible spammers and unreliable users.) For a minor point, the possibility to redact reported messages is not mentioned. From jdfalk-lists@cybernothing.org Thu Jun 23 11:30: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 555ED9E8056 for ; Thu, 23 Jun 2011 11:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djZCO2SQU8Ou for ; Thu, 23 Jun 2011 11:30:31 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 18F7D9E8055 for ; Thu, 23 Jun 2011 11:30:31 -0700 (PDT) Received: from [192.168.1.191] (adsl-69-228-65-174.dsl.pltn13.pacbell.net [69.228.65.174]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5NITuhw022077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 23 Jun 2011 11:30:28 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p5NITuhw022077 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1308853828; bh=j1VeBd6r2+yqGG8c1YQcWZJKgjxTSHXnEtyKdgpnh SI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=a0L19CdA3yO1 XPL/hoVMndZEfrPTaoNo1gCWDU9xiqtODO9TQp9Ar4djIEPSmEJPvzYoTEl5T2p0QZV IzDa0uzWSLu0qPp8MbNrzeeduMI1ZMHA6IsiBc+PiDP0pTZvegUBJIqa2ISDd6Vlplh xEG5Ybvl96+fWmLt7qeqcmcrU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <4E0089F2.20708@tana.it> Date: Thu, 23 Jun 2011 11:29:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3A5386A5-348E-4F98-9DB3-4E93BB2D3100@cybernothing.org> References: <1C806C86-8D87-4FC9-9A36-58BB22076AB7@cybernothing.org> <4E0089F2.20708@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] draft-jdfalk-marf-as 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, 23 Jun 2011 18:30:32 -0000 On Jun 21, 2011, at 5:09 AM, Alessandro Vesely wrote: > Would it be possible to expand treatment of non-FBL data? I heard > rumors about FBL being considered illegal in Europe. I'd bet it's > not, although EU law requires users' consent. At any rate, for > clarity, I'd avoid calling "FBL" the unsolicited feedback generated > without prior agreement. This particular Applicability Statement is already restricted to = solicited, end-user-triggered complaint feedback, so it does (in section = 2, end of list item 1) point to the part of the MAAWG Complaint FBL BCP = which discusses policy concerns. > Appendix C in the CFBL BCP has some preliminary work on non-FBL. A > topic that I think should be worked out a little bit more is the > choice between mailbox and access providers. In section 2 of ARF-AS I > would say that a report can alternatively be sent to one of >=20 > a) a sender authenticated with DKIM or SPF, > b) the abuse-mailbox found in the RIR WHOIS database for the IP > address of the boundary relay, or > c) a network provider higher in such allocation hierarchy. That'd need to be a different Applicability Statement, describing = non-solicited feedback. This one only describes solicited feedback (as = described in the introduction and in section 2 list item 3, among other = places.) I don't believe that there's sufficient implementation experience for an = AS on non-solicited feedback, but I could be wrong. > The CFBL BCP says to ignore abuse-reports sent by mistake. Perhaps, > this is where the non-spam ARF type has to be used, sending back the > message to the author's mailbox provider so that they can undo any > learning they had imparted to their spam filtering systems. Seems technically feasible, but I've never heard of any implementation = which works that way today. > Of > course, the non-spam report needs to be acknowledged by the user who > originally reported the message as spam. In case the user and the > remote provider don't agree, either one or both of them deserve being > categorized as bogus abuse-report sources. (As silly as this may > seem, it may turn out to be a good way to categorize gullible spammers > and unreliable users.) This is already fairly common, without needing to juggle = externally-visible metadata. For example, Cloudmark is known to track = reporter reputation within their spam reporting system. > For a minor point, the possibility to redact reported messages is not > mentioned. Good point, especially since we have a separate draft for that. Only = question is whether draft-jdfalk-marf-redaction will advance any time = soon; I sure would like to get the BCP and AS finished and published = sooner. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From jdfalk-lists@cybernothing.org Thu Jun 23 11:38: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 B335821F8493 for ; Thu, 23 Jun 2011 11:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHtl5KVse13G for ; Thu, 23 Jun 2011 11:38:14 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id EF5CC21F848F for ; Thu, 23 Jun 2011 11:38:10 -0700 (PDT) Received: from [192.168.1.191] (adsl-69-228-65-174.dsl.pltn13.pacbell.net [69.228.65.174]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5NIbc1K022181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 23 Jun 2011 11:38:10 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p5NIbc1K022181 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1308854290; bh=BRwO+XAKMjL1pLRxhTiMC/HLbrYycpuUupG3s1oxA SA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=YJR/VzP3KAkT w6cw5SxdG9m+kzB0bGmPy11sroyFJaedE3LtR7CFZSKblo2gQxt5q2MIV942KKAgCCZ 0Vga+4qHSt7FIRCg/EsJl6/AT2Bx/Fo+yHlXsVxaaeQWhMk6sKPvaO+60gRI9/v61LP 1S7QlB1xQ4PDcDjBmGJ3b2Rso= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <20110131191547.C3FC5F580AF@smtp.patriot.net> Date: Thu, 23 Jun 2011 11:37:37 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20110131191547.C3FC5F580AF@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] Nits in draft-jdfalk-maawg-cfblbcp-00.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, 23 Jun 2011 18:38:14 -0000 On Jan 31, 2011, at 11:24 AM, Shmuel (Seymour J.) Metz wrote: > Just a couple of items in the front of > draft-jdfalk-maawg-cfblbcp-00.txt that need correction or > clarification. > > The command is MAIL; FROM:reverse-path is an operand. > > The definition of rDNS should mention that the RR is a PTR, not an A. Thanks! I've corrected these, at long last. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From jdfalk-lists@cybernothing.org Thu Jun 23 11:52: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 18E8F11E807D for ; Thu, 23 Jun 2011 11:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exwhyzOeJGOm for ; Thu, 23 Jun 2011 11:52:17 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id F3F1111E8088 for ; Thu, 23 Jun 2011 11:52:16 -0700 (PDT) Received: from [192.168.1.191] (adsl-69-228-65-174.dsl.pltn13.pacbell.net [69.228.65.174]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5NIphET022403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 23 Jun 2011 11:52:16 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p5NIphET022403 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1308855136; bh=Q6daL+tz0xxbB8+h4F0BdMJ/bhLAWO3Qd+RnFtDGa 4Q=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=f1vvKroMv0fRNleCT/gRpZyfj iiaBZdC/x6GyMKYdvZBgWUdTqaTB2jqz67ZpMEU5AEo/k05O39iS3otml+Djt6YFCNF qA+qeuSaNAJ3uxBzq4Fa+kczSm2u499iLAmroPqdG84C6747k+cOvZnKK3nJKo5XQvf q2L7/Y4AnBS4= From: "J.D. Falk" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jun 2011 11:51:43 -0700 References: <20110623184921.23102.27094.idtracker@ietfa.amsl.com> To: Message Abuse Report Format working group Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [marf] Fwd: New Version Notification for draft-jdfalk-maawg-cfblbcp-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, 23 Jun 2011 18:52:19 -0000 Just FYI, I've submitted this updated version with a few nits fixed and = contacted the Independent Stream editor to get that process started. Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 23, 2011 11:49:21 AM PDT > To: ietf@cybernothing.org > Cc: ietf@cybernothing.org > Subject: New Version Notification for = draft-jdfalk-maawg-cfblbcp-01.txt > authentication-results: ocelope.disgruntled.net/p5NInMuR022371; = dkim=3Dnone (no signature) header.i=3Dunknown; dkim-asp=3Dnone >=20 > A new version of I-D, draft-jdfalk-maawg-cfblbcp-01.txt has been = successfully submitted by J.D. Falk and posted to the IETF repository. >=20 > Filename: draft-jdfalk-maawg-cfblbcp > Revision: 01 > Title: Complaint Feedback Loop Best Current Practices > Creation date: 2011-06-23 > WG ID: Individual Submission > Number of pages: 36 >=20 > Abstract: > Complaint Feedback Loops similar to those described herein have > existed for more than a decade, resulting in many de facto standards > and best practices. This document is an attempt to codify, and thus > clarify, the ways that both providers and consumers of these = feedback > mechanisms intend to use the feedback, describing some = already-common > industry best practices. >=20 > This paper is the result of cooperative efforts within the Messaging > Anti-Abuse Working Group, a trade organization separate from the > IETF. The original MAAWG document upon which this document is based > was published in April, 2010. While not originally written as an > Internet Draft, it has been contributed to the IETF standards > repository in order to make it easier to incorporate this material > into IETF work. >=20 >=20 >=20 >=20 > The IETF Secretariat -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From johnl@iecc.com Thu Jun 23 12:29:53 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 CC57511E816B for ; Thu, 23 Jun 2011 12:29:53 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LAXW1Bb2Tgi for ; Thu, 23 Jun 2011 12:29:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4C80F11E80AC for ; Thu, 23 Jun 2011 12:29:52 -0700 (PDT) Received: (qmail 4959 invoked from network); 23 Jun 2011 19:29:51 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 23 Jun 2011 19:29:51 -0000 Date: 23 Jun 2011 19:29:29 -0000 Message-ID: <20110623192929.13813.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <3A5386A5-348E-4F98-9DB3-4E93BB2D3100@cybernothing.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] draft-jdfalk-marf-as 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, 23 Jun 2011 19:29:53 -0000 >I don't believe that there's sufficient implementation experience for >an AS on non-solicited feedback, but I could be wrong. I've been sending all of my abuse reports in ARF format for several years. I get the target addresses by a combination of looking up rDNS in abuse.net and a largish local table of IP address ranges->domains. It works reasonably well, at least as well as sending messages just pasted in as text. I used to get a lot of responses that said "we're too scared and/or incompetent to open your attachment so send it pasted in", but I haven't gotten any of those in a while. My experience, which may or may not be typical of what other people would find, is that sending reports in ARF format works fine, but figuring out where to send them is a big challenge. In particular, getting the addresses from WHOIS works poorly both because of the iffy quality of WHOIS data, and because WHOIS servers don't have the capacity to handle high volume scraping. R's, John From jdfalk-lists@cybernothing.org Thu Jun 23 12:51:41 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 7D78811E807A for ; Thu, 23 Jun 2011 12:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+VQskHIEkKt for ; Thu, 23 Jun 2011 12:51:40 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7749011E8072 for ; Thu, 23 Jun 2011 12:51:40 -0700 (PDT) Received: from [192.168.1.191] (adsl-69-228-65-174.dsl.pltn13.pacbell.net [69.228.65.174]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5NJp7n7023456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 23 Jun 2011 12:51:39 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p5NJp7n7023456 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1308858699; bh=yEtW5kTUn+HkLrKdIWTxpJKl5PcljgvuQlwUugSsc IM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=RQSM59/pKAKH iNvyRTomO7VEdejGFzHJAEVkX5m7gPewjOTGuRNq78VBUGhZYLFNf8s43s0WgbvwT9Q og1kFTwMxf4+evNPFiuzuVEByuYNjpc1l8ChgfD1rufqMAiWtJf82Kgd0g0iojj/sHg QrsbasRUmy4oD+cn2wCHFuZs8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: <20110623192929.13813.qmail@joyce.lan> Date: Thu, 23 Jun 2011 12:51:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110623192929.13813.qmail@joyce.lan> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] draft-jdfalk-marf-as 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, 23 Jun 2011 19:51:41 -0000 On Jun 23, 2011, at 12:29 PM, John Levine wrote: >> I don't believe that there's sufficient implementation experience for >> an AS on non-solicited feedback, but I could be wrong. >=20 > I've been sending all of my abuse reports in ARF format for several > years. I get the target addresses by a combination of looking up rDNS > in abuse.net and a largish local table of IP address ranges->domains. > It works reasonably well, at least as well as sending messages just > pasted in as text. I used to get a lot of responses that said "we're > too scared and/or incompetent to open your attachment so send it > pasted in", but I haven't gotten any of those in a while. >=20 > My experience, which may or may not be typical of what other people > would find, is that sending reports in ARF format works fine, but > figuring out where to send them is a big challenge. In particular, > getting the addresses from WHOIS works poorly both because of the iffy > quality of WHOIS data, and because WHOIS servers don't have the > capacity to handle high volume scraping. Since you're pretty much the only one, a "My Uncommon Practices" = document could be useful. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From johnl@iecc.com Thu Jun 23 13:27: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 40B1521F8444 for ; Thu, 23 Jun 2011 13:27:59 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCV1kWDCtkuM for ; Thu, 23 Jun 2011 13:27:58 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8339A21F8449 for ; Thu, 23 Jun 2011 13:27:58 -0700 (PDT) Received: (qmail 19564 invoked from network); 23 Jun 2011 20:27:57 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 23 Jun 2011 20:27:57 -0000 Date: 23 Jun 2011 20:27:34 -0000 Message-ID: <20110623202734.31332.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] draft-jdfalk-marf-as 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, 23 Jun 2011 20:27:59 -0000 >Since you're pretty much the only one, a "My Uncommon Practices" document could be useful. Surely it should be a BCP. Since it is the only practice, by definition it must be the best, and we know from the DKIM mailing list document that whatever the C stands for, it's not common. R's, John From barryleiba.mailing.lists@gmail.com Fri Jun 24 07:10: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 672C421F84E2 for ; Fri, 24 Jun 2011 07:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.918 X-Spam-Level: X-Spam-Status: No, score=-102.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuvmJA-pZD8L for ; Fri, 24 Jun 2011 07:10:35 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 562BB21F84E1 for ; Fri, 24 Jun 2011 07:10:35 -0700 (PDT) Received: by gxk19 with SMTP id 19so1698965gxk.31 for ; Fri, 24 Jun 2011 07:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Z4ROjwtlh77ULIlLldRa18QFRUqJBYm1HmHU9Kz7R2s=; b=lxKz+CHl7p+H3hTpIactomjw2mg8SDXFlNO2igHq25PTh3aZCJoDTqHoUe/pIB+oGt 5t4ebF9dEUpY/45iVLZiEILZNbPFKS8KujA74YqBAcBoypaTrqBog4OwxBMebCffaqQ2 1fRAYkRUT/X2iNaDc8Owfd7pZMveOKDt/t1Mc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=IT4ubIdWWLznfxa4ZgBTVBKrjOcR0eE5OB6uOWAWO0mSg7+gI1GoJFP50o1Wwf1Z7l OfF0nwtla8MC5wI4qO/jOzr4m1f942BIFegGrSUFnRAgADYowfiqO3M7FSV+yUtSlf7+ GOorfpdBLGfq90EU8oG/9PhIkFs9da/Txxztg= MIME-Version: 1.0 Received: by 10.151.60.14 with SMTP id n14mr3926808ybk.72.1308924626538; Fri, 24 Jun 2011 07:10:26 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.170.15 with HTTP; Fri, 24 Jun 2011 07:10:26 -0700 (PDT) In-Reply-To: <20110623202734.31332.qmail@joyce.lan> References: <20110623202734.31332.qmail@joyce.lan> Date: Fri, 24 Jun 2011 10:10:26 -0400 X-Google-Sender-Auth: ndhhTv4FcVC8ZudrbB0fhynoJeQ Message-ID: From: Barry Leiba To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: marf@ietf.org Subject: Re: [marf] draft-jdfalk-marf-as 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, 24 Jun 2011 14:10:36 -0000 > Surely it should be a BCP. Since it is the only practice, by definition > it must be the best, and we know from the DKIM mailing list document > that whatever the C stands for, it's not common. Stop being snarky. [Checks "from" line.] Oh, wait... never mind. Barry, as Barry From vesely@tana.it Fri Jun 24 09:17: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 61F5F11E8096 for ; Fri, 24 Jun 2011 09:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.189 X-Spam-Level: X-Spam-Status: No, score=-5.189 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdPIwomUO+6I for ; Fri, 24 Jun 2011 09:17:28 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 457AB11E808E for ; Fri, 24 Jun 2011 09:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1308932246; bh=Wg+bz8/teVjfiayFgVKgLxGDAHZ6+UNglN+5QQ2VqY8=; l=1276; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=bgY9XrK3YLSP4bUKC78HkAegAkzaF4vAqED1Qk0Jlj0labZ5HJqFj5bPUgM3+kwgB UvLedpALYswyDR+zUHEbCKH+SlhANSuj+jpyvUjeXgAuzDBrWDnuMWqCwcbUoZPNwB 7x094zjSF0elX+iQE/eCvP066yjmdkB6cnAzqYQM= 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, 24 Jun 2011 18:17:26 +0200 id 00000000005DC03F.000000004E04B896.000019CA Message-ID: <4E04B896.5010604@tana.it> Date: Fri, 24 Jun 2011 18:17:26 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <20110623192929.13813.qmail@joyce.lan> In-Reply-To: <20110623192929.13813.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [marf] Abuse reporting, was draft-jdfalk-marf-as 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, 24 Jun 2011 16:17:29 -0000 On 23/Jun/11 21:29, John Levine wrote: > My experience, which may or may not be typical of what other people > would find, is that sending reports in ARF format works fine, but > figuring out where to send them is a big challenge. Yes. > In particular, getting the addresses from WHOIS works poorly both > because of the iffy quality of WHOIS data, and because WHOIS > servers don't have the capacity to handle high volume scraping. I don't agree. WHOIS is trying and getting better. IIRC, I found an abuse POC in Arin saying something like they haven't been able to verify such address for a while. A rather non-formal statement that suggests they do routinely check those email addresses. https://www.arin.net/policy/nrpm.html#three6 The abuse contact is mandatory in Apnic http://www.apnic.net/policy/proposals/prop-079 Ripe has an abuse finder tool, and a task force is discussing the introduction of an abuse-c. http://apps.db.ripe.net/search/abuse-finder.html http://www.ripe.net/ripe/groups/tf/abuse-contact I think a document is needed in order to state the "obvious" facts that RIRs don't have the scope for discussing. Since JD said it cannot be part of the FBL AS, we'd probably better write a new one. Is it possible to do so? From internet-drafts@ietf.org Tue Jun 28 06:35: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 DD71721F85CD; Tue, 28 Jun 2011 06:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBHZp0Gte794; Tue, 28 Jun 2011 06:35:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB221F8585; Tue, 28 Jun 2011 06:35:07 -0700 (PDT) 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.55 Message-ID: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 06:35:07 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.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, 28 Jun 2011 13:35:23 -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 : SPF Authentication Failure Reporting using the Abuse Rep= ort Format Author(s) : Scott Kitterman Filename : draft-ietf-marf-spf-reporting-00.txt Pages : 16 Date : 2011-06-28 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-00.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-00.txt From sklist@kitterman.com Tue Jun 28 06:42: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 19B0C11E80D1 for ; Tue, 28 Jun 2011 06:42:08 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVyvUV+HKQQ4 for ; Tue, 28 Jun 2011 06:42:06 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECA111E80B4 for ; Tue, 28 Jun 2011 06:42:06 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 615BE38C140; Tue, 28 Jun 2011 09:42:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1309268525; bh=iVXu/616zxZh9yFNjva5E+jevFYLi/85rDsi3lAYSfM=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=CLpYm9R9SjkCUC4frXVa0MiG4odAkQ7uLN9evsz9oAXC8zGhyuKLI1RgYFI5aTGuw mFEetSN3kw3gg9Lu24srHEh1MhWNr01e+QZaI2MkqBgriD+b3Wr6W+JN3qhiVOU7wo Am3tfBW32CBsKGJyvBdjAokzcqvuwT2sQTgFJW6c= From: Scott Kitterman To: marf@ietf.org Date: Tue, 28 Jun 2011 09:42:03 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) References: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> In-Reply-To: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106280942.04119.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.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, 28 Jun 2011 13:42:08 -0000 On Tuesday, June 28, 2011 09:35:07 AM internet-drafts@ietf.org wrote: ... > Title : SPF Authentication Failure Reporting using the Abuse > Report Format Author(s) : Scott Kitterman ... This is the first draft of the split out document. Please review and let me know how it can be improved. Scott K From vesely@tana.it Tue Jun 28 09:44: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 2800D11E813D for ; Tue, 28 Jun 2011 09:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.659 X-Spam-Level: X-Spam-Status: No, score=-5.659 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPodyUcjN9m0 for ; Tue, 28 Jun 2011 09:44:21 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5A09F11E8105 for ; Tue, 28 Jun 2011 09:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1309279458; bh=uCBKqyYixlGVukrPR+AOsUs4j5eWnH17XhiIp70T4O0=; l=1322; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=kWB0R6s9DaM0UBPCoaMU7hUkA51gdZKjgSaOsoc3tW3U7xLaWDqdICKexLxFR3Gvf Cb05w1xYrBG6raLtG81PjBl5FO0h7p8txVu+hoG9gj2S5MsRgYtC2AVRrjqFJhxIRY VfIALVohKwCu84TYroWCP08gOIlEoUU/YsX/vin0= 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, 28 Jun 2011 18:44:18 +0200 id 00000000005DC033.000000004E0A04E2.00000C87 Message-ID: <4E0A04E2.3040904@tana.it> Date: Tue, 28 Jun 2011 18:44:18 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> <201106280942.04119.sklist@kitterman.com> In-Reply-To: <201106280942.04119.sklist@kitterman.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.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, 28 Jun 2011 16:44:22 -0000 On 28/Jun/11 15:42, Scott Kitterman wrote: > On Tuesday, June 28, 2011 09:35:07 AM internet-drafts@ietf.org wrote: > ... >> Title : SPF Authentication Failure Reporting using the Abuse >> Report Format Author(s) : Scott Kitterman > ... > > This is the first draft of the split out document. Please review and let me > know how it can be improved. I have some comments on both I-Ds. Actually, there should be three I-Ds, so my comments perhaps are about the missing one. One point is the reference to [I-D.MARF-DKIM-REPORTING]. Shouldn't that refer to the missing I-D, i.e. RFCxxxx "Abuse Report Format (ARF) Extensions for Authentication Failure Reporting" instead? I liked the idea of splitting the documents, but would now recommend factoring some text where possible. A second point is the idea of a "conditional" report. That may mean, e.g., only send me an SPF-failure report if you verified a DKIM signature for the same domain name. By enabling reporting, one will likely receive an inordinate amount of spam generated notifications: it will be useful to check mail settings of a new domain, but will turned off after a short time. Conditional reporting, instead, can be kept permanently enabled. What do you think? Third point, an example of a complete report would be appreciated. From sklist@kitterman.com Tue Jun 28 09:52: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 8C08611E80E4 for ; Tue, 28 Jun 2011 09:52:29 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqcqgGy37SZ4 for ; Tue, 28 Jun 2011 09:52:29 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0761D11E80C3 for ; Tue, 28 Jun 2011 09:52:29 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 8899338C140; Tue, 28 Jun 2011 12:52:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1309279944; bh=KLVXWXO5LBCtwo5LngUSrJ4lqCVihl23ECpTz8vpxOA=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=fszfGHLvPemSiqHx6Nn/eAC2JtT09XeGt/9PkSJBZLo8Of19Vqs2kd086HW7cBMpF N0Ct6ZV8RzlkszKNDxOeVfbbwiUYllgXAPOlU8m/66lbiEIL1XQV5/Hd0I47VRt5Gj OpkAJDfYwog3KxElaR3QYymKd6Z4eRTby7ge8dOM= From: Scott Kitterman To: marf@ietf.org Date: Tue, 28 Jun 2011 12:52:22 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) References: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> <201106280942.04119.sklist@kitterman.com> <4E0A04E2.3040904@tana.it> In-Reply-To: <4E0A04E2.3040904@tana.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106281252.23049.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.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, 28 Jun 2011 16:52:29 -0000 On Tuesday, June 28, 2011 12:44:18 PM Alessandro Vesely wrote: > On 28/Jun/11 15:42, Scott Kitterman wrote: > > On Tuesday, June 28, 2011 09:35:07 AM internet-drafts@ietf.org wrote: > > ... > > > >> Title : SPF Authentication Failure Reporting using the Abuse > >> > >> Report Format Author(s) : Scott Kitterman > > > > ... > > > > This is the first draft of the split out document. Please review and let > > me know how it can be improved. > > I have some comments on both I-Ds. Actually, there should be three > I-Ds, so my comments perhaps are about the missing one. One point is > the reference to [I-D.MARF-DKIM-REPORTING]. Shouldn't that refer to > the missing I-D, i.e. RFCxxxx "Abuse Report Format (ARF) Extensions > for Authentication Failure Reporting" instead? Yes. It should. I'm hoping that one will be done soon (I'm not the one doing it). I also have a couple of downrefs to sort out. > I liked the idea of splitting the documents, but would now recommend > factoring some text where possible. > > A second point is the idea of a "conditional" report. That may mean, > e.g., only send me an SPF-failure report if you verified a DKIM > signature for the same domain name. By enabling reporting, one will > likely receive an inordinate amount of spam generated notifications: > it will be useful to check mail settings of a new domain, but will > turned off after a short time. Conditional reporting, instead, can be > kept permanently enabled. What do you think? I'm not sure how useful that would be since that would get you reports for any mail that was forwarded as well. I suspect the reverse, send a DKIM failure report if SPF passed for the same domain might be useful, but I suspect complex enough to take up as a separate topic. > Third point, an example of a complete report would be appreciated. I think that goes in the still missing Abuse Report Format (ARF) Extensions for Authentication Failure Reporting. Once I see what's covered in that draft, I may have additions for this one, we'll see. Scott K From internet-drafts@ietf.org Tue Jun 28 15:04: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 ACF8A11E8132; Tue, 28 Jun 2011 15:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTnnbhBecEV2; Tue, 28 Jun 2011 15:04:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA7B11E8101; Tue, 28 Jun 2011 15:04:09 -0700 (PDT) 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.55 Message-ID: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> Date: Tue, 28 Jun 2011 15:04:09 -0700 Cc: marf@ietf.org Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.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, 28 Jun 2011 22:04:09 -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-00.txt Pages : 19 Date : 2011-06-28 This memo registers an extension report type to ARF to be used for reporting forensic information about messages that fail one or more message authentication schemes in use by the purported sender of the message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-00.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-00.txt From hfontana@ecertsystems.com Tue Jun 28 15:11: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 EEFEB11E8102 for ; Tue, 28 Jun 2011 15:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoIky0k78Bae for ; Tue, 28 Jun 2011 15:11:14 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCD1F11E814D for ; Tue, 28 Jun 2011 15:11:13 -0700 (PDT) Received: by qyk9 with SMTP id 9so2902857qyk.10 for ; Tue, 28 Jun 2011 15:11:12 -0700 (PDT) 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 :content-type; bh=B5Fnokq8cbqPS1XgEgMhhyjFfcfPnr+Eo64OwUs2ZOM=; b=ZDg8JIEhp95Lwa4aooRD84FYUuy+k5HH5I7m9D2yxodMc2CAEdm9eYU9+Y+lhPaSfr yezT+vZ7GPu3EA2i7QowQBrrKV19q+zb6IlSRDGJlEJtMFbNVlqPSk51gOXty9ed7+Wg UmEV/VQCV/p9gk+IMxgV6/92Z5xEC0GQCtUzo= Received: by 10.229.7.74 with SMTP id c10mr33972qcc.283.1309299072096; Tue, 28 Jun 2011 15:11:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.57.132 with HTTP; Tue, 28 Jun 2011 15:10:51 -0700 (PDT) In-Reply-To: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> From: Hilda Fontana Date: Tue, 28 Jun 2011 15:10:51 -0700 Message-ID: To: marf@ietf.org Content-Type: multipart/alternative; boundary=0015175cdac018d93604a6ccf2bf Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.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, 28 Jun 2011 22:11:15 -0000 --0015175cdac018d93604a6ccf2bf Content-Type: text/plain; charset=ISO-8859-1 This is the first draft of the split out document for the ARF reporting. Please review and let me know how best to improve it. thanks H On Tue, Jun 28, 2011 at 3:04 PM, wrote: > 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-00.txt > Pages : 19 > Date : 2011-06-28 > > This memo registers an extension report type to ARF to be used for > reporting forensic information about messages that fail one or more > message authentication schemes in use by the purported sender of the > message. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-00.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-authfailure-report-00.txt > _______________________________________________ > 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. --0015175cdac018d93604a6ccf2bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is the first draft of the split out document for the ARF reporting.=A0= Please review and let me know how best to improve it.

thanks
H

On Tue, Jun 28, 2011 at 3:04 PM, <internet-draf= ts@ietf.org> wrote:
A New Internet-Dr= aft is available from the on-line Internet-Drafts directories. This draft i= s a work item of the Messaging Abuse Reporting Format Working Group of the = IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Authentication Failure Reportin= g using the Abuse Report Format
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Hilda L. Fontana
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-marf-authfailure-repor= t-00.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 19
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-06-28

=A0 This memo registers an extension report type to ARF to be used for
=A0 reporting forensic information about messages that fail one or more =A0 message authentication schemes in use by the purported sender of the =A0 message.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-= ietf-marf-authfailure-report-00.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-ie= tf-marf-authfailure-report-00.txt
_______________________________________________
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

--0015175cdac018d93604a6ccf2bf-- From scott@kitterman.com Tue Jun 28 15:26:12 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 3775921F8724 for ; Tue, 28 Jun 2011 15:26:12 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4tHFlBqvuIq for ; Tue, 28 Jun 2011 15:26:11 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id 57F5121F8729 for ; Tue, 28 Jun 2011 15:26:11 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 8682A38C140; Tue, 28 Jun 2011 18:26:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1309299970; bh=3Bj4oXLc0nb7kqVLIgDxg6Xfm2SIVbx2npGyYO7PyBc=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=MuBVyBgeRD8MHRD9N7RK3RM+Xoopil+wwRfzyZYu9/vWP1L5cV1Ttjy1cQnXG9Tks jAsNa71ofkVajc8bx+ekYMW9/Dhn0tjEYQ6eDfmRcvK59pYv7vOD/GuyW6qJ+/MWRb VNUOQ8fznWO85g4F0wmxjj285z1foysChCA00Lu0= From: Scott Kitterman To: marf@ietf.org Date: Tue, 28 Jun 2011 18:26:09 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201106281826.09663.scott@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Tue, 28 Jun 2011 15:36:14 -0700 Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.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, 28 Jun 2011 22:26:12 -0000 On Tuesday, June 28, 2011 06:10:51 PM Hilda Fontana wrote: > This is the first draft of the split out document for the ARF reporting. > Please review and let me know how best to improve it. Paragraph 3.3 ... spf: The evaluation of the sending domain's SPF record produced a "fail" or "softfail" result.? Please change to: spf: The evaluation of the sending domain's SPF record produced a "Fail", "SoftFail", or "PermError" result. The capitalization is consistent with the way RFC 4408 describes the results. This also better aligns this draft with draft-ietf-marf-spf-reporting-00.txt (I do have TempError in the draft now, but I'll drop it for -01). Para 4/6.2 ... spf-dns will need to be a multiple appearance type as via include mechanisms or redirect modifiers multiple records commonly needed to be retrieved to determine an SPF result. It should also be a domain-spec (for the domain for which the record was retrieved) and a quoted-string for the actual record. Scott K From hfontana@ecertsystems.com Tue Jun 28 15:58: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 036FD11E81B8 for ; Tue, 28 Jun 2011 15:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCIP9uuBeD9q for ; Tue, 28 Jun 2011 15:58:03 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id A8E5111E81B1 for ; Tue, 28 Jun 2011 15:57:57 -0700 (PDT) Received: by qyk29 with SMTP id 29so497763qyk.10 for ; Tue, 28 Jun 2011 15:57:57 -0700 (PDT) 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=YEiB7hpAOeMpdQhP72YYmrqbTljMZscFxJ6dn4Mveqg=; b=Sj3B92NYba1B1VpkCjR4uOnfIimk7L05NXaETm6pMiCARdDIwpkgxhzE0dRRAix+2Q fRLU9p3qXH2bQvrChkq52RF3+H7OiimlvJ3+VWasHcPDIXBKAi2A5L1vHwmEw45PLiTm qnbZb1ozhK9xB2MIm9Uqp49DBd+/6fvBgtLGA= Received: by 10.229.215.6 with SMTP id hc6mr87230qcb.93.1309301877118; Tue, 28 Jun 2011 15:57:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.57.132 with HTTP; Tue, 28 Jun 2011 15:57:37 -0700 (PDT) In-Reply-To: <201106281826.09663.scott@kitterman.com> References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> <201106281826.09663.scott@kitterman.com> From: Hilda Fontana Date: Tue, 28 Jun 2011 15:57:37 -0700 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=0016363100854a17d004a6cd9923 Cc: marf@ietf.org Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.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, 28 Jun 2011 22:58:04 -0000 --0016363100854a17d004a6cd9923 Content-Type: text/plain; charset=ISO-8859-1 thank you Scott I will update On Tue, Jun 28, 2011 at 3:26 PM, Scott Kitterman wrote: > On Tuesday, June 28, 2011 06:10:51 PM Hilda Fontana wrote: > > This is the first draft of the split out document for the ARF reporting. > > Please review and let me know how best to improve it. > > Paragraph 3.3 ... > > spf: The evaluation of the sending domain's SPF record produced a > "fail" or "softfail" result.? > > Please change to: > > spf: The evaluation of the sending domain's SPF record produced a > "Fail", "SoftFail", or "PermError" result. > > The capitalization is consistent with the way RFC 4408 describes the > results. > This also better aligns this draft with > draft-ietf-marf-spf-reporting-00.txt > (I do have TempError in the draft now, but I'll drop it for -01). > > Para 4/6.2 ... > > spf-dns will need to be a multiple appearance type as via include > mechanisms > or redirect modifiers multiple records commonly needed to be retrieved to > determine an SPF result. It should also be a domain-spec (for the domain > for > which the record was retrieved) and a quoted-string for the actual record. > > Scott K > _______________________________________________ > 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. --0016363100854a17d004a6cd9923 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable thank you Scott I will update

On Tue, Jun= 28, 2011 at 3:26 PM, Scott Kitterman <scott@kitterman.com> wrote:
On Tuesday, June 28, 2011 06:10:51 PM Hilda Fontana wrote= :
> This is the first draft of the split out document for the ARF reportin= g.
> Please review and let me know how best to improve it.

Paragraph 3.3 ...

spf: =A0The evaluation of the sending domain's SPF record produced a =A0 =A0 =A0"fail" or "softfail" result.?

Please change to:

spf: =A0The evaluation of the sending domain's SPF record produced a =A0 =A0 =A0"Fail", "SoftFail", or "PermError"= ; result.

The capitalization is consistent with the way RFC 4408 describes the result= s.
This also better aligns this draft with draft-ietf-marf-spf-reporting-00.tx= t
(I do have TempError in the draft now, but I'll drop it for -01).

Para 4/6.2 ...

spf-dns will need to be a multiple appearance type as via include mechanism= s
or redirect modifiers multiple records commonly needed to be retrieved to determine an SPF result. =A0It should also be a domain-spec (for the domain= for
which the record was retrieved) and a quoted-string for the actual record.<= br>
Scott K
_________________________________________= ______
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

--0016363100854a17d004a6cd9923-- From msk@cloudmark.com Tue Jun 28 16:27: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 94C6721F86B1 for ; Tue, 28 Jun 2011 16:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.766 X-Spam-Level: X-Spam-Status: No, score=-103.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TejX88px+Of7 for ; Tue, 28 Jun 2011 16:27:00 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2D21F21F858D for ; Tue, 28 Jun 2011 16:27:00 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 28 Jun 2011 16:26:53 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 28 Jun 2011 16:26:52 -0700 Thread-Topic: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.txt Thread-Index: Acw1sqLMn6IE1PeySXSkngrVZqoJ2QANZhnA Message-ID: References: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> <201106280942.04119.sklist@kitterman.com> <4E0A04E2.3040904@tana.it> In-Reply-To: <4E0A04E2.3040904@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] I-D Action: draft-ietf-marf-spf-reporting-00.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, 28 Jun 2011 23:27:00 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Tuesday, June 28, 2011 9:44 AM > To: marf@ietf.org > Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.txt >=20 > A second point is the idea of a "conditional" report. That may mean, > e.g., only send me an SPF-failure report if you verified a DKIM > signature for the same domain name. By enabling reporting, one will > likely receive an inordinate amount of spam generated notifications: > it will be useful to check mail settings of a new domain, but will > turned off after a short time. Conditional reporting, instead, can be > kept permanently enabled. What do you think? I'm wary of going down this road. Although the current suite of extension = drafts goes into only DKIM and SPF, it's possible (maybe likely) that other= message evaluation schemes will be added here later. A true-false table o= f just DKIM and SPF has a size of four; adding one more makes it eight, etc= . Eventually putting policy information able to account for all combinatio= ns into the DNS will become completely ugly. From sklist@kitterman.com Tue Jun 28 17:46: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 D5B3E1F0C4A for ; Tue, 28 Jun 2011 17:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4p52zxR-rHI for ; Tue, 28 Jun 2011 17:46:48 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id EE3CC1F0C49 for ; Tue, 28 Jun 2011 17:46:47 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 0D119D04083; Tue, 28 Jun 2011 19:46:47 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1309308407; bh=qoZgDigcOqG9Tp+VCDGbHCuOPlYwyspstZf1W0bALxI=; h=References:In-Reply-To:MIME-Version:Content-Type:Subject:From: Date:To:Message-ID; b=HTBXpmatkFablRZMQAKclIxyop+t059qAHeJCKPEkAo2O3rI8foKbL4q6EQmGFOvf S1Hkou0u209ix2Hf4Fu2Dae/j1PGyrZo7/5CQS7l52ykB8bxShC8+9cfO7ioYAtz7Y n5v6Hx9/IUOR4zHgfzQK9jIragTg5PfF0AjzeslM= Received: from 226.sub-97-239-157.myvzw.com (226.sub-97-239-157.myvzw.com [97.239.157.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E3401D04007; Tue, 28 Jun 2011 19:46:44 -0500 (CDT) References: <20110628133507.5389.21089.idtracker@ietfa.amsl.com> <201106280942.04119.sklist@kitterman.com> <4E0A04E2.3040904@tana.it> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----BJVE2EBEEYXNE8U1CRYPACG37P4I8U" From: Scott Kitterman Date: Tue, 28 Jun 2011 20:46:06 -0400 To: "marf@ietf.org" Message-ID: <5cd17f05-324a-4bbf-b0a7-67b3b2e32a73@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.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, 29 Jun 2011 00:46:49 -0000 ------BJVE2EBEEYXNE8U1CRYPACG37P4I8U Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "Murray S. Kucherawy" wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf >Of Alessandro Vesely >> Sent: Tuesday, June 28, 2011 9:44 AM >> To: marf@ietf.org >> Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.txt >> >> A second point is the idea of a "conditional" report. That may mean, >> e.g., only send me an SPF-failure report if you verified a DKIM >> signature for the same domain name. By enabling reporting, one will >> likely receive an inordinate amount of spam generated notifications: >> it will be useful to check mail settings of a new domain, but will >> turned off after a short time. Conditional reporting, instead, can >be >> kept permanently enabled. What do you think? > >I'm wary of going down this road. Although the current suite of >extension drafts goes into only DKIM and SPF, it's possible (maybe >likely) that other message evaluation schemes will be added here later. >A true-false table of just DKIM and SPF has a size of four; adding one >more makes it eight, etc. Eventually putting policy information able >to account for all combinations into the DNS will become completely >ugly. This is generally true, but think send a feedback report on SPF Pass without a valid DKIM signature could be useful to answer the question "Let me know about stuff coming out of my IP space that isn't DKIM signed". This is a real question I know is getting asked. It might be useful to have a standardized way to ask and answer it. I don't support addressing this now. I don't support a general solution for all possible combinations. Perhaps after the current work is done we'll know what makes sense. Scott K ------BJVE2EBEEYXNE8U1CRYPACG37P4I8U Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

"Murray S. Kucherawy" <msk@cloudmark.com> wrote:

>> -----Original Message-----
>> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf
>Of Alessandro Vesely
>> Sent: Tuesday, June 28, 2011 9:44 AM
>> To: marf@ietf.org
>> Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.txt
>>
>> A second point is the idea of a "conditional" report. That may mean,
>> e.g., only send me an SPF-failure report if you verified a DKIM
>> signature for the same domain name. By enabling reporting, one will
>> likely receive an inordinate amount of spam generated notifications:
>> it will be useful to check mail settings of a new domain, but will
>> turned off after a short time. Conditional reporting, instead, can
>be
>> kept permanently enabled. What do you think?
>
>I'm wary of going down this road. Although the current suite of
>extension drafts goes into only DKIM and SPF, it's possible (maybe
>likely) that other message evaluation schemes will be added here later.
>A true-false table of just DKIM and SPF has a size of four; adding one
>more makes it eight, etc. Eventually putting policy information able
>to account for all combinations into the DNS will become completely
>ugly.

This is generally true, but think send a feedback report on SPF Pass without a valid DKIM signature could be useful to answer the question "Let me know about stuff coming out of my IP space that isn't DKIM signed". This is a real question I know is getting asked. It might be useful to have a standardized way to ask and answer it.

I don't support addressing this now. I don't support a general solution for all possible combinations. Perhaps after the current work is done we'll know what makes sense.

Scott K ------BJVE2EBEEYXNE8U1CRYPACG37P4I8U-- From johnl@iecc.com Tue Jun 28 18:35:34 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 9DD32228017 for ; Tue, 28 Jun 2011 18:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.921 X-Spam-Level: X-Spam-Status: No, score=-108.921 tagged_above=-999 required=5 tests=[AWL=2.278, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zxc8JSQv0GJ for ; Tue, 28 Jun 2011 18:35:34 -0700 (PDT) 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 EFCC5228016 for ; Tue, 28 Jun 2011 18:35:33 -0700 (PDT) Received: (qmail 8812 invoked from network); 29 Jun 2011 01:35:33 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 29 Jun 2011 01:35:33 -0000 Received: (qmail 67441 invoked from network); 29 Jun 2011 01:35:33 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 29 Jun 2011 01:35:33 -0000 Date: 29 Jun 2011 01:35:11 -0000 Message-ID: <20110629013511.18491.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <5cd17f05-324a-4bbf-b0a7-67b3b2e32a73@email.android.com> 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-spf-reporting-00.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, 29 Jun 2011 01:35:34 -0000 >This is generally true, but think send a feedback report on SPF Pass >without a valid DKIM signature could be useful to answer the question >"Let me know about stuff coming out of my IP space that isn't DKIM >signed". This is a real question I know is getting asked. It might be >useful to have a standardized way to ask and answer it. But how often is it asked outside the context of setting up an FBL? If you're already making private arrangements between the sender and the recipient, you can handle the policy stuff out of line. The reason to put it in the protocol is to say "Hey, world! I want you to run this complex state machine to decide when to send me stuff that I might or might not accept!" That doesn't seem very useful to me. R's, John From sklist@kitterman.com Tue Jun 28 21:00: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 8B0D611E80D5 for ; Tue, 28 Jun 2011 21:00:15 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ATXHPhJygTw for ; Tue, 28 Jun 2011 21:00:14 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by ietfa.amsl.com (Postfix) with ESMTP id D8A3511E80A0 for ; Tue, 28 Jun 2011 21:00:14 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 74E4638C14C; Wed, 29 Jun 2011 00:00:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1309320014; bh=aWHTdF6aMxPUznuIlS2xmKHbmrITTuz3CvwgsPr4+Gw=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=hDChxmTjx65JYJIejaefbgCq5tGgftmtKE6tTINcvfmrr3F3P0Krh+dZc8mPih/LV JG1MmpQbiYr8vqfLS+GKHN3SGZvmPLHfGxJGlI+qaSTnFbOMmvhN1Lk7AUZrcEwz4/ VHopugNw4uAq9b3h88n850A+PiGcBg85TKQafo6c= From: Scott Kitterman To: marf@ietf.org Date: Wed, 29 Jun 2011 00:00:11 -0400 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic-pae; KDE/4.6.2; i686; ; ) References: <20110629013511.18491.qmail@joyce.lan> In-Reply-To: <20110629013511.18491.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201106290000.11594.sklist@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.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, 29 Jun 2011 04:00:15 -0000 On Tuesday, June 28, 2011 09:35:11 PM John Levine wrote: > >This is generally true, but think send a feedback report on SPF Pass > >without a valid DKIM signature could be useful to answer the question > >"Let me know about stuff coming out of my IP space that isn't DKIM > >signed". This is a real question I know is getting asked. It might be > >useful to have a standardized way to ask and answer it. > > But how often is it asked outside the context of setting up an FBL? > If you're already making private arrangements between the sender > and the recipient, you can handle the policy stuff out of line. > > The reason to put it in the protocol is to say "Hey, world! I want you > to run this complex state machine to decide when to send me stuff that > I might or might not accept!" That doesn't seem very useful to me. I'd say that's A reason. The entire MARF WG is somewhat vulnerable to these same sentiments. If such arrangements are a set once and forget it setup then perhaps. OTOH, if these are things that are subject to change (perhaps, for example, reporting requirements are different during a particular system upgrade rollout) then there is utility is having a standardized set of knobs to turn so that software support adjustments without a lot of customization or cost. We absolutely can save this argument for later, so we probably should. We may collectively know more by then. Scott K From vesely@tana.it Wed Jun 29 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 7CA5B9E800C for ; Wed, 29 Jun 2011 07:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.189 X-Spam-Level: X-Spam-Status: No, score=-5.189 tagged_above=-999 required=5 tests=[AWL=-0.470, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTHXRStLDNB2 for ; Wed, 29 Jun 2011 07:25:34 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B29EB9E800B for ; Wed, 29 Jun 2011 07:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1309357531; bh=RwxXdoeCwd4uw64+I8qRHJqigx88+ca0ZE28Vm5PZVM=; l=5738; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ZYghj+13Mb+wZBVZOM1kcs9UznlVeJdP2CZEb1OiN3dvfQDsEu1AxvTvF6Ne9CB+g GMcljlqe6334n6S1xeZbnJfhXwI41qqf4vA4wZAnOKwpNr+ZKagEk82AObp3VVRzqD lv8qai1nsW3JqrEumH1OM5O3h+cyp61l8RasV77I= 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, 29 Jun 2011 16:25:31 +0200 id 00000000005DC035.000000004E0B35DB.00004C2D Message-ID: <4E0B35DB.10402@tana.it> Date: Wed, 29 Jun 2011 16:25:31 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: marf@ietf.org References: <20110628220409.17100.29803.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-authfailure-report-00.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, 29 Jun 2011 14:25:35 -0000 On 29/Jun/11 00:10, Hilda Fontana wrote: > This is the first draft of the split out document for the ARF > reporting. Please review and let me know how best to improve it. I have a bunch of comments. I just place them below and apologize for a lengthy message. Please trim and edit the subject appropriately if replying inline about just a few topics. * Section 1. Introduction I suggest to grab the final paragraph and the "RFCxxxx" list from Murray's Introduction in dkim-reporting. * Section 3.1. Authentication-Results: Why should one include results "for both DKIM and SPF even if those tests were not actually performed"? [AUTH-RESULTS] does not provide for adding result information for a test that was not performed. For example, "dkim=none" means the message had no signature. To indicate that no authentication was performed one may just write "none", but then that's not for either DKIM or SPF. Why should one copy A-R fields from the reported message? The original fields are still available in the message/rfc822 part of the report. It may be interesting to know which one(s) triggered the report generation. The Auth-Failure field just tells its type. The original message may contain multiple A-R fields by multiple authentication servers. We can assume that the triggering A-R field is the topmost one of the given type. The Reporting-MTA won't necessarily match the authserv-id of any A-R field, because [ARF] defines Reporting-MTA as optional and does not provide it with such semantics. We may invent a new "Verifying-MTA", say, for matching purposes. But is this worth? IMHO, the simplest specification is that the feedback-report part contains just the triggering A-Rs, whether or not they are also present in the message/rfc822 part of the report. * Section 3.2. New ARF header fields The first paragraph says they are "extensions to Section 6.2 of [ARF]", which I couldn't find. I'd mention Section 3.1 of [ARF] instead, and quote that such fields "MUST appear exactly once". * Sections 3.2.1 and 3.3. Failure types. How about defining Auth-Failure as "method/token"? The method would have to be a registered authentication method[*], the token could be either the result (e.g. "fail") or a keyword defined by the specific ARF extension document (e.g. "revoked"). [*] http://www.iana.org/assignments/email-auth/email-auth.xml People would be unable to report an "iprev" failure, if they wanted to, because there is no ARF extension for that. If one writes such an extension, it will have to work without requiring this I-D to be modified, won't it? In this case, Section 3.3 should just specify the field semantics, i.e. its last paragraph. It would also be worth to introduce a new section describing the minimal template that a specific ARF extension should instantiate to register itself, if going for this pattern. Anyway, the I-D references Section 3.3 implicitly from Section 3.2.1 ("The list of valid values is enumerated below") and Section 4 ("as specified elsewhere in this memo"). An xref would be useful. DNS errors on retrieving a RR have a different effect for DKIM than for SPF. The inability to retrieve a (valid) DKIM key deserves its own failure type. For a minor issue, the "Auth-Failure" field bears the same name as this Feedback-Type field's value. This is probably bound to generate confusion when one mentions such phrase with the wrong capitalization. * Section 3.2.2. Required For DKIM Reports People involved in reporting spf (or iprev) will not interested in this section. IMHO, it would be better to just mention that each type-specific ARF extension may define further fields, and move these definitions to dkim-reporting. Anyway, the list misses the DKIM-Canonicalized-Body. I wouldn't suggest that such field be required, as it is unneeded if the failure can be located anywhere else, e.g. reporting bad public key syntax. * Section 7.2. Forgeries. We should state that reports should not be recursively generated against authentication failures for auth-failure reports. Possibly, empty envelope sender addresses should inhibit report generation too. * Section 7.5. Reporting Multiple Incidents I don't think this topic belongs to Security Considerations, although part of it does. IMHO, the main issue is to define the semantics of the Requested Report Interval (ri). Each type-specific ARF extension can then reuse it, and limit itself to defining ri's emplacement. I like very much the idea of exponentially growing intervals for groups of nearly-identical failure reasons. Perhaps, such interval type could be indicated by adding a suffix, e.g. "ri=10e"? (BTW, "inverse-exponential" means logarithmic to calculus-oriented readers, which is probably not what we want to mean.) Apps might have problems complying with such specification. For example, setting up a semaphore for permanent storage of per-type failure counts may imply a whole bunch of requirements that an implementation is not prepared or willing to take. What should it do then, send all or none of them? If we want to allow customizing downgraded behavior we can use yet another suffix, e.g. "ri=10e+" to send all reports in case the reporter app is unable to properly manage exponential Report Intervals. Alternatively, we can specify what downgraded behavior is implied. * Section B.1. The Auth-Failure: field is missing in feedback-report. A DKIM-Signature by example.com is missing in the header. We don't require reports to be DKIM-signed, but by signing the example we can express our preference (somewhere between MAY and SHOULD, I'd guess.) From msk@cloudmark.com Wed Jun 29 10:42: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 B210811E808E for ; Wed, 29 Jun 2011 10:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.872 X-Spam-Level: X-Spam-Status: No, score=-103.872 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBmeSQFpq5Z6 for ; Wed, 29 Jun 2011 10:42:36 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id C27F911E808C for ; Wed, 29 Jun 2011 10:42:36 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 29 Jun 2011 10:42:36 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 29 Jun 2011 10:42:35 -0700 Thread-Topic: [marf] Abuse reporting, was draft-jdfalk-marf-as Thread-Index: AcwyijtkHKVOT9MhRUSmT9QMqVA4YQD+YVTg Message-ID: References: <20110623192929.13813.qmail@joyce.lan> <4E04B896.5010604@tana.it> In-Reply-To: <4E04B896.5010604@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] Abuse reporting, was draft-jdfalk-marf-as 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, 29 Jun 2011 17:42:37 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of A= lessandro Vesely > Sent: Friday, June 24, 2011 9:17 AM > To: marf@ietf.org > Subject: [marf] Abuse reporting, was draft-jdfalk-marf-as >=20 > I don't agree. WHOIS is trying and getting better. IIRC, I found an > abuse POC in Arin saying something like they haven't been able to > verify such address for a while. A rather non-formal statement that > suggests they do routinely check those email addresses. > https://www.arin.net/policy/nrpm.html#three6 >=20 > The abuse contact is mandatory in Apnic > http://www.apnic.net/policy/proposals/prop-079 >=20 > Ripe has an abuse finder tool, and a task force is discussing the > introduction of an abuse-c. > http://apps.db.ripe.net/search/abuse-finder.html > http://www.ripe.net/ripe/groups/tf/abuse-contact >=20 > I think a document is needed in order to state the "obvious" facts > that RIRs don't have the scope for discussing. Since JD said it > cannot be part of the FBL AS, we'd probably better write a new one. >=20 > Is it possible to do so? We'd have to recharter to do it. For now if you want to get started, post = it as an individual submission, and later we can consider rechartering to t= ake it on. Also, John pointed you at the WEIRDS pre-working-group list. ICANN people = approached me about starting that effort up, and right now they're explorin= g requirements. There will probably be a bar BoF at the Quebec City confer= ence next month followed by a lobby to create a working group later on once= they get some momentum going. It's true that any standard we produce won't compel a WHOIS provider to giv= e out information it doesn't want to make available, but ICANN does have a = little more stomping power on registrars than the IETF does. -MSK From jdfalk-lists@cybernothing.org Wed Jun 29 19:23: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 6473611E80C3 for ; Wed, 29 Jun 2011 19:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLQDS0P1bVak for ; Wed, 29 Jun 2011 19:23:56 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 57C8211E80BB for ; Wed, 29 Jun 2011 19:23:56 -0700 (PDT) Received: from [192.168.11.36] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5U2Nqt4007203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 29 Jun 2011 19:23:55 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p5U2Nqt4007203 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1309400635; bh=4oC7T4Vfm2iT840y3Jlf97rFkW+Dt/VmZiqNAZGO+ 9k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=EJpHkLD8akb5 xjqvPHePEs4Ma+gHg7xwmdME04ZP8gXGK+4oaIunbLDSbQHvP2EK6xMXIcdjWMWS+9l c2Pzhq6jBdaa3S2H4G4AfCslY3ptvzdej6g1NdGT/OiCjRx0X6pagUKkvwhCTuHEG6R GtL07GrrRDODl/uLWBNqWUgj4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Wed, 29 Jun 2011 19:23:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <15BC94AD-21A9-49EA-BA14-D1463181C261@cybernothing.org> References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.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, 30 Jun 2011 02:23:57 -0000 On Jun 28, 2011, at 3:10 PM, Hilda Fontana wrote: > This is the first draft of the split out document for the ARF = reporting. Please review and let me know how best to improve it. If Delivery-Result: is required, then I expect we'll see a lot (perhaps = a majority) of implementations being intentionally non-standard and = omitting it anyway. Mailbox providers tend to be /very/ touchy about = who they'll share exact delivery results with, and for good reason: the = bad guys have lots of incentives to try to trick their way into delivery = feedback results that they can use to tune their spamming systems. I'd urge making that an optional field, or possibly include a = null/refused value. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From msk@cloudmark.com Wed Jun 29 21:44: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 1D6A411E811B for ; Wed, 29 Jun 2011 21:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.777 X-Spam-Level: X-Spam-Status: No, score=-103.777 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7rroXklQXwV for ; Wed, 29 Jun 2011 21:44:28 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id ABB9111E80C8 for ; Wed, 29 Jun 2011 21:44:28 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 29 Jun 2011 21:44:28 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 29 Jun 2011 21:44:27 -0700 Thread-Topic: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.txt Thread-Index: Acw2zMR4HrLShlcgTPaAim2M1vXzbAAE1juw Message-ID: References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> <15BC94AD-21A9-49EA-BA14-D1463181C261@cybernothing.org> In-Reply-To: <15BC94AD-21A9-49EA-BA14-D1463181C261@cybernothing.org> 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-00.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, 30 Jun 2011 04:44:29 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= .D. Falk > Sent: Wednesday, June 29, 2011 7:24 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.txt >=20 > If Delivery-Result: is required, then I expect we'll see a lot (perhaps > a majority) of implementations being intentionally non-standard and > omitting it anyway. Mailbox providers tend to be /very/ touchy about > who they'll share exact delivery results with, and for good reason: the > bad guys have lots of incentives to try to trick their way into > delivery feedback results that they can use to tune their spamming > systems. >=20 > I'd urge making that an optional field, or possibly include a > null/refused value. Just to be clear, you mean that in the context of auth-failure reports spec= ifically, and not ARF in general? I'm thinking if you're willing to update your feedback generation system to= support auth-failure reports, then you understand what's involved and woul= d be willing to do this as well. But I don't run an FBL myself (yet) so I = admit this is speculation. From jdfalk-lists@cybernothing.org Thu Jun 30 09:53:41 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 94C3311E8195 for ; Thu, 30 Jun 2011 09:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0Ebk+l2HUa9 for ; Thu, 30 Jun 2011 09:53:40 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2581111E8194 for ; Thu, 30 Jun 2011 09:53:32 -0700 (PDT) Received: from [192.168.11.36] (c-76-126-154-212.hsd1.ca.comcast.net [76.126.154.212]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5UGrMYD019822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 30 Jun 2011 09:53:28 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p5UGrMYD019822 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1309452809; bh=S3I68ht+cjLLbnNsNbvc6FoCw84Vkxhk+IqVQqtGI Mw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=a5LVIqplCA9h UUluRpdYlMgn/zsBdA8g4XVov5vmPKekVuBDWlZXiYaEiyYOntg7vzWuCOapfMrb7Yf C6cMg+7cQx2meFKEF8ZuJqJ5Ri8eKTJGmu9RqMzqe9Yr0KDBU/KVV9AXH7cAFr5ikVe NOMo0cpZaeOXH2sexUfr6ImIQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "J.D. Falk" In-Reply-To: Date: Thu, 30 Jun 2011 09:53:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> <15BC94AD-21A9-49EA-BA14-D1463181C261@cybernothing.org> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.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, 30 Jun 2011 16:53:41 -0000 On Jun 29, 2011, at 9:44 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of J.D. Falk >> Sent: Wednesday, June 29, 2011 7:24 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] I-D Action: = draft-ietf-marf-authfailure-report-00.txt >>=20 >> If Delivery-Result: is required, then I expect we'll see a lot = (perhaps >> a majority) of implementations being intentionally non-standard and >> omitting it anyway. Mailbox providers tend to be /very/ touchy about >> who they'll share exact delivery results with, and for good reason: = the >> bad guys have lots of incentives to try to trick their way into >> delivery feedback results that they can use to tune their spamming >> systems. >>=20 >> I'd urge making that an optional field, or possibly include a >> null/refused value. >=20 > Just to be clear, you mean that in the context of auth-failure reports = specifically, and not ARF in general? I was only thinking about the auth-results context for now, but I'd = imagine I'll make a similar point for /any/ ARF extension that tries to = convey the results of a post-receipt (after 250) spam filtering module. = This is from experience, not philosophy. > I'm thinking if you're willing to update your feedback generation = system to support auth-failure reports, then you understand what's = involved and would be willing to do this as well. But I don't run an = FBL myself (yet) so I admit this is speculation. Getting into philosophy now, I think that conflating authentication = results with inbox/spam folder placement is a layer violation. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions= From hfontana@ecertsystems.com Thu Jun 30 10:32: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 92B6411E8293 for ; Thu, 30 Jun 2011 10:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQC2PxI5oJ6g for ; Thu, 30 Jun 2011 10:32:54 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE6311E8295 for ; Thu, 30 Jun 2011 10:32:53 -0700 (PDT) Received: by qwc23 with SMTP id 23so2013845qwc.31 for ; Thu, 30 Jun 2011 10:32:53 -0700 (PDT) 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=12tEFhBr6rx/SnOel7YXdKVv+gJLSVo7X0Laf358YEw=; b=KKJp+r9mv3RHzLgyYMBWr/LM96zJqpgJFRK2Um7oYfLVlkGvWdHEhb3qgzFmOR5jnr HTCVSEIkOf7k2KZ2wDiytWasFAnjuFGt8Ak1jP/7KIR6BidZ2UURgU6iIfqTRHDEO0rF ENPJQEfPk6Wg1LlP8l+rNwJOHRR/xgq+vY8Zo= Received: by 10.229.129.139 with SMTP id o11mr1802280qcs.17.1309455173086; Thu, 30 Jun 2011 10:32:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.57.132 with HTTP; Thu, 30 Jun 2011 10:32:33 -0700 (PDT) In-Reply-To: <15BC94AD-21A9-49EA-BA14-D1463181C261@cybernothing.org> References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> <15BC94AD-21A9-49EA-BA14-D1463181C261@cybernothing.org> From: Hilda Fontana Date: Thu, 30 Jun 2011 10:32:33 -0700 Message-ID: To: "J.D. Falk" Content-Type: multipart/alternative; boundary=000e0cd6ca4e70ec7804a6f14a27 Cc: Message Abuse Report Format working group Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.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, 30 Jun 2011 17:32:55 -0000 --000e0cd6ca4e70ec7804a6f14a27 Content-Type: text/plain; charset=ISO-8859-1 experience shows that most ISPs will indicate delivered or rejected not indicated what the actual outcome was i.e. inbox or spam - perhaps we could change the wording to something along those lines On Wed, Jun 29, 2011 at 7:23 PM, J.D. Falk wrote: > On Jun 28, 2011, at 3:10 PM, Hilda Fontana wrote: > > > This is the first draft of the split out document for the ARF reporting. > Please review and let me know how best to improve it. > > If Delivery-Result: is required, then I expect we'll see a lot (perhaps a > majority) of implementations being intentionally non-standard and omitting > it anyway. Mailbox providers tend to be /very/ touchy about who they'll > share exact delivery results with, and for good reason: the bad guys have > lots of incentives to try to trick their way into delivery feedback results > that they can use to tune their spamming systems. > > I'd urge making that an optional field, or possibly include a null/refused > value. > > -- > J.D. Falk > the leading purveyor of industry counter-rhetoric solutions > > _______________________________________________ > 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. --000e0cd6ca4e70ec7804a6f14a27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable experience shows that most ISPs will indicate delivered or rejected not ind= icated what the actual outcome was i.e. inbox or spam - perhaps we could ch= ange the wording to something along those lines

On Wed, Jun 29, 2011 at 7:23 PM, J.D. Falk <jdfalk-lists@cybernothing.org>= ; wrote:
On Jun 28, 2011, at 3:10 PM, Hilda Fontana wrote:

> This is the first draft of the split out document for the ARF reportin= g. =A0Please review and let me know how best to improve it.

If Delivery-Result: is required, then I expect we'll see a lot (p= erhaps a majority) of implementations being intentionally non-standard and = omitting it anyway. =A0Mailbox providers tend to be /very/ touchy about who= they'll share exact delivery results with, and for good reason: the ba= d guys have lots of incentives to try to trick their way into delivery feed= back results that they can use to tune their spamming systems.

I'd urge making that an optional field, or possibly include a null/refu= sed value.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

_______________________________________________
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

--000e0cd6ca4e70ec7804a6f14a27-- From hfontana@ecertsystems.com Thu Jun 30 10:36:13 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 3C99C11E8261 for ; Thu, 30 Jun 2011 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsD9EnintfAX for ; Thu, 30 Jun 2011 10:36:12 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8F7F11E808A for ; Thu, 30 Jun 2011 10:36:11 -0700 (PDT) Received: by qwc23 with SMTP id 23so2016102qwc.31 for ; Thu, 30 Jun 2011 10:36:11 -0700 (PDT) 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=wuRMxWRd94ByD22BhGXNLkX3hQ1S9ntBo6adO4/Qd6U=; b=Y+1ef8cXQcmSaeiBkLYDQiWaD0b6p1vCuOrqaATCguA2mBzdPm1H9KggfUdC6xxnKy 1zhAd8/BElvdakhTDST3pncMzU8WJJJmRKmyrw42GFs8Xt8D9ebuwfQ+be+sQscufC/h IZZTIZWOBU6w/ZBeJpTEGU4FucpeHaCrKtjEs= Received: by 10.229.215.6 with SMTP id hc6mr1791399qcb.93.1309455371067; Thu, 30 Jun 2011 10:36:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.57.132 with HTTP; Thu, 30 Jun 2011 10:35:50 -0700 (PDT) In-Reply-To: <4E0B35DB.10402@tana.it> References: <20110628220409.17100.29803.idtracker@ietfa.amsl.com> <4E0B35DB.10402@tana.it> From: Hilda Fontana Date: Thu, 30 Jun 2011 10:35:50 -0700 Message-ID: To: Alessandro Vesely Content-Type: multipart/alternative; boundary=0016363100853de42f04a6f15618 Cc: marf@ietf.org Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-00.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, 30 Jun 2011 17:36:13 -0000 --0016363100853de42f04a6f15618 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 29, 2011 at 7:25 AM, Alessandro Vesely wrote: > On 29/Jun/11 00:10, Hilda Fontana wrote: > > This is the first draft of the split out document for the ARF > > reporting. Please review and let me know how best to improve it. > > I have a bunch of comments. I just place them below and apologize for > a lengthy message. Please trim and edit the subject appropriately if > replying inline about just a few topics. > > > * Section 1. Introduction > > I suggest to grab the final paragraph and the "RFCxxxx" list from > Murray's Introduction in dkim-reporting. > > > * Section 3.1. Authentication-Results: > > Why should one include results "for both DKIM and SPF even if those > tests were not actually performed"? [AUTH-RESULTS] does not provide > for adding result information for a test that was not performed. For > example, "dkim=none" means the message had no signature. To indicate > that no authentication was performed one may just write "none", but > then that's not for either DKIM or SPF. > > Why should one copy A-R fields from the reported message? The > original fields are still available in the message/rfc822 part of the > report. It may be interesting to know which one(s) triggered the > report generation. The Auth-Failure field just tells its type. The > original message may contain multiple A-R fields by multiple > authentication servers. We can assume that the triggering A-R field > is the topmost one of the given type. The Reporting-MTA won't > necessarily match the authserv-id of any A-R field, because [ARF] > defines Reporting-MTA as optional and does not provide it with such > semantics. We may invent a new "Verifying-MTA", say, for matching > purposes. But is this worth? > > IMHO, the simplest specification is that the feedback-report part > contains just the triggering A-Rs, whether or not they are also > present in the message/rfc822 part of the report. > for automation it would be useful for the headers to be standard - so if dkim was not checked perhaps dkim="" would be preferable to dkim=none - to your point above but I think its worth including to try to standardize the format > > > * Section 3.2. New ARF header fields > > The first paragraph says they are "extensions to Section 6.2 of > [ARF]", which I couldn't find. I'd mention Section 3.1 of [ARF] > instead, and quote that such fields "MUST appear exactly once". > > > * Sections 3.2.1 and 3.3. Failure types. > > How about defining Auth-Failure as "method/token"? The method would > have to be a registered authentication method[*], the token could be > either the result (e.g. "fail") or a keyword defined by the specific > ARF extension document (e.g. "revoked"). > [*] http://www.iana.org/assignments/email-auth/email-auth.xml > > People would be unable to report an "iprev" failure, if they wanted > to, because there is no ARF extension for that. If one writes such an > extension, it will have to work without requiring this I-D to be > modified, won't it? In this case, Section 3.3 should just specify the > field semantics, i.e. its last paragraph. It would also be worth to > introduce a new section describing the minimal template that a > specific ARF extension should instantiate to register itself, if going > for this pattern. > > Anyway, the I-D references Section 3.3 implicitly from Section 3.2.1 > ("The list of valid values is enumerated below") and Section 4 ("as > specified elsewhere in this memo"). An xref would be useful. > > DNS errors on retrieving a RR have a different effect for DKIM than > for SPF. The inability to retrieve a (valid) DKIM key deserves its > own failure type. > > For a minor issue, the "Auth-Failure" field bears the same name as > this Feedback-Type field's value. This is probably bound to generate > confusion when one mentions such phrase with the wrong capitalization. > > > * Section 3.2.2. Required For DKIM Reports > > People involved in reporting spf (or iprev) will not interested in > this section. IMHO, it would be better to just mention that each > type-specific ARF extension may define further fields, and move these > definitions to dkim-reporting. > > Anyway, the list misses the DKIM-Canonicalized-Body. I wouldn't > suggest that such field be required, as it is unneeded if the failure > can be located anywhere else, e.g. reporting bad public key syntax. > > > * Section 7.2. Forgeries. > > We should state that reports should not be recursively generated > against authentication failures for auth-failure reports. Possibly, > empty envelope sender addresses should inhibit report generation too. > > > * Section 7.5. Reporting Multiple Incidents > > I don't think this topic belongs to Security Considerations, although > part of it does. IMHO, the main issue is to define the semantics of > the Requested Report Interval (ri). Each type-specific ARF extension > can then reuse it, and limit itself to defining ri's emplacement. > > I like very much the idea of exponentially growing intervals for > groups of nearly-identical failure reasons. Perhaps, such interval > type could be indicated by adding a suffix, e.g. "ri=10e"? (BTW, > "inverse-exponential" means logarithmic to calculus-oriented readers, > which is probably not what we want to mean.) > > Apps might have problems complying with such specification. For > example, setting up a semaphore for permanent storage of per-type > failure counts may imply a whole bunch of requirements that an > implementation is not prepared or willing to take. What should it do > then, send all or none of them? If we want to allow customizing > downgraded behavior we can use yet another suffix, e.g. "ri=10e+" to > send all reports in case the reporter app is unable to properly manage > exponential Report Intervals. Alternatively, we can specify what > downgraded behavior is implied. > > > * Section B.1. > > The Auth-Failure: field is missing in feedback-report. > > A DKIM-Signature by example.com is missing in the header. We don't > require reports to be DKIM-signed, but by signing the example we can > express our preference (somewhere between MAY and SHOULD, I'd guess.) > ok > > _______________________________________________ > 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. --0016363100853de42f04a6f15618 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 29, 2011 at 7:25 AM, Alessan= dro Vesely <vesely@t= ana.it> wrote:
On 29/Jun/11 00:10, Hilda Fontana wrote:
> This is the first draft of the split out document for the ARF
> reporting. =A0Please review and let me know how best to improve it.
I have a bunch of comments. =A0I just place them below and apologize = for
a lengthy message. =A0Please trim and edit the subject appropriately if
replying inline about just a few topics.


* Section 1. =A0Introduction

I suggest to grab the final paragraph and the "RFCxxxx" list from=
Murray's Introduction in dkim-reporting.


* Section 3.1. =A0Authentication-Results:

Why should one include results "for both DKIM and SPF even if those tests were not actually performed"? =A0[AUTH-RESULTS] does not provide=
for adding result information for a test that was not performed. =A0For
example, "dkim=3Dnone" means the message had no signature. =A0To = indicate
that no authentication was performed one may just write "none", b= ut
then that's not for either DKIM or SPF.

Why should one copy A-R fields from the reported message? =A0The
original fields are still available in the message/rfc822 part of the
report. =A0It may be interesting to know which one(s) triggered the
report generation. =A0The Auth-Failure field just tells its type. =A0The original message may contain multiple A-R fields by multiple
authentication servers. =A0We can assume that the triggering A-R field
is the topmost one of the given type. =A0The Reporting-MTA won't
necessarily match the authserv-id of any A-R field, because [ARF]
defines Reporting-MTA as optional and does not provide it with such
semantics. =A0We may invent a new "Verifying-MTA", say, for match= ing
purposes. =A0But is this worth?

IMHO, the simplest specification is that the feedback-report part
contains just the triggering A-Rs, whether or not they are also
present in the message/rfc822 part of the report.

= for automation it would be useful for the headers to be standard - so if dk= im was not checked perhaps dkim=3D"" would be preferable to dkim= =3Dnone - to your point above but I think its worth including to try to sta= ndardize the format=A0


* Section 3.2. =A0New ARF header fields

The first paragraph says they are "extensions to Section 6.2 of
[ARF]", which I couldn't find. =A0I'd mention Section 3.1 of [= ARF]
instead, and quote that such fields "MUST appear exactly once".

* Sections 3.2.1 and 3.3. =A0Failure types.

How about defining Auth-Failure as "method/token"? =A0The method = would
have to be a registered authentication method[*], the token could be
either the result (e.g. "fail") or a keyword defined by the speci= fic
ARF extension document (e.g. "revoked").
[*] http://www.iana.org/assignments/email-auth/email-auth.xml<= /a>

People would be unable to report an "iprev" failure, if they want= ed
to, because there is no ARF extension for that. =A0If one writes such an extension, it will have to work without requiring this I-D to be
modified, won't it? =A0In this case, Section 3.3 should just specify th= e
field semantics, i.e. its last paragraph. =A0It would also be worth to
introduce a new section describing the minimal template that a
specific ARF extension should instantiate to register itself, if going
for this pattern.

Anyway, the I-D references Section 3.3 implicitly from Section 3.2.1
("The list of valid values is enumerated below") and Section 4 (&= quot;as
specified elsewhere in this memo"). =A0An xref would be useful.

DNS errors on retrieving a RR have a different effect for DKIM than
for SPF. =A0The inability to retrieve a (valid) DKIM key deserves its
own failure type.

For a minor issue, the "Auth-Failure" field bears the same name a= s
this Feedback-Type field's value. =A0This is probably bound to generate=
confusion when one mentions such phrase with the wrong capitalization.


* Section 3.2.2. =A0Required For DKIM Reports

People involved in reporting spf (or iprev) will not interested in
this section. =A0IMHO, it would be better to just mention that each
type-specific ARF extension may define further fields, and move these
definitions to dkim-reporting.

Anyway, the list misses the DKIM-Canonicalized-Body. =A0I wouldn't
suggest that such field be required, as it is unneeded if the failure
can be located anywhere else, e.g. reporting bad public key syntax.


* Section 7.2. =A0Forgeries.

We should state that reports should not be recursively generated
against authentication failures for auth-failure reports. =A0Possibly,
empty envelope sender addresses should inhibit report generation too.


* Section 7.5. =A0Reporting Multiple Incidents

I don't think this topic belongs to Security Considerations, although part of it does. =A0IMHO, the main issue is to define the semantics of
the Requested Report Interval (ri). =A0Each type-specific ARF extension
can then reuse it, and limit itself to defining ri's emplacement.

I like very much the idea of exponentially growing intervals for
groups of nearly-identical failure reasons. =A0Perhaps, such interval
type could be indicated by adding a suffix, e.g. "ri=3D10e"? =A0(= BTW,
"inverse-exponential" means logarithmic to calculus-oriented read= ers,
which is probably not what we want to mean.)

Apps might have problems complying with such specification. =A0For
example, setting up a semaphore for permanent storage of per-type
failure counts may imply a whole bunch of requirements that an
implementation is not prepared or willing to take. =A0What should it do
then, send all or none of them? =A0If we want to allow customizing
downgraded behavior we can use yet another suffix, e.g. "ri=3D10e+&quo= t; to
send all reports in case the reporter app is unable to properly manage
exponential Report Intervals. =A0Alternatively, we can specify what
downgraded behavior is implied.


* Section B.1.

The Auth-Failure: field is missing in feedback-report.

A DKIM-Signature by exampl= e.com is missing in the header. =A0We don't
require reports to be DKIM-signed, but by signing the example we can
express our preference (somewhere between MAY and SHOULD, I'd guess.)
ok

_______________________________________________
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

--0016363100853de42f04a6f15618-- From johnl@iecc.com Thu Jun 30 19:48: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 7AF321F0C35 for ; Thu, 30 Jun 2011 19:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.499 X-Spam-Level: X-Spam-Status: No, score=-109.499 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAsDEndKzIzN for ; Thu, 30 Jun 2011 19:48:41 -0700 (PDT) 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 7F5B01F0C34 for ; Thu, 30 Jun 2011 19:48:41 -0700 (PDT) Received: (qmail 30828 invoked from network); 1 Jul 2011 02:48:36 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 1 Jul 2011 02:48:36 -0000 Received: (qmail 53503 invoked from network); 1 Jul 2011 02:48:35 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 1 Jul 2011 02:48:35 -0000 Date: 1 Jul 2011 02:48:13 -0000 Message-ID: <20110701024813.95769.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-authfailure-report-00.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, 01 Jul 2011 02:48:42 -0000 >This is the first draft of the split out document for the ARF reporting. >Please review and let me know how best to improve it. Well, OK. >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. Sorry, never mind. R's, John