From hfontana@ecertsystems.com Tue Apr 5 09:44:00 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C953A6965 for ; Tue, 5 Apr 2011 09:44:00 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEJF3R-mPWYZ for ; Tue, 5 Apr 2011 09:43:58 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 821BC3A6960 for ; Tue, 5 Apr 2011 09:43:57 -0700 (PDT) Received: by pvh1 with SMTP id 1so273681pvh.31 for ; Tue, 05 Apr 2011 09:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecertsystems.com; s=google; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YPaZNfq4RncWBk/WKj1E1Jexyxwo7LLqkjBJte+eA+0=; b=CTBEq1PFmZVu3ErImmZsVJrdttUPkdREawzmLs4RMfutWbcon09+9Z6Ll2rXX6hsAa mogGQjSqY+EmgMNXhsNLAjaAJceyrGGJgbt0qJU/tkI2eziJtNfeUwbtQHplhYp0DiBQ PGG9FpPFmKNt0QYa4erKFOvxbaKrugEAbi2tM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ecertsystems.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=WkikGjuObRI6JfSvbia0rsWaR334eT7vA2vb7m/p50/AWuhVJ/p14bPQ1QJUPRpI3u dJomXb9KsH3hm1golcNdcqyTFzDK1SmZrzTssE0m5iCbVpIzmA3mdrrn1qQz0HEtz8QF WvFTYIubWOFqntl2jDoDq5/RUdgZn/siFN5BY= Received: by 10.142.232.3 with SMTP id e3mr7523508wfh.400.1302021940246; Tue, 05 Apr 2011 09:45:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.168 with HTTP; Tue, 5 Apr 2011 09:45:20 -0700 (PDT) In-Reply-To: References: From: Hilda Fontana Date: Tue, 5 Apr 2011 09:45:20 -0700 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/related; boundary=000e0cd2bd743cfa8004a02e9b88 Cc: "marf@ietf.org" Subject: Re: [marf] Split of dkim-reporting draft X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 16:44:00 -0000 --000e0cd2bd743cfa8004a02e9b88 Content-Type: multipart/alternative; boundary=000e0cd2bd743cfa7b04a02e9b87 --000e0cd2bd743cfa7b04a02e9b87 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable what was the final decision here? On Thu, Mar 31, 2011 at 12:16 AM, Murray S. Kucherawy wr= ote: > Tony Hansen volunteered as well. I=92m happy to hand it off to either or > both of you. > > > > *From:* Hilda Fontana [mailto:hfontana@ecertsystems.com] > *Sent:* Thursday, March 31, 2011 12:13 AM > > *To:* Murray S. Kucherawy > *Cc:* marf@ietf.org > *Subject:* Re: [marf] Split of dkim-reporting draft > > > > I can have a go at the ARF report type > > On Thu, Mar 31, 2011 at 12:09 AM, Murray S. Kucherawy > wrote: > > One document would register the changes to DKIM and ADSP (i.e. the update= s > to the registered lists of tags and values) and one would register the ne= w > ARF report type. The two documents can be published simultaneously and > refer to each other. > > > > *From:* Hilda Fontana [mailto:hfontana@ecertsystems.com] > *Sent:* Thursday, March 31, 2011 12:04 AM > *To:* Murray S. Kucherawy > *Cc:* marf@ietf.org > > > *Subject:* Re: [marf] Split of dkim-reporting draft > > > > what does it mean "Defining the auth-failure report type" with DKIM, SPF > and Redaction not included? > > On Wed, Mar 30, 2011 at 3:52 AM, Murray S. Kucherawy > wrote: > > The consensus at our IETF 80 meeting was to divide the DKIM reporting dra= ft > into smaller documents. I believe the split should go as follows: > > > > - Defining the auth-failure report type (someone besides me > should take up authorship of this, but I=92ll do it if nobody steps up) > > - DKIM/ADSP extensions (I=92ll keep this one unless there=92s > objection) > > - SPF extensions (Scott Kitterman volunteered) > > - Redaction BCP (JD Falk volunteered; this may be a new document > or could become a chapter of the BCP document) > > > > I=92ll start work on the first two until someone takes the first one away > from me. Scott, please start working on a draft and post something when > you=92re ready; let us know if you need help with xml2rfc or suchlike. > > > > JD (and others), what=92s your view on the best location for the redactio= n > text? > > > > -MSK > > > _______________________________________________ > 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 > > > > [image: Image removed by sender.] > > > > 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 a= ny > 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 immediat= ely > and permanently delete the e-mail, any attachments, and all copies from a= ny > 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. > > > > > > > > > -- > > 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 a= ny > 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 immediat= ely > and permanently delete the e-mail, any attachments, and all copies from a= ny > 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. > > > > > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > > --=20 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 CONFIDENTIA= L 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 fro= m 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 an= y copies of such printouts. Thank you for your cooperation. --000e0cd2bd743cfa7b04a02e9b87 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable what was the final decision here?=A0

On = Thu, Mar 31, 2011 at 12:16 AM, Murray S. Kucherawy <msk@cloudmark.com> wrote:<= br>

Tony Hansen v= olunteered as well.=A0 I=92m happy to hand it off to either or both of you.=

=A0

From: Hilda Fonta= na [mailto:h= fontana@ecertsystems.com]
Sent: Thursday, March 31, 2011 12:13 AM


To: Murray S. Kucherawy
Cc: marf@ietf.org
Subject: Re: [mar= f] Split of dkim-reporting draft

=A0

I c= an have a go at the ARF report type

On Thu,= Mar 31, 2011 at 12:09 AM, Murray S. Kucherawy <msk@cloudmark.com> wrote:

One document would register the changes to DKIM and ADSP (i= .e. the updates to the registered lists of tags and values) and one would r= egister the new ARF report type.=A0 The two documents can be published simu= ltaneously and refer to each other.

=A0

From: Hilda Fontana [mailto:hfontana@ecertsystems.com]
Sent: Thursday, March 31, 2011 12:04 AM
To: Murray S. Kuch= erawy
Cc: marf= @ietf.org


Subject: Re: [marf] Split of dkim-reporting draft

=A0

what does it mean "Defining the auth-failure report= type" with DKIM, SPF and Redaction not included?

On Wed, Mar 30, 2011 at 3:52 AM, Murray S.= Kucherawy <msk@c= loudmark.com> wrote:

The consens= us at our IETF 80 meeting was to divide the DKIM reporting draft into small= er documents.=A0 I believe the split should go as follows:

=A0

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Defining the auth-failure report type (someone be= sides me should take up authorship of this, but I=92ll do it if nobody step= s up)

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 DKIM/ADSP extensions (I=92ll keep this one unless there=92s objection)=

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 SPF = extensions (Scott Kitterman volunteered)

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Redaction BCP (JD Falk volunteered;= this may be a new document or could become a chapter of the BCP document)<= /p>

=A0

I=92ll start work on t= he first two until someone takes the first one away from me. =A0Scott, plea= se start working on a draft and post something when you=92re ready; let us = know if you need help with xml2rfc or suchlike.

=A0

JD (and others), what= =92s your view on the best location for the redaction text?

=A0

-MSK


_____= __________________________________________
marf mailing list
marf@ietf.org
https://www.= ietf.org/mailman/listinfo/marf




--

Hilda L Fontana

VP, Technology= =A0

eCert, Inc.=

One Market Street, Suite 3600<= /p>

San Francisco, CA 94105

=

p: 626.676.8852

f:=A0 415.651.8932

<= /div>

=A0

3D"Image

=A0

eCert - Trust=A0the Message<= span style=3D"font-size: 7.5pt; color: black;">TM=A0

=A0

=

----------------------= ------------------

=A0

CONFIDENTIALITY NOTICE

=A0

The information contained in this e-mail and an= y attachments is CONFIDENTIAL and is intended only for the use of the addre= ssee. Any unauthorized use, disclosure, distribution, dissemination, or cop= ying is strictly prohibited and may be unlawful. If you are not the intende= d recipient, you are prohibited from any further viewing of the e-mail or a= ny 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 immediatel= y and permanently delete the e-mail, any attachments, and all copies from a= ny drives or storage media and destroy any printouts of the e-mail or attac= hments and any copies of such printouts. Thank you for your cooperation.

=A0

=A0




--

Hild= a L Fontana

VP, Technol= ogy=A0

eCert, Inc.

One Market S= treet, Suite 3600

San Francisco, CA 94105

p: 626.676.8852

f:=A0 415.= 651.8932

=A0

=

=A0

eCert - Trust=A0the MessageTM=A0

=A0

--------------------------------------= --

CONFIDENTIALITY NOTICE

<= span style=3D"font-size: 7.5pt; color: black;">=A0

The information contained i= n this e-mail and any attachments is CONFIDENTIAL and is intended only for = the use of the addressee. Any unauthorized use, disclosure, distribution, d= issemination, or copying is strictly prohibited and may be unlawful. If you= are not the intended recipient, you are prohibited from any further viewin= g 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, a= nd 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.

=A0

=A0


_______________________________________= ________
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

--000e0cd2bd743cfa7b04a02e9b87-- --000e0cd2bd743cfa8004a02e9b88 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: a7cceed13fe4627a_0.0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/wAALCAAnAGABAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK//9k= --000e0cd2bd743cfa8004a02e9b88-- From jdfalk-lists@cybernothing.org Wed Apr 6 17:08:42 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B650D3A699A for ; Wed, 6 Apr 2011 17:08:42 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4WBemjC0Sz3 for ; Wed, 6 Apr 2011 17:08:41 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 6EFF93A6996 for ; Wed, 6 Apr 2011 17:08:41 -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 p370AMKJ029245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 6 Apr 2011 17:10:25 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p370AMKJ029245 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1302135025; bh=AoRzFbu7eYD3jPj4cP83P8l/OlFa580Jv/iQ8UpOW C8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=F/6bUlwIYsbL TucJDLwW/7Aw0ZHDb6R1tCQEdyk7Pg5SsdA8+64F6SAzinCpU+Op1kkxuKT1H1SBRO4 RoF5qQhfgGQh5gGh8FIfmZViL/YL5hLZQiPKTuf4f5ndHI/UvTAdNcQgY9x9QoYzkfZ tXW+UIh/XfGlCxTepEbLk5ffk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: <20110314172534.GA14740@ortolo.eu> Date: Wed, 6 Apr 2011 17:10:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110314172534.GA14740@ortolo.eu> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1082) Subject: Re: [marf] Comments about draft-ietf-marf-reporting-discovery X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 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, 07 Apr 2011 00:08:42 -0000 On Mar 14, 2011, at 10:25 AM, Tanguy Ortolo wrote: > I have just read the Internet draft about discovery of willingness to > provide or receive ARF reports. Here are some comments about it. Thanks, I appreciate the input. > Section 5, =A74: >> In the case of a feedback generator, to inquire whether or not an = ADMD >> wishes to receive feedback reports, the DNS domain to which the >> report should be sent is determined (using a mechanism at the >> discretion of the generator) >=20 > The goal of this draft being to correct the lack of defined methods in > [MARf-BASE] (cf. section 1, =A71), I think it would be appropriate to > define the method for determining the responsible domain name. I'll adjust the text to specifically require using the DKIM d=3D string = (unless anyone has an argument for not tying it to DKIM?) > Section 5.2, =A72: >> gf the format of reports offered; [=85] >=20 > Feedback reports being an agreement between a producer and a consumer, > it would be impossible to use if both require a different format = (though > there is currently only one such format defined). I suggest that the > producer could offer several formats, making this tag a = colon-separated > list. Maybe consumers could offer the choice between several formats > too, but I think it would be less relevant, though I would not be able > to argument it. Right now ARF is the only format likely to be offered, but I wanted to = leave it open for other formats that might be developed in the future. > And finally, I think that this draft could cover the case where = several > entities under a same domain name would require separated reports. In > fact, this would be the same use case as DKIM selectors: example.net = has > two entities, admin and marketing, that operate separately and would > like to receive feedback separately. The use of such reporting = selectors > could be defined for authentication methods that allow such selectors > (currently only DKIM, I think), and implemented in the exact same way = as > DKIM selectors: in my example, that would lead to the DNS records > admin._report.example.net and marketing._report.example.net. Today the reports are almost invariably routed by the last-hop IP = address, so this kind of differentiation of mailstreams hasn't been = possible. With DKIM, I'd expect to see different subdomains in the d=3D string = rather than selectors, because selectors are intended for key rotation. = Mailstreams could be identified by the i=3D string, but...well, there's = a big long thread on ietf-dkim about that right now. In any case, I = think d=3D will emerge (again) as the best identifier to use. On Mar 20, 2011, at 8:05 AM, Alessandro Vesely wrote: > However, section 7 seems to be overly restrictive. A generator should = be > allowed to send a report to a different domain in some circumstances. = For > example, a RIR might provide a generic reporting address for (some of) = its > addresses. Sure, but that'd be separate from this discovery mechanism. > The problem here is that different formats may provide for different = report > types. I think we should order them from most generic to most = specialized, > and urge specialized consumers to also accept generic formats, for the = sake > of interoperability. For example, an operator may find it convenient = to send > ARF reports, but, if they happen to be involved in IODEF exchanged for > specific cases, they may want to discover the possibility to send that = kind > of report to a given consumer. I'd love to get some help on this from someone more experienced with = IODEF. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From msk@cloudmark.com Fri Apr 8 11:08:01 2011 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0ABE3A6A0D for ; Fri, 8 Apr 2011 11:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.928 X-Spam-Level: X-Spam-Status: No, score=-103.928 tagged_above=-999 required=5 tests=[AWL=-1.330, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VkbIR-BzTyz for ; Fri, 8 Apr 2011 11:07:53 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id EDB733A6A03 for ; Fri, 8 Apr 2011 11:07:52 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 8 Apr 2011 11:09:38 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Fri, 8 Apr 2011 11:09:37 -0700 Thread-Topic: [marf] Split of dkim-reporting draft Thread-Index: AcvzsOaZ1U/misq9Qn6UqyPe9yXzRQCZvBZw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_F5833273385BB34F99288B3648C4F06F1343319D37EXCHC2corpclo_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [marf] Split of dkim-reporting draft X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 18:08:01 -0000 --_005_F5833273385BB34F99288B3648C4F06F1343319D37EXCHC2corpclo_ Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F1343319D37EXCHC2corpclo_" --_000_F5833273385BB34F99288B3648C4F06F1343319D37EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There hasn't been one. I'll send you both the raw XML and you can decide b= etween you how to divide up the work. -MSK From: Hilda Fontana [mailto:hfontana@ecertsystems.com] Sent: Tuesday, April 05, 2011 9:45 AM To: Murray S. Kucherawy Cc: marf@ietf.org Subject: Re: [marf] Split of dkim-reporting draft what was the final decision here? On Thu, Mar 31, 2011 at 12:16 AM, Murray S. Kucherawy > wrote: Tony Hansen volunteered as well. I'm happy to hand it off to either or bot= h of you. From: Hilda Fontana [mailto:hfontana@ecertsystems.com] Sent: Thursday, March 31, 2011 12:13 AM To: Murray S. Kucherawy Cc: marf@ietf.org Subject: Re: [marf] Split of dkim-reporting draft I can have a go at the ARF report type On Thu, Mar 31, 2011 at 12:09 AM, Murray S. Kucherawy > wrote: One document would register the changes to DKIM and ADSP (i.e. the updates = to the registered lists of tags and values) and one would register the new = ARF report type. The two documents can be published simultaneously and ref= er to each other. From: Hilda Fontana [mailto:hfontana@ecertsystems.com] Sent: Thursday, March 31, 2011 12:04 AM To: Murray S. Kucherawy Cc: marf@ietf.org Subject: Re: [marf] Split of dkim-reporting draft what does it mean "Defining the auth-failure report type" with DKIM, SPF an= d Redaction not included? On Wed, Mar 30, 2011 at 3:52 AM, Murray S. Kucherawy > wrote: The consensus at our IETF 80 meeting was to divide the DKIM reporting draft= into smaller documents. I believe the split should go as follows: - Defining the auth-failure report type (someone besides me should= take up authorship of this, but I'll do it if nobody steps up) - DKIM/ADSP extensions (I'll keep this one unless there's objectio= n) - SPF extensions (Scott Kitterman volunteered) - Redaction BCP (JD Falk volunteered; this may be a new document o= r could become a chapter of the BCP document) I'll start work on the first two until someone takes the first one away fro= m me. Scott, please start working on a draft and post something when you'r= e ready; let us know if you need help with xml2rfc or suchlike. JD (and others), what's your view on the best location for the redaction te= xt? -MSK _______________________________________________ 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 [cid:image001.jpg@01CBF5DD.72C8F060] eCert - Trust the MessageTM www.ecertsystems.com ---------------------------------------- CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments is CONFIDENTIA= L 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 prohibi= ted from any further viewing of the e-mail or any attachments or from makin= g any use of the e-mail or attachments. If you believe you have received th= is 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 a= nd destroy any printouts of the e-mail or attachments and any copies of suc= h printouts. Thank you for your cooperation. -- Hilda L Fontana VP, Technology eCert, Inc. One Market Street, Suite 3600 San Francisco, CA 94105 p: 626.676.8852 f: 415.651.8932 Error! Filename not specified. eCert - Trust the MessageTM www.ecertsystems.com ---------------------------------------- CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments is CONFIDENTIA= L 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 prohibi= ted from any further viewing of the e-mail or any attachments or from makin= g any use of the e-mail or attachments. If you believe you have received th= is 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 a= nd destroy any printouts of the e-mail or attachments and any copies of suc= h printouts. Thank you for your cooperation. _______________________________________________ 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 [cid:image002.jpg@01CBF5DD.72C8F060] eCert - Trust the MessageTM www.ecertsystems.com ---------------------------------------- CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments is CONFIDENTIA= L 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 prohibi= ted from any further viewing of the e-mail or any attachments or from makin= g any use of the e-mail or attachments. If you believe you have received th= is 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 a= nd destroy any printouts of the e-mail or attachments and any copies of suc= h printouts. Thank you for your cooperation. --_000_F5833273385BB34F99288B3648C4F06F1343319D37EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There has= n’t been one.  I’ll send you both the raw XML and you can = decide between you how to divide up the work.

 

-MSK

 

From: Hilda Fontana [mailto= :hfontana@ecertsystems.com]
Sent: Tuesday, April 05, 2011 9:45 A= M
To: Murray S. Kucherawy
Cc: marf@ietf.org
Subje= ct: Re: [marf] Split of dkim-reporting draft

 

what was the final decision here? 

On Thu, Mar 31, 2011 at 12:16 AM, Murray S.= Kucherawy <msk@cloudmark.com&g= t; wrote:

Tony Hansen volunteered as well.  I’m happy to hand= it off to either or both of you.

 

From: Hilda Fontana [mailto:hfontana@ecertsystems.com]
Sent: Thursday, March 31, 2011 12:13 AM


To: Murray S. Kuch= erawy
Cc: marf= @ietf.org
Subject: Re: [marf] Split of dkim-reporting draft

 

I can have a go at the ARF report type

O= n Thu, Mar 31, 2011 at 12:09 AM, Murray S. Kucherawy <msk@cloudmark.com> wrote:<= /o:p>

On= e document would register the changes to DKIM and ADSP (i.e. the updates to= the registered lists of tags and values) and one would register the new AR= F report type.  The two documents can be published simultaneously and = refer to each other.

 

From: Hilda Fontana [ma= ilto:hfontan= a@ecertsystems.com]
Sent: Thursday, March 31, 2011 12:04 AM<= br>To: Murray S. Kucherawy
Cc: marf@ietf.org

=
Subject: Re: [marf] Split of dk= im-reporting draft

 

what does it mean "Defining the auth-failure report type&q= uot; with DKIM, SPF and Redaction not included?

On Wed, Mar 30, 2011 at 3:52 AM, Murray S. Kucherawy <msk@cloudmark.com> wrote:

The consensus at our IETF 80 meeting was to d= ivide the DKIM reporting draft into smaller documents.  I believe the = split should go as follows:

 

-<= span style=3D'font-size:7.0pt'>       &n= bsp;  Defining the auth-failure report type (someone besides me= should take up authorship of this, but I’ll do it if nobody steps up= )

-    = ;      DKIM/ADSP extensions (I’ll kee= p this one unless there’s objection)

-          SPF extensions (Scott Kitterman volunteered)

-        &n= bsp; Redaction BCP (JD Falk volunteered; this may be a new document = or could become a chapter of the BCP document)

 <= o:p>

I’ll start work on the first two until someone t= akes the first one away from me.  Scott, please start working on a dra= ft and post something when you’re ready; let us know if you need help= with xml2rfc or suchlike.

 

JD (and others), what’s your view on the best location for the redac= tion text?

 

-MSK


_________________= ______________________________
marf mailing list
marf@ietf.org
https://www.ietf.org/mail= man/listinfo/marf




--=

Hilda L Fontana

VP, Technol= ogy 

eCert, Inc.

One Market Street, = Suite 3600

San Francisco, CA 94105

p: 626.676.8852<= o:p>

f:  415.65= 1.8932

 

3D"Image=

 

eCert - Trust the Message<= sup>TM 

<= b> 

--= --------------------------------------

 

CONFIDENTIALITY NOTICE=

 

The information contained in this e-mail and any attachmen= ts is CONFIDENTIAL and is intended only for the use of the addressee. Any u= nauthorized use, disclosure, distribution, dissemination, or copying is str= ictly 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 attachme= nts 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 perma= nently delete the e-mail, any attachments, and all copies from any drives o= r storage media and destroy any printouts of the e-mail or attachments and = any copies of such printouts. Thank you for your cooperation.

 

 




-- =

Hilda L Fontana

VP, Technology&nb= sp;

eCe= rt, Inc.

One Market Street, Suite 36= 00

San Francisco, CA 94105

p: 626.676.8852

f:  415.651.8932

 

Error! Filename not specified.

 

= eCert - Trust the MessageTM 

 

-------------= ---------------------------

 

CONFIDENTIALITY NOTICE=

 

The information contained in this e-mail and any attachments is CONFI= DENTIAL and is intended only for the use of the addressee. Any unauthorized= use, disclosure, distribution, dissemination, or copying is strictly prohi= bited and may be unlawful. If you are not the intended recipient, you are p= rohibited 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 recei= ved this e-mail in error, please notify us immediately and permanently dele= te the e-mail, any attachments, and all copies from any drives or storage m= edia and destroy any printouts of the e-mail or attachments and any copies = of such printouts. Thank you for your cooperation.

 

 


_______________________________________________
marf mailing list<= br>marf@ietf.org
https://www.ietf.org= /mailman/listinfo/marf



--

Hilda L Fontana

VP, Technology  =

eCert, Inc.=

One Market Street, Su= ite 3600

San Francisco, CA 94= 105

p: 626.676.8852

f:  415.651.8932

<= div>

 

eCert - Trust the Messa= geTM <= o:p>

&n= bsp;

----------------------------------------

 

CONFIDENTIALITY NOTICE

 

The information contained in this e-mail and any attachments is CON= FIDENTIAL and is intended only for the use of the addressee. Any unauthoriz= ed use, disclosure, distribution, dissemination, or copying is strictly pro= hibited 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 fr= om making any use of the e-mail or attachments. If you believe you have rec= eived this e-mail in error, please notify us immediately and permanently de= lete 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 copie= s of such printouts. Thank you for your cooperation.

<= /div>

 

 

= --_000_F5833273385BB34F99288B3648C4F06F1343319D37EXCHC2corpclo_-- --_005_F5833273385BB34F99288B3648C4F06F1343319D37EXCHC2corpclo_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=377; creation-date="Fri, 08 Apr 2011 11:09:37 GMT"; modification-date="Fri, 08 Apr 2011 11:09:37 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/wAALCAAnAGABAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK//9k= --_005_F5833273385BB34F99288B3648C4F06F1343319D37EXCHC2corpclo_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=377; creation-date="Fri, 08 Apr 2011 11:09:37 GMT"; modification-date="Fri, 08 Apr 2011 11:09:37 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/wAALCAAnAGABAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK//9k= --_005_F5833273385BB34F99288B3648C4F06F1343319D37EXCHC2corpclo_-- From msk@cloudmark.com Wed Apr 13 10:09:11 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0079DE075D for ; Wed, 13 Apr 2011 10:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.011 X-Spam-Level: X-Spam-Status: No, score=-104.011 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q69M6zI154cE for ; Wed, 13 Apr 2011 10:09:09 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfc.amsl.com (Postfix) with ESMTP id 45283E0705 for ; Wed, 13 Apr 2011 10:09:09 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 13 Apr 2011 10:09:08 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Wed, 13 Apr 2011 10:09:07 -0700 Thread-Topic: FBL BCP Thread-Index: Acv5/X/UGL9M3TveRnaXFwXuNmBkVQ== 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_F5833273385BB34F99288B3648C4F06F1343319DD4EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] FBL BCP 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, 13 Apr 2011 17:09:11 -0000 --_000_F5833273385BB34F99288B3648C4F06F1343319DD4EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per our meeting in Prague, we'd like to get some direction on the MAAWG fee= dback loop BCP document and how we want to handle our deliverable of produc= ing one of our own. The MAAWG document has basically been translated to I-D form by JD Falk and= is available here: http://datatracker.ietf.org/doc/draft-jdfalk-maawg-cfblbcp/ Our options come down to the following: 1) Post an informational draft that essentially endorses the MAAWG BCP as-i= s. 2) Propose some changes, which go back to the MAAWG Board for approval, and= then they would change their published version, and then we would do (1). 3) Publish an endorsement of the MAAWG BCP, but also include a list of diff= erences we have with it. This would be our BCP, and doesn't require any ch= anges to their version. 4) Make our own version, taking what we want from theirs. It would mention= attribution as appropriate but make it clear that it's not exactly their v= ersion. This one could get BCP status. MAAWG may or may not like this, de= pending on what the changes are. All of these require MARF participants to review the above draft and commen= t, even if the comment is "I like it as-is". Once we have consensus we can= pick a preferred course of action and start working on it. So that's everybody's homework on this topic. -MSK --_000_F5833273385BB34F99288B3648C4F06F1343319DD4EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Per our meeting = in Prague, we’d like to get some direction on the MAAWG feedback loop= BCP document and how we want to handle our deliverable of producing one of= our own.

 

The MAAWG document has basically been translated to I-D form b= y JD Falk and is available here:

&n= bsp;

      &nbs= p;         http://datatracker.ietf.= org/doc/draft-jdfalk-maawg-cfblbcp/


= Our options come down to the following:

=  

1) Post an informational draft th= at essentially endorses the MAAWG BCP as-is.

 

2) Propose some changes, whi= ch go back to the MAAWG Board for approval, and then they would change thei= r published version, and then we would do (1).

 

3) Publish an endorsement = of the MAAWG BCP, but also include a list of differences we have with it.&n= bsp; This would be our BCP, and doesn’t require any changes to their = version.

 

4) Make our own version, taking what we want from theirs. = ; It would mention attribution as appropriate but make it clear that itR= 17;s not exactly their version.  This one could get BCP status.  = MAAWG may or may not like this, depending on what the changes are.

 

All of= these require MARF participants to review the above draft and comment, eve= n if the comment is “I like it as-is”.  Once we have conse= nsus we can pick a preferred course of action and start working on it.=

 

So= that’s everybody’s homework on this topic.

 

-MSK

= --_000_F5833273385BB34F99288B3648C4F06F1343319DD4EXCHC2corpclo_-- From jdfalk-lists@cybernothing.org Wed Apr 13 10:46:13 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1C0F2E0869 for ; Wed, 13 Apr 2011 10:46:13 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5RAXI20aYjU for ; Wed, 13 Apr 2011 10:46:12 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfc.amsl.com (Postfix) with ESMTP id 631B9E0868 for ; Wed, 13 Apr 2011 10:46:12 -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 p3DHk856009713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 13 Apr 2011 10:46:11 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p3DHk856009713 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1302716771; bh=2kY4J5M5BP1909XIsTEPWzco82pJqQhXt37KX5QUv 74=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=EWssf4pfunn/ AKWb53FLymNTrWteeCoOIZoa+M03+0ZB8HmHgyhfKbiAJoshtzLMeaHyTZkiimshm38 nJUYhE2DPaQbrJHyNTkkN3fFwgRYsmgaDPZcG+G3BOThu8wuH9CnfSPNQ3bN/hy3RiF NCuvLuUqwTwYZzV4Wi90C/r9Q= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: Date: Wed, 13 Apr 2011 10:46:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> References: To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1082) Subject: Re: [marf] FBL BCP 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, 13 Apr 2011 17:46:13 -0000 On Apr 13, 2011, at 10:09 AM, Murray S. Kucherawy wrote: > 3) Publish an endorsement of the MAAWG BCP, but also include a list of = differences we have with it. This would be our BCP, and doesn=92t = require any changes to their version. [as participant] After rereading the FBL-related sections in = draft-ietf-dkim-mailinglists, I'm leaning towards option 3. Rather than = (or along with) a list of differences, we could include (or refer to) = additional issues which could impact feedback loops. [as editor of the document] Whichever of those options the WG wants to = pursue is fine with me. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From msk@cloudmark.com Wed Apr 13 10:48:39 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53C20E0868 for ; Wed, 13 Apr 2011 10:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.45 X-Spam-Level: X-Spam-Status: No, score=-104.45 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjnGLoKLtGHh for ; Wed, 13 Apr 2011 10:48:38 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfc.amsl.com (Postfix) with ESMTP id AD331E07EA for ; Wed, 13 Apr 2011 10:48:38 -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, 13 Apr 2011 10:48:37 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 13 Apr 2011 10:48:35 -0700 Thread-Topic: [marf] FBL BCP Thread-Index: Acv6Aq/eYcXIhTLeTYSpyKbDPzBT4gAADp9g Message-ID: References: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> In-Reply-To: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@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] FBL BCP 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, 13 Apr 2011 17:48:39 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of J= .D. Falk > Sent: Wednesday, April 13, 2011 10:46 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] FBL BCP >=20 > On Apr 13, 2011, at 10:09 AM, Murray S. Kucherawy wrote: >=20 > > 3) Publish an endorsement of the MAAWG BCP, but also include a list > of differences we have with it. This would be our BCP, and doesn't > require any changes to their version. >=20 > [as participant] After rereading the FBL-related sections in draft- > ietf-dkim-mailinglists, I'm leaning towards option 3. Rather than (or > along with) a list of differences, we could include (or refer to) > additional issues which could impact feedback loops. >=20 > [as editor of the document] Whichever of those options the WG wants to > pursue is fine with me. 3) Makes sense to me if the consensus list of differences we have with the = MAAWG BCP is small. Otherwise, (4) might be the better option. From vesely@tana.it Thu Apr 14 09:47:26 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CF3AE0787 for ; Thu, 14 Apr 2011 09:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.26 X-Spam-Level: X-Spam-Status: No, score=-5.26 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtEIPLZPbtky for ; Thu, 14 Apr 2011 09:47:25 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfc.amsl.com (Postfix) with ESMTP id EFC6FE0768 for ; Thu, 14 Apr 2011 09:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1302799640; bh=KPMrDHINCXn4XBTjtjO7b1fUaweDLIavB4mOXJkqnbI=; l=1929; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Gi52DuzuFbkeFHgGk5/B4i2qVtiJjkVttjg6BzZ37qsleZ6eJE5+nL32ZCbNEsZcn 0Oe6GJujIhCrHIICcOkzaJuOGUHGzSGlL/9r3sQU68qxjDQLzaZp9N1ihMBaCM/w3T /P9dzqz0PSgv/cVgyCztybDvNY3fTGtRDJrhVNyM= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 14 Apr 2011 18:47:20 +0200 id 00000000005DC03F.000000004DA72518.00007D14 Message-ID: <4DA72518.3060109@tana.it> Date: Thu, 14 Apr 2011 18:47:20 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: marf@ietf.org References: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> In-Reply-To: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [marf] FBL BCP 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, 14 Apr 2011 16:47:26 -0000 On 13/Apr/11 19:46, J.D. Falk wrote: > On Apr 13, 2011, at 10:09 AM, Murray S. Kucherawy wrote: > >> 3) Publish an endorsement of the MAAWG BCP, but also include a >> list of differences we have with it. This would be our BCP, and >> doesn’t require any changes to their version. > > [as participant] After rereading the FBL-related sections in > draft-ietf-dkim-mailinglists, I'm leaning towards option 3. Rather > than (or along with) a list of differences, we could include (or > refer to) additional issues which could impact feedback loops. The definition of FBL given in dkim-mailinglists is much easier than the one in maawg-cfblbcp. For one nit, I don't understand the reason why the latter document intentionally refrains from using the acronym "FBL". The reporting-discovery doc just uses the word "feedback", and talks about feedback reports, feedback generators/consumers, and feedback reporting advertisement. The latter term, possibly, can be clearly understood even when met out of context. The others may clash with some semiconductor devices or other stuff. In addition, there is the Whois-based reporting approach. Some reworking of this model is underway, and it may eventually bring up yet another flavor of reporting abuse. Abusix uses the term "global reporting" for it, which clashes with the same term as used by globalreporting.org (see links in the footer). IMHO, it may improve clarity if our BCP, besides endorsing the MAAWG BCP, also endorses the other two practices, sketches the differences among them, and possibly gives some guidance. -- http://tools.ietf.org/html/draft-ietf-marf-reporting-discovery http://tools.ietf.org/html/draft-ietf-dkim-mailinglists http://tools.ietf.org/html/draft-jdfalk-maawg-cfblbcp http://abusix.org/service/global-reporting http://www.globalreporting.org/Home http://www.ripe.net/ripe/groups/tf/abuse-contact From jdfalk-lists@cybernothing.org Thu Apr 14 12:28:34 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE538E0771 for ; Thu, 14 Apr 2011 12:28:34 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFWOz-3A+VOB for ; Thu, 14 Apr 2011 12:28:33 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfc.amsl.com (Postfix) with ESMTP id DF275E06FC for ; Thu, 14 Apr 2011 12:28:33 -0700 (PDT) Received: from [192.168.11.34] (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 p3EJSTYG029364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 14 Apr 2011 12:28:32 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p3EJSTYG029364 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1302809312; bh=7eqlrI+pGQ6eHd+4ZWmnRY4TDopYUAFhwkm9GzOrz Mg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=kMH/13jRehvZ Rnug9ed/be9fdynr8I2TfhQJrQuA7IbH78Kre6m4cfm9k60fdkjm38T72IHe2Eb7IOg 6Z7kD4nv3h3eqS3Zebwe8inU4HV/zGcgofafqDIHRA2IY6SVbsybsXhT26wQIAB9en1 qYkkcsN5c1qu7tIknW4cZWnP4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: <4DA72518.3060109@tana.it> Date: Thu, 14 Apr 2011 12:28:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5CED81BA-89E3-4860-BEF1-85A60D1AFA53@cybernothing.org> References: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> <4DA72518.3060109@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1082) Subject: Re: [marf] FBL BCP 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, 14 Apr 2011 19:28:35 -0000 On Apr 14, 2011, at 9:47 AM, Alessandro Vesely wrote: > In addition, there is the Whois-based reporting approach. Some > reworking of this model is underway, and it may eventually bring up > yet another flavor of reporting abuse. Abusix uses the term "global > reporting" for it, which clashes with the same term as used by > globalreporting.org (see links in the footer). >=20 > IMHO, it may improve clarity if our BCP, besides endorsing the MAAWG > BCP, also endorses the other two practices, sketches the differences > among them, and possibly gives some guidance. This is discussed somewhat in the 3rd appendix, though the terminology = is different. IIRC, many MAAWG members were extremely wary of = unsolicited feedback, whether using WHOIS records or other methods to = determine the address to flood with reports. After years of dealing = with spam, we always prefer opt-in participation models -- especially = for email. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From Internet-Drafts@ietf.org Thu Apr 14 15:15:03 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 87904E0715; Thu, 14 Apr 2011 15:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4p9cTmVmyQp; Thu, 14 Apr 2011 15:15:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5DE61E08A7; Thu, 14 Apr 2011 15:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110414221502.7992.31103.idtracker@ietfc.amsl.com> Date: Thu, 14 Apr 2011 15:15:02 -0700 Cc: marf@ietf.org Subject: [marf] I-D ACTION:draft-ietf-marf-redaction-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, 14 Apr 2011 22:15:04 -0000 --NextPart 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 : Redaction of Potentially Sensitive Data from Mail Abuse Reports Author(s) : J. Falk Filename : draft-ietf-marf-redaction-00.txt Pages : 5 Date : 2011-04-14 Email messages often contain information which might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-redaction-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-marf-redaction-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-14150114.I-D@ietf.org> --NextPart-- From sm@resistor.net Fri Apr 15 00:19:09 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 25E77E0797 for ; Fri, 15 Apr 2011 00:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ooj3kny27pQ3 for ; Fri, 15 Apr 2011 00:19:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id A0356E0752 for ; Fri, 15 Apr 2011 00:19:03 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p3F7Iuma001045; Fri, 15 Apr 2011 00:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1302851941; bh=R89Scw+v3Ch/sfD5oiBqYMS6J/NIR5gYeUe2QfT/QTg=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=LW3zixMNH55Z2FD3XIIrRrqmWHD37HiQrlVy322juemRkQFI7IBYiE17P1NVaO3jt HXD0iXwqbJd7lFQ3yLt09YYqThYm1vT8W03BOrQM9OHBw5/sWqz8lLtonXDVMMqMKw 28AszWYMLqXHrDUG81Vr4iLMRwbaN0Gni8QFaj5g= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1302851941; bh=R89Scw+v3Ch/sfD5oiBqYMS6J/NIR5gYeUe2QfT/QTg=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=tK2pWPsWf1PvsLD+6Rr4aS2pgiWEDdVSmJcMidMr5OgZ2aLZULlPbaelpXW2+5Rpu hgU5q5tUSILvrsWEr1SyLBWWnexgiEwQIMFEE58ZqBLmFGWmqvjE3pGQniqzUa42t/ iTVKwAFEOhWn6ibpVzFTJrhyesNWeq7s/6SC1O0Y= Message-Id: <6.2.5.6.2.20110415000104.02912368@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 15 Apr 2011 00:18:30 -0700 To: Alessandro Vesely From: SM In-Reply-To: <4DA72518.3060109@tana.it> References: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> <4DA72518.3060109@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] FBL BCP 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, 15 Apr 2011 07:19:09 -0000 Hi Alessandro, At 09:47 14-04-2011, Alessandro Vesely wrote: >In addition, there is the Whois-based reporting approach. Some >reworking of this model is underway, and it may eventually bring up >yet another flavor of reporting abuse. Abusix uses the term "global >reporting" for it, which clashes with the same term as used by >globalreporting.org (see links in the footer). Do you mean the unsolicited reports send to any email address that appears in Whois? The coalition of the willing generally uses Spamcop to do that on the assumption that someone out there will take action. Force feeding receivers with abuse reports is not effective when over 99% of the reports are incorrect. Regards, -sm From vesely@tana.it Fri Apr 15 02:14:49 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0C9FBE06E9 for ; Fri, 15 Apr 2011 02:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.211 X-Spam-Level: X-Spam-Status: No, score=-5.211 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXh3rAsqsG09 for ; Fri, 15 Apr 2011 02:14:48 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfc.amsl.com (Postfix) with ESMTP id 57305E0693 for ; Fri, 15 Apr 2011 02:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1302858887; bh=p7/4B2YpeHmJeJQMm2XQMAv3TX2ykssdF54N6IY2poc=; l=1066; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=WKSV6hFgiHf5uVak4xuLrtizFT9RFux4e9aaR4Me4JYcjav84Nd1fZAU8af5TduTb cJBKMeg5piwuPfwmCT/CJCX/Tk7u8pI8Bn5OpbRhe/ZHXxZUxhbygW/IisL1Yu+XzK 7hhDSP4/a7OqRjKEufFzy70bIw8WM5G7qB6darkA= 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, 15 Apr 2011 11:14:47 +0200 id 00000000005DC033.000000004DA80C87.0000587A Message-ID: <4DA80C86.3020301@tana.it> Date: Fri, 15 Apr 2011 11:14:46 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: SM References: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> <4DA72518.3060109@tana.it> <6.2.5.6.2.20110415000104.02912368@resistor.net> In-Reply-To: <6.2.5.6.2.20110415000104.02912368@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: marf@ietf.org Subject: Re: [marf] FBL BCP 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, 15 Apr 2011 09:14:49 -0000 On 15/Apr/11 09:18, SM wrote: > At 09:47 14-04-2011, Alessandro Vesely wrote: >> In addition, there is the Whois-based reporting approach. > > Do you mean the unsolicited reports send to any email address that > appears in Whois? Yes, IP-based Whois, and databases based on that. > The coalition of the willing generally uses Spamcop to do that on > the assumption that someone out there will take action. The complainant's mailbox provider is more knowledgeable than a third party for such job --with all due appreciation for Spamcop's activity. Providers may carry out some simple verifications on submitted reports, while third parties have to trust them. In either case, this activity of forwarding abuse reports to the /right place/ deserves to be named and mentioned in some standard document. We have recently standardized a report format. Adding guidance for its effective use seems just natural. > Force feeding receivers with abuse reports is not effective when over > 99% of the reports are incorrect. Is it so already? From sm@resistor.net Fri Apr 15 08:57:16 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 644DC130012 for ; Fri, 15 Apr 2011 08:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poylg0mmcZ99 for ; Fri, 15 Apr 2011 08:57:11 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id 8CDCDE0841 for ; Fri, 15 Apr 2011 08:57:09 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p3FFuxZM009672; Fri, 15 Apr 2011 08:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1302883027; bh=WzDdOCcqgMoMZWw3ymC5zSc36hKhELOj0bOhbBrBVBw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=KG/t5qbZ5PadWSJVzYc9sWBWC0G9exYoAcB7+Df6CwkIxbsbWADEIuKL4pqn3unsd /xQfU8/0YAWckbt7A2byxUD3AUVOBWOo3DBTqSmy0G5YVJ5Nn766WDfjzURE/Z84Xa Ba6bbjyi00KmSzs9IzdXf9t+Cc5gYMrbYKNvp/p0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1302883027; bh=WzDdOCcqgMoMZWw3ymC5zSc36hKhELOj0bOhbBrBVBw=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=ECLsmDhUvmQRteeIpkqpVdueIa34zMmT8FLIELdi2OGg/M9GNmJub6yP/kGp3xIV5 l3kvwGxTaXGD3luHcSO2mhl0fk12Ao3oHikfqVyPtlNL5SRif9GEsfSMHL185ProBp SWfd+eFC0W70VlaLEPh440RSIu8REcs5zJJ8t4D8= Message-Id: <6.2.5.6.2.20110415074219.06702e60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 15 Apr 2011 08:12:15 -0700 To: Alessandro Vesely From: SM In-Reply-To: <4DA80C86.3020301@tana.it> References: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> <4DA72518.3060109@tana.it> <6.2.5.6.2.20110415000104.02912368@resistor.net> <4DA80C86.3020301@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] FBL BCP 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, 15 Apr 2011 15:57:16 -0000 Hi Alessandro, At 02:14 15-04-2011, Alessandro Vesely wrote: >Yes, IP-based Whois, and databases based on that. I'll borrow a few words from J.D. [1]. "After years of dealing with spam, we always prefer opt-in participation models". Why is the opt-out (I am not sure if that option exists) model acceptable for these reports? >Is it so already? Yes. Regards, -sm 1. http://www.ietf.org/mail-archive/web/marf/current/msg01069.html From steve@wordtothewise.com Fri Apr 15 09:13:00 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 37766E091E for ; Fri, 15 Apr 2011 09:13:00 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S31hWkxIZ7sy for ; Fri, 15 Apr 2011 09:12:55 -0700 (PDT) Received: from m.wordtothewise.com (b.wordtothewise.com [208.187.80.136]) by ietfc.amsl.com (Postfix) with ESMTP id 2128BE091D for ; Fri, 15 Apr 2011 09:12:55 -0700 (PDT) Received: from [192.168.80.43] (184.wordtothewise.com [208.187.80.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 93FE02DF30 for ; Fri, 15 Apr 2011 09:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wordtothewise.com; s=1.wttw; t=1302883973; bh=KEywhQ6+TeYGBAmiPeNaFzyDQTVfp0RMSCRBDKUJeVg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=EB0M0pBYWnCq8lBiS5kdFaHhOCfgCk74/AcziVghVVSCXsDJ2rH8lB0KMbcTjEtaZ qayFnm0w79yiFxkm8+IutL8hKM9elop4Ua0vMG7KVuxjsBa5lnydzRCT4OH7U8oZmX ehMDANR4B2wAYe5dw6JvIcMkIMcKdcAz+9dZjZ5w= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Steve Atkins In-Reply-To: <6.2.5.6.2.20110415074219.06702e60@resistor.net> Date: Fri, 15 Apr 2011 09:12:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <63ECF696-7F19-4229-AF64-78BCA59FFB72@wordtothewise.com> References: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> <4DA72518.3060109@tana.it> <6.2.5.6.2.20110415000104.02912368@resistor.net> <4DA80C86.3020301@tana.it> <6.2.5.6.2.20110415074219.06702e60@resistor.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1084) Subject: Re: [marf] FBL BCP 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, 15 Apr 2011 16:13:00 -0000 On Apr 15, 2011, at 8:12 AM, SM wrote: > Hi Alessandro, > At 02:14 15-04-2011, Alessandro Vesely wrote: >> Yes, IP-based Whois, and databases based on that. >=20 > I'll borrow a few words from J.D. [1]. "After years of dealing with = spam, we always prefer opt-in participation models". Why is the opt-out = (I am not sure if that option exists) model acceptable for these = reports? I think that may be the wrong thing to focus on (not least because it = leads to the rathole that manually written abuse reports are usually = unsolicited, and a common argument is that if 1 manually written report = is OK, then 10,000 boilerplate reports must be OK). The bigger point may be that unless a report receiver has tooled up to = accept a certain level of reports in this format, they're unlikely to be = able to do anything useful with them other than direct them to = /dev/null. If they have tooled up to accept those reports then opting-in = to receiving them by some approach is part of that process. Several enthusiasts and companies have tried sending large volumes of = unsolicited, bulk reports to addresses scraped from whois. It's not gone = well, and they've often ended up routed to /dev/null. ARF reports are in an easily recognizable format. I'd rather not = encourage behaviour on the part of report senders that will make report = receivers filter based on that format. Cheers, Steve >=20 >> Is it so already? >=20 > Yes. >=20 > Regards, > -sm >=20 > 1. http://www.ietf.org/mail-archive/web/marf/current/msg01069.html=20 > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From vesely@tana.it Fri Apr 15 10:41:54 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 23EA8E0678 for ; Fri, 15 Apr 2011 10:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.135 X-Spam-Level: X-Spam-Status: No, score=-5.135 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1TNMvzkbt-u for ; Fri, 15 Apr 2011 10:41:49 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfc.amsl.com (Postfix) with ESMTP id 955BDE0663 for ; Fri, 15 Apr 2011 10:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1302889308; bh=khr55fSpHJhlLl23Do00g0yHpA9tNPJk+SG/VRm3s6c=; l=2637; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=dym92SvngD8drw8PmnurEO/b4hwZNSv9cap7Q1zgMlQEXE9zKFKlrqSl/tu8VGJwd JrL7yl+6HBRJYUNpV+va1SCMxvPa3yEEZ8Dmkx64D6nCfMOOoX8/2hoQSHgMN7+fKy SmZafRC4HoWrRjbhxcSOGvrFVByIyKuUEdEQwuzY= 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, 15 Apr 2011 19:41:48 +0200 id 00000000005DC039.000000004DA8835C.00000DFB Message-ID: <4DA8835B.80300@tana.it> Date: Fri, 15 Apr 2011 19:41:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: marf@ietf.org References: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> <4DA72518.3060109@tana.it> <6.2.5.6.2.20110415000104.02912368@resistor.net> <4DA80C86.3020301@tana.it> <6.2.5.6.2.20110415074219.06702e60@resistor.net> <63ECF696-7F19-4229-AF64-78BCA59FFB72@wordtothewise.com> In-Reply-To: <63ECF696-7F19-4229-AF64-78BCA59FFB72@wordtothewise.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] FBL BCP 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, 15 Apr 2011 17:41:54 -0000 On 15/Apr/11 18:12, Steve Atkins wrote: > On Apr 15, 2011, at 8:12 AM, SM wrote: >> At 02:14 15-04-2011, Alessandro Vesely wrote: >>> Yes, IP-based Whois, and databases based on that. >> >> I'll borrow a few words from J.D. [1]. "After years of dealing >> with spam, we always prefer opt-in participation models". Why is >> the opt-out (I am not sure if that option exists) model >> acceptable for these reports? I wouldn't call it "opt-out" if the target address was that of an incident response team, or similar abuse POC. > I think that may be the wrong thing to focus on (not least because > it leads to the rathole that manually written abuse reports are > usually unsolicited, and a common argument is that if 1 manually > written report is OK, then 10,000 boilerplate reports must be OK). > The bigger point may be that unless a report receiver has tooled up > to accept a certain level of reports in this format, they're > unlikely to be able to do anything useful with them other than > direct them to /dev/null. If they have tooled up to accept those > reports then opting-in to receiving them by some approach is part > of that process. I subscribed to receive Spamcop's reports. I received none to date. Possibly because I try and avoid sending spam. Or maybe because the spam I may have happened to send was reported to some other hub. After SM reminded me of it, I found out that my record on Spamcop was still linked to an old range of IP addresses that I quit in 2008. Obviously I'm unable to recall every place where I wrote IP addresses. IP-based Whois databases are unique, in a DNS sense. I'd prefer to set up a finite number of DNS RRs than go hunting for every spam reporting hub and FBL that spam originating from my server might be reported to. That's why I like reporting discovery: it scales. > Several enthusiasts and companies have tried sending large volumes > of unsolicited, bulk reports to addresses scraped from whois. It's > not gone well, and they've often ended up routed to /dev/null. Were they incorrect reports? Is that the rationale behind SM's affirmative response below? Of course, directly setting "/dev/null" for Whois abuse POCs may result in remarkable band optimizations, but then such setting would betray the fact that the relevant admins couldn't care less... > ARF reports are in an easily recognizable format. I'd rather not > encourage behaviour on the part of report senders that will make > report receivers filter based on that format. Yes, we must carefully avoid that. >>> Is it so already? >> >> Yes. From jdfalk-lists@cybernothing.org Fri Apr 15 11:42:12 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4E106E065F for ; Fri, 15 Apr 2011 11:42:12 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnXmdm+A1FQc for ; Fri, 15 Apr 2011 11:42:11 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfc.amsl.com (Postfix) with ESMTP id 7D960E0698 for ; Fri, 15 Apr 2011 11:42:11 -0700 (PDT) Received: from [192.168.11.34] (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 p3FIg8sI014120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 15 Apr 2011 11:42:11 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p3FIg8sI014120 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1302892931; bh=fJVPkF71z2LfBcQVXinCr70x8mQsA4MnO7layPqgh hw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=PVJDf0SbPQeB fM76eCLHstaZr3TIDnFYZWW24Wqc8/LlIZVHAgdw1yXewr4AoX3dPs8xIsjEobbsLSk alHN336NSzAfbR0DkgMvJvIeTPLjluaPiXpdhgtSPqhgV+XAJhBJb4qVa0cG2msb9Zt o8Lu3EAsv60jf6gNRx/w7wBdM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: <4DA80C86.3020301@tana.it> Date: Fri, 15 Apr 2011 11:42:08 -0700 Content-Transfer-Encoding: 7bit Message-Id: <917D958D-0204-46AD-9020-FF65599991A6@cybernothing.org> References: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> <4DA72518.3060109@tana.it> <6.2.5.6.2.20110415000104.02912368@resistor.net> <4DA80C86.3020301@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1082) Subject: Re: [marf] FBL BCP 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, 15 Apr 2011 18:42:12 -0000 On Apr 15, 2011, at 2:14 AM, Alessandro Vesely wrote: >> Force feeding receivers with abuse reports is not effective when over >> 99% of the reports are incorrect. > > Is it so already? Maybe for a few sites, but not for the majority of ARF Consumers today. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From johnl@iecc.com Fri Apr 15 12:01:21 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 76248E08A9 for ; Fri, 15 Apr 2011 12:01:21 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xavBjrYufx6u for ; Fri, 15 Apr 2011 12:01:20 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfc.amsl.com (Postfix) with ESMTP id B46C2E08BD for ; Fri, 15 Apr 2011 12:01:02 -0700 (PDT) Received: (qmail 88770 invoked from network); 15 Apr 2011 19:01:01 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 15 Apr 2011 19:01:01 -0000 Date: 15 Apr 2011 19:00:39 -0000 Message-ID: <20110415190039.48166.qmail@joyce.lan> From: "John Levine" To: marf@ietf.org In-Reply-To: <917D958D-0204-46AD-9020-FF65599991A6@cybernothing.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [marf] FBL BCP 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, 15 Apr 2011 19:01:21 -0000 >>> Force feeding receivers with abuse reports is not effective when over >>> 99% of the reports are incorrect. >> >> Is it so already? > >Maybe for a few sites, but not for the majority of ARF Consumers today. My impression is that most ARF reports are sent through FBLs, which by their nature tend to go to the right place. I can easily believe that the vast majority of over-the-transom reports are wrong, when I see some of the crud that shows up at abuse.net. R's, John From sm@resistor.net Fri Apr 15 12:36:30 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8E56E0682 for ; Fri, 15 Apr 2011 12:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBhgr-b3hiO7 for ; Fri, 15 Apr 2011 12:36:25 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id 44D2FE0688 for ; Fri, 15 Apr 2011 12:36:24 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p3FJaEpO026922; Fri, 15 Apr 2011 12:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1302896182; bh=MHJnwXt5Gmkuz1oz6ZFresWwz5gVCkIkbMqJ21mnZks=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=tIh/vUuSZ/4ezvB47WgD2DmWPCjA2sfADG+EsGrnuXtMqDRALUJA4qGIti3T9yvxI Rypig41C5V1SS2r27OuEJ29/k311Sm6T0Foe4VBPoaWHoYrHS66WF0JHcF+u+HxNLy C7YYo6+PdDPOQCFHkjKVbrMVfjILvHRBaa+r3xRw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1302896182; bh=MHJnwXt5Gmkuz1oz6ZFresWwz5gVCkIkbMqJ21mnZks=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=keqyyydUkSMWSrIcLR9C4XKOyXAImfwEiDjAP7Ahb8cnmH7FlbCc6G/RG9JrAPnC8 lDjiwzZiivYta/4/DFGzVU4pIEOZOfeavQyBsh+reI3apiTyCh91VmnCioBsPwLmue yvrEivTWsH4gaNG4pZBwdqmxiBC/pJgwth2bD3Z0= Message-Id: <6.2.5.6.2.20110415115123.06bd3990@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 15 Apr 2011 12:30:13 -0700 To: Message Abuse Report Format working group From: SM In-Reply-To: <63ECF696-7F19-4229-AF64-78BCA59FFB72@wordtothewise.com> References: <6ADF1E40-321E-4C7C-9B43-B83186D575CA@cybernothing.org> <4DA72518.3060109@tana.it> <6.2.5.6.2.20110415000104.02912368@resistor.net> <4DA80C86.3020301@tana.it> <6.2.5.6.2.20110415074219.06702e60@resistor.net> <63ECF696-7F19-4229-AF64-78BCA59FFB72@wordtothewise.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alessandro Vesely Subject: Re: [marf] FBL BCP 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, 15 Apr 2011 19:36:31 -0000 At 09:12 15-04-2011, Steve Atkins wrote: >The bigger point may be that unless a report receiver has tooled up >to accept a certain level of reports in this format, they're >unlikely to be able to do anything useful with them other than >direct them to /dev/null. If they have tooled up to accept those >reports then opting-in to receiving them by some approach is part of >that process. Yes. [snip] >ARF reports are in an easily recognizable format. I'd rather not >encourage behaviour on the part of report senders that will make >report receivers filter based on that format. Yes. At 10:41 15-04-2011, Alessandro Vesely wrote: >I wouldn't call it "opt-out" if the target address was that of an >incident response team, or similar abuse POC. And I am going to find it more difficult to convince people to process the reports if the abuse point of contact is used in an abusive way. >IP-based Whois databases are unique, in a DNS sense. I'd prefer to >set up a finite number of DNS RRs than go hunting for every spam >reporting hub and FBL that spam originating from my server might be >reported to. That's why I like reporting discovery: it scales. There are senders of abuse reports out there that have some difficulty reading IP-based Whois results. >Of course, directly setting "/dev/null" for Whois abuse POCs may >result in remarkable band optimizations, but then such setting would >betray the fact that the relevant admins couldn't care less... I guess that I should use "/dev/null" as an optimization technique. However, there is the errant, again misdirected, denial of service report that could do with some attention. Regards, -sm From shmuel+gen@patriot.net Sun Apr 17 11:18:45 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5FFCEE070C for ; Sun, 17 Apr 2011 11:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJ2MdIsjs5Uy for ; Sun, 17 Apr 2011 11:18:43 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfc.amsl.com (Postfix) with ESMTP id D2354E06A0 for ; Sun, 17 Apr 2011 11:18:43 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.175]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id D2BB7F58088 for ; Sun, 17 Apr 2011 14:12:29 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Sun, 17 Apr 2011 14:19:19 -0400 To: marf@ietf.org In-Reply-To: <6.2.5.6.2.20110415115123.06bd3990@resistor.net> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110417181229.D2BB7F58088@smtp.patriot.net> Subject: Re: [marf] FBL BCP X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 18:18:45 -0000 In <6.2.5.6.2.20110415115123.06bd3990@resistor.net>, on 04/15/2011 at 12:30 PM, SM said: >And I am going to find it more difficult to convince people to >process the reports if the abuse point of contact is used in an >abusive way. Whether it is abusive depends on what the feedback address is registered for. Certainly an ARF abuse complaint should not be sent to addresses not registered for the purposes and an unregistered provider should not be sending to a consumer who requires registration. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From johnl@iecc.com Sun Apr 17 14:40:05 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A042EE069C for ; Sun, 17 Apr 2011 14:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.099 X-Spam-Level: X-Spam-Status: No, score=-111.099 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShgKBYGW1i+D for ; Sun, 17 Apr 2011 14:40:05 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfc.amsl.com (Postfix) with ESMTP id E7640E065F for ; Sun, 17 Apr 2011 14:40:04 -0700 (PDT) Received: (qmail 48191 invoked from network); 17 Apr 2011 21:40:02 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 17 Apr 2011 21:40:02 -0000 Date: 17 Apr 2011 21:39:40 -0000 Message-ID: <20110417213940.59702.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] FBL BCP X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 21:40:05 -0000 Having read it, my preference is: >1) Post an informational draft that essentially endorses the MAAWG BCP as-is. Having had a certain amount to do with this document at MAAWG, I saw the key fact that the FBLs that matter involve a vast amount of mail, with a correspondingly large flow of FBLs. Unless I've missed something, this group doesn't have anywhere near as much experience with large mail systems as the group at MAAWG who wrote it. (If you were wondering, I consider my 75,000 messages/day to be quite small.) So I think we should sign off on it as is. If people have bright ideas about how to do FBLs differently, there's nothing keeping you from writing I-Ds intended for experimental and later standards track RFCs. From barryleiba.mailing.lists@gmail.com Sun Apr 17 16:51:46 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 08A29E06E3 for ; Sun, 17 Apr 2011 16:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.665 X-Spam-Level: X-Spam-Status: No, score=-103.665 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW93+9MTMOD5 for ; Sun, 17 Apr 2011 16:51:45 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 4D1FCE0674 for ; Sun, 17 Apr 2011 16:51:45 -0700 (PDT) Received: by wwa36 with SMTP id 36so3348713wwa.13 for ; Sun, 17 Apr 2011 16:51:44 -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:content-type :content-transfer-encoding; bh=5+IOBB01kpp8mOc5Kar8McEGKQaBXPLwhrzcnewAXno=; b=Tf1T9pDDWiVokWmlGNgyG7LlZoYXnOPlH0jKsmnOKJXUjSv9iO3WIa3B55wYvEbIjA 4GhxzMepRm0r6OhycKnJ9MfyNC2jzGcmjxgax0JMvGVa3cfVvDNOjnc/d1O+tzHCbrG/ ad78SUgw2eMeFNYlMp/3FwwmeCjQC6mcXhReQ= 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:content-type :content-transfer-encoding; b=DD+SBci9Vw3YFsFR5rwQE/3hfH2zxoE4AtZTKf9mQnLQHYce0rxcTg0P/6KeCuh2f1 +huQs4qDQia8+hP6ehGWEDNc98G4gCHG3FJGi46InwCzlaTO38HoUCGbHvNCLqTmhdtQ qd6WpBpe5QCgEnA0IeN42aBceJc2HrfiURsx4= MIME-Version: 1.0 Received: by 10.216.159.141 with SMTP id s13mr4286108wek.17.1303084304535; Sun, 17 Apr 2011 16:51:44 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.216.242.71 with HTTP; Sun, 17 Apr 2011 16:51:44 -0700 (PDT) In-Reply-To: <20110417213940.59702.qmail@joyce.lan> References: <20110417213940.59702.qmail@joyce.lan> Date: Sun, 17 Apr 2011 19:51:44 -0400 X-Google-Sender-Auth: K2rk5FvBKKiPRJ7wHbRY5EKBJJ8 Message-ID: From: Barry Leiba To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] FBL BCP X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 23:51:46 -0000 > Having read it, my preference is: > >>1) Post an informational draft that essentially endorses the MAAWG BCP as= -is. > > Having had a certain amount to do with this document at MAAWG, I saw > the key fact that the FBLs that matter involve a vast amount of mail, > with a correspondingly large flow of FBLs. =A0Unless I've missed > something, this group doesn't have anywhere near as much experience > with large mail systems as the group at MAAWG who wrote it. =A0(If you > were wondering, I consider my 75,000 messages/day to be quite small.) > > So I think we should sign off on it as is. I agree. I'm happy if we have a couple/few paragraphs to say about it, but more than that seems to be hobbling the horse and then having to pull the cart by ourselves. Barry, as participant From sm@resistor.net Sun Apr 17 22:53:35 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7C5B3E067C for ; Sun, 17 Apr 2011 22:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBaWP-4ic9H4 for ; Sun, 17 Apr 2011 22:53:30 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfc.amsl.com (Postfix) with ESMTP id 31413E0665 for ; Sun, 17 Apr 2011 22:53:29 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p3I5rJMB008979; Sun, 17 Apr 2011 22:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1303106006; bh=ld/uL717qVBgc2Gi9xuvBdiuF8+W+UooIhVcHGbOIFs=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=K5MQs+7GQxMUFGbV/EDhBXQATBcB2VZULUeqo427pOthIqX5ii/G8q/4q65cGb/h4 xqQSnX+z/9TjdsCG+JaE1ns3fsJ5TNdwc6iOMp98p5/Wy1Kn17HjB4KQ880kdRnOlU bhG8Km++NafeeByxCe8Qft4ZDd98EfSmI11Gxggg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1303106006; bh=ld/uL717qVBgc2Gi9xuvBdiuF8+W+UooIhVcHGbOIFs=; h=Message-Id:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To: References:Mime-Version:Content-Type; b=r/OMs3RKDQUewd9eiLGJTQpbI8H6C/7Di64HDG3l52xyeRj4Od/z7KvO4/SUvIFlD +f/iExu0roPwrjk9Vv2k3HhRE/3pkqlahlps7OMykRL5h+UFSocChjKGZw4BDdgQ2w EDSerswB24nIb/GEbJib+7AZ0VEGKEp/uOEgNCOs= Message-Id: <6.2.5.6.2.20110417221926.04b707b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 17 Apr 2011 22:53:15 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] FBL BCP 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, 18 Apr 2011 05:53:35 -0000 Hi Murray, At 10:09 13-04-2011, Murray S. Kucherawy wrote: >Per our meeting in Prague, we'd like to get some direction on the >MAAWG feedback loop BCP document and how we want to handle our >deliverable of producing one of our own. > >The MAAWG document has basically been translated to I-D form by JD >Falk and is available here: > > http://datatracker.ietf.org/doc/draft-jdfalk-maawg-cfblbcp/ > >Our options come down to the following: [snip] >4) Make our own version, taking what we want from theirs. It would >mention attribution as appropriate but make it clear that it's not >exactly their version. This one could get BCP status. MAAWG may or >may not like this, depending on what the changes are. From previous discussions, I understood that it would not be possible to use draft-jdfalk-maawg-cfblbcp as input for work within this working group. I prefer not to see a document which MAAWG may not like as it is their work after all. I suggest that the WG Chairs talk to MAAWG and explain to them how the IETF works. If MAAWG is happy to give change control to the IETF, the MARF WG can consider using the work as input. If the deliverable cannot be produced without the MAAWG document, I suggest taking it off the list. Regards, -sm From vesely@tana.it Mon Apr 18 03:00:41 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5A534E06AB for ; Mon, 18 Apr 2011 03:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.106 X-Spam-Level: X-Spam-Status: No, score=-5.106 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IQ5N03BlIR5 for ; Mon, 18 Apr 2011 03:00:37 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfc.amsl.com (Postfix) with ESMTP id D1594E069D for ; Mon, 18 Apr 2011 03:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1303120835; bh=j/64oNPohRDUxkyoIVv+LiEhRzrSxxQLTpXnEdBUZv8=; l=1830; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=EB4+zwnsuAg4ET+gDfEZwuXpUQC6m3+mHftyjzcbpRMj/vxYnfLZoLwhpXPRC0g/1 gFbfLy+OXNqsB6KJOnclih9CXye5SMdHiQ5H+adLQFzGcPcpEe6cd07nwHIQhXtYuo 5MjFZu6PZciwtkqRoHY0BMjLAijZfKD++kYqYB3w= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 18 Apr 2011 12:00:35 +0200 id 00000000005DC048.000000004DAC0BC3.000077A9 Message-ID: <4DAC0BC2.7040402@tana.it> Date: Mon, 18 Apr 2011 12:00:34 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: marf@ietf.org References: <20110417181229.D2BB7F58088@smtp.patriot.net> In-Reply-To: <20110417181229.D2BB7F58088@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] FBL BCP 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, 18 Apr 2011 10:00:41 -0000 On 17/Apr/11 20:19, Shmuel (Seymour J.) Metz wrote: > In <6.2.5.6.2.20110415115123.06bd3990@resistor.net>, on 04/15/2011 > at 12:30 PM, SM said: > >>And I am going to find it more difficult to convince people to >>process the reports if the abuse point of contact is used in an >>abusive way. > > Whether it is abusive depends on what the feedback address is > registered for. Certainly an ARF abuse complaint should not be sent to > addresses not registered for the purposes I'd agree, but then what does "registered for the purposes" mean? IMHO that's exactly the kind of thing we need to clarify. The correct target can be any of 1) a public reporting hub / global reputation tracker, 2) a reporting hub for users of a given domain only, 3) an FBL subscriber, 4) the abuse POC of a DKIM signer of the reported message, or 5) an abuse POC responsible for the IP of the last relay. The MAAWG document primarily deals with (3), but appendixes B and C contemplate cases (4) and (5), respectively. (2) was discussed on the ASRG from December 2009 to March 2010. (1) was mentioned in DomainRep. There is no clear-cut distinction among these methods for selecting the report target, because they can be mixed both sequentially (forwarding) and in parallel (multiple targets.) For this reason, the document that endorses the MAAWG BCP should also complement it, and thus provide a general overview. On 17/Apr/11 23:39, John Levine wrote: > If people have bright ideas about how to do FBLs differently, there's > nothing keeping you from writing I-Ds intended for experimental and later > standards track RFCs. Why do you say "you", you want out? "Experimental" seems to be the right thing, but it wants a WG for crafting it properly, and possibly provide code. From barryleiba.mailing.lists@gmail.com Mon Apr 18 06:35:26 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5F6ACE076B for ; Mon, 18 Apr 2011 06:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.629 X-Spam-Level: X-Spam-Status: No, score=-103.629 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgIMbJN3uB8z for ; Mon, 18 Apr 2011 06:35:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfc.amsl.com (Postfix) with ESMTP id 75A44E070E for ; Mon, 18 Apr 2011 06:35:25 -0700 (PDT) Received: by wwa36 with SMTP id 36so3771633wwa.13 for ; Mon, 18 Apr 2011 06:35:24 -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:content-type :content-transfer-encoding; bh=nExVA8A2S+prdVfgpc6kL7zhZa+pT/2cMk7vdYwWYLU=; b=lLozy22fmYVGp2myptbYwgZTm60C3kFLunnPstbLl3ETSx57VIh97DArTGVEdP8cdn OnSpSd1HLjpUwxtQVKn7n6nuMH/o1/HqqryDmca0HzwPIxRb9WacCGwDv0qaweyCb0h0 VPhWRU8dtZRPVezCYe3TVntqmPuIzgDajx+eA= 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:content-type :content-transfer-encoding; b=WKccJQhYDOEtg+feFj7DInCAS4wSYUO6khAjcsG6rbnvGj4dDJZSdD5mJ+UzLbuEnh lBL6Kts4LHWy0eM2e0EbFAPki8wkMz/+BsrRfNseBD0K4dFsMeKbH1Ac7XLyYa5x55yF RtQC64bqTP2fHMK6Ogg+oGSjeI4XooTki+IQE= MIME-Version: 1.0 Received: by 10.216.136.89 with SMTP id v67mr64039wei.47.1303133724863; Mon, 18 Apr 2011 06:35:24 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.216.242.71 with HTTP; Mon, 18 Apr 2011 06:35:24 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110417221926.04b707b8@resistor.net> References: <6.2.5.6.2.20110417221926.04b707b8@resistor.net> Date: Mon, 18 Apr 2011 09:35:24 -0400 X-Google-Sender-Auth: uwBn-Ggg3G064BD_Q9ZryKD7Rl4 Message-ID: From: Barry Leiba To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] FBL BCP 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, 18 Apr 2011 13:35:26 -0000 > From previous discussions, I understood that it would not be possible to = use > draft-jdfalk-maawg-cfblbcp as input for work within this working group. = =A0I > prefer not to see a document which MAAWG may not like as it is their work > after all. =A0I suggest that the WG Chairs talk to MAAWG and explain to t= hem > how the IETF works. =A0If MAAWG is happy to give change control to the IE= TF, > the MARF WG can consider using the work as input. =A0If the deliverable c= annot > be produced without the MAAWG document, I suggest taking it off the list. I suggest that we stop having meta-discussion about the document, and instead review the document and come up with working group consensus about it. That will let us give feedback to MAAWG based on working group consensus, and will also allow individuals to feed their own comments back to MAAWG. All that will help MAAWG improve the document in a possible revision. After we've done that, we can see where we stand with respect to the MAAWG document, and then have the meta-discussion of what to do about the work item. Barry, as chair From dotzero@gmail.com Mon Apr 18 07:18:24 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 961B9E074A for ; Mon, 18 Apr 2011 07:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN99e-cA+ern for ; Mon, 18 Apr 2011 07:18:20 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfc.amsl.com (Postfix) with ESMTP id 72762E0700 for ; Mon, 18 Apr 2011 07:18:20 -0700 (PDT) Received: by qyk29 with SMTP id 29so1029061qyk.10 for ; Mon, 18 Apr 2011 07:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v0O4ZEptT8ALYjVA3k+JpGc1oiXKZFkmNwGiy562Qb8=; b=urqyLxtRRnHkfYYzQTgbQPhHz+Ca66WDVSeeDKAuKnBfF0JW73RRCGMMBXRxelyB51 KbZ8rb/Qw+X7L7XJXwIKLYjH5mSGtppAat9jnWUvIKdoV0lWCcyfEATTpvw2ogenwK99 rxLw0oPWdG7RMFnJu1T8KBcQ5c4u4aLylS8Ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eCkqOgZmOwJoTLD/HuIxk9bOGxHa69lLh1J5qMSJAUoosZbnUX5Iv6orc6FfCjkq5L +GZ7t5VLOgtT5kDLbD/9S7BLIlJLQueyfCiD/iLjPQ5b465IE1fJJruHewcpwb73FSSE tUE2rekGMDFl/k6UDEEqgAurCLwCHNtyX+G4U= MIME-Version: 1.0 Received: by 10.224.194.138 with SMTP id dy10mr2752196qab.207.1303136300141; Mon, 18 Apr 2011 07:18:20 -0700 (PDT) Received: by 10.229.69.164 with HTTP; Mon, 18 Apr 2011 07:18:20 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20110417221926.04b707b8@resistor.net> Date: Mon, 18 Apr 2011 10:18:20 -0400 Message-ID: From: Dotzero To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] FBL BCP 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, 18 Apr 2011 14:18:24 -0000 I'm comfortable with leaving the document as-is and do not feel that there is a compelling reason to come up with a separate BCP document at this time. I'm confident that the MAAWG folks have an understanding of how the IETF works and that their intent was asstated- to provide the document that they produced as a reference point. The status is informational. Mike On Mon, Apr 18, 2011 at 9:35 AM, Barry Leiba wrot= e: >> From previous discussions, I understood that it would not be possible to= use >> draft-jdfalk-maawg-cfblbcp as input for work within this working group. = =A0I >> prefer not to see a document which MAAWG may not like as it is their wor= k >> after all. =A0I suggest that the WG Chairs talk to MAAWG and explain to = them >> how the IETF works. =A0If MAAWG is happy to give change control to the I= ETF, >> the MARF WG can consider using the work as input. =A0If the deliverable = cannot >> be produced without the MAAWG document, I suggest taking it off the list= . > > I suggest that we stop having meta-discussion about the document, and > instead review the document and come up with working group consensus > about it. =A0That will let us give feedback to MAAWG based on working > group consensus, and will also allow individuals to feed their own > comments back to MAAWG. =A0All that will help MAAWG improve the document > in a possible revision. > > After we've done that, we can see where we stand with respect to the > MAAWG document, and then have the meta-discussion of what to do about > the work item. > > Barry, as chair > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From jdfalk-lists@cybernothing.org Tue Apr 19 15:55:52 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 61258E07DE for ; Tue, 19 Apr 2011 15:55:52 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lKiHbhusIll for ; Tue, 19 Apr 2011 15:55:51 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfc.amsl.com (Postfix) with ESMTP id 3FFA3E0660 for ; Tue, 19 Apr 2011 15:55:51 -0700 (PDT) Received: from [192.168.11.33] (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 p3JMtlnj020112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Apr 2011 15:55:49 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p3JMtlnj020112 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1303253750; bh=Cl5unWX3sSshbIVWzKNiFHjcIMIc2s2Bvrcu4l9tz S8=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=SF6ouJrLH3AuxsWZsAuRXvJ2ntcf812UmnpV YXH2/RZDFQPjAnPxYstKWHDfAffWveolYq263HfTz9qRXiWrUWebygDZxaEi6LJlpUc cmqQz92ULxxlE+WF0Jv2/Jyk0DxMVZW9wzsvdjkWRJYiqXJhFeot0HrxqEW+9Jv9CkU k= From: "J.D. Falk" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Apr 2011 15:55:46 -0700 Message-Id: <3F3A68C6-7D31-4389-AEA0-4EAB1B7A25D1@cybernothing.org> To: Message Abuse Report Format working group Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [marf] another ARF consumer implementation 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, 19 Apr 2011 22:55:52 -0000 Just heard about it, haven't tried it yet. = http://blog.postmaster.gr/2011/04/19/arfparse-a-simple-tool-to-extract-arf= -information/ -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From shmuel+gen@patriot.net Thu Apr 21 06:58:45 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1D981E077E for ; Thu, 21 Apr 2011 06:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.059 X-Spam-Level: X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuI1vuaX+WZr for ; Thu, 21 Apr 2011 06:58:44 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfc.amsl.com (Postfix) with ESMTP id 7108BE0689 for ; Thu, 21 Apr 2011 06:58:44 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.180]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 7AA72F58088 for ; Thu, 21 Apr 2011 09:51:43 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Wed, 20 Apr 2011 13:25:25 -0400 To: marf@ietf.org In-Reply-To: <4DAC0BC2.7040402@tana.it> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110421135206.7AA72F58088@smtp.patriot.net> Subject: Re: [marf] FBL BCP X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 13:58:45 -0000 In <4DAC0BC2.7040402@tana.it>, on 04/18/2011 at 12:00 PM, Alessandro Vesely said: >I'd agree, but then what does "registered for the purposes" mean? My take is that we need syntax for defining both addresses and use of the address; a consumer wanting both public and registered feedback may not want them going to the same address. >The correct target can be any of >1) a public reporting hub / global reputation tracker, >2) a reporting hub for users of a given domain only, >3) an FBL subscriber, >4) the abuse POC of a DKIM signer of the reported message, or 5) an >abuse POC responsible for the IP of the last relay. A consumer might want all of those, but not in the same mailbox. Given the above, I suggest that we define a rr=role paramaeter and allow multiple groups of tag-value pairs, either in a single '_report' TXT RR or in separate '_report&foo' TXT RR's. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From jdfalk-lists@cybernothing.org Thu Apr 21 10:50:05 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F8CEE073A for ; Thu, 21 Apr 2011 10:50:05 -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_24=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0aE5fUeVm4W for ; Thu, 21 Apr 2011 10:50:04 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by ietfc.amsl.com (Postfix) with ESMTP id A3E57E06EA for ; Thu, 21 Apr 2011 10:50:01 -0700 (PDT) Received: from [192.168.11.33] (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 p3LHnwwf021034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 21 Apr 2011 10:50:00 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net p3LHnwwf021034 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1303408200; bh=EbRac1JhzEEI//akdXcAjZiA5Ut/N+xHNZVjYqJhq pc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=G5ypxKlaRIBO Hd0Kdesrm3l+73/418Q/P8SWhYpR1FEDSRuXgEMUu1Na4Kccayj7F6pCsDGpdbqouC7 +FNXRn30RFLQ9ghT8n0QZcohPa3Nz8G3xOGVlFGUd21jHEObVEJ1L2IbmS+ob7fyZOo yFBdxY9nRkqpZVn/1zDGJl+oU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "J.D. Falk" In-Reply-To: <20110421135206.7AA72F58088@smtp.patriot.net> Date: Thu, 21 Apr 2011 10:49:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110421135206.7AA72F58088@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1082) Subject: Re: [marf] FBL BCP 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, 21 Apr 2011 17:50:05 -0000 On Apr 20, 2011, at 10:25 AM, Shmuel (Seymour J.) Metz wrote: > In <4DAC0BC2.7040402@tana.it>, on 04/18/2011 > at 12:00 PM, Alessandro Vesely said: >=20 >> I'd agree, but then what does "registered for the purposes" mean? >=20 > My take is that we need syntax for defining both addresses and use of > the address; a consumer wanting both public and registered feedback > may not want them going to the same address. >=20 >> The correct target can be any of >> 1) a public reporting hub / global reputation tracker, >> 2) a reporting hub for users of a given domain only, >> 3) an FBL subscriber, >> 4) the abuse POC of a DKIM signer of the reported message, or 5) an >> abuse POC responsible for the IP of the last relay. >=20 > A consumer might want all of those, but not in the same mailbox. >=20 > Given the above, I suggest that we define a rr=3Drole paramaeter and > allow multiple groups of tag-value pairs, either in a single '_report' > TXT RR or in separate '_report&foo' TXT RR's. This sounds a lot like draft-ietf-marf-reporting-discovery, plus a few = additional POC options. Only question is whether anyone would want to = advertise all of those separate addresses in DNS -- and whether anyone = would want to take the time to look them up, or just send ARF to the = advertised address and non-ARF to abuse@. (Either way, it doesn't sound at all like a CURRENT practice to add to a = BCP document.) -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions From shmuel+gen@patriot.net Thu Apr 21 11:59:46 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 105C9E06B9 for ; Thu, 21 Apr 2011 11:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfO7H3qFqb9a for ; Thu, 21 Apr 2011 11:59:45 -0700 (PDT) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by ietfc.amsl.com (Postfix) with ESMTP id 74B43E0677 for ; Thu, 21 Apr 2011 11:59:45 -0700 (PDT) Received: from ECS35455305 (unknown [69.72.27.164]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id C1DBEF58095 for ; Thu, 21 Apr 2011 14:52:46 -0400 (EDT) From: Shmuel (Seymour J.) Metz Date: Thu, 21 Apr 2011 14:55:29 -0400 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20110421185301.C1DBEF58095@smtp.patriot.net> Subject: Re: [marf] FBL BCP X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 18:59:46 -0000 In , on 04/21/2011 at 10:49 AM, "J.D. Falk" said: >This sounds a lot like draft-ietf-marf-reporting-discovery, It's a suggestion for a change to that document. >plus a few additional POC options. Along with the ability to specify more than one POC. >Only question is whether anyone would want to advertise all of those >separate addresses in DNS Alessandro seemed to be suggesting that there was a need to allow separation. >and whether anyone would want to take the time to look them up, or >just send ARF to the advertised address and non-ARF to abuse@. There wouldn't be a separate lookup. It would be one lookup with parsing. >(Either way, it doesn't sound at all like a CURRENT practice to add >to a BCP document.) Correct. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From vesely@tana.it Fri Apr 22 10:25:31 2011 Return-Path: X-Original-To: marf@ietfc.amsl.com Delivered-To: marf@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E56A6E06E9 for ; Fri, 22 Apr 2011 10:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.258 X-Spam-Level: X-Spam-Status: No, score=-5.258 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgspprsvFe80 for ; Fri, 22 Apr 2011 10:25:30 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfc.amsl.com (Postfix) with ESMTP id 9F442E065A for ; Fri, 22 Apr 2011 10:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1303493123; bh=GqL6akUNpikq/TEdQvAdnr2Cpm/64vYYyYY+jj4Lmeo=; l=3858; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=TJ2RgXdbiot6DNB0Ylmmlcq3qJepnEYNRybpGpCLFHFyoWjeF11mJaoVHa0hA2qFs nngCM6cA9U8Kcb2RzX4XjEGJ7ZDc3EQ5CQrcVmbs6o3zN6acv8rOJpj58ppztGK3ma vDavW+zFeQ6cjYYbMD04GmpsZ1Etj+lHY+EmESrA= 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, 22 Apr 2011 19:25:23 +0200 id 00000000005DC045.000000004DB1BA03.000079D2 Message-ID: <4DB1BA00.2050403@tana.it> Date: Fri, 22 Apr 2011 19:25:20 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: marf@ietf.org References: <20110421185301.C1DBEF58095@smtp.patriot.net> In-Reply-To: <20110421185301.C1DBEF58095@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [marf] FBL BCP 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, 22 Apr 2011 17:25:32 -0000 On 21/Apr/11 20:55, Shmuel (Seymour J.) Metz wrote: > In , on > 04/21/2011 > at 10:49 AM, "J.D. Falk" said: > >>Only question is whether anyone would want to advertise all of those >>separate addresses in DNS > > Alessandro seemed to be suggesting that there was a need to allow > separation. No, not exactly... Let me repeat that list: 1) a public reporting hub / global reputation tracker, 2) a reporting hub for users of a given domain only, 3) an FBL subscriber, 4) the abuse POC of a DKIM signer of the reported message, or 5) an abuse POC responsible for the IP of the last relay. (Also in http://en.wikipedia.org/wiki/Spam_reporting --new.) (1) and (3) are private mechanisms that are currently not fully standardized. Spamcop is a peculiar kind of (1) where subscribers can specify their address. For (3), the CFBL BCP gives some hints in Sec. 3.5. Subscription involves specifying an email address (that Sec. 4.1#2 recommends be "dedicated".) (5) is the address that the ISP registered at RIR's Whois db. Apparently, it is out of our charter's scope. For (2) and (4), separation could have come by itself if addresses were given at different places. Specifically: (2) is not standardized. It has to be triggered by a button, which eases its use for web mail. For reports sent via email, it could be specified as an update to RFC 6186. Alternatively, last year I proposed a "Report-To" tag in the last item of "More A-R bits...": http://mipassoc.org/pipermail/mail-vet-discuss/2010q2/000597.html (4) is not related to dkim-reporting --indeed, it implies successful verification of the relevant DKIM signature-- but an abuse reporting address could be standardized in a similar way. The same goes for spam relayed by SPF-authenticated senders. Instead, it is certainly more practical to define the addresses for reporting DKIM- or SPF- authenticated spam (4) homogeneously in the reporting-discovery document. The draft already mentions DKIM. Possibly, the ISP's abuse address (2) can also be defined that way, but there are a few more details to be worked out. So, the domain part to put after "_report." for querying would be: DKIM the domain defined in d= (already mentioned in Sec. 5), SPF the domain where the TXT or SPF record was found, and ISP the authserv-id of the A-R record, for authenticated messages. With such homogeneous definition, one can define the same target address for all methods. Using different (sub-) addresses may seem to be consistent with the CFBL BCP recommendation mentioned above. However, if the rationale behind that recommendation is to use secret addresses, I note that no published address can be kept secret. If one automates that stuff, sorting reports by type will take a fraction of the effort required for verifying them. In case separation is needed inside a single domain, I'm not sure whether it is better to look up a single record for all types, or have different records for each type. That is, for example, "rf=ARF; r=abuse@example.com; r.dkim=abuse-dkim@example.com;" versus _dkim._report.example.com Is such functionality needed? >>(Either way, it doesn't sound at all like a CURRENT practice to add >>to a BCP document.) > > Correct. They are not yet current. (2) and (4) need to be defined, otherwise people will have to resort to RFC 2142's abuse@. I think they can be defined by this WG, one way or the other. Apologies for a longer-than-planned message -- BTW: I've split the FBL wikipedia page, according to what Steve suggested back in November 2008: http://en.wikipedia.org/wiki/Abuse_Reporting_Format http://en.wikipedia.org/wiki/Feedback_loop_%28email%29 From sm@resistor.net Wed Apr 27 14:10: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 02127E07D9 for ; Wed, 27 Apr 2011 14:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 bX8cQ-vLl8FT for ; Wed, 27 Apr 2011 14:10:22 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC372E07A8 for ; Wed, 27 Apr 2011 14:10:21 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p3RLAECv005440; Wed, 27 Apr 2011 14:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1303938619; bh=26zP9iPBvhzq+6qrGVDRpWPU0KxBzNrKAv0T9rGKEQI=; h=Message-Id:X-Mailer:Date:To:From:Subject:Mime-Version: Content-Type; b=yzNlsXojEG8jTYN4uv35IviYXndurmfQj+7JIPtggyoyRpP4hWMPjvCJPrUGVwVYf IBO18inF0PzFC54ll4uDBZ0zs3y28PP8mk4KnvFGVbu5cNrpIKsc4AptT8c5oITw6S UVBn5B95jtZqjtknWyHsmIRjMO2prcl+nn5vMFpk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1303938619; bh=26zP9iPBvhzq+6qrGVDRpWPU0KxBzNrKAv0T9rGKEQI=; h=Message-Id:X-Mailer:Date:To:From:Subject:Mime-Version: Content-Type; b=YfpRXT5NgRuFGO+eAjrmrYSM7MW7uMBm/bpWceAZgr2tVta47BxqiYHHqaEr7Gsvm 2mhGuM3KcycU2nVckV0HPJgFE5gd+LhA1SSS2fVL2v7nqRNdt9eEPsP6lSJ+H3+I9n 2gTAkuN5jORLLj+P4LvY2XP1ys3AAJ77U1CWAM+Y= Message-Id: <6.2.5.6.2.20110427131827.0490f778@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 27 Apr 2011 14:07:58 -0700 To: marf@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [marf] Not an objection to FBL BCP 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, 27 Apr 2011 21:10:30 -0000 Hello, This is not an objection to the message posted at http://www.ietf.org/mail-archive/web/marf/current/msg01065.html I have participated in a working group where an I-D was reluctantly brought to the IETF. Nobody wanted to confront the issue to avoid ruffling feathers. Changes were asked for and ignored. That caused some discontent within the working group. I prefer not to participate in that type of discussion again. According to the MARF Charter: "The group will produce an informational document detailing guidelines for deploying and using ARF, including descriptions of current practices and their rationales." That calls for an informational document and not a BCP. I don't think that it is appropriate to use draft-jdfalk-maawg-cfblbcp-00 as input for that work as the document may not be modified, and derivative works of it may not be created. I suggest that the MARF WG Chairs asks MAAWG whether it can resubmit the I-D without any such restrictions as that is, if I am not mistaken, the usual practice for IETF working group work. I don't think that it is appropriate to ask a working group to "propose some changes, which go back to the MAAWG Board for approval". I would have the same stance if it was for the W3C, for example. I don't plan to bother the responsible AD or anyone else about this matter. Regards, -sm From barryleiba.mailing.lists@gmail.com Wed Apr 27 15:53:16 2011 Return-Path: X-Original-To: marf@ietfa.amsl.com Delivered-To: marf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BA4E07CE for ; Wed, 27 Apr 2011 15:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.324 X-Spam-Level: X-Spam-Status: No, score=-103.324 tagged_above=-999 required=5 tests=[AWL=-0.347, 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 lO49UHv-zWMr for ; Wed, 27 Apr 2011 15:53:15 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id AF464E07CB for ; Wed, 27 Apr 2011 15:53:15 -0700 (PDT) Received: by gwb20 with SMTP id 20so951081gwb.31 for ; Wed, 27 Apr 2011 15:53:15 -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 :content-transfer-encoding; bh=qUPsMQMGibBgEGtiY2qBnPTinWV7ricvtipJ+KmeSEU=; b=Gb+zUc6yUn+5UO1BE/I/gglug9BIEN+zLaflYo1QhVPdqlH8ScimKAEUBP0YgSdDYf lU0INcg+I++W6R43qZVqviVN5KJGD3XdIHvjKjwsdHthHpu8ubotOgrtt9y0pNa5sMRF xiRBYl7aJs0T2umg3BePuOL/3ilwo8XQ6tsS8= 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 :content-transfer-encoding; b=P8lxybt/F0wHrCFAkSruSTMS3gPECIoCKLNXvSyCyUrnQ3n31suyY+dtE180eCIdPW /acRs9bf9O9PDLCdSbWg0gtwbEbgmXk/PHGtOnopEacqJbEWzTYQ9TnRVx793luolEug 9djQh2KmycDWSDk5AQPtRAVOOQsIW1GhiFOGA= MIME-Version: 1.0 Received: by 10.236.108.161 with SMTP id q21mr3560065yhg.198.1303944795148; Wed, 27 Apr 2011 15:53:15 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.137.10 with HTTP; Wed, 27 Apr 2011 15:53:15 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110427131827.0490f778@elandnews.com> References: <6.2.5.6.2.20110427131827.0490f778@elandnews.com> Date: Wed, 27 Apr 2011 18:53:15 -0400 X-Google-Sender-Auth: aSa62wLokxo5fe0GXwogjQQDgvU Message-ID: From: Barry Leiba To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Not an objection to FBL BCP 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, 27 Apr 2011 22:53:16 -0000 Hi, SM. > I suggest that the MARF WG Chairs asks MAAWG whether it can resubmit the = I-D > without any such restrictions as that is, if I am not mistaken, the usual > practice for IETF working group work. > > I don't think that it is appropriate to ask a working group to "propose s= ome > changes, which go back to the MAAWG Board for approval". =A0I would have = the > same stance if it was for the W3C, for example. The chairs have already asked MAAWG to do that. The way they want to handle it at this time is to get feedback from the MARF participants on what they've already published, and to see where that takes them. That's what the chairs have been suggesting to the working group. Let's start with reviewing the MAAWG document as something that is NOT a working group document, and giving them feedback. If, after that feedback, they update their document and decide to change the terms they put on it, that's great. If not, we will still have done something useful with our feedback, just as we might review and give feedback for a W3C document, for example. When we need to make a definite decision about what to do about that charter item, we will have gone through one round of feedback to MAAWG, and we'll have a good idea of what we'd like to do with our own document. Barry, as chair