From msk@cloudmark.com Mon Feb 1 11:37:59 2010 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 330C43A6A35 for ; Mon, 1 Feb 2010 11:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 kqI+dwp2jLGd for ; Mon, 1 Feb 2010 11:37:55 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id F38AE3A680D for ; Mon, 1 Feb 2010 11:37:54 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 1 Feb 2010 11:38:30 -0800 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Mon, 1 Feb 2010 11:38:29 -0800 Thread-Topic: draft-ietf-marf-base-00 Thread-Index: Acqe3QbXkIS0YlJNQhyw3sk374RCAwEmOaXg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01C35F74CCEXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] draft-ietf-marf-base-00 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: Mon, 01 Feb 2010 19:37:59 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01C35F74CCEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In particular, is there consensus on this text? 6.6. Omitting Data from ARF Reports ADMDs generating ARF reports may decide they wish to omit portions of the data included in an ARF report to protect the privacy of its users and/or the security of its messaging infrastructure. There is normative text earlier in this document discouraging this practice since, like DSNs, the purpose is to get as much data about the abuse back to the originating ADMD so corrective action can be taken. Nevertheless, this is a practice that experience has shown will occur. Report generators undertaking such practices may find their reports are less likely to generate corrective action as the data required to do so has been withheld, essentially making the report nearly meaningless. From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mur= ray S. Kucherawy Sent: Tuesday, January 26, 2010 3:12 PM To: marf@ietf.org Subject: [marf] draft-ietf-marf-base-00 As you can see I've posted the revised draft, i.e. draft-shafranovich-feedb= ack-report with the recently discussed modifications, as draft-ietf-marf-ba= se-00. We have a deliverable of June to submit this to the IESG for approval. Ple= ase review it and submit any feedback to this list. If it's quiet, we can = start a working group last call on it at our planned working group meeting = at the next IETF general meeting in Anaheim, and get that one off our list = early. -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01C35F74CCEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In particular, is there consensus on this text?

 =

6.6.  Omitting Data = from ARF Reports

 

 

   ADMDs generating ARF reports may decide they wish to omit portions of<= /o:p>

   the data included in an ARF report to protect the privacy of its=

   users and/or the security of its messaging infrastructure.  There is

   normative text earlier in this document discouraging this practice

   since, like DSNs, the purpose is to get as much data about the abuse

   back to the originating ADMD so corrective action can be taken.<= /span>

   Nevertheless, this is a practice that experience has shown will<= /span>

   occur.

 

   Report generators undertaking such practices may find their reports

   are less likely to generate corrective action as the data required to<= /o:p>

   do so has been withheld, essentially making the report nearly

   meaningless.

 =

 =

From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Mu= rray S. Kucherawy
Sent: Tuesday, January 26, 2010 3:12 PM
To: marf@ietf.org
Subject: [marf] draft-ietf-marf-base-00

 

As you can see I’ve posted the revised draft, i.= e. draft-shafranovich-feedback-report with the recently discussed modification= s, as draft-ietf-marf-base-00.

 

We have a deliverable of June to submit this to the IE= SG for approval.  Please review it and submit any feedback to this list. = ; If it’s quiet, we can start a working group last call on it at our plann= ed working group meeting at the next IETF general meeting in Anaheim, and get that one= off our list early.

 

-MSK

 

--_000_BB012BD379D7B046ABE1472D8093C61C01C35F74CCEXCHC2corpclo_-- From steve@wordtothewise.com Mon Feb 1 11:46:32 2010 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 B5B473A6A4C for ; Mon, 1 Feb 2010 11:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkQkPXkF8uwq for ; Mon, 1 Feb 2010 11:46:31 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id E8B363A6A48 for ; Mon, 1 Feb 2010 11:46:31 -0800 (PST) Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 4EC4B4F82EE for ; Mon, 1 Feb 2010 11:47:07 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Mon, 1 Feb 2010 11:47:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> References: To: marf@ietf.org X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] draft-ietf-marf-base-00 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: Mon, 01 Feb 2010 19:46:32 -0000 On Feb 1, 2010, at 11:38 AM, Murray S. Kucherawy wrote: I've not had a chance to more than skim the draft, but... > In particular, is there consensus on this text? > =20 ... the second paragraph is generally false, as the reports that are = currently sent by, for example, AOL are a long way from being "essentially = meaningless". Low-volume mailing lists using "old school" MLMs such as majordomo are = the main case where eliding the recipient makes the report useless, and that's a = fairly rare case, compared with 1:1 or typical bulk email sent by professional = senders. I don't think it adds much and could be safely removed. The first = paragraph and the preceding text already says "we'd prefer you don't do that". Cheers, Steve > 6.6. Omitting Data from ARF Reports > =20 > =20 > ADMDs generating ARF reports may decide they wish to omit portions = of > the data included in an ARF report to protect the privacy of its > users and/or the security of its messaging infrastructure. There = is > normative text earlier in this document discouraging this practice > since, like DSNs, the purpose is to get as much data about the = abuse > back to the originating ADMD so corrective action can be taken. > Nevertheless, this is a practice that experience has shown will > occur. > =20 > Report generators undertaking such practices may find their reports > are less likely to generate corrective action as the data required = to > do so has been withheld, essentially making the report nearly > meaningless. > =20 > =20 > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of Murray S. Kucherawy > Sent: Tuesday, January 26, 2010 3:12 PM > To: marf@ietf.org > Subject: [marf] draft-ietf-marf-base-00 > =20 > As you can see I=92ve posted the revised draft, i.e. = draft-shafranovich-feedback-report with the recently discussed = modifications, as draft-ietf-marf-base-00. > =20 > We have a deliverable of June to submit this to the IESG for approval. = Please review it and submit any feedback to this list. If it=92s = quiet, we can start a working group last call on it at our planned = working group meeting at the next IETF general meeting in Anaheim, and = get that one off our list early. > =20 > -MSK > =20 > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf From msk@cloudmark.com Mon Feb 1 12:37:31 2010 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 1042D28C197 for ; Mon, 1 Feb 2010 12:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599] 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 8Mf+sinoFxmB for ; Mon, 1 Feb 2010 12:37:30 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 4FB1D28C186 for ; Mon, 1 Feb 2010 12:37:30 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 1 Feb 2010 12:38:05 -0800 From: "Murray S. Kucherawy" To: Steve Atkins , "marf@ietf.org" Date: Mon, 1 Feb 2010 12:38:04 -0800 Thread-Topic: [marf] draft-ietf-marf-base-00 Thread-Index: Acqjd1elwQ+xDAD+RZunpkHA767nCwABk8qA Message-ID: References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> In-Reply-To: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] draft-ietf-marf-base-00 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: Mon, 01 Feb 2010 20:37:31 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Steve Atkins > Sent: Monday, February 01, 2010 11:47 AM > To: marf@ietf.org > Subject: Re: [marf] draft-ietf-marf-base-00 >=20 >=20 > I don't think it adds much and could be safely removed. The first > paragraph > and the preceding text already says "we'd prefer you don't do that". I don't agree that we can remove it entirely. That the act of redacting is= based upon privacy concerns is by itself a reason to mention it in Securit= y Considerations, and I suspect the SECDIR people who will review this when= it goes to the IESG will want it mentioned. I'd be fine with dropping the second paragraph, but the first will probably= require some wordsmithing as a result. How about: The sending of these reports will reveal possibly private information about= the person sending the report. For example, such as a report sent in resp= onse to a mailing list posting will reveal to the report recipient a valid = email address on the list that might otherwise have remained hidden. For this reason, report generators may wish to redact portions of the repor= t to conceal private information. Doing so may be necessary where privacy = trumps operational necessity, but as mentioned in (section back-reference) = it may impede a timely or meaningful response from the report recipient. ? From steve@wordtothewise.com Mon Feb 1 12:42:37 2010 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 10BCC28C1C3 for ; Mon, 1 Feb 2010 12:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFD7q1DLykO5 for ; Mon, 1 Feb 2010 12:42:36 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 5C65428C1A4 for ; Mon, 1 Feb 2010 12:42:36 -0800 (PST) Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 03FB94F82F9 for ; Mon, 1 Feb 2010 12:43:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Mon, 1 Feb 2010 12:43:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> To: marf@ietf.org X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] draft-ietf-marf-base-00 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: Mon, 01 Feb 2010 20:42:37 -0000 On Feb 1, 2010, at 12:38 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of >> Steve Atkins >> Sent: Monday, February 01, 2010 11:47 AM >> To: marf@ietf.org >> Subject: Re: [marf] draft-ietf-marf-base-00 >>=20 >>=20 >> I don't think it adds much and could be safely removed. The first >> paragraph >> and the preceding text already says "we'd prefer you don't do that". >=20 > I don't agree that we can remove it entirely. That the act of = redacting is based upon privacy concerns is by itself a reason to = mention it in Security Considerations, and I suspect the SECDIR people = who will review this when it goes to the IESG will want it mentioned. Right. >=20 > I'd be fine with dropping the second paragraph, but the first will = probably require some wordsmithing as a result. How about: >=20 >=20 > The sending of these reports will reveal possibly private information = about the person sending the report. For example, such as a report sent = in response to a mailing list posting will reveal to the report = recipient a valid email address on the list that might otherwise have = remained hidden. >=20 > For this reason, report generators may wish to redact portions of the = report to conceal private information. Doing so may be necessary where = privacy trumps operational necessity, but as mentioned in (section = back-reference) it may impede a timely or meaningful response from the = report recipient. Much better, yes. It gets the message across nicely without exaggerating = the issue. (I might go with "operational preference" rather than "operational = necessity", maybe, but that's mostly just word-twiddling). Cheers, Steve From msk@cloudmark.com Mon Feb 1 12:47:27 2010 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 B18F03A69AE for ; Mon, 1 Feb 2010 12:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599] 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 DixOGUsfvUo5 for ; Mon, 1 Feb 2010 12:47:27 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 13DAD3A6765 for ; Mon, 1 Feb 2010 12:47:27 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 1 Feb 2010 12:48:02 -0800 From: "Murray S. Kucherawy" To: Steve Atkins , "marf@ietf.org" Date: Mon, 1 Feb 2010 12:48:02 -0800 Thread-Topic: [marf] draft-ietf-marf-base-00 Thread-Index: AcqjfyzTRo3JDdXNQTKTZcn2W46ViAAAIsLg Message-ID: References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] draft-ietf-marf-base-00 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: Mon, 01 Feb 2010 20:47:27 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Steve Atkins > Sent: Monday, February 01, 2010 12:43 PM > To: marf@ietf.org > Subject: Re: [marf] draft-ietf-marf-base-00 >=20 > (I might go with "operational preference" rather than "operational > necessity", maybe, but that's mostly just word-twiddling). My use of "operational necessity" is meant to make a distinction between th= e actual operators of an FBL and the lawyers that influence their choices. = :) From michael.adkins@corp.aol.com Mon Feb 1 13:05:23 2010 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 121233A6985 for ; Mon, 1 Feb 2010 13:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqJnD+9URfVb for ; Mon, 1 Feb 2010 13:05:22 -0800 (PST) Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by core3.amsl.com (Postfix) with ESMTP id 01B483A6874 for ; Mon, 1 Feb 2010 13:05:21 -0800 (PST) Received: from AOLMTCMEH01.ad.office.aol.com (aolmtcmeh01.office.aol.com [10.178.121.20]) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id o11L5s4x011375; Mon, 1 Feb 2010 16:05:54 -0500 Received: from AOLMTCMEI01.ad.office.aol.com ([10.178.3.18]) by AOLMTCMEH01.ad.office.aol.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 16:05:54 -0500 Received: from [10.181.178.134] ([10.178.3.11]) by AOLMTCMEI01.ad.office.aol.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 16:05:53 -0500 Message-ID: <4B674244.3090303@corp.aol.com> Date: Mon, 01 Feb 2010 16:06:12 -0500 From: Michael Adkins User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Steve Atkins References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2010 21:05:53.0987 (UTC) FILETIME=[5756E930:01CAA382] Cc: marf@ietf.org Subject: Re: [marf] draft-ietf-marf-base-00 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: Mon, 01 Feb 2010 21:05:23 -0000 >> I'd be fine with dropping the second paragraph, but the first will probably require some wordsmithing as a result. How about: >> >> >> The sending of these reports will reveal possibly private information about the person sending the report. For example, such as a report sent in response to a mailing list posting will reveal to the report recipient a valid email address on the list that might otherwise have remained hidden. >> >> For this reason, report generators may wish to redact portions of the report to conceal private information. Doing so may be necessary where privacy trumps operational necessity, but as mentioned in (section back-reference) it may impede a timely or meaningful response from the report recipient. >> > > Much better, yes. It gets the message across nicely without exaggerating the issue. > > +1 > (I might go with "operational preference" rather than "operational necessity", maybe, but that's mostly just word-twiddling). > > Cheers, > Steve > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From vesely@tana.it Tue Feb 2 00:59:06 2010 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 7CCA828C1E5 for ; Tue, 2 Feb 2010 00:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.808 X-Spam-Level: X-Spam-Status: No, score=-4.808 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rotn+yRqloJf for ; Tue, 2 Feb 2010 00:59:05 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 6D1F128C1D8 for ; Tue, 2 Feb 2010 00:59:05 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 02 Feb 2010 09:59:37 +0100 id 00000000005DC033.000000004B67E979.00004A52 Message-ID: <4B67E97A.5080306@tana.it> Date: Tue, 02 Feb 2010 09:59:38 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] draft-ietf-marf-base-00 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, 02 Feb 2010 08:59:06 -0000 On 01/Feb/10 21:38, Murray S. Kucherawy wrote: > I'd be fine with dropping the second paragraph, but the first will probably require some wordsmithing as a result. How about: > > > The sending of these reports will reveal possibly private information about the person sending the report. For example, such as a report sent in response to a mailing list posting will reveal to the report recipient a valid email address on the list that might otherwise have remained hidden. This example is useful as it implicitly suggests that the address or the name may also be found in the body of the message. However, it is not the most frequent case, and it may be controversial about the effect that the report is meant to raise (responses from mailing lists are generally ham, and if they are spam it is not the subscriber who should have filtered it.) I'd leave the example out and mention the message body explicitly. > For this reason, report generators may wish to redact portions of the report to conceal private information. Doing so may be necessary where privacy trumps operational necessity, but as mentioned in (section back-reference) it may impede a timely or meaningful response from the report recipient. Is the impediment true for some type of report only? Are there more specific reasons for redacting? (For example, I wonder if the cases when the user name is the same as the login name should be treated differently.) I also have a few questions about the rest of the document. * opt-out: this Feedback-Type has been removed, but it is still present in the examples and in the Removal-Recipient field name. * Feedback Type Names may deserve further discussion. I'd like to have a "test" type, and would eliminate "virus" as it should probably be dealt with using INCH and connection-related infrastructures. * purpose: there seem to be some consensus on the ASRG that ARF might be used in relation to spam buttons on MUAs. Would that be worth being mentioned in Section 1.1 bullets? E.g. To inform mailbox providers that a mailbox owner of theirs is the target of an abusive mail transmission. From johnl@taugh.com Tue Feb 2 08:55:36 2010 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 E3C9D3A6828 for ; Tue, 2 Feb 2010 08:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.121 X-Spam-Level: X-Spam-Status: No, score=-19.121 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 QXeMbN1-842Q for ; Tue, 2 Feb 2010 08:55:35 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id A204B3A67B1 for ; Tue, 2 Feb 2010 08:55:35 -0800 (PST) Received: (qmail 82258 invoked from network); 2 Feb 2010 16:56:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=KNcrUiz+w0Xm3mPdjRU0c1bnnAH0ag5fgrI4Re992fA=; b=HKGyUpcM75YXIWkzMQBhZ/fIDOpzIbgwC9V6nD16M92c39FXFmSCrNraNsRHqKEjHOBcT4A3lnIFzJBuT/P1gFyv4HDRkey4wxh2MfWn43Lv+Sz/05S1zygYVVWck3fyfIvGYVsPkviN4RV9jOArJq6Cv5Lkc6HWA0dYujtJfrA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=KNcrUiz+w0Xm3mPdjRU0c1bnnAH0ag5fgrI4Re992fA=; b=VzvHiDoxW3UOZTED2p+SeeHKPQvMm00IkGxP4WGaN0h33+1zB0IHKcnTfp8f1d6LPwbFDQcvb34bUfqrkzGfDgzetwTbQrTzgO75mHOCJEWtU98DlZLFHsDjLxXMRttlsEaQFzGJK2l/+vYiAtI8iX7e0+xJoQzbouNDSbiTEVo= Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Feb 2010 16:55:51 -0000 Date: 2 Feb 2010 11:56:12 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" In-Reply-To: <4B67E97A.5080306@tana.it> References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> <4B67E97A.5080306@tana.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: marf@ietf.org Subject: Re: [marf] draft-ietf-marf-base-00 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, 02 Feb 2010 16:55:37 -0000 >> The sending of these reports will reveal possibly private information about >> the person sending the report. For example, such as a report sent in >> response to a mailing list posting will reveal to the report recipient a >> valid email address on the list that might otherwise have remained hidden. > > This example is useful as it implicitly suggests that the address or the name > may also be found in the body of the message. However, it is not the most > frequent case Actually, most ARF reports are sent from ISPs to ESPs, and in about 100% of those cases the address is somewhere else in the message. >> For this reason, report generators may wish to redact portions of the >> report to conceal private information. Doing so may be necessary where >> privacy trumps operational necessity, but as mentioned in (section >> back-reference) it may impede a timely or meaningful response from the >> report recipient. > > Is the impediment true for some type of report only? Are there more specific > reasons for redacting? (For example, I wonder if the cases when the user name > is the same as the login name should be treated differently.) The two reasons are A) the lawyers said it's a privacy problem and B) "listwashing". Case A is vastly more common. > * Feedback Type Names may deserve further discussion. I'd like to have a > "test" type, and would eliminate "virus" as it should probably be dealt with > using INCH and connection-related infrastructures. I actually send virus ARF reports. > * purpose: there seem to be some consensus on the ASRG that ARF might be used > in relation to spam buttons on MUAs. Would that be worth being mentioned in > Section 1.1 bullets? E.g. If we do that, we'll publish a separate update document. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From msk@cloudmark.com Tue Feb 2 15:12:42 2010 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 6491028C132 for ; Tue, 2 Feb 2010 15:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599] 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 qkXnaBI98Fmo for ; Tue, 2 Feb 2010 15:12:39 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id D56FD28C137 for ; Tue, 2 Feb 2010 15:12:32 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Tue, 2 Feb 2010 15:13:12 -0800 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Tue, 2 Feb 2010 15:13:11 -0800 Thread-Topic: [marf] draft-ietf-marf-base-00 Thread-Index: Acqj5hF2tRdCRbUCQHGeBtnIhblR0gAdW6EA Message-ID: References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> <4B67E97A.5080306@tana.it> In-Reply-To: <4B67E97A.5080306@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] draft-ietf-marf-base-00 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, 02 Feb 2010 23:12:42 -0000 [as participant] > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Tuesday, February 02, 2010 1:00 AM > To: marf@ietf.org > Subject: Re: [marf] draft-ietf-marf-base-00 >=20 > > The sending of these reports will reveal possibly private information > > about the person sending the report. For example, such as a report > > sent in response to a mailing list posting will reveal to the report > > recipient a valid email address on the list that might otherwise have > > remained hidden. >=20 > This example is useful as it implicitly suggests that the address or > the name may also be found in the body of the message. However, it is > not the most frequent case, and it may be controversial about the > effect that the report is meant to raise (responses from mailing lists > are generally ham, and if they are spam it is not the subscriber who > should have filtered it.) I'd leave the example out and mention the > message body explicitly. Actually I think including an example is useful here, but it doesn't need t= o be this one if there's a better one. Can someone suggest a better one? > Is the impediment true for some type of report only? Are there more > specific reasons for redacting? (For example, I wonder if the cases > when the user name is the same as the login name should be treated > differently.) >=20 >=20 > I also have a few questions about the rest of the document. >=20 > * opt-out: this Feedback-Type has been removed, but it is still > present in the examples and in the Removal-Recipient field name. Thanks, I'll fix that. > * Feedback Type Names may deserve further discussion. I'd like to have > a "test" type, and would eliminate "virus" as it should probably be > dealt with using INCH and connection-related infrastructures. How would you define a "test" type? As has been mentioned, "virus" is actually in use. To some degree we're do= cumenting a current, widely-deployed system, so it's appropriate to include= it. > * purpose: there seem to be some consensus on the ASRG that ARF might > be used in relation to spam buttons on MUAs. Would that be worth being > mentioned in Section 1.1 bullets? E.g. >=20 > To inform mailbox providers that a mailbox owner of theirs is > the target of an abusive mail transmission. I think this is covered by the first bullet ("related to" covers "claiming = to be from"), but that can be made explicit if there's consensus that this = would be useful. From vesely@tana.it Wed Feb 3 01:56:09 2010 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 9AD6928C159 for ; Wed, 3 Feb 2010 01:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.716 X-Spam-Level: X-Spam-Status: No, score=-4.716 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnqjHoet2-T6 for ; Wed, 3 Feb 2010 01:56:08 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 4F79028C155 for ; Wed, 3 Feb 2010 01:56:08 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 03 Feb 2010 10:56:46 +0100 id 00000000005DC03C.000000004B69485E.00007868 Message-ID: <4B69485E.2070208@tana.it> Date: Wed, 03 Feb 2010 10:56:46 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> <4B67E97A.5080306@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] draft-ietf-marf-base-00 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: Wed, 03 Feb 2010 09:56:09 -0000 On 02/Feb/10 17:56, John R Levine wrote: >>> redact portions of the report to conceal private information [...] >>> impede a timely or meaningful response from the report recipient. >> Are there more specific reasons for redacting? > > The two reasons are A) the lawyers said it's a privacy problem and B) > "listwashing". Case A is vastly more common. If there is an established legal point on that issue, it may be worth to mention it --informatively-- in the RFC. IME there are two kinds of users: some carefully avoid to publish their address, while the others either don't care or consider publishing it an integral part of exercising their human rights. ARF obviously concerns the second kind. In case they make their position explicit, does the legal problem persist? From vesely@tana.it Wed Feb 3 01:57:20 2010 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 A837228C148 for ; Wed, 3 Feb 2010 01:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.716 X-Spam-Level: X-Spam-Status: No, score=-4.716 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyGW6nurzgYs for ; Wed, 3 Feb 2010 01:57:20 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id CAF4228C146 for ; Wed, 3 Feb 2010 01:57:19 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 03 Feb 2010 10:58:00 +0100 id 00000000005DC041.000000004B6948A8.00007F56 Message-ID: <4B6948A8.6050304@tana.it> Date: Wed, 03 Feb 2010 10:58:00 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> <4B67E97A.5080306@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [marf] draft-ietf-marf-base-00 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: Wed, 03 Feb 2010 09:57:20 -0000 On 03/Feb/10 00:13, Murray S. Kucherawy wrote: >> * Feedback Type Names may deserve further discussion. I'd like to have >> a "test" type > > How would you define a "test" type? Something done for the sole purpose of verifying that the machinery to send/receive ARF messages works properly. These messages should be transported and processed normally, except that they should bear no lasting consequence whatsoever. Circuits, like sending ARF messages to the connection providers, à la Abusix, expecting that they resend them to the MTA operators, cannot be tested locally. OTOH, to check proper settings by reporting their own messages as spam is not the kind of activity that new operators would be most inclined to do... "Test" is much clearer than "non-spam" or "other" for this usage. Am I the only one who would use it? > As has been mentioned, "virus" is actually in use. Fine, then. From shmuel+gen@patriot.net Tue Feb 2 02:49:05 2010 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 6292428C29A for ; Tue, 2 Feb 2010 02:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.415 X-Spam-Level: X-Spam-Status: No, score=0.415 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_83=0.6] 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 F9Ax6Nvd4b7G for ; Tue, 2 Feb 2010 02:49:04 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 61BB028C298 for ; Tue, 2 Feb 2010 02:49:04 -0800 (PST) Received: from ECS35455305 (core-dc-1-70.dynamic-dialup.coretel.net [69.72.26.70]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 90D0CF580BE for ; Tue, 2 Feb 2010 05:39:33 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 02 Feb 2010 05:49:06 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100202103934.90D0CF580BE@smtp.patriot.net> Subject: Re: [marf] draft-ietf-marf-base-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 13:03:59 -0000 In , on 02/01/2010 at 11:38 AM, "Murray S. Kucherawy" said: >In particular, is there consensus on this text? My only issue is grammar c/has been/have been/ OTOH, if we are to allow redacting then I would like to see some standard way of indicating that the data have been redacted, and I would like the use of it to be a MUST. Perhaps a new parameter: multipart/report; report-type=feedback-report; redacted=yes. -- 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 shmuel+gen@patriot.net Tue Feb 2 03:59:11 2010 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 9B73E3A6AFD for ; Tue, 2 Feb 2010 03:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_50=0.001] 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 d5Fi8XmFxM9J for ; Tue, 2 Feb 2010 03:59:11 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 765333A6A2F for ; Tue, 2 Feb 2010 03:59:11 -0800 (PST) Received: from ECS35455305 (core-dc-1-153.dynamic-dialup.coretel.net [69.72.26.153]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 98FA7F580BE for ; Tue, 2 Feb 2010 06:49:42 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 02 Feb 2010 07:00:29 -0500 To: Message Abuse Report Format working group 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: <20100202114943.98FA7F580BE@smtp.patriot.net> Subject: [marf] [MARF] Drop boxes X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 13:04:32 -0000 The draft is unclear as to whether it applies to reporting of drop boxes (either mail boxes or URI's) in abusive e-mail. I believe that there should be some optional fields relating to such reports, assuming that MARF is applicable. These might include both URI's in the spam and redirections. -- 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 shmuel+gen@patriot.net Tue Feb 2 03:59:08 2010 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 A368A3A692F for ; Tue, 2 Feb 2010 03:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_40=-0.185] 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 Tkw29iKhPaDB for ; Tue, 2 Feb 2010 03:59:07 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id D969F3A68BF for ; Tue, 2 Feb 2010 03:59:07 -0800 (PST) Received: from ECS35455305 (core-dc-1-153.dynamic-dialup.coretel.net [69.72.26.153]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id B90C0F580BF for ; Tue, 2 Feb 2010 06:49:38 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 02 Feb 2010 07:00:17 -0500 To: Message Abuse Report Format working group 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: <20100202114939.B90C0F580BF@smtp.patriot.net> Subject: [marf] [MARF] Additional MIME subparts X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 13:04:37 -0000 I'd like to see provision for additional MIME parts of multipart/report; report-type=feedback-report. Specifically, I'd like to relegate supporting documentation[1] to a separate MIME part. I'd also like for those additional part to be identified by, e.g., their MIME type, rather than by their position withing the multipart/report. Finally, I'd like an IETF registry of the defined additional parts. If the group concurs, "4. Extensibility" should discuss the new registry. [1] E.g., whois data. Note that while in theory the provider could do his own, e.g., traceroute, relevant data might have changed in the intervening period. -- 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 shmuel+gen@patriot.net Tue Feb 2 03:59:08 2010 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 78E233A692F for ; Tue, 2 Feb 2010 03:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_50=0.001] 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 0MaGXdyrA5Y7 for ; Tue, 2 Feb 2010 03:59:07 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 7A7273A6936 for ; Tue, 2 Feb 2010 03:59:04 -0800 (PST) Received: from ECS35455305 (core-dc-1-153.dynamic-dialup.coretel.net [69.72.26.153]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id EEA61F580BE for ; Tue, 2 Feb 2010 06:49:33 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 02 Feb 2010 06:26:43 -0500 To: Message Abuse Report Format working group 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: <20100202114935.EEA61F580BE@smtp.patriot.net> Subject: [marf] Drop boxes X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 13:04:43 -0000 The draft is unclear as to whether it applies to reporting of drop boxes (either mail boxes or URI's) in abusive e-mail. I believe that there should be some optional fields relating to such reports, assuming that MARF is applicable. These might include both URI's in the spam and redirections. -- 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 steve@wordtothewise.com Wed Feb 3 05:10:41 2010 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 8E6813A6AF8 for ; Wed, 3 Feb 2010 05:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FejubCucfOY6 for ; Wed, 3 Feb 2010 05:10:40 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 563813A6907 for ; Wed, 3 Feb 2010 05:10:39 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 9018880F9D for ; Wed, 3 Feb 2010 05:11:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: <20100202114939.B90C0F580BF@smtp.patriot.net> Date: Wed, 3 Feb 2010 05:11:21 -0800 Content-Transfer-Encoding: 7bit Message-Id: <61D4D112-C749-4419-AB92-861687025248@wordtothewise.com> References: <20100202114939.B90C0F580BF@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] [MARF] Additional MIME subparts 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: Wed, 03 Feb 2010 13:10:41 -0000 On Feb 2, 2010, at 4:00 AM, Shmuel (Seymour J.) Metz wrote: > I'd like to see provision for additional MIME parts of multipart/report; > report-type=feedback-report. Specifically, I'd like to relegate supporting > documentation[1] to a separate MIME part. I'd also like for those > additional part to be identified by, e.g., their MIME type, rather than by > their position withing the multipart/report. Finally, I'd like an IETF > registry of the defined additional parts. If the group concurs, "4. > Extensibility" should discuss the new registry. > > [1] E.g., whois data. Note that while in theory the provider could do > his own, e.g., traceroute, relevant data might have changed in > the intervening period. If you want to add unstructured data (with the understanding that it's fairly unlikely it'll ever be read) there's already a place for that - the first, probably text/plain, MIME part. Cheers, Steve From steve@wordtothewise.com Wed Feb 3 05:29:43 2010 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 E071F3A6BF0 for ; Wed, 3 Feb 2010 05:29:43 -0800 (PST) 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 Av6YJohLM3xC for ; Wed, 3 Feb 2010 05:29:42 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id CA4AB3A687E for ; Wed, 3 Feb 2010 05:29:42 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 5FAE580FAB for ; Wed, 3 Feb 2010 05:30:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: <20100202114943.98FA7F580BE@smtp.patriot.net> Date: Wed, 3 Feb 2010 05:30:24 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20100202114943.98FA7F580BE@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] [MARF] Drop boxes 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: Wed, 03 Feb 2010 13:29:44 -0000 On Feb 2, 2010, at 4:00 AM, Shmuel (Seymour J.) Metz wrote: > The draft is unclear as to whether it applies to reporting of drop boxes > (either mail boxes or URI's) in abusive e-mail. I believe that there > should be some optional fields relating to such reports, assuming that > MARF is applicable. These might include both URI's in the spam and > redirections. It is supported in the ARF format (Reported-URI). Whether a particular ARF creator and consumer use it in that way is covered by the agreement between them. Cheers, Steve From yakov@shaftek.org Wed Feb 3 07:46:52 2010 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 18B4E3A6C53 for ; Wed, 3 Feb 2010 07:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 lOYz3hzsqRzS for ; Wed, 3 Feb 2010 07:46:51 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BB22F3A6C50 for ; Wed, 3 Feb 2010 07:46:50 -0800 (PST) Received: by wwa36 with SMTP id 36so141454wwa.31 for ; Wed, 03 Feb 2010 07:47:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.162.68 with SMTP id x46mr108065wek.2.1265212049722; Wed, 03 Feb 2010 07:47:29 -0800 (PST) In-Reply-To: <20100202114939.B90C0F580BF@smtp.patriot.net> References: <20100202114939.B90C0F580BF@smtp.patriot.net> From: Yakov Shafranovich Date: Wed, 3 Feb 2010 10:47:09 -0500 Message-ID: <501c18e01002030747y2c43a4ado924ffc09c4e52f38@mail.gmail.com> To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] [MARF] Additional MIME subparts 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: Wed, 03 Feb 2010 15:46:52 -0000 This standard is based off RFC 3462 which is limited to three MIME parts: first for human readable, second for machine readable, and third for the actual message. This keeps the standard simple. Before unraveling that, perhaps you can provide some use cases where it would be necessary to have more than one MIME subpart? Additionally, as stated in the draft, the standard is focused on one message/one report paradigm. It does not support reporting for multiple messages in a single ARF report, this is out of scope. Third, as I mentioned once before, the logic behind the MIME fields in the middle section is as follows - the enclosed spam message constitutes prima facie or self evident evidence of the spam or virus occurrence. The fields in the middle section contain data that cannot be easily derived from the original spam message such as "Source-IP" which may not be included in the "Received" headers, "Original-Mail-From" which is part of the SMTP transaction. The fields "Reported-Domain" and "Reported-URI" are used to indicate to the receiver which specific data within the message triggered the report. Again, this is not data easily derived from the message itself since it requires knowledge of what the originating system did. Yakov On Tue, Feb 2, 2010 at 7:00 AM, Shmuel Metz wrote: > I'd like to see provision for additional MIME parts of multipart/report; > report-type=3Dfeedback-report. Specifically, I'd like to relegate support= ing > documentation[1] to a separate MIME part. I'd also like for those > additional part to be identified by, e.g., their MIME type, rather than b= y > their position withing the multipart/report. Finally, I'd like an IETF > registry of the defined additional parts. If the group concurs, "4. > Extensibility" should discuss the new registry. > > [1] E.g., whois data. Note that while in theory the provider could do > =A0 =A0his own, e.g., traceroute, relevant data might have changed in > =A0 =A0the intervening period. > > -- > =A0 =A0 Shmuel (Seymour J.) Metz, SysProg and JOAT > =A0 =A0 Atid/2 =A0 =A0 =A0 =A0 > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) > > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From yakov@shaftek.org Wed Feb 3 07:48:41 2010 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 608C23A6C0A for ; Wed, 3 Feb 2010 07:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ym3DBpxa+12K for ; Wed, 3 Feb 2010 07:48:40 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 68AB73A67BD for ; Wed, 3 Feb 2010 07:48:40 -0800 (PST) Received: by fxm7 with SMTP id 7so1703041fxm.28 for ; Wed, 03 Feb 2010 07:49:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.85.9 with SMTP id t9mr2025393wee.79.1265212159131; Wed, 03 Feb 2010 07:49:19 -0800 (PST) From: Yakov Shafranovich Date: Wed, 3 Feb 2010 10:48:59 -0500 Message-ID: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [marf] Reported-Domain vs Reported-URI 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: Wed, 03 Feb 2010 15:48:41 -0000 Question: The current draft has both Reported-Domain and Reported-URI included. As per RFC 4501, there is a URI syntax used for domain names. For example: dns:www.example.org Even specific DNS records can be pointed to like: dns://192.168.1.1/ftp.example.org?type=A Do we need both fields? Yakov From yakov@shaftek.org Wed Feb 3 07:57:22 2010 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 43DE128C163 for ; Wed, 3 Feb 2010 07:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_83=0.6] 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 xXigLNH7XqT0 for ; Wed, 3 Feb 2010 07:57:18 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 196653A6C6B for ; Wed, 3 Feb 2010 07:57:17 -0800 (PST) Received: by fxm7 with SMTP id 7so1713822fxm.28 for ; Wed, 03 Feb 2010 07:57:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.91.81 with SMTP id g59mr526320wef.128.1265212676269; Wed, 03 Feb 2010 07:57:56 -0800 (PST) In-Reply-To: <20100202103934.90D0CF580BE@smtp.patriot.net> References: <20100202103934.90D0CF580BE@smtp.patriot.net> From: Yakov Shafranovich Date: Wed, 3 Feb 2010 10:57:36 -0500 Message-ID: <501c18e01002030757s2d145fbcpa0fb609e3f7db299@mail.gmail.com> To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] draft-ietf-marf-base-00 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: Wed, 03 Feb 2010 15:57:22 -0000 On Tue, Feb 2, 2010 at 5:49 AM, Shmuel Metz wrote: > In > , > on 02/01/2010 > =A0 at 11:38 AM, "Murray S. Kucherawy" said: > >>In particular, is there consensus on this text? > > My only issue is grammar > > c/has been/have been/ > > OTOH, if we are to allow redacting then I would like to see some standard > way of indicating that the data have been redacted, and I would like the > use of it to be a MUST. Perhaps a new parameter: multipart/report; > report-type=3Dfeedback-report; redacted=3Dyes. > We discussed this a few weeks ago and the consensus seems to be that such flag is useless. From msk@cloudmark.com Wed Feb 3 09:41:40 2010 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 AE15928C16D for ; Wed, 3 Feb 2010 09:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599] 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 y6f0eTtCIEGw for ; Wed, 3 Feb 2010 09:41:40 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 10FE428C0E3 for ; Wed, 3 Feb 2010 09:41:40 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 3 Feb 2010 09:42:23 -0800 From: "Murray S. Kucherawy" To: Yakov Shafranovich , "marf@ietf.org" Date: Wed, 3 Feb 2010 09:42:22 -0800 Thread-Topic: [marf] Reported-Domain vs Reported-URI Thread-Index: Acqk6HaqeKqmY0mVQo6Q5O2JJ2VDsgAD0p9A Message-ID: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> In-Reply-To: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 03 Feb 2010 17:41:40 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Yakov Shafranovich > Sent: Wednesday, February 03, 2010 7:49 AM > To: marf@ietf.org > Subject: [marf] Reported-Domain vs Reported-URI >=20 > Question: >=20 > The current draft has both Reported-Domain and Reported-URI included. > As per RFC 4501, there is a URI syntax used for domain names. For > example: >=20 > dns:www.example.org >=20 > Even specific DNS records can be pointed to like: >=20 > dns://192.168.1.1/ftp.example.org?type=3DA >=20 > Do we need both fields? [as participant] If we take the perspective that the base draft primarily documents existing= practice, then we should include both only so that compatibility with exis= ting implementations is maintained. But strictly from a standards perspective, I believe it is indeed redundant= . We could note the redundancy explicitly, and explain why it was included an= yway. But one interesting point is that RFC4501 isn't referenced by the base draf= t. Should we add such a reference, or is simply referring to the base URI = RFC sufficient? From msk@cloudmark.com Wed Feb 3 09:44:10 2010 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 9EDA73A6C80 for ; Wed, 3 Feb 2010 09:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599] 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 JYxnO995D5V6 for ; Wed, 3 Feb 2010 09:44:10 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 0FD433A6A7F for ; Wed, 3 Feb 2010 09:44:10 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 3 Feb 2010 09:44:53 -0800 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Wed, 3 Feb 2010 09:44:52 -0800 Thread-Topic: [marf] draft-ietf-marf-base-00 Thread-Index: Acqj5hF2tRdCRbUCQHGeBtnIhblR0gBEnRhA Message-ID: References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> <4B67E97A.5080306@tana.it> In-Reply-To: <4B67E97A.5080306@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] draft-ietf-marf-base-00 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: Wed, 03 Feb 2010 17:44:10 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Tuesday, February 02, 2010 1:00 AM > To: marf@ietf.org > Subject: Re: [marf] draft-ietf-marf-base-00 >=20 > * opt-out: this Feedback-Type has been removed, but it is still > present in the examples and in the Removal-Recipient field name. Thanks; removed. From msk@cloudmark.com Wed Feb 3 09:47:49 2010 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 A2B4E28C0E3 for ; Wed, 3 Feb 2010 09:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599] 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 ii5dwp8+r7xg for ; Wed, 3 Feb 2010 09:47:38 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 041EF3A6C94 for ; Wed, 3 Feb 2010 09:47:36 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 3 Feb 2010 09:48:19 -0800 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Wed, 3 Feb 2010 09:48:18 -0800 Thread-Topic: [marf] draft-ietf-marf-base-00 Thread-Index: Acqkt2ElDMp2cWaHSvWKOmtYSrVHbAAQaF9w Message-ID: References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> <4B67E97A.5080306@tana.it> <4B6948A8.6050304@tana.it> In-Reply-To: <4B6948A8.6050304@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [marf] draft-ietf-marf-base-00 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: Wed, 03 Feb 2010 17:47:49 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtYXJmLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzptYXJmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBBbGVzc2Fu ZHJvIFZlc2VseQ0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDAzLCAyMDEwIDE6NTggQU0N Cj4gVG86IG1hcmZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttYXJmXSBkcmFmdC1pZXRmLW1h cmYtYmFzZS0wMA0KPiANCj4gIlRlc3QiIGlzIG11Y2ggY2xlYXJlciB0aGFuICJub24tc3BhbSIg b3IgIm90aGVyIiBmb3IgdGhpcyB1c2FnZS4gQW0gSQ0KPiB0aGUgb25seSBvbmUgd2hvIHdvdWxk IHVzZSBpdD8NCg0KV2hhdCBkbyBleGlzdGluZyBGQkwgb3BlcmF0b3JzIGRvIGluIHRlcm1zIG9m IHRlc3RpbmcgYSBuZXcgRkJMPw0KDQo= From yakov@shaftek.org Wed Feb 3 09:52:40 2010 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 B6C6A3A6961 for ; Wed, 3 Feb 2010 09:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 IHyAgxI81yRX for ; Wed, 3 Feb 2010 09:52:39 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 1D9CF3A6958 for ; Wed, 3 Feb 2010 09:52:37 -0800 (PST) Received: by ewy28 with SMTP id 28so1723874ewy.28 for ; Wed, 03 Feb 2010 09:53:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.90.133 with SMTP id e5mr320586wef.23.1265219596585; Wed, 03 Feb 2010 09:53:16 -0800 (PST) In-Reply-To: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> From: Yakov Shafranovich Date: Wed, 3 Feb 2010 12:52:56 -0500 Message-ID: <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 03 Feb 2010 17:52:40 -0000 On Wed, Feb 3, 2010 at 12:42 PM, Murray S. Kucherawy wr= ote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of >> Yakov Shafranovich >> Sent: Wednesday, February 03, 2010 7:49 AM >> To: marf@ietf.org >> Subject: [marf] Reported-Domain vs Reported-URI >> >> Question: >> >> The current draft has both Reported-Domain and Reported-URI included. >> As per RFC 4501, there is a URI syntax used for domain names. For >> example: >> >> dns:www.example.org >> >> Even specific DNS records can be pointed to like: >> >> dns://192.168.1.1/ftp.example.org?type=3DA >> >> Do we need both fields? > > [as participant] > > If we take the perspective that the base draft primarily documents existi= ng practice, then we should include both only so that compatibility with ex= isting implementations is maintained. > > But strictly from a standards perspective, I believe it is indeed redunda= nt. > > We could note the redundancy explicitly, and explain why it was included = anyway. > > But one interesting point is that RFC4501 isn't referenced by the base dr= aft. =A0Should we add such a reference, or is simply referring to the base = URI RFC sufficient? > I didn't reference any of the URI RFCs, the assumption is that people will use the URI registry. Perhaps we should add a blurb referencing the registry like this: "Implementors should be aware that the Reported-URI field can carry many different types of data depending on the URI scheme used. For more information, please consult the URI registry maintained by IANA [http://www.iana.org/assignments/uri-schemes.html]. Furthermore, it is outside the scope of this standard whether the data carried in this field implies any additional information. Implementors may negotiate their own agreements surrounding the interpretation of this data" Yakov From msk@cloudmark.com Wed Feb 3 09:54:37 2010 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 B86E73A6C9B for ; Wed, 3 Feb 2010 09:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599] 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 OfQS7+Nar0oe for ; Wed, 3 Feb 2010 09:54:37 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 0AB853A6A7F for ; Wed, 3 Feb 2010 09:54:37 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 3 Feb 2010 09:55:20 -0800 From: "Murray S. Kucherawy" To: Yakov Shafranovich Date: Wed, 3 Feb 2010 09:55:19 -0800 Thread-Topic: [marf] Reported-Domain vs Reported-URI Thread-Index: Acqk+cS3C50Vb4UDRyqpFpAQsetvAQAACBYA Message-ID: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> In-Reply-To: <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 03 Feb 2010 17:54:37 -0000 > -----Original Message----- > From: Yakov Shafranovich [mailto:yakov@shaftek.org] > Sent: Wednesday, February 03, 2010 9:53 AM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: Re: [marf] Reported-Domain vs Reported-URI >=20 > I didn't reference any of the URI RFCs, the assumption is that people > will use the URI registry. Perhaps we should add a blurb referencing > the registry like this: I think pre-WG, when I added the ABNF I added a reference to the basic URI = RFC, namely RFC3986. It appears as a normative reference in the current dr= aft. > "Implementors should be aware that the Reported-URI field can carry > many different types of data depending on the URI scheme used. For > more information, please consult the URI registry maintained by IANA > [http://www.iana.org/assignments/uri-schemes.html]. >=20 > Furthermore, it is outside the scope of this standard whether the data > carried in this field implies any additional information. Implementors > may negotiate their own agreements surrounding the interpretation of > this data" Any +/- 1s for this text? From jdfalk-lists@cybernothing.org Wed Feb 3 12:17:35 2010 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 024AF3A68C6 for ; Wed, 3 Feb 2010 12:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.649 X-Spam-Level: X-Spam-Status: No, score=-6.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 Nwf4uzjWQBUm for ; Wed, 3 Feb 2010 12:17:34 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 16FB63A68C0 for ; Wed, 3 Feb 2010 12:17:31 -0800 (PST) Received: from jds-macbook.rpcorp.local (np60.co.returnpath.net [38.109.196.60]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o13KIB76031206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 3 Feb 2010 13:18:13 -0700 References: <20100202114939.B90C0F580BF@smtp.patriot.net> <61D4D112-C749-4419-AB92-861687025248@wordtothewise.com> In-Reply-To: <61D4D112-C749-4419-AB92-861687025248@wordtothewise.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <8520B916-E3DD-456A-B2F8-E8B93ADA6284@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Wed, 3 Feb 2010 13:18:05 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] [MARF] Additional MIME subparts 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: Wed, 03 Feb 2010 20:17:35 -0000 On Feb 3, 2010, at 6:11 AM, Steve Atkins wrote: > On Feb 2, 2010, at 4:00 AM, Shmuel (Seymour J.) Metz wrote: >=20 >> I'd like to see provision for additional MIME parts of = multipart/report; >> report-type=3Dfeedback-report. Specifically, I'd like to relegate = supporting >> documentation[1] to a separate MIME part. I'd also like for those >> additional part to be identified by, e.g., their MIME type, rather = than by >> their position withing the multipart/report. Finally, I'd like an = IETF >> registry of the defined additional parts. If the group concurs, "4.=20= >> Extensibility" should discuss the new registry. >>=20 >> [1] E.g., whois data. Note that while in theory the provider could do >> his own, e.g., traceroute, relevant data might have changed in >> the intervening period. >=20 > If you want to add unstructured data (with the understanding that > it's fairly unlikely it'll ever be read) there's already a place for = that - > the first, probably text/plain, MIME part. Agreed. I don't see much value in adding a new part for data that can't = be automatically parsed when we already have one designated for that = purpose. -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Wed Feb 3 12:21:07 2010 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 A07373A6A3C for ; Wed, 3 Feb 2010 12:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.632 X-Spam-Level: X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 ra4aOlkEh84d for ; Wed, 3 Feb 2010 12:21:06 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 9C7703A6978 for ; Wed, 3 Feb 2010 12:21:06 -0800 (PST) Received: from jds-macbook.rpcorp.local (np60.co.returnpath.net [38.109.196.60]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o13KLl6R031268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 3 Feb 2010 13:21:49 -0700 References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> <4B674244.3090303@corp.aol.com> In-Reply-To: <4B674244.3090303@corp.aol.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Wed, 3 Feb 2010 13:21:42 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] draft-ietf-marf-base-00 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: Wed, 03 Feb 2010 20:21:07 -0000 On Feb 1, 2010, at 2:06 PM, Michael Adkins wrote: >>> I'd be fine with dropping the second paragraph, but the first will = probably require some wordsmithing as a result. How about: >>>=20 >>>=20 >>> The sending of these reports will reveal possibly private = information about the person sending the report. For example, such as a = report sent in response to a mailing list posting will reveal to the = report recipient a valid email address on the list that might otherwise = have remained hidden. >>>=20 >>> For this reason, report generators may wish to redact portions of = the report to conceal private information. Doing so may be necessary = where privacy trumps operational necessity, but as mentioned in (section = back-reference) it may impede a timely or meaningful response from the = report recipient. >>>=20 >>=20 >> Much better, yes. It gets the message across nicely without = exaggerating the issue. >>=20 > +1 +1 -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Wed Feb 3 12:26:23 2010 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 1BDF83A6CE4 for ; Wed, 3 Feb 2010 12:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.624 X-Spam-Level: X-Spam-Status: No, score=-6.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 sWgdnnp8PmJu for ; Wed, 3 Feb 2010 12:26:22 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 3BBA43A6C42 for ; Wed, 3 Feb 2010 12:26:22 -0800 (PST) Received: from jds-macbook.rpcorp.local (np60.co.returnpath.net [38.109.196.60]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o13KR2BU031319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 3 Feb 2010 13:27:05 -0700 References: <4181A8C5-40AA-4B8D-A290-8441D78B3C4B@wordtothewise.com> <4B67E97A.5080306@tana.it> <4B6948A8.6050304@tana.it> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <32981EAC-A1FE-46F7-8D2B-81718B30F70C@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Wed, 3 Feb 2010 13:26:56 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] draft-ietf-marf-base-00 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: Wed, 03 Feb 2010 20:26:23 -0000 On Feb 3, 2010, at 10:48 AM, Murray S. Kucherawy wrote: > What do existing FBL operators do in terms of testing a new FBL? We test interoperability using live data. New ARF generators don't crop up so often that a test flag would seem = necessary. I'm not vehemently opposed to it, but I doubt we'd ever = implement it. -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Wed Feb 3 12:29:29 2010 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 E572C28C1AB for ; Wed, 3 Feb 2010 12:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 ToMfRd87JW2J for ; Wed, 3 Feb 2010 12:29:27 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 16CA03A6CF5 for ; Wed, 3 Feb 2010 12:29:27 -0800 (PST) Received: from jds-macbook.rpcorp.local (np60.co.returnpath.net [38.109.196.60]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o13KU41j031370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 3 Feb 2010 13:30:07 -0700 References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <50BE0D9D-EDD5-47CC-9B28-B298C80BF370@cybernothing.org> Content-Transfer-Encoding: 7bit From: "J.D. Falk" Date: Wed, 3 Feb 2010 13:29:59 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 03 Feb 2010 20:29:29 -0000 On Feb 3, 2010, at 10:55 AM, Murray S. Kucherawy wrote: >> "Implementors should be aware that the Reported-URI field can carry >> many different types of data depending on the URI scheme used. For >> more information, please consult the URI registry maintained by IANA >> [http://www.iana.org/assignments/uri-schemes.html]. >> >> Furthermore, it is outside the scope of this standard whether the data >> carried in this field implies any additional information. Implementors >> may negotiate their own agreements surrounding the interpretation of >> this data" > > Any +/- 1s for this text? +1 -- J.D. Falk Return Path Inc From shmuel+gen@patriot.net Wed Feb 3 17:05:11 2010 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 0427A3A6856 for ; Wed, 3 Feb 2010 17:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=1.338, BAYES_00=-2.599] 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 iYN40VXYI22i for ; Wed, 3 Feb 2010 17:05:10 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 19B183A67E3 for ; Wed, 3 Feb 2010 17:05:09 -0800 (PST) Received: from ECS35455305 (core-dc-1-227.dynamic-dialup.coretel.net [69.72.26.227]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id CA681F5809B for ; Wed, 3 Feb 2010 19:55:43 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 03 Feb 2010 20:07:06 -0500 To: marf@ietf.org In-Reply-To: <501c18e01002030747y2c43a4ado924ffc09c4e52f38@mail.gmail.com> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100204005543.CA681F5809B@smtp.patriot.net> Subject: Re: [marf] [MARF] Additional MIME subparts X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 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, 04 Feb 2010 01:05:11 -0000 In <501c18e01002030747y2c43a4ado924ffc09c4e52f38@mail.gmail.com>, on 02/03/2010 at 10:47 AM, Yakov Shafranovich said: >Additionally, as stated in the draft, the standard is focused on one >message/one report paradigm. As was my suggestion. >The fields in the middle section contain data that cannot >be easily derived from the original spam message such as "Source-IP" >which may not be included in the "Received" headers, Traces and such at the time of the spam may not be reproducible if there are, e.g., subsequent DNS changes. The intent was to provide a mechanism for giving point in time evidence. The second section of the report does not provide for that. -- 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 yakov@shaftek.org Wed Feb 3 17:06:49 2010 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 C87793A6856 for ; Wed, 3 Feb 2010 17:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ncHWIasKGlab for ; Wed, 3 Feb 2010 17:06:49 -0800 (PST) Received: from mail-ew0-f222.google.com (mail-ew0-f222.google.com [209.85.219.222]) by core3.amsl.com (Postfix) with ESMTP id DD2E83A67E3 for ; Wed, 3 Feb 2010 17:06:48 -0800 (PST) Received: by ewy22 with SMTP id 22so80420ewy.14 for ; Wed, 03 Feb 2010 17:07:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.90.7 with SMTP id d7mr223587wef.81.1265245649172; Wed, 03 Feb 2010 17:07:29 -0800 (PST) In-Reply-To: <20100204005543.CA681F5809B@smtp.patriot.net> References: <501c18e01002030747y2c43a4ado924ffc09c4e52f38@mail.gmail.com> <20100204005543.CA681F5809B@smtp.patriot.net> From: Yakov Shafranovich Date: Wed, 3 Feb 2010 20:07:09 -0500 Message-ID: <501c18e01002031707g79133f5ncbcbffc03aa202c9@mail.gmail.com> To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] [MARF] Additional MIME subparts 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, 04 Feb 2010 01:06:49 -0000 On Wed, Feb 3, 2010 at 8:07 PM, Shmuel Metz wrote: > In <501c18e01002030747y2c43a4ado924ffc09c4e52f38@mail.gmail.com>, on > 02/03/2010 > =A0 at 10:47 AM, Yakov Shafranovich said: > >>Additionally, as stated in the draft, the standard is focused on one >>message/one report paradigm. > > As was my suggestion. > >>The fields in the middle section contain data that cannot >>be easily derived from the original spam message such as "Source-IP" >>which may not be included in the "Received" headers, > > Traces and such at the time of the spam may not be reproducible if there > are, e.g., subsequent DNS changes. The intent was to provide a mechanism > for giving point in time evidence. The second section of the report does > not provide for that. > What sort of evidence do you have in mind? From barryleiba.mailing.lists@gmail.com Thu Feb 4 09:40:46 2010 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 7B3ED3A69F9 for ; Thu, 4 Feb 2010 09:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pivuuH+3iU1F for ; Thu, 4 Feb 2010 09:40:45 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4A7DB3A68FA for ; Thu, 4 Feb 2010 09:40:45 -0800 (PST) Received: by wwa36 with SMTP id 36so301613wwa.31 for ; Thu, 04 Feb 2010 09:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ekdQbLSsuc8SWuarp1Hz+AJww6+pXqRRCTnr/c10X34=; b=Eult+Xq+1TLCEe39yXg0NR9CaFhdrhSM7vUupFWirjT3tvQK16lmrzWiX+tLD6ReAX UB0g8vMZilLFndPp16RnTc07EsJc5TR3gVhlc+f40Cqmkvve8RRBloAhf1wdrlzWGUpK S6zvJU4QBlfF+vRvTkn1JhG7B+X3g7e+zvstQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=Iwz2ftztoKFY27yZDAki4bWsnJ/K8ctMwz7zsPWXpoogLCqvlbYOnVLtsAYeGwC5S2 TZZ/NcLtZHN1CWxYGy111rwutsJxOTVj81uT7mGrhn99XN+mhowTEjIbgbOzUmKb4gRY PAxPBSLxn2RVM/JVj7uO73d8Ik29l0xr0uLbk= MIME-Version: 1.0 Received: by 10.216.88.212 with SMTP id a62mr851949wef.72.1265305287991; Thu, 04 Feb 2010 09:41:27 -0800 (PST) In-Reply-To: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> Date: Thu, 4 Feb 2010 12:41:27 -0500 Message-ID: <6c9fcc2a1002040941j7689e662pd03299956673e3d4@mail.gmail.com> From: Barry Leiba To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [marf] Reported-Domain vs Reported-URI X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 17:40:46 -0000 >> "Implementors should be aware that the Reported-URI field can carry >> many different types of data depending on the URI scheme used. For >> more information, please consult the URI registry maintained by IANA >> [http://www.iana.org/assignments/uri-schemes.html]. >> >> Furthermore, it is outside the scope of this standard whether the data >> carried in this field implies any additional information. Implementors >> may negotiate their own agreements surrounding the interpretation of >> this data" > > Any +/- 1s for this text? +1, as participant. Also, as chair, I'll point this out: > If we take the perspective that the base draft primarily documents > existing practice, then we should include both only so that compatibility > with existing implementations is maintained. > > But strictly from a standards perspective, I believe it is indeed redundant. > > We could note the redundancy explicitly, and explain why it was included > anyway. The spec can certainly document existing practice while deprecating it. That would involve text that explains the redundancy, says that one of the items is now deprecated, and says that implementations SHOULD NOT generate the deprecated item. Barry From yakov@shaftek.org Thu Feb 4 09:43:18 2010 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 8805228C123 for ; Thu, 4 Feb 2010 09:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 A8gn4IltEUGE for ; Thu, 4 Feb 2010 09:43:17 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id A2FBF3A69F9 for ; Thu, 4 Feb 2010 09:43:17 -0800 (PST) Received: by ewy28 with SMTP id 28so3190254ewy.28 for ; Thu, 04 Feb 2010 09:44:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.87.7 with SMTP id x7mr798657wee.53.1265305441231; Thu, 04 Feb 2010 09:44:01 -0800 (PST) In-Reply-To: <6c9fcc2a1002040941j7689e662pd03299956673e3d4@mail.gmail.com> References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <6c9fcc2a1002040941j7689e662pd03299956673e3d4@mail.gmail.com> From: Yakov Shafranovich Date: Thu, 4 Feb 2010 12:43:41 -0500 Message-ID: <501c18e01002040943j1384c1a6tf73ffbb65776709f@mail.gmail.com> To: barryleiba@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 04 Feb 2010 17:43:18 -0000 On Thu, Feb 4, 2010 at 12:41 PM, Barry Leiba wrote: > Also, as chair, I'll point this out: >> If we take the perspective that the base draft primarily documents >> existing practice, then we should include both only so that compatibilit= y >> with existing implementations is maintained. >> >> But strictly from a standards perspective, I believe it is indeed redund= ant. >> >> We could note the redundancy explicitly, and explain why it was included >> anyway. > > The spec can certainly document existing practice while deprecating > it. =A0That would involve text that explains the redundancy, says that > one of the items is now deprecated, and says that implementations > SHOULD NOT generate the deprecated item. Do we have any proposed text for this? From msk@cloudmark.com Thu Feb 4 10:00:46 2010 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 E466C3A6C6E for ; Thu, 4 Feb 2010 10:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599] 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 WIxK20dnw-KS for ; Thu, 4 Feb 2010 10:00:46 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 481DD3A69F9 for ; Thu, 4 Feb 2010 10:00:43 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 4 Feb 2010 10:01:30 -0800 From: "Murray S. Kucherawy" To: Yakov Shafranovich , "barryleiba@computer.org" Date: Thu, 4 Feb 2010 10:01:30 -0800 Thread-Topic: [marf] Reported-Domain vs Reported-URI Thread-Index: AcqlwaasFofBdma6S6OVojg/f3MlyQAAlOxg Message-ID: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <6c9fcc2a1002040941j7689e662pd03299956673e3d4@mail.gmail.com> <501c18e01002040943j1384c1a6tf73ffbb65776709f@mail.gmail.com> In-Reply-To: <501c18e01002040943j1384c1a6tf73ffbb65776709f@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 04 Feb 2010 18:00:47 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Yakov Shafranovich > Sent: Thursday, February 04, 2010 9:44 AM > To: barryleiba@computer.org > Cc: marf@ietf.org > Subject: Re: [marf] Reported-Domain vs Reported-URI >=20 > > The spec can certainly document existing practice while deprecating > > it. =A0That would involve text that explains the redundancy, says that > > one of the items is now deprecated, and says that implementations > > SHOULD NOT generate the deprecated item. >=20 > Do we have any proposed text for this? ...and is there consensus that we should deprecate Reported-Domain? From vesely@tana.it Fri Feb 5 02:54:15 2010 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 693433A69B6 for ; Fri, 5 Feb 2010 02:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.712 X-Spam-Level: X-Spam-Status: No, score=-4.712 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6piZrDpAnLY for ; Fri, 5 Feb 2010 02:54:14 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 419653A677D for ; Fri, 5 Feb 2010 02:54:14 -0800 (PST) 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, 05 Feb 2010 11:55:03 +0100 id 00000000005DC02F.000000004B6BF907.000050A8 Message-ID: <4B6BF907.1070906@tana.it> Date: Fri, 05 Feb 2010 11:55:03 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> In-Reply-To: <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 05 Feb 2010 10:54:15 -0000 On 03/Feb/10 18:52, Yakov Shafranovich wrote: > I didn't reference any of the URI RFCs, the assumption is that people > will use the URI registry. Perhaps we should add a blurb referencing > the registry like this: > > "Implementors should be aware that the Reported-URI field can carry > many different types of data depending on the URI scheme used. For > more information, please consult the URI registry maintained by IANA > [http://www.iana.org/assignments/uri-schemes.html]. > > Furthermore, it is outside the scope of this standard whether the data > carried in this field implies any additional information. Implementors > may negotiate their own agreements surrounding the interpretation of > this data" While I like the first paragraph, the 2nd one adds to the concept that the semantics of ARF data may vary widely. Shouldn't we try to promote an unambiguous meaning of each field? My understanding, based on previous discussions, is that Reported-Domain is the mail domain responsible for sending the purported spam, while Reported-URI is a spamvertized mailbox (e.g. Reply-To) or web page whose monitoring is being requested. If that's correct, I'd see no reason for eliminating any of them. From shmuel+gen@patriot.net Fri Feb 5 05:57:41 2010 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 7A80728C171 for ; Fri, 5 Feb 2010 05:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219] 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 cL82aw6SR2q1 for ; Fri, 5 Feb 2010 05:57:40 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 8413028C15A for ; Fri, 5 Feb 2010 05:57:40 -0800 (PST) Received: from ECS35455305 (core-dc-1-247.dynamic-dialup.coretel.net [69.72.26.247]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 42179F580A3 for ; Fri, 5 Feb 2010 08:48:17 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 03 Feb 2010 20:13:29 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100205134818.42179F580A3@smtp.patriot.net> Subject: Re: [marf] [MARF] Drop boxes X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 13:57:41 -0000 In , on 02/03/2010 at 05:30 AM, Steve Atkins said: >It is supported in the ARF format (Reported-URI). Well, the example given for that in the text is "e.g. a URI to which the report recipient can go for further details." -- 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 dotis@mail-abuse.org Fri Feb 5 08:24:08 2010 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 455DB3A6D53 for ; Fri, 5 Feb 2010 08:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qpcasSrxKJYN for ; Fri, 5 Feb 2010 08:24:07 -0800 (PST) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 2871E3A6D4E for ; Fri, 5 Feb 2010 08:24:07 -0800 (PST) Received: from US-DOUGLASO-MB.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id D0464A9465E for ; Fri, 5 Feb 2010 16:24:50 +0000 (UTC) Message-ID: <4B6C4651.6020106@mail-abuse.org> Date: Fri, 05 Feb 2010 08:24:49 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> In-Reply-To: <4B6BF907.1070906@tana.it> Content-Type: multipart/alternative; boundary="------------000603080103020600070602" Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 05 Feb 2010 16:24:08 -0000 This is a multi-part message in MIME format. --------------000603080103020600070602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/5/10 2:55 AM, Alessandro Vesely wrote: > On 03/Feb/10 18:52, Yakov Shafranovich wrote: >> I didn't reference any of the URI RFCs, the assumption is that people >> will use the URI registry. Perhaps we should add a blurb referencing >> the registry like this: >> >> "Implementors should be aware that the Reported-URI field can carry >> many different types of data depending on the URI scheme used. For >> more information, please consult the URI registry maintained by IANA >> [http://www.iana.org/assignments/uri-schemes.html]. >> >> Furthermore, it is outside the scope of this standard whether the data >> carried in this field implies any additional information. Implementors >> may negotiate their own agreements surrounding the interpretation of >> this data" > > While I like the first paragraph, the 2nd one adds to the concept that > the semantics of ARF data may vary widely. Shouldn't we try to promote > an unambiguous meaning of each field? > > My understanding, based on previous discussions, is that > Reported-Domain is the mail domain responsible for sending the > purported spam, while Reported-URI is a spamvertized mailbox (e.g. > Reply-To) or web page whose monitoring is being requested. If that's > correct, I'd see no reason for eliminating any of them. +1 --------------000603080103020600070602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/5/10 2:55 AM, Alessandro Vesely wrote:
On 03/Feb/10 18:52, Yakov Shafranovich wrote:
I didn't reference any of the URI RFCs, the assumption is that people
will use the URI registry. Perhaps we should add a blurb referencing
the registry like this:

"Implementors should be aware that the Reported-URI field can carry
many different types of data depending on the URI scheme used. For
more information, please consult the URI registry maintained by IANA
[http://www.iana.org/assignments/uri-schemes.html].

Furthermore, it is outside the scope of this standard whether the data
carried in this field implies any additional information. Implementors
may negotiate their own agreements surrounding the interpretation of
this data"

While I like the first paragraph, the 2nd one adds to the concept that the semantics of ARF data may vary widely. Shouldn't we try to promote an unambiguous meaning of each field?

My understanding, based on previous discussions, is that Reported-Domain is the mail domain responsible for sending the purported spam, while Reported-URI is a spamvertized mailbox (e.g. Reply-To) or web page whose monitoring is being requested. If that's correct, I'd see no reason for eliminating any of them.
+1


--------------000603080103020600070602-- From yakov@shaftek.org Fri Feb 5 08:30:07 2010 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 29EC13A6F28 for ; Fri, 5 Feb 2010 08:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Fgpp7zyuDvmr for ; Fri, 5 Feb 2010 08:30:05 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 1E7D23A6F2C for ; Fri, 5 Feb 2010 08:30:04 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so303780fgb.13 for ; Fri, 05 Feb 2010 08:30:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.91.66 with SMTP id g44mr1536110wef.121.1265387452310; Fri, 05 Feb 2010 08:30:52 -0800 (PST) In-Reply-To: <4B6BF907.1070906@tana.it> References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> From: Yakov Shafranovich Date: Fri, 5 Feb 2010 11:30:32 -0500 Message-ID: <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Cc: marf@ietf.org Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 05 Feb 2010 16:30:07 -0000 On Fri, Feb 5, 2010 at 5:55 AM, Alessandro Vesely wrote: > On 03/Feb/10 18:52, Yakov Shafranovich wrote: >> >> I didn't reference any of the URI RFCs, the assumption is that people >> will use the URI registry. Perhaps we should add a blurb referencing >> the registry like this: >> >> "Implementors should be aware that the Reported-URI field can carry >> many different types of data depending on the URI scheme used. For >> more information, please consult the URI registry maintained by IANA >> [http://www.iana.org/assignments/uri-schemes.html]. >> >> Furthermore, it is outside the scope of this standard whether the data >> carried in this field implies any additional information. Implementors >> may negotiate their own agreements surrounding the interpretation of >> this data" > > While I like the first paragraph, the 2nd one adds to the concept that the > semantics of ARF data may vary widely. Shouldn't we try to promote an > unambiguous meaning of each field? > > My understanding, based on previous discussions, is that Reported-Domain is > the mail domain responsible for sending the purported spam, while > Reported-URI is a spamvertized mailbox (e.g. Reply-To) or web page whose > monitoring is being requested. If that's correct, I'd see no reason for > eliminating any of them. Some senders and receivers interpret "Reported-Domain" as a domain that was advertised within the message. From shmuel+gen@patriot.net Fri Feb 5 14:10:19 2010 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 8011628C169 for ; Fri, 5 Feb 2010 14:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 TykF4wcHOAGi for ; Fri, 5 Feb 2010 14:10:17 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 7079328C166 for ; Fri, 5 Feb 2010 14:10:17 -0800 (PST) Received: from ECS35455305 (core-dc-1-150.dynamic-dialup.coretel.net [69.72.26.150]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id B2A19F5809A for ; Fri, 5 Feb 2010 17:00:54 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Fri, 05 Feb 2010 11:00:57 -0500 To: marf@ietf.org In-Reply-To: <501c18e01002031707g79133f5ncbcbffc03aa202c9@mail.gmail.com> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100205220055.B2A19F5809A@smtp.patriot.net> Subject: Re: [marf] [MARF] Additional MIME subparts X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 22:10:19 -0000 In <501c18e01002031707g79133f5ncbcbffc03aa202c9@mail.gmail.com>, on 02/03/2010 at 08:07 PM, Yakov Shafranovich said: >What sort of evidence do you have in mind? Output from dig, nslookup, tracerte and whois. Redirection. I've seen posts in the past about situations where the evidence at the time of abuse was not reproducible even a day later. -- 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@taugh.com Fri Feb 5 14:25:39 2010 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 EBC103A6E35 for ; Fri, 5 Feb 2010 14:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.128 X-Spam-Level: X-Spam-Status: No, score=-19.128 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8] 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 9N+sUp6E0XG7 for ; Fri, 5 Feb 2010 14:25:38 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id A05773A6B10 for ; Fri, 5 Feb 2010 14:25:38 -0800 (PST) Received: (qmail 79555 invoked from network); 5 Feb 2010 22:26:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=cjxntOBMTRladDg/HSMzIJyKTM566bltnrraYbba0Fc=; b=LQSz7XRVp+Ap2mEBgMq5ZPOI+tO96rb4ut1+hFtXYOTV4p1Oh5Qucykx43iXC4X9lLA9T1pWgSzs0Ou3wofnVM0lJrvAIMPh9IDgrY3V3n5jm7sdaVIhk9YPH1iyWWhiIXa8s9DDlcZVtWPCO4ksdhCa2RXNJhMyu0L5qJx68bI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=cjxntOBMTRladDg/HSMzIJyKTM566bltnrraYbba0Fc=; b=nseRrwTKSUgtK16JQ+L/sxCybVID6MdWgPCWCrVEKVk3d0p6dczhEc9KhnzLTs8x7SqFvDXpB0fBIK2Gmapnc48OldlN5MGyB3oHBvXYhC9b59GXE7sj6HXxHsMtcZxzI7dAsCp9mnK1JocXt48eIryIqem7pHYodkMm6bRwhUs= Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 5 Feb 2010 22:26:07 -0000 Date: 5 Feb 2010 17:26:28 -0500 Message-ID: From: "John R Levine" To: "Message Abuse Report Format working group" In-Reply-To: <20100205220055.B2A19F5809A@smtp.patriot.net> References: <20100205220055.B2A19F5809A@smtp.patriot.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [marf] [MARF] Additional MIME subparts 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, 05 Feb 2010 22:25:40 -0000 >> What sort of evidence do you have in mind? > > Output from dig, nslookup, tracerte and whois. Redirection. I've seen > posts in the past about situations where the evidence at the time of abuse > was not reproducible even a day later. Why wouldn't you put that in the initial plain text section? I don't think it's plausible to try to define a parsed container format for every possible bit of evidence. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From steve@wordtothewise.com Fri Feb 5 14:32:22 2010 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 771053A6F94 for ; Fri, 5 Feb 2010 14:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xECvRFbnFglR for ; Fri, 5 Feb 2010 14:32:21 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id D48523A6F93 for ; Fri, 5 Feb 2010 14:32:21 -0800 (PST) Received: from [192.168.1.108] (adsl-99-180-47-182.dsl.pltn13.sbcglobal.net [99.180.47.182]) by m.wordtothewise.com (Postfix) with ESMTP id DA5924F8593 for ; Fri, 5 Feb 2010 14:33:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Fri, 5 Feb 2010 14:33:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7363583F-E5F9-40B1-A82E-D60629C07AE3@wordtothewise.com> References: <20100205220055.B2A19F5809A@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] [MARF] Additional MIME subparts 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, 05 Feb 2010 22:32:22 -0000 On Feb 5, 2010, at 2:26 PM, John R Levine wrote: >>> What sort of evidence do you have in mind? >>=20 >> Output from dig, nslookup, tracerte and whois. Redirection. I've seen >> posts in the past about situations where the evidence at the time of = abuse >> was not reproducible even a day later. >=20 > Why wouldn't you put that in the initial plain text section? >=20 > I don't think it's plausible to try to define a parsed container = format for every possible bit of evidence. Or send it manually. ARF is intended for reports that are likely to be processed = mechanically, resulting from reports that are generated mechanically. If your report requires all that data to be of value, you're not = providing much added value by sending it in ARF format. If it doesn't, you = shouldn't be including that data. ARF isn't... optimal for unsolicited reports to role accounts in many respects. This is one of them. Cheers, Steve From steve@blighty.com Fri Feb 5 14:31:00 2010 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 A4CC03A6F93 for ; Fri, 5 Feb 2010 14:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3m5E4wzgP2E for ; Fri, 5 Feb 2010 14:30:59 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id DCE4C3A6F92 for ; Fri, 5 Feb 2010 14:30:59 -0800 (PST) Received: from [192.168.1.108] (adsl-99-180-47-182.dsl.pltn13.sbcglobal.net [99.180.47.182]) by m.wordtothewise.com (Postfix) with ESMTP id E82594F8591 for ; Fri, 5 Feb 2010 14:31:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Fri, 5 Feb 2010 14:31:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100205220055.B2A19F5809A@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Fri, 05 Feb 2010 14:53:27 -0800 Subject: Re: [marf] [MARF] Additional MIME subparts 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, 05 Feb 2010 22:31:00 -0000 On Feb 5, 2010, at 2:26 PM, John R Levine wrote: >>> What sort of evidence do you have in mind? >>=20 >> Output from dig, nslookup, tracerte and whois. Redirection. I've seen >> posts in the past about situations where the evidence at the time of = abuse >> was not reproducible even a day later. >=20 > Why wouldn't you put that in the initial plain text section? >=20 > I don't think it's plausible to try to define a parsed container = format for every possible bit of evidence. Or send it manually. ARF is intended for reports that are likely to be processed = mechanically, resulting from reports that are generated mechanically. If your report requires all that data to be of value, you're not = providing much added value by sending it in ARF format. If it doesn't, you = shouldn't be including that data. ARF isn't... optimal for unsolicited reports to role accounts in many respects. This is one of them. Cheers, Steve From yakov@shaftek.org Sat Feb 6 16:22:20 2010 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 AC3533A6E70 for ; Sat, 6 Feb 2010 16:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 nzzM1LXfcrdy for ; Sat, 6 Feb 2010 16:22:19 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 86EB73A68B0 for ; Sat, 6 Feb 2010 16:22:19 -0800 (PST) Received: by wwa36 with SMTP id 36so1072455wwa.31 for ; Sat, 06 Feb 2010 16:23:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.89.12 with SMTP id b12mr2619455wef.93.1265502192122; Sat, 06 Feb 2010 16:23:12 -0800 (PST) In-Reply-To: References: <20100205220055.B2A19F5809A@smtp.patriot.net> From: Yakov Shafranovich Date: Sat, 6 Feb 2010 19:22:52 -0500 Message-ID: <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com> To: John R Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: Message Abuse Report Format working group Subject: Re: [marf] [MARF] Additional MIME subparts 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: Sun, 07 Feb 2010 00:22:21 -0000 On Fri, Feb 5, 2010 at 5:26 PM, John R Levine wrote: >>> What sort of evidence do you have in mind? >> >> Output from dig, nslookup, tracerte and whois. Redirection. I've seen >> posts in the past about situations where the evidence at the time of abuse >> was not reproducible even a day later. > > Why wouldn't you put that in the initial plain text section? > > I don't think it's plausible to try to define a parsed container format for > every possible bit of evidence. > I think he is referring to a different issue - encapsulation. Being limited to three MIME parts, does not allow inclusion of files or binary data as an additional MIME part - like we do with regular email messages. From sm@resistor.net Sun Feb 7 10:57:53 2010 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 5FF1C28C10B for ; Sun, 7 Feb 2010 10:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] 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 OD8uiAqbJW3s for ; Sun, 7 Feb 2010 10:57:52 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 36EF428C104 for ; Sun, 7 Feb 2010 10:57:52 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4/8.14.4) with ESMTP id o17Iwddm019589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 7 Feb 2010 10:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1265569128; x=1265655528; bh=KGJ5PUQfs9+mC3fa36ab87SEqgKmeGrDALErZhAKHY0=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=RHEAU2qOiFDt0Bdt4MU1WJcm6pKhPG04Y3Au+DCbnX4R+0dEn76PzL/UtGh7CRhMv opFenUOIkQc/5Mo9HEK4nuFNt8BwQdtXZTc/VJzDu5KpuGLMMEjX4sqgGatqWgarq6 HFdRfDZOXDfvFjB21Mk2gsjQP4zUILKq8s4pbZSQ= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=c0SPL8FFB18wCjNYaVgSqKiCBgn5P2CVguGbBE1N/NubtP75EmUNUEQhCIcwK+6c5 Wys506U2EPs/p+Jr0JMDcPHsufckxMgUqqqWUV2lucsGEdZyzPwByAmWAfFgvwcCrRV 7ZTbg+vj8zsUCCcQUAkxgLj30jexHOfQK8eMNlU= Message-Id: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 07 Feb 2010 10:58:28 -0800 To: marf@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [marf] Comments on draft-ietf-marf-base-00 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: Sun, 07 Feb 2010 18:57:53 -0000 Hello, I read draft-ietf-marf-base-00. The comments below could be categorized as stylistic. In Section 1: "This memo seeks to define a standard extensible format by creating the "message/feedback-report" [MIME] type for these reports." The Abstract Section says that the "document defines an extensible format and MIME type". I suggest changing the "seeks to define" to "defines". "While there has been previous work in this area (e.g. [STRADS-BCP] and [ASRG-ABUSE]), none of them have yet been successful." The intended status of this document is Standards Track. There is an informative reference to "Crissman, G., "Proposed Spam Reporting BCP Document", May 2005." draft-shafranovich-feedback-report-05 had a URL for the document. It's a 404 now. There is an informative reference to "Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF), "Abuse Reporting Standards Subgroup oof the ASRG", May 2005." (oof is a typo). If this is to acknowledge the work, it could be moved to the appropriate section if this document has a better fate. In Section 1.2, there is a requirement that: "A copy of the original email message (both body and header) or the message header must be enclosed in order to allow the receiver to handle the report properly;" Is a copy of the original required for the receiver to handle the report properly? That sentence could be rephrased if this WG wants to allow redaction. In Section 1.3.2: "See [EMAIL-ARCH] for further discussion on e-mail system architecture." What does defining a format for abuse reporting have to do with this subsection? In Section 2: "The Subject header field of the feedback report SHOULD be the same as the included email message about which the report is being generated and MAY include only a typical forwarding prefix used by MUAs such as "FW:". (Many smaller operators using MUAs for abuse handling rely on the subject lines for processing.)" There is already a SHOULD. The "MAY include only" does not fit in well as a RFC 2119 requirement. The sentence could be split into two and explain that the subject can have a "FW:" prefix. In Section 3: "Although these fields have a syntax similar to those of mail message header fields, they are semantically distinct; hence they SHOULD NOT be repeated in the header area of the message containing the report." "Header area" is ill-defined. Can the fields be used in message headers? In Section 3.1: "The format of this field MUST follow section 14.43 of [HTTP]." I suggest having that reference as normative. In Section 3.2, there are references to DSN and SMTP. These are informative references in this document. In Section 4: "Any new required fields REQUIRE a new version of this specification to be published." It would be better to allow it be done through Standards Track documents. In Section 5.2: "The expert should be appointed by the Area Director for the Applications Area." Please let the IESG decide on the appointment. In Section 6.2, what is the "purported sender"? In Section 6.3: "Whenever an SMTP transaction is used to send an ARF message, the MAIL FROM command must use a NULL return address, i.e. "MAIL FROM:<>"." Is that a requirement? In Section 6.4: "It follows that any attack against the authentication methods supported by this document (and later amendments to it) is also a security consideration here." Please remove later amendments as a security consideration as it is not possible to tell what that will be. Regards, -sm From shmuel+gen@patriot.net Sun Feb 7 13:27:53 2010 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 5EA373A72A5 for ; Sun, 7 Feb 2010 13:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_40=-0.185, DATE_IN_PAST_06_12=1.069] 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 Ksr0YqXC2WcT for ; Sun, 7 Feb 2010 13:27:52 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 61B863A72A1 for ; Sun, 7 Feb 2010 13:27:52 -0800 (PST) Received: from ECS35455305 (core-dc-1-59.dynamic-dialup.coretel.net [69.72.26.59]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 67BFDF580A7 for ; Sun, 7 Feb 2010 16:32:12 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Sun, 07 Feb 2010 07:23:50 -0500 To: marf@ietf.org In-Reply-To: <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100207213213.67BFDF580A7@smtp.patriot.net> Subject: Re: [marf] [MARF] Additional MIME subparts X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 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, 07 Feb 2010 21:27:53 -0000 In <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com>, on 02/06/2010 at 07:22 PM, Yakov Shafranovich said: >I think he is referring to a different issue - encapsulation. Indeed. The results of, e.g., whois, often include non-ASCII data. Similar issues may exist for other types of evidence. I hadn't thought of the possible requirement to provide binary files, but that might also be an issue. -- 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@taugh.com Sun Feb 7 14:14:52 2010 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 57BE228C11B for ; Sun, 7 Feb 2010 14:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.446 X-Spam-Level: X-Spam-Status: No, score=-9.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RDNS_DYNAMIC=0.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 jSyx1qMaW2-k for ; Sun, 7 Feb 2010 14:14:51 -0800 (PST) Received: from gal.iecc.com (64.57.183.53.lightlink.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D60EB3A6816 for ; Sun, 7 Feb 2010 14:14:50 -0800 (PST) Received: (qmail 95251 invoked from network); 7 Feb 2010 22:15:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=/ll7hpWPLDABqiSZY0sPHxnI4UkUghpn9GMOL8WZBhk=; b=blKRudpHTBrksJMXSoYTp69lADzyviTQzM6jUskX5JnfHnw1DMkbDQ5HGkh8BTQDboPflx8GycikrGOVyJnVazDMjThG2u6TX9FIumF8YWpLtdVkitrM9j+fdYvCJ7kvf/zzTBEeMz9/5xiprkEHG1DenRfxqP05kP8+lNC9Oho= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=/ll7hpWPLDABqiSZY0sPHxnI4UkUghpn9GMOL8WZBhk=; b=gxp5Pph88tJDLwFrO7o+H0T/bVIMxEy/NfB24UfqiIwq3PFa8ormYk0K8vDnEWFnn3ZSchwjyavhk+vK5u8VtCULwfzN4U1wwSdNorXMNw8JoukJu98MH6IVx7qUjIZs+8YfGc0A3Qte2OVwZrJo7PLYFJCh72GsSx7treEcUKY= Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Feb 2010 22:15:27 -0000 Date: 7 Feb 2010 17:15:48 -0500 Message-ID: From: "John R Levine" To: "Shmuel (Seymour J.) Metz" In-Reply-To: <20100207213213.67BFDF580A7@smtp.patriot.net> References: <20100207213213.67BFDF580A7@smtp.patriot.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: marf@ietf.org Subject: Re: [marf] [MARF] Additional MIME subparts 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: Sun, 07 Feb 2010 22:14:52 -0000 > Indeed. The results of, e.g., whois, often include non-ASCII data. Similar > issues may exist for other types of evidence. I hadn't thought of the > possible requirement to provide binary files, but that might also be an > issue. ARF reports are in most cases handled by software, with no human ever seeimg them. Can you describe the scenario in which all of this extra stuff would be useful? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From yakov@shaftek.org Sun Feb 7 14:50:59 2010 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 839983A68FA for ; Sun, 7 Feb 2010 14:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 6Ib0qhjzaN9S for ; Sun, 7 Feb 2010 14:50:58 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 933C03A6877 for ; Sun, 7 Feb 2010 14:50:58 -0800 (PST) Received: by wwa36 with SMTP id 36so1422446wwa.31 for ; Sun, 07 Feb 2010 14:51:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.93.1 with SMTP id k1mr1479050wef.151.1265583115150; Sun, 07 Feb 2010 14:51:55 -0800 (PST) In-Reply-To: <20100207213213.67BFDF580A7@smtp.patriot.net> References: <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com> <20100207213213.67BFDF580A7@smtp.patriot.net> From: Yakov Shafranovich Date: Sun, 7 Feb 2010 17:51:34 -0500 Message-ID: <501c18e01002071451y7e411c4cy1a08a6ffffc43fcc@mail.gmail.com> To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] [MARF] Additional MIME subparts 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: Sun, 07 Feb 2010 22:50:59 -0000 On Sun, Feb 7, 2010 at 7:23 AM, Shmuel Metz wrote: > In <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com>, on > 02/06/2010 > =A0 at 07:22 PM, Yakov Shafranovich said: > >>I think he is referring to a different issue - encapsulation. > > Indeed. The results of, e.g., whois, often include non-ASCII data. Simila= r > issues may exist for other types of evidence. I hadn't thought of the > possible requirement to provide binary files, but that might also be an > issue. > I don't think this is a problem at all. The following is a quote from RFC 3462, which defines multipart/report used by ARF: " The text in the first section may be in any MIME standards-track content-type, charset, or language. Where a description of the error is desired in several languages or several media, a Multipart/Alternative construct may be used. " Note the last sentence - multipart/alternative can be used to embed additional MIME parts inside the first part of a multipart/report. I don't see a reason why multipart/mixed cannot be used as well which will give you ability to embed files. I would expand the MARF draft, in section 2 as follows: "b. The first MIME part of the message contains a human readable description of the report and MUST be included. As described in section 1 of RFC 3462, the human readable section of a multipart/report may be set to any valid MIME type. Implementors also have ability to embed additional information and binary files if necessary by using the multipart/mixed MIME type. The format and interpretation of data in this section is for intended for human operators as per RFC 3462 and is not defined in this standard. " Yakov From yakov@shaftek.org Sun Feb 7 14:52:29 2010 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 BF6753A6978 for ; Sun, 7 Feb 2010 14:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 HodvWkXDv6ny for ; Sun, 7 Feb 2010 14:52:28 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E68813A6877 for ; Sun, 7 Feb 2010 14:52:27 -0800 (PST) Received: by wwa36 with SMTP id 36so1422763wwa.31 for ; Sun, 07 Feb 2010 14:53:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.90.70 with SMTP id d48mr586172wef.199.1265583204391; Sun, 07 Feb 2010 14:53:24 -0800 (PST) From: Yakov Shafranovich Date: Sun, 7 Feb 2010 17:53:04 -0500 Message-ID: <501c18e01002071453n4884788fy901091ed1da96b1e@mail.gmail.com> To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [marf] Coordinating with YAM WG 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: Sun, 07 Feb 2010 22:52:29 -0000 Do we need any sort of coordination with the folks at YAM WG? They are working on moving RFC 3462 to standards track among other things, which underlies our standard. Yakov From johnl@taugh.com Sun Feb 7 14:59:11 2010 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 DC9A93A6993 for ; Sun, 7 Feb 2010 14:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.446 X-Spam-Level: X-Spam-Status: No, score=-9.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RDNS_DYNAMIC=0.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 cp93ywRB4mG7 for ; Sun, 7 Feb 2010 14:59:11 -0800 (PST) Received: from gal.iecc.com (64.57.183.53.lightlink.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id B7D663A6831 for ; Sun, 7 Feb 2010 14:59:10 -0800 (PST) Received: (qmail 12407 invoked from network); 7 Feb 2010 23:00:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=VCU+2RtCN9N/HzVblzcagH+4ixSN5YyxDP9t8NZxW0s=; b=3AckzDq7ExcKSqHOWHKgnK818oZKoDZN+XqM6BroInM7lc66tP+XtxEUy4i9qXyhsu9oo1WBTQWMqv9FjiUTKeAN5WkecQFYNKOn/xLesIGU8ZjHbN2VUOCGOvV1oecZa0m2U3SBBQHFjLBSlQkrCLFDXbwSn9rj8UBtCqDuAwU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=VCU+2RtCN9N/HzVblzcagH+4ixSN5YyxDP9t8NZxW0s=; b=JszE6IVNVad1uF4RWIUgUdmbdkSwj+RgNU8Jb7TBysx+A0MDFaYuld023Z+jl+o+IKCNBNtTtz9LdIdJU3WwsSa8aIjnWV2xdkryy2vodwk/0jZDLb3q2Ff/Y7HYKLmPswr0T7l7rtdf6OBHm5kBIsuvEt6+TFGZxDU4YedIwK8= Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Feb 2010 22:59:48 -0000 Date: 7 Feb 2010 18:00:09 -0500 Message-ID: From: "John R Levine" To: "ARF mailing list" In-Reply-To: <501c18e01002071453n4884788fy901091ed1da96b1e@mail.gmail.com> References: <501c18e01002071453n4884788fy901091ed1da96b1e@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [marf] Coordinating with YAM WG 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: Sun, 07 Feb 2010 22:59:12 -0000 > Do we need any sort of coordination with the folks at YAM WG? There's enough overlap in the membership that I don't think we need to worry about it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From yakov@shaftek.org Sun Feb 7 15:10:42 2010 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 14D523A68C7 for ; Sun, 7 Feb 2010 15:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_SPAM=2.3] 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 GLpBzAbfuLgc for ; Sun, 7 Feb 2010 15:10:29 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 387ED3A68FA for ; Sun, 7 Feb 2010 15:10:29 -0800 (PST) Received: by wwa36 with SMTP id 36so1427161wwa.31 for ; Sun, 07 Feb 2010 15:11:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.85.194 with SMTP id u44mr709390wee.65.1265584280174; Sun, 07 Feb 2010 15:11:20 -0800 (PST) In-Reply-To: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> From: Yakov Shafranovich Date: Sun, 7 Feb 2010 18:11:00 -0500 Message-ID: <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Sun, 07 Feb 2010 23:10:42 -0000 On Sun, Feb 7, 2010 at 1:58 PM, SM wrote: > > =A0 "While there has been previous work in this area (e.g. > =A0 [STRADS-BCP] and [ASRG-ABUSE]), none of them have yet been > =A0 successful." > > The intended status of this document is Standards Track. =A0There is an > informative reference to "Crissman, G., "Proposed Spam Reporting BCP > Document", May 2005." =A0draft-shafranovich-feedback-report-05 had a URL = for > the document. =A0It's a 404 now. =A0There is an informative reference to > "Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRT= F), > "Abuse Reporting Standards Subgroup oof the ASRG", May 2005." (oof is a > typo). =A0If this is to acknowledge the work, it could be moved to the > appropriate section if this document has a better fate. > I believe that the first document can be found here: http://mb.preciseic.net/shr/spam/bcp.html The second is here: http://asrg.sp.am/subgroups/abuse_reports.shtml > In Section 1.2, there is a requirement that: > > =A0 =A0 "A copy of the original email message (both body and header) or t= he > =A0 =A0 =A0message header must be enclosed in order to allow the receiver= to > =A0 =A0 =A0handle the report properly;" > > Is a copy of the original required for the receiver to handle the report > properly? =A0That sentence could be rephrased if this WG wants to allow > redaction. > Another issue is that RFC 3462 defines part 3 as optional. I am not sure if we can redefine it as required here. > In Section 1.3.2: > > =A0"See [EMAIL-ARCH] for further discussion on e-mail system > =A0 architecture." > > What does defining a format for abuse reporting have to do with this > subsection? > I believe that the reference is for terms used in email architecture. This will need to be more explicit. > > In Section 3: > > =A0"Although these fields have a syntax similar to those > =A0 of mail message header fields, they are semantically distinct; hence > =A0 they SHOULD NOT be repeated in the header area of the message > =A0 containing the report." > > "Header area" is ill-defined. =A0Can the fields be used in message header= s? > No they cannot be used as email headers. > > In Section 6.2, what is the "purported sender"? > It is a term used with email authentication drafts. We need a reference to some document defining it. > In Section 6.3: > > =A0"Whenever an SMTP transaction is used to send an ARF > =A0 message, the MAIL FROM command must use a NULL return address, i.e. > =A0 "MAIL FROM:<>"." > > Is that a requirement? > This follows a similar approach used in DSNs / RFC 3464, section 2: " The envelope sender address of the DSN SHOULD be chosen to ensure that no delivery status reports will be issued in response to the DSN itself, and MUST be chosen so that DSNs will not generate mail loops. Whenever an SMTP transaction is used to send a DSN, the MAIL FROM command MUST use a NULL return address, i.e., "MAIL FROM:<>". " However, I am not sure if this is necessary here. It actually might be a good idea to allow something in MAIL FROM so we can tell if an ARF report bounces. Yakov From yakov@shaftek.org Sun Feb 7 15:12:31 2010 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 054CE3A697A for ; Sun, 7 Feb 2010 15:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 YpXOx6ugZEet for ; Sun, 7 Feb 2010 15:12:30 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 028123A68FA for ; Sun, 7 Feb 2010 15:12:29 -0800 (PST) Received: by wwa36 with SMTP id 36so1427643wwa.31 for ; Sun, 07 Feb 2010 15:13:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.88.79 with SMTP id z57mr1560360wee.22.1265584406609; Sun, 07 Feb 2010 15:13:26 -0800 (PST) In-Reply-To: <501c18e01002071451y7e411c4cy1a08a6ffffc43fcc@mail.gmail.com> References: <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com> <20100207213213.67BFDF580A7@smtp.patriot.net> <501c18e01002071451y7e411c4cy1a08a6ffffc43fcc@mail.gmail.com> From: Yakov Shafranovich Date: Sun, 7 Feb 2010 18:13:06 -0500 Message-ID: <501c18e01002071513v71000849j51eae2f6d4605a6b@mail.gmail.com> To: marf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [marf] [MARF] Additional MIME subparts 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: Sun, 07 Feb 2010 23:12:31 -0000 On Sun, Feb 7, 2010 at 5:51 PM, Yakov Shafranovich wrot= e: > On Sun, Feb 7, 2010 at 7:23 AM, Shmuel =A0Metz > wrote: >> In <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com>, on >> 02/06/2010 >> =A0 at 07:22 PM, Yakov Shafranovich said: >> >>>I think he is referring to a different issue - encapsulation. >> >> Indeed. The results of, e.g., whois, often include non-ASCII data. Simil= ar >> issues may exist for other types of evidence. I hadn't thought of the >> possible requirement to provide binary files, but that might also be an >> issue. >> > > I don't think this is a problem at all. The following is a quote from > RFC 3462, which defines multipart/report used by ARF: > > " The text in the first section may be in any MIME standards-track > =A0 content-type, charset, or language. =A0Where a description of the err= or > =A0 is desired in several languages or several media, a > =A0 Multipart/Alternative construct may be used. > " > > Note the last sentence - multipart/alternative can be used to embed > additional MIME parts inside the first part of a multipart/report. I > don't see a reason why multipart/mixed cannot be used as well which > will give you ability to embed files. I would expand the MARF draft, > in section 2 as follows: > > "b. =A0The first MIME part of the message contains a human readable > description of the report and MUST be included. As described in > section 1 of RFC 3462, the human readable section of a > multipart/report may be set to any valid MIME type. Implementors also > have ability to embed additional information and binary files if > necessary by using the multipart/mixed MIME type. The format and > interpretation of data in this section is for intended for human > operators as per RFC 3462 and is not defined in this standard. > " > One other thing - this may be a very obscure way to use multipart/report and is probably that did not come up with DSNs and MDNs. We might want to look into the possibilities of writing up a "best practices" document after ARF is standardized. From tony@att.com Sun Feb 7 17:14:46 2010 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 AD6373A6819 for ; Sun, 7 Feb 2010 17:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 B9DfFzOIXiA8 for ; Sun, 7 Feb 2010 17:14:44 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 512883A67D4 for ; Sun, 7 Feb 2010 17:14:44 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-3.tower-167.messagelabs.com!1265591743!16308342!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 25585 invoked from network); 8 Feb 2010 01:15:44 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-3.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Feb 2010 01:15:43 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o181FpI0012847 for ; Sun, 7 Feb 2010 20:15:51 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o181FjVM012831 for ; Sun, 7 Feb 2010 20:15:46 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o181FbL2026139 for ; Sun, 7 Feb 2010 20:15:37 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o181FVE8026089 for ; Sun, 7 Feb 2010 20:15:33 -0500 Received: from [135.70.20.26] (vpn-135-70-20-26.vpn.west.att.com[135.70.20.26]) by maillennium.att.com (mailgw1) with ESMTP id <20100208011531gw100m6bfke> (Authid: tony); Mon, 8 Feb 2010 01:15:31 +0000 X-Originating-IP: [135.70.20.26] Message-ID: <4B6F65B2.7030200@att.com> Date: Sun, 07 Feb 2010 20:15:30 -0500 From: Tony Hansen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ARF mailing list References: <501c18e01002071453n4884788fy901091ed1da96b1e@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Coordinating with YAM WG 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: Mon, 08 Feb 2010 01:14:46 -0000 Yeah, I'd agree with that. - Tony Hansen, YAM co-chair John R Levine wrote: >> Do we need any sort of coordination with the folks at YAM WG? > > There's enough overlap in the membership that I don't think we need to > worry about it. From dhc@dcrocker.net Sun Feb 7 18:29:20 2010 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 0DC823A68F2 for ; Sun, 7 Feb 2010 18:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 jZSaG97qZwuU for ; Sun, 7 Feb 2010 18:29:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 276843A6885 for ; Sun, 7 Feb 2010 18:29:19 -0800 (PST) Received: from [192.168.1.43] (adsl-68-122-70-87.dsl.pltn13.pacbell.net [68.122.70.87]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o182UEOf024877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2010 18:30:19 -0800 Message-ID: <4B6F7737.5070904@dcrocker.net> Date: Sun, 07 Feb 2010 18:30:15 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Yakov Shafranovich References: <501c18e01002071453n4884788fy901091ed1da96b1e@mail.gmail.com> In-Reply-To: <501c18e01002071453n4884788fy901091ed1da96b1e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10364/Sun Feb 7 17:23:21 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 07 Feb 2010 18:30:19 -0800 (PST) Cc: marf@ietf.org Subject: Re: [marf] Coordinating with YAM WG X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net 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, 08 Feb 2010 02:29:20 -0000 On 2/7/2010 2:53 PM, Yakov Shafranovich wrote: > Do we need any sort of coordination with the folks at YAM WG? They are > working on moving RFC 3462 to standards track among other things, > which underlies our standard. YAM is carefully NOT going to make any technical changes of substance, so it's probably worth asking what concerns you might have, that would need coordination? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From yakov@shaftek.org Sun Feb 7 18:31:49 2010 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 41F4F3A6F8A for ; Sun, 7 Feb 2010 18:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 2+Npht+lng5e for ; Sun, 7 Feb 2010 18:31:48 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 3CD133A68F2 for ; Sun, 7 Feb 2010 18:31:48 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so496444eya.5 for ; Sun, 07 Feb 2010 18:32:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.93.71 with SMTP id k49mr2314526wef.172.1265596364209; Sun, 07 Feb 2010 18:32:44 -0800 (PST) In-Reply-To: <4B6F7737.5070904@dcrocker.net> References: <501c18e01002071453n4884788fy901091ed1da96b1e@mail.gmail.com> <4B6F7737.5070904@dcrocker.net> From: Yakov Shafranovich Date: Sun, 7 Feb 2010 21:32:24 -0500 Message-ID: <501c18e01002071832j4eae8f7cm4d6c0ba9ba01c935@mail.gmail.com> To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Cc: marf@ietf.org Subject: Re: [marf] Coordinating with YAM WG 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: Mon, 08 Feb 2010 02:31:49 -0000 On Sun, Feb 7, 2010 at 9:30 PM, Dave CROCKER wrote: > > > On 2/7/2010 2:53 PM, Yakov Shafranovich wrote: >> >> Do we need any sort of coordination with the folks at YAM WG? They are >> working on moving RFC 3462 to standards track among other things, >> which underlies our standard. > > > YAM is carefully NOT going to make any technical changes of substance, so > it's probably worth asking what concerns you might have, that would need > coordination? > I am aware of that. I just wanted to make sure that they are aware that in addition to DSN and MDN, we are working on a third standard that is based on RFC 3462. Yakov From sm@resistor.net Mon Feb 8 01:59:55 2010 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 A79443A7329 for ; Mon, 8 Feb 2010 01:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, MANGLED_SPAM=2.3] 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 LtD+EqSIgRv6 for ; Mon, 8 Feb 2010 01:59:54 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 785BD3A6F97 for ; Mon, 8 Feb 2010 01:59:54 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4/8.14.4) with ESMTP id o18A0hWS005095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 02:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1265623253; x=1265709653; bh=4iN8dHpql3ObSCBYwqcLOIp9wT9tWuZ6yRotrC+fEjw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=N1buSpAc9OQgwKoi3ao9gQHgX15DNjv+QVzGpfzYAY31yzQzn4gGugPHtysbN88No 0ROgIB41jZz1kXcjLsi5nv/ODJyuSEw95LUcQJYGN5W/BnEt/kcChz57y1n6/rmToG 38RDVfIS80/Q4yCqFoNtZIzdFWc+78gxOzt6ZX1Y= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=fu/8unJvgghx8+kIckXpRfatrZPmFM5dfbh4z+vi0u6RZ6kDHhL7S+PLTVT7kbWwp K4QuwmT10nrZuJy2pD7/j3PZUqT4xJzKLQWYkMEeN5IgfLJg/Yqa3oq3UyLr+PETgv5 ia80YPHfNBudxSn8FLy1PcyvaG2KgMT1EXyY3QI= Message-Id: <6.2.5.6.2.20100207213326.0821dd60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 Feb 2010 01:59:42 -0800 To: Yakov Shafranovich From: SM In-Reply-To: <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.co m> References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 09:59:55 -0000 Hi Yakov, At 15:11 07-02-10, Yakov Shafranovich wrote: >I believe that the first document can be found here: > >http://mb.preciseic.net/shr/spam/bcp.html The first paragraph of the document says that it is an Internet-Draft. As I couldn't find any record of the I-D submission, I would not consider it as a valid reference. The STRADS-BCP reference disappeared once before. It isn't a stable reference. >The second is here: > >http://asrg.sp.am/subgroups/abuse_reports.shtml The reference is not meaningful in my opinion unless you want to explain that such efforts are not successful. You could have a variant of the last two sentences of that paragraph under Acknowledgements. >Another issue is that RFC 3462 defines part 3 as optional. I am not >sure if we can redefine it as required here. Quoting RFC 3462: "Return of content may be wasteful of network bandwidth and a variety of implementation strategies can be used. Generally the sender should choose the appropriate strategy and inform the recipient of the required level of returned content required." The above text explains why the body part (part 3) is optional. In the case of delivery status reports, the body part isn't a requirement as the delivery status notification is sent to the email address specified in the return path. The difference between DSN and ARF is that the operator does not have a copy of the original message. For comparison, in Section 1.2: "A copy of the original email message (both body and header) or the message header must be enclosed in order to allow the receiver to handle the report properly;" Quoting from Section 1.2 of RFC 3464: "It must provide enough information to allow message senders (or the user agents) to unambiguously associate a DSN with the message that was sent and the original recipient address for which the DSN is issued (if such information is available), even if the message was forwarded to another recipient address." The requirement (in this I-D) could be rephrased to include "enough information" so that the receiver can handle the report properly. You can then expand on when the message header (only) or both the header and body is useful. The discussion does not have to be in the Requirements Section. It can be argued that part 3 should be included (it is not optional in the usual sense but it isn't a requirement) or possibly be a requirement. It all depends on whether the report would be useful without the message headers and/or body. >I believe that the reference is for terms used in email architecture. >This will need to be more explicit. The document only has one term from RFC 5598. By the way, that term (ADMD) should be expanded in the I-D on first use. If the reference is part of the definitions, the reference would have to be normative. >No they cannot be used as email headers. In Section 3: "Although these fields have a syntax similar to those of mail message header fields, they are semantically distinct; hence they SHOULD NOT be repeated in the header area of the message containing the report." Some implementers can be quite liberal in their interpretation of the specification. It is better to have "should not be used" then. I do not have a clear definition yet to suggest alternative text. >It is a term used with email authentication drafts. We need a >reference to some document defining it. The I-D mentions that reports can be crafted to generate undesirable actions in Section 6.2. The I-D only has to recommend techniques which might help the receiver make a determination about the validity of the report. >This follows a similar approach used in DSNs / RFC 3464, section 2: > >" The envelope sender address of the DSN SHOULD be chosen to ensure > that no delivery status reports will be issued in response to the DSN > itself, and MUST be chosen so that DSNs will not generate mail loops. > Whenever an SMTP transaction is used to send a DSN, the MAIL FROM > command MUST use a NULL return address, i.e., "MAIL FROM:<>". >" > >However, I am not sure if this is necessary here. It actually might be >a good idea to allow something in MAIL FROM so we can tell if an ARF >report bounces. If the report is automated, Section 4.5.5 of RFC 5321 is applicable. If the format is used for direct feedback by end users, the null reverse-path is not required. The approach used in RFC 3464 is probably due to how email works; there is a notification if the message cannot be delivered. If ARF will cause mail loops, the null reverse-path should be considered as a requirement. I am unsure about whether the DSN approach would be best here as it might be useful to know whether the report is being delivered. The ARF message would cause a DSN to be generated in case of delivery failure. Regards, -sm From shmuel+gen@patriot.net Mon Feb 8 05:20:02 2010 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 573F53A71E7 for ; Mon, 8 Feb 2010 05:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599] 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 nP1xX4sz7cPH for ; Mon, 8 Feb 2010 05:19:59 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 3352F3A7317 for ; Mon, 8 Feb 2010 05:19:55 -0800 (PST) Received: from ECS35455305 (core-dc-1-70.dynamic-dialup.coretel.net [69.72.26.70]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id AD97AF580A3 for ; Mon, 8 Feb 2010 08:24:17 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 08 Feb 2010 08:20:57 -0500 To: marf@ietf.org In-Reply-To: <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100208132417.AD97AF580A3@smtp.patriot.net> Subject: Re: [marf] Comments on draft-ietf-marf-base-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 13:20:02 -0000 In <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com>, on 02/07/2010 at 06:11 PM, Yakov Shafranovich said: >Another issue is that RFC 3462 defines part 3 as optional. I am not sure >if we can redefine it as required here. It's done all of the time. A SHOULD or MUST in the draft refers to the MARF specifications in the draft, not to the Multipart/Report specifications in RFC 3462. This is similar to the relation between RFC 5536 and RFC 5321. >However, I am not sure if this is necessary here. It actually might be a >good idea to allow something in MAIL FROM so we can tell if an ARF >report bounces. What about a MUST for the null reverse path if the report is automatically generated and a MAY if it is manually generated? -- 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 shmuel+gen@patriot.net Mon Feb 8 05:22:38 2010 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 136683A739D for ; Mon, 8 Feb 2010 05:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.798, BAYES_00=-2.599] 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 DI86X0SVbkRl for ; Mon, 8 Feb 2010 05:22:37 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 166913A73A0 for ; Mon, 8 Feb 2010 05:22:37 -0800 (PST) Received: from ECS35455305 (core-dc-1-70.dynamic-dialup.coretel.net [69.72.26.70]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id AAD6CF580A3 for ; Mon, 8 Feb 2010 08:27:00 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 08 Feb 2010 08:23:40 -0500 To: marf@ietf.org In-Reply-To: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100208132700.AAD6CF580A3@smtp.patriot.net> Subject: Re: [marf] Comments on draft-ietf-marf-base-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 13:22:38 -0000 In <6.2.5.6.2.20100207093735.09314ad8@elandnews.com>, on 02/07/2010 at 10:58 AM, SM said: >Is a copy of the original required for the receiver to handle the report >properly? That sentence could be rephrased if this WG wants to allow >redaction. I believe that it would be a mistake to allow redaction unless there is a flag indicating that the contents are redacted. -- 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@taugh.com Mon Feb 8 05:46:11 2010 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 1A2B23A7372 for ; Mon, 8 Feb 2010 05:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.446 X-Spam-Level: X-Spam-Status: No, score=-9.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RDNS_DYNAMIC=0.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 r9nTJ7tlj5ge for ; Mon, 8 Feb 2010 05:46:10 -0800 (PST) Received: from gal.iecc.com (64.57.183.53.lightlink.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id C49193A739A for ; Mon, 8 Feb 2010 05:46:09 -0800 (PST) Received: (qmail 41944 invoked from network); 8 Feb 2010 13:47:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=Rk3380ngTWawh0iqxeQPD3toG/qJ2jDMop9bQIJvIis=; b=qTs4bvPGuGE+B9mGGF1THAs6GYUtLIEXqzJpgLeg70PtlqPyHr8CBKvowzZOFZcq5dRYs1eZKybPf3YUQb2dZSf0dg54gw3tfnXHRrVlfZhAa+C5Rj0zGAZx84fNpBJT+FTyFlSwHyHcJQmThQwA9wj5iNeEfreI5hhVR0Up6pg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=Rk3380ngTWawh0iqxeQPD3toG/qJ2jDMop9bQIJvIis=; b=GZ73KNURHN5u5Deh7wP2SdNiDJwJ+Dj69au64vjvDSCOj2+x60Xj4gVy4ujXnQWnZ18xWJtrY1Uxp6vOAIGv5ScpFvpWyjUoq2wXSpZ0LIWRsle978gyd0c7rjTPNfqviI0I1RxSulMyPg6ZKph6b0w75g7+YLVfVL/a+kVxsZ8= Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Feb 2010 13:46:48 -0000 Date: 8 Feb 2010 08:47:10 -0500 Message-ID: From: "John R Levine" To: "Message Abuse Report Format working group" In-Reply-To: <20100208132700.AAD6CF580A3@smtp.patriot.net> References: <20100208132700.AAD6CF580A3@smtp.patriot.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 13:46:11 -0000 > I believe that it would be a mistake to allow redaction unless there is a > flag indicating that the contents are redacted. That horse left the barn years ago. Remember that we don't "allow" people to do anything, we write specs that we hope that parties hoping to interoperate will find it worth their while to implement. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From vesely@tana.it Mon Feb 8 08:28:02 2010 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 399BF28C141 for ; Mon, 8 Feb 2010 08:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.687 X-Spam-Level: X-Spam-Status: No, score=-4.687 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLaUDh6awtMI for ; Mon, 8 Feb 2010 08:28:01 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 4D0093A7438 for ; Mon, 8 Feb 2010 08:28:01 -0800 (PST) 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, 08 Feb 2010 17:29:03 +0100 id 00000000005DC03C.000000004B703BCF.00004866 Message-ID: <4B703BCF.1070604@tana.it> Date: Mon, 08 Feb 2010 17:29:03 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> In-Reply-To: <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Bounces (was: Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 16:28:02 -0000 On 08/Feb/10 00:11, Yakov Shafranovich wrote: > On Sun, Feb 7, 2010 at 1:58 PM, SM wrote: >> In Section 6.3: >> >> "Whenever an SMTP transaction is used to send an ARF >> message, the MAIL FROM command must use a NULL return address, i.e. >> "MAIL FROM:<>"." >> >> Is that a requirement? >> > > This follows a similar approach used in DSNs / RFC 3464, section 2: > > " The envelope sender address of the DSN SHOULD be chosen to ensure > that no delivery status reports will be issued in response to the DSN > itself, and MUST be chosen so that DSNs will not generate mail loops. > Whenever an SMTP transaction is used to send a DSN, the MAIL FROM > command MUST use a NULL return address, i.e., "MAIL FROM:<>". > " > > However, I am not sure if this is necessary here. It actually might be > a good idea to allow something in MAIL FROM so we can tell if an ARF > report bounces. +1. A loop-avoidance specification just needs to ensure that ARF reports are never reported as spam. From msk@cloudmark.com Mon Feb 8 08:48:55 2010 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 66B3D3A7239 for ; Mon, 8 Feb 2010 08:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599] 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 t+VIBRcbsam2 for ; Mon, 8 Feb 2010 08:48:54 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id BB4F43A67F6 for ; Mon, 8 Feb 2010 08:48:54 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 8 Feb 2010 08:49:57 -0800 From: "Murray S. Kucherawy" To: Yakov Shafranovich , "marf@ietf.org" Date: Mon, 8 Feb 2010 08:49:56 -0800 Thread-Topic: [marf] [MARF] Additional MIME subparts Thread-Index: AcqoSysV7dOphD/MQc+a3sVX34ClWAAk3hZA Message-ID: References: <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com> <20100207213213.67BFDF580A7@smtp.patriot.net> <501c18e01002071451y7e411c4cy1a08a6ffffc43fcc@mail.gmail.com> <501c18e01002071513v71000849j51eae2f6d4605a6b@mail.gmail.com> In-Reply-To: <501c18e01002071513v71000849j51eae2f6d4605a6b@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] [MARF] Additional MIME subparts 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: Mon, 08 Feb 2010 16:48:55 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Yakov Shafranovich > Sent: Sunday, February 07, 2010 3:13 PM > To: marf@ietf.org > Subject: Re: [marf] [MARF] Additional MIME subparts >=20 > One other thing - this may be a very obscure way to use > multipart/report and is probably that did not come up with DSNs and > MDNs. We might want to look into the possibilities of writing up a > "best practices" document after ARF is standardized. That's an explicit part of this working group's charter (item #2). From shmuel+gen@patriot.net Mon Feb 8 08:58:34 2010 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 29CFD3A685A for ; Mon, 8 Feb 2010 08:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 fAsrAACTqYva for ; Mon, 8 Feb 2010 08:58:33 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 1BE613A6849 for ; Mon, 8 Feb 2010 08:58:32 -0800 (PST) Received: from ECS35455305 (core-dc-1-246.dynamic-dialup.coretel.net [69.72.26.246]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 181BAF580AB for ; Mon, 8 Feb 2010 12:02:46 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 08 Feb 2010 08:29:47 -0500 To: Message Abuse Report Format working group 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: <20100208170248.181BAF580AB@smtp.patriot.net> Subject: Re: [marf] [MARF] Additional MIME subparts X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 16:58:34 -0000 In , on 02/07/2010 at 05:15 PM, "John R Levine" said: >To: "Shmuel (Seymour J.) Metz" > Cc: marf@ietf.org Please send only a single copy. If there is a reason that you must send an off-list copy, please annotate it as a duplicate so that I will know to respond to the list rather than only to you. Thanks. >ARF reports are in most cases handled by software, with no human ever >seeimg them. Can you describe the scenario in which all of this extra >stuff would be useful? I see a MIME part for evidence as useful only when the report is routed to a human being. I don't see it as directly relevant to automated processing. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Mon Feb 8 09:43:10 2010 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 670F228C131 for ; Mon, 8 Feb 2010 09:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599] 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 Tu9lTlF6FN7u for ; Mon, 8 Feb 2010 09:43:09 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id B3C6728C132 for ; Mon, 8 Feb 2010 09:43:09 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 8 Feb 2010 09:44:12 -0800 From: "Murray S. Kucherawy" To: Yakov Shafranovich , Alessandro Vesely Date: Mon, 8 Feb 2010 09:44:11 -0800 Thread-Topic: [marf] Reported-Domain vs Reported-URI Thread-Index: AcqmgKBGDQ2zjUCMQXa7AwEFBCd5zACZR4VA Message-ID: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> In-Reply-To: <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Mon, 08 Feb 2010 17:43:10 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Yakov Shafranovich > Sent: Friday, February 05, 2010 8:31 AM > To: Alessandro Vesely > Cc: marf@ietf.org > Subject: Re: [marf] Reported-Domain vs Reported-URI >=20 > Some senders and receivers interpret "Reported-Domain" as a domain > that was advertised within the message. This sort of ambiguous interpretation worries me. It suggests we need some= text that explains how the field should really be used by both ends of the= feedback loop. So let's find out what the most common use is and consider whether or not w= e should make that normative. The spec currently says: o "Reported-Domain" includes a domain name that the report generator believes to be relevant to the report, e.g. the domain whose apparent actions provoked the generation of the report. Domain format is defined in section 2.3.1 of [DNS]. This is a bit vague. If machine parsing is the intent, then the spec shoul= d indicate specifically how or why that domain might have been chosen. So how are generators using this field? From johnl@taugh.com Mon Feb 8 10:24:20 2010 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 59BD43A6AD0 for ; Mon, 8 Feb 2010 10:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.446 X-Spam-Level: X-Spam-Status: No, score=-9.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RDNS_DYNAMIC=0.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 k-wjctiKy2oz for ; Mon, 8 Feb 2010 10:24:19 -0800 (PST) Received: from gal.iecc.com (64.57.183.53.lightlink.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 389BE3A6821 for ; Mon, 8 Feb 2010 10:24:19 -0800 (PST) Received: (qmail 8791 invoked from network); 8 Feb 2010 18:25:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=IKPKdYHhN6FfXuY1bskyFO8ifEyyYGewCmUlddKxzww=; b=nZtASpyLX/To2umjQ6KjU+Goo3QiEzMW7I5/DOELa230QLbyt1IsvLRSGWV7mPhuUdKFrDDN4VLzaXVRJY7WsUz9HOnb40Meov3m7UZu2jZQWZ9rjSYtiPxQ7xvNbEu2TjUDo3gjjjLXWqycuamXvvp4LU/KpCfffnfVzWJTqVk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=IKPKdYHhN6FfXuY1bskyFO8ifEyyYGewCmUlddKxzww=; b=bwPd/QTu+UiYLkW1tKvSGYpKcSVbYS4kSNLPceP8EAGtOxFrodjO9LJAcpr8kYq5JCKzC/mV9KlAz35LuBwAbq6/PMjLNQxuovx22iyWoWkt/XGRKadYn8BlnxzD6mKPN9mE9jVbFBG4ulCZoYNg1kXDaHlFiXeGl97p+AAcrao= Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Feb 2010 18:24:58 -0000 Date: 8 Feb 2010 13:25:20 -0500 Message-ID: From: "John R Levine" To: "Message Abuse Report Format working group" In-Reply-To: <20100208170248.181BAF580AB@smtp.patriot.net> References: <20100208170248.181BAF580AB@smtp.patriot.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [marf] [MARF] Additional MIME subparts 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: Mon, 08 Feb 2010 18:24:20 -0000 > I see a MIME part for evidence as useful only when the report is routed to > a human being. I don't see it as directly relevant to automated > processing. ARF is intended for automated processing, so it seems out of scope. If you want to send the WHOIS dump, you can always mail a message in whatever form you want to abuse@wherever. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From msk@cloudmark.com Mon Feb 8 10:29:46 2010 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 697E13A7440 for ; Mon, 8 Feb 2010 10:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] 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 I0nusCgTNCN4 for ; Mon, 8 Feb 2010 10:29:45 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id C6E7E3A70CD for ; Mon, 8 Feb 2010 10:29:45 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 8 Feb 2010 10:30:49 -0800 From: "Murray S. Kucherawy" To: John R Levine , Message Abuse Report Format working group Date: Mon, 8 Feb 2010 10:30:48 -0800 Thread-Topic: [marf] [MARF] Additional MIME subparts Thread-Index: Acqo7BVlVsN+R7TmQB6nUzMea/DIGwAAK7/Q Message-ID: References: <20100208170248.181BAF580AB@smtp.patriot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] [MARF] Additional MIME subparts 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: Mon, 08 Feb 2010 18:29:46 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > John R Levine > Sent: Monday, February 08, 2010 10:25 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] [MARF] Additional MIME subparts >=20 > > I see a MIME part for evidence as useful only when the report is > routed to > > a human being. I don't see it as directly relevant to automated > > processing. >=20 > ARF is intended for automated processing, so it seems out of scope. By that logic, shouldn't we mandate that the first (text/plain) MIME part a= lways be empty? From steve@wordtothewise.com Mon Feb 8 10:42:39 2010 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 09A2128C150 for ; Mon, 8 Feb 2010 10:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj83VdQQects for ; Mon, 8 Feb 2010 10:42:38 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 47C4328C14B for ; Mon, 8 Feb 2010 10:42:38 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id BAE7F807F2 for ; Mon, 8 Feb 2010 10:43:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Mon, 8 Feb 2010 10:43:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <910B191A-3364-457C-A896-5D5CF89E3F1D@wordtothewise.com> References: <20100208170248.181BAF580AB@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] [MARF] Additional MIME subparts 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: Mon, 08 Feb 2010 18:42:39 -0000 On Feb 8, 2010, at 10:30 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of >> John R Levine >> Sent: Monday, February 08, 2010 10:25 AM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] [MARF] Additional MIME subparts >>=20 >>> I see a MIME part for evidence as useful only when the report is >> routed to >>> a human being. I don't see it as directly relevant to automated >>> processing. >>=20 >> ARF is intended for automated processing, so it seems out of scope. >=20 > By that logic, shouldn't we mandate that the first (text/plain) MIME = part always be empty? While ARF is intended for automated processing, we don't want to lock out tiny ISPs who might get 5 FBL reports a week from being able to do something useful with them using a regular MUA. Also even if an ARF consumer is handling inbound ARF format reports automatically, there's always going to be the case where a human needs to put eyes on them, for diagnostics. But as 99% of ARF reports will likely be handled entirely automatically, there should not be anything in the human readable section that's essential for handling the report. c.f. Received headers or MIME preamble or the Organization or User-Agent headers. They're useful if you need them for diagnostics, but they're almost never looked at, and don't contain anything needed for reading the message. That means that if you're adding information that needs to be looked at by a human in order for a FBL report to be actionable you're doing it wrong. But dropping a brief message or a URL or somesuch in the human readable part such that it can be handled without automation causes no harm and will be occasionally helpful to a FBL consumer. Cheers, Steve From msk@cloudmark.com Mon Feb 8 10:43:15 2010 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 5E4D228C14B for ; Mon, 8 Feb 2010 10:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 sUCqBzRQrShd for ; Mon, 8 Feb 2010 10:43:11 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id A90453A6F40 for ; Mon, 8 Feb 2010 10:43:11 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 8 Feb 2010 10:44:15 -0800 From: "Murray S. Kucherawy" To: "MARF@ietf.org" Date: Mon, 8 Feb 2010 10:44:14 -0800 Thread-Topic: About discussing old topics Thread-Index: Acqo7rX2zOWhL+NST3m0j6OsJRfVBQ== 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_BB012BD379D7B046ABE1472D8093C61C01C3C4528FEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] About discussing old topics 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: Mon, 08 Feb 2010 18:43:15 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01C3C4528FEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [as co-chair] There have been a few cases where an idea is proposed that is quickly put d= own as an old topic, something we've already discussed. We realize that ARF has a long and established history, but even with the a= rchives from the old list, it doesn't have much of that history within the = context of the IETF. When it comes time to submit these documents to the I= ESG for review, they will want to see some discussion and then consensus ab= out these ideas, even if the consensus was not to include them. If on revi= ew it is clear that the working group was firmly resistant to any new ideas= or inquiry, we won't have a very easy path through the approval process. So please get into the habit of entertaining ideas, even old ones, at least= for a few rounds to get input from the newcomers and establish some consen= sus as a group. The chairs can intervene if an old topic is being discusse= d ad nauseam, but for now we need to consider or reconsider stuff that's br= ought up for discussion. Thanks. --_000_BB012BD379D7B046ABE1472D8093C61C01C3C4528FEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[as co-chair]

 

There have been a few cases where an idea is proposed = that is quickly put down as an old topic, something we’ve already discusse= d.

 

We realize that ARF has a long and established history= , but even with the archives from the old list, it doesn’t have much of that his= tory within the context of the IETF.  When it comes time to submit these documents to the IESG for review, they will want to see some discussion and then consensus about these ideas, even if the consensus was not to include them.  If on review it is clear that the working group was firmly resistant to any new ideas or inquiry, we won’t have a very easy path through the approval process.

 

So please get into the habit of entertaining ideas, ev= en old ones, at least for a few rounds to get input from the newcomers and establi= sh some consensus as a group.  The chairs can intervene if an old topic i= s being discussed ad nauseam, but for now we need to consider or reconsider s= tuff that’s brought up for discussion.

 

Thanks.

--_000_BB012BD379D7B046ABE1472D8093C61C01C3C4528FEXCHC2corpclo_-- From steve@blighty.com Mon Feb 8 10:40:44 2010 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 6C6E53A6991 for ; Mon, 8 Feb 2010 10:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 ds6FF7FbjINi for ; Mon, 8 Feb 2010 10:40:43 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id A44073A6801 for ; Mon, 8 Feb 2010 10:40:43 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id E45748080A for ; Mon, 8 Feb 2010 10:41:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Mon, 8 Feb 2010 10:41:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <82B29420-5A6E-41C0-898C-7003FF112F9A@blighty.com> References: <20100208170248.181BAF580AB@smtp.patriot.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Mon, 08 Feb 2010 10:47:26 -0800 Subject: Re: [marf] [MARF] Additional MIME subparts 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: Mon, 08 Feb 2010 18:40:44 -0000 On Feb 8, 2010, at 10:30 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of >> John R Levine >> Sent: Monday, February 08, 2010 10:25 AM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] [MARF] Additional MIME subparts >>=20 >>> I see a MIME part for evidence as useful only when the report is >> routed to >>> a human being. I don't see it as directly relevant to automated >>> processing. >>=20 >> ARF is intended for automated processing, so it seems out of scope. >=20 > By that logic, shouldn't we mandate that the first (text/plain) MIME = part always be empty? While ARF is intended for automated processing, we don't want to lock out tiny ISPs who might get 5 FBL reports a week from being able to do something useful with them using a regular MUA. Also even if an ARF consumer is handling inbound ARF format reports automatically, there's always going to be the case where a human needs to put eyes on them, for diagnostics. But as 99% of ARF reports will likely be handled entirely automatically, there should not be anything in the human readable section that's essential for handling the report. c.f. Received headers or MIME preamble or the Organization or User-Agent headers. They're useful if you need them for diagnostics, but they're almost never looked at, and don't contain anything needed for reading the message. That means that if you're adding information that needs to be looked at by a human in order for a FBL report to be actionable you're doing it wrong. But dropping a brief message or a URL or somesuch in the human readable part such that it can be handled without automation causes no harm and will be occasionally helpful to a FBL consumer. Cheers, Steve From msk@cloudmark.com Mon Feb 8 10:52:02 2010 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 742E13A70D4 for ; Mon, 8 Feb 2010 10:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599] 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 t9vL3a5KpuVd for ; Mon, 8 Feb 2010 10:52:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id AE4B13A67BD for ; Mon, 8 Feb 2010 10:52:01 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 8 Feb 2010 10:53:04 -0800 From: "Murray S. Kucherawy" To: Yakov Shafranovich , "marf@ietf.org" Date: Mon, 8 Feb 2010 10:53:04 -0800 Thread-Topic: [marf] [MARF] Additional MIME subparts Thread-Index: AcqoSCk6McSZduikTUq9YchGqsaBDAApusgw Message-ID: References: <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com> <20100207213213.67BFDF580A7@smtp.patriot.net> <501c18e01002071451y7e411c4cy1a08a6ffffc43fcc@mail.gmail.com> In-Reply-To: <501c18e01002071451y7e411c4cy1a08a6ffffc43fcc@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] [MARF] Additional MIME subparts 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: Mon, 08 Feb 2010 18:52:02 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Yakov Shafranovich > Sent: Sunday, February 07, 2010 2:52 PM > To: marf@ietf.org > Subject: Re: [marf] [MARF] Additional MIME subparts >=20 > I don't think this is a problem at all. The following is a quote from > RFC 3462, which defines multipart/report used by ARF: >=20 > " The text in the first section may be in any MIME standards-track > content-type, charset, or language. Where a description of the > error > is desired in several languages or several media, a > Multipart/Alternative construct may be used. > " >=20 > Note the last sentence - multipart/alternative can be used to embed > additional MIME parts inside the first part of a multipart/report. I > don't see a reason why multipart/mixed cannot be used as well which > will give you ability to embed files. [as participant] I don't think this conforms to the general intent of RFC3462, which to me f= airly clearly intended the first MIME part to contain a human-readable desc= ription of what's in the other parts. Using multipart/alternative there is= consistent with that, but using multipart/mixed to pack parts of the actua= l report into it seems to deviate from that intent. The part where we can define extensions of the nature we're discussing, wit= hin the RFC3462 framework, is the second part. If we want to accommodate a= dditional data outside the "name: value" format we have now, we'd have to s= ay that message/feedback-report is itself a multipart and then establish th= e requisite structure around that. Given that one of the chartered goals is to maintain backward compatibility= with existing deployments, I suspect we can't accommodate anything that co= mplex until we're discussing ARF extensions in later draft work. But this = is something we should revisit at that time. From msk@cloudmark.com Mon Feb 8 10:59:37 2010 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 624BA3A7253 for ; Mon, 8 Feb 2010 10:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599] 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 JpKMuIjZ9HUe for ; Mon, 8 Feb 2010 10:59:36 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id B84993A70AF for ; Mon, 8 Feb 2010 10:59:36 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 8 Feb 2010 11:00:40 -0800 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Mon, 8 Feb 2010 11:00:39 -0800 Thread-Topic: [marf] Bounces (was: Comments on draft-ietf-marf-base-00 Thread-Index: Acqo29WOWA5M955KTmC5YzoJZjNcZgAFK3Tw Message-ID: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <4B703BCF.1070604@tana.it> In-Reply-To: <4B703BCF.1070604@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Bounces (was: Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 18:59:37 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Monday, February 08, 2010 8:29 AM > To: marf@ietf.org > Subject: Re: [marf] Bounces (was: Comments on draft-ietf-marf-base-00 >=20 > > However, I am not sure if this is necessary here. It actually might be > > a good idea to allow something in MAIL FROM so we can tell if an ARF > > report bounces. >=20 > +1. A loop-avoidance specification just needs to ensure that ARF > reports are never reported as spam. What suggestions do you have for such a specification? I'm a little worried that a rule like "Never generate an ARF report for a m= essage that contains a MIME part of type message/feedback-report" will beco= me a spam vector. From steve@wordtothewise.com Mon Feb 8 11:08:00 2010 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 984103A7479 for ; Mon, 8 Feb 2010 11:08:00 -0800 (PST) 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 DAOMhbqE2xvS for ; Mon, 8 Feb 2010 11:07:59 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id D8D4B3A7474 for ; Mon, 8 Feb 2010 11:07:59 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 707018053C for ; Mon, 8 Feb 2010 11:09:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: <4B703BCF.1070604@tana.it> Date: Mon, 8 Feb 2010 11:09:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <10DA6B81-6357-4849-B937-55DBC2814CA0@wordtothewise.com> References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <4B703BCF.1070604@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Bounces (was: Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 19:08:00 -0000 On Feb 8, 2010, at 8:29 AM, Alessandro Vesely wrote: > On 08/Feb/10 00:11, Yakov Shafranovich wrote: >> On Sun, Feb 7, 2010 at 1:58 PM, SM wrote: >>> In Section 6.3: >>>=20 >>> "Whenever an SMTP transaction is used to send an ARF >>> message, the MAIL FROM command must use a NULL return address, = i.e. >>> "MAIL FROM:<>"." >>>=20 >>> Is that a requirement? >>>=20 >>=20 >> This follows a similar approach used in DSNs / RFC 3464, section 2: >>=20 >> " The envelope sender address of the DSN SHOULD be chosen to ensure >> that no delivery status reports will be issued in response to the = DSN >> itself, and MUST be chosen so that DSNs will not generate mail = loops. >> Whenever an SMTP transaction is used to send a DSN, the MAIL FROM >> command MUST use a NULL return address, i.e., "MAIL FROM:<>". >> " >>=20 >> However, I am not sure if this is necessary here. It actually might = be >> a good idea to allow something in MAIL FROM so we can tell if an ARF >> report bounces. Yup. If I'm running a feedback loop I'd really like to know if the = consumer of it has vanished or broken. DSNs are quite different, as they're sent automatically to the return path, rather than manually to somewhere else. >=20 > +1. A loop-avoidance specification just needs to ensure that ARF = reports are never reported as spam. It's an even lower bar - it just needs to ensure that inbound ARF = reports are never automatically trigger outbound ones. (If an ARF consumer hits the TiS button and sends a spam report about an ARF formatted mail manually it won't break anything). I don't see a need for anything ARF-specific to break loops here. Cheers, Steve From msk@cloudmark.com Mon Feb 8 12:43:59 2010 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 2E4A33A6DBE for ; Mon, 8 Feb 2010 12:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599] 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 bUXl+RUCTCKR for ; Mon, 8 Feb 2010 12:43:57 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 40AC03A672E for ; Mon, 8 Feb 2010 12:43:57 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 8 Feb 2010 12:45:00 -0800 From: "Murray S. Kucherawy" To: SM , "marf@ietf.org" Date: Mon, 8 Feb 2010 12:45:00 -0800 Thread-Topic: [marf] Comments on draft-ietf-marf-base-00 Thread-Index: AcqoJ5j3Z2LBAIHARG6RN+7KGVEWiAAy45Bg Message-ID: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> In-Reply-To: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 20:43:59 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > SM > Sent: Sunday, February 07, 2010 10:58 AM > To: marf@ietf.org > Subject: [marf] Comments on draft-ietf-marf-base-00 >=20 > Hello, Hi! > I read draft-ietf-marf-base-00. The comments below could be > categorized as stylistic. >=20 > In Section 1: >=20 > "This memo seeks to define a standard extensible format by > creating the "message/feedback-report" [MIME] type for > these reports." >=20 > The Abstract Section says that the "document defines an extensible > format and MIME type". I suggest changing the "seeks to define" to > "defines". Upon publication, it will be defining something, so I believe it's fine as-= is. > "While there has been previous work in this area (e.g. > [STRADS-BCP] and [ASRG-ABUSE]), none of them have yet been > successful." >=20 > The intended status of this document is Standards Track. There is an > informative reference to "Crissman, G., "Proposed Spam Reporting BCP > Document", May 2005." draft-shafranovich-feedback-report-05 had a > URL for the document. It's a 404 now. There is an informative > reference to "Anti-Spam Research Group (ASRG) of the Internet > Research Task Force (IRTF), "Abuse Reporting Standards Subgroup oof > the ASRG", May 2005." (oof is a typo). If this is to acknowledge the > work, it could be moved to the appropriate section if this document > has a better fate. I'll fix the typo and it looks like a current URL has already been provided= in a different reply. But what would the appropriate section be if not th= e Informative References? > In Section 1.2, there is a requirement that: >=20 > "A copy of the original email message (both body and header) or > the > message header must be enclosed in order to allow the receiver > to > handle the report properly;" >=20 > Is a copy of the original required for the receiver to handle the > report properly? That sentence could be rephrased if this WG wants > to allow redaction. Elsewhere in the text we already discourage but accept the redaction practi= ce. I don't think the introduction is a good place to start making normati= ve assertions, but rather to give general intent. > In Section 1.3.2: >=20 > "See [EMAIL-ARCH] for further discussion on e-mail system > architecture." >=20 > What does defining a format for abuse reporting have to do with this > subsection? Section 1.3 is all definitions. EMAIL-ARCH discusses things like ADMDs whi= ch are mentioned in the ARF draft later on, so it seems to me that referenc= e is appropriate. > In Section 2: >=20 > "The Subject header field of the feedback report SHOULD be the > same as the included email message about which the report is > being generated and MAY include only a typical forwarding prefix > used by MUAs such as "FW:". (Many smaller operators using MUAs > for abuse handling rely on the subject lines for processing.)" >=20 > There is already a SHOULD. The "MAY include only" does not fit in > well as a RFC 2119 requirement. The sentence could be split into two > and explain that the subject can have a "FW:" prefix. Actually I think it's sufficient just to change "MAY" to "may"; the "SHOULD= " semantics seem to allow for that anyway. > In Section 3: >=20 > "Although these fields have a syntax similar to those > of mail message header fields, they are semantically distinct; > hence > they SHOULD NOT be repeated in the header area of the message > containing the report." >=20 > "Header area" is ill-defined. Can the fields be used in message > headers? Would changing "header area" to just "header" be sufficient? The intent is to discourage the use of ARF fields, normally found in the se= cond MIME part, in the actual message header. They could be used there, of= course, but a parser implementing ARF would probably not look there for th= em. > In Section 3.1: >=20 > "The format of this field MUST follow section 14.43 of [HTTP]." >=20 > I suggest having that reference as normative. Yes, good point. > In Section 3.2, there are references to DSN and SMTP. These are > informative references in this document. Also correct. > In Section 4: >=20 > "Any new required fields REQUIRE a new version of this specification > to be published." >=20 > It would be better to allow it be done through Standards Track > documents. Are those different things? > In Section 5.2: >=20 > "The expert should be appointed by the Area Director for the > Applications Area." >=20 > Please let the IESG decide on the appointment. Section 3.2 of RFC5226 says: Designated experts are appointed by the IESG (normally upon recommendation by the relevant Area Director). So you're right, but basically I think we're saying the same thing. > In Section 6.2, what is the "purported sender"? It's intentionally not defined here. An agent processing an ARF report, or= indeed any message, makes some conclusion about who/what sent it based on = header field heuristics. I don't think we should presume to define such he= uristics here. > In Section 6.3: >=20 > "Whenever an SMTP transaction is used to send an ARF > message, the MAIL FROM command must use a NULL return address, i.e. > "MAIL FROM:<>"." >=20 > Is that a requirement? As has been pointed out, DSN does the same thing. However, you're right th= at we don't specify this anywhere else in the document. It sounds like thi= s is under discussion now in another thread, but if this is something we wa= nt to assert then it needs to be done so normatively elsewhere. We'll have= to see where that other thread leads us. > In Section 6.4: >=20 > "It follows that any attack against the authentication methods > supported by this document (and later amendments to it) is > also a security consideration here." >=20 > Please remove later amendments as a security consideration as it is > not possible to tell what that will be. Yep, you're right. How about this? "It follows that any attack against an authentication method that might be = used to protect the authenticity of an abuse report is also a security cons= ideration here." From dhc@dcrocker.net Mon Feb 8 12:58:45 2010 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 0CC8028C120 for ; Mon, 8 Feb 2010 12:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 FVDLET7aQHoW for ; Mon, 8 Feb 2010 12:58:43 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 9AEBE3A7288 for ; Mon, 8 Feb 2010 12:58:43 -0800 (PST) Received: from [192.168.1.43] (adsl-68-122-70-87.dsl.pltn13.pacbell.net [68.122.70.87]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o18Kxfmm010846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 12:59:46 -0800 Message-ID: <4B707B3B.1060409@dcrocker.net> Date: Mon, 08 Feb 2010 12:59:39 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: John R Levine References: <20100208132700.AAD6CF580A3@smtp.patriot.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10366/Mon Feb 8 08:41:04 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 08 Feb 2010 12:59:47 -0800 (PST) Cc: Message Abuse Report Format working group Subject: Re: [marf] Comments on draft-ietf-marf-base-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net 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, 08 Feb 2010 20:58:45 -0000 On 2/8/2010 5:47 AM, John R Levine wrote: >> I believe that it would be a mistake to allow redaction unless there is a >> flag indicating that the contents are redacted. > > That horse left the barn years ago. Remember that we don't "allow" > people to do anything, we write specs that we hope that parties hoping > to interoperate will find it worth their while to implement. A standard cannot /enforce/ anything, but it can /mandate/ particulars. In fact, a standard that does not mandate anything isn't a meaningful standard. The distinction between an entire message vs. a redacted message is significant, so that having the specify and (possibly also) mandate a means for flagging redaction is quite reasonable. Unfortunately it naturally leads to the question of an inline notation for marking where redaction has been perfored... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Mon Feb 8 13:02:51 2010 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 58DC628C185 for ; Mon, 8 Feb 2010 13:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599] 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 owarPrVydsf8 for ; Mon, 8 Feb 2010 13:02:50 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 297B528C181 for ; Mon, 8 Feb 2010 13:02:50 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 8 Feb 2010 13:03:54 -0800 From: "Murray S. Kucherawy" To: Yakov Shafranovich , SM Date: Mon, 8 Feb 2010 13:03:53 -0800 Thread-Topic: [marf] Comments on draft-ietf-marf-base-00 Thread-Index: AcqoSuoKi6LGCsukS5W6y0m3Yy5CFQAtkaPA Message-ID: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> In-Reply-To: <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 21:02:51 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Yakov Shafranovich > Sent: Sunday, February 07, 2010 3:11 PM > To: SM > Cc: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-base-00 >=20 > I believe that the first document can be found here: >=20 > http://mb.preciseic.net/shr/spam/bcp.html Thanks; I've updated that reference. Hopefully that URL is reasonably perm= anent... > > In Section 1.2, there is a requirement that: > > > > =A0 =A0 "A copy of the original email message (both body and header) or > the > > =A0 =A0 =A0message header must be enclosed in order to allow the receiv= er > to > > =A0 =A0 =A0handle the report properly;" > > > > Is a copy of the original required for the receiver to handle the > report > > properly? =A0That sentence could be rephrased if this WG wants to allow > > redaction. >=20 > Another issue is that RFC 3462 defines part 3 as optional. I am not > sure if we can redefine it as required here. I agree that we might meet some static by making that assertion. Consider a message that purports to be ARF, but is missing the third part. = Then a parser can legitimately conclude that the message conforms to multi= part/report, but does not conform to ARF. I think that's acceptable based = on the specifications, and would then be a matter for local policy to decid= e how to handle it. =20 > > In Section 1.3.2: > > > > =A0"See [EMAIL-ARCH] for further discussion on e-mail system > > =A0 architecture." > > > > What does defining a format for abuse reporting have to do with this > > subsection? > > >=20 > I believe that the reference is for terms used in email architecture. > This will need to be more explicit. How about: "[EMAIL-ARCH] introduces several terms and concepts that are used in this m= emo, and thus readers are advised to become familiar with it as well." > > In Section 3: > > > > =A0"Although these fields have a syntax similar to those > > =A0 of mail message header fields, they are semantically distinct; > hence > > =A0 they SHOULD NOT be repeated in the header area of the message > > =A0 containing the report." > > > > "Header area" is ill-defined. =A0Can the fields be used in message > headers? >=20 > No they cannot be used as email headers. So should that be a MUST NOT? I'm not sure we can safely do that, as that = would suggest they are not allowed in the general message header field regi= stry. > > In Section 6.2, what is the "purported sender"? >=20 > It is a term used with email authentication drafts. We need a > reference to some document defining it. Actually I'd prefer we didn't. What one parsing agent considers to be the = purported sender may differ from the next. From msk@cloudmark.com Mon Feb 8 13:09:01 2010 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 D1E2C3A7255 for ; Mon, 8 Feb 2010 13:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599] 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 mlJ4naOh995F for ; Mon, 8 Feb 2010 13:09:01 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 206043A7247 for ; Mon, 8 Feb 2010 13:09:01 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Mon, 8 Feb 2010 13:10:05 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Mon, 8 Feb 2010 13:10:04 -0800 Thread-Topic: [marf] Comments on draft-ietf-marf-base-00 Thread-Index: Acqowe9FNyPOUzLvSY2ArlvZN7lRhgAQRaWQ Message-ID: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <20100208132700.AAD6CF580A3@smtp.patriot.net> In-Reply-To: <20100208132700.AAD6CF580A3@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 21:09:01 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Shmuel Metz > Sent: Monday, February 08, 2010 5:24 AM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-base-00 >=20 > In <6.2.5.6.2.20100207093735.09314ad8@elandnews.com>, on 02/07/2010 > at 10:58 AM, SM said: >=20 > >Is a copy of the original required for the receiver to handle the > report > >properly? That sentence could be rephrased if this WG wants to allow > >redaction. >=20 > I believe that it would be a mistake to allow redaction unless there is > a > flag indicating that the contents are redacted. Given that we're tending toward making this format most useful by machines,= how would they use that flag if it were set? From msk@cloudmark.com Mon Feb 8 13:25:10 2010 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 1F6BA28C116 for ; Mon, 8 Feb 2010 13:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599] 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 Sy3D8HSLEZto for ; Mon, 8 Feb 2010 13:25:09 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 1C0B63A746A for ; Mon, 8 Feb 2010 13:25:09 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 8 Feb 2010 13:26:12 -0800 From: "Murray S. Kucherawy" To: SM , Yakov Shafranovich Date: Mon, 8 Feb 2010 13:26:12 -0800 Thread-Topic: [marf] Comments on draft-ietf-marf-base-00 Thread-Index: AcqopZzofub960jFTPyrs+ZkOE+xFAAXYb+w Message-ID: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <6.2.5.6.2.20100207213326.0821dd60@resistor.net> In-Reply-To: <6.2.5.6.2.20100207213326.0821dd60@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 21:25:10 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > SM > Sent: Monday, February 08, 2010 2:00 AM > To: Yakov Shafranovich > Cc: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-base-00 >=20 > [...] >=20 > The requirement (in this I-D) could be rephrased to include "enough > information" so that the receiver can handle the report > properly. You can then expand on when the message header (only) or > both the header and body is useful. The discussion does not have to > be in the Requirements Section. I like this approach, but it needs more thought to be included in a normati= ve part of a specification such as Section 2d of this I-D. In particular, = I don't think we can use normative language where the decision is actually = subjective; that is, I don't think one can write "You MUST do X unless you = don't think the recipient will actually need it" because the sender doesn't= know what software or internal processes may exist at the receiver. I think we'd be much safer to say the third part MUST always be there. > >I believe that the reference is for terms used in email architecture. > >This will need to be more explicit. >=20 > The document only has one term from RFC 5598. By the way, that term > (ADMD) should be expanded in the I-D on first use. If the reference > is part of the definitions, the reference would have to be normative. ADMD is only used for discussion, so expanding it on first use is fine but = I don't think it needs to be normative. (Can an informational draft be nor= mative anyway?) > >No they cannot be used as email headers. >=20 > In Section 3: >=20 > "Although these fields have a syntax similar to those > of mail message header fields, they are semantically distinct; > hence > they SHOULD NOT be repeated in the header area of the message > containing the report." >=20 > Some implementers can be quite liberal in their interpretation of the > specification. It is better to have "should not be used" then. I do > not have a clear definition yet to suggest alternative text. I don't have a problem with that small change, except that it might fly in = the face of later registrations of those names in the IANA header field reg= istry. > I am unsure about whether the DSN approach would be best here as it > might be useful to know whether the report is being delivered. The > ARF message would cause a DSN to be generated in case of delivery > failure. I can conceive of an automatically-generated ARF report where for example a= spam filter is programmed to generate ARFs for suspect messages right at t= he MTA. (We might even want to mention that as a possible DoS vector.) If an ARF is generated without a NULL envelope sender but aimed at an addre= ss that doesn't work, then the generating address can also get bombed by DS= Ns. But the tradeoff is that with the NULL sender, legitimate ARFs that do= n't get delivered are never detected. Perhaps softening the language in 6.3 is appropriate; discuss both scenario= s and the ramifications of each, and let the ADMD make its own decision. From dhc@dcrocker.net Mon Feb 8 13:28:54 2010 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 645AB28C1B0 for ; Mon, 8 Feb 2010 13:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 wwb7XmezNt+M for ; Mon, 8 Feb 2010 13:28:53 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 51F6328C106 for ; Mon, 8 Feb 2010 13:28:53 -0800 (PST) Received: from [192.168.1.43] (adsl-68-122-70-87.dsl.pltn13.pacbell.net [68.122.70.87]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o18LTpFv013393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 13:29:56 -0800 Message-ID: <4B70824D.1050201@dcrocker.net> Date: Mon, 08 Feb 2010 13:29:49 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10366/Mon Feb 8 08:41:04 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 08 Feb 2010 13:29:57 -0800 (PST) Cc: "marf@ietf.org" Subject: Re: [marf] Comments on draft-ietf-marf-base-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net 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, 08 Feb 2010 21:28:54 -0000 On 2/8/2010 1:03 PM, Murray S. Kucherawy wrote: > I agree that we might meet some static by making that assertion. > > Consider a message that purports to be ARF, but is missing the third part. > Then a parser can legitimately conclude that the message conforms to > multipart/report, but does not conform to ARF. I think that's acceptable > based on the specifications, and would then be a matter for local policy to > decide how to handle it. +1 >> I believe that the reference is for terms used in email architecture. This >> will need to be more explicit. > > How about: > > "[EMAIL-ARCH] introduces several terms and concepts that are used in this > memo, and thus readers are advised to become familiar with it as well." +1 >>> In Section 3: >>> >>> "Although these fields have a syntax similar to those of mail message >>> header fields, they are semantically distinct; >> hence >>> they SHOULD NOT be repeated in the header area of the message containing >>> the report." >>> >>> "Header area" is ill-defined. Can the fields be used in message >> headers? >> >> No they cannot be used as email headers. Officially the structured bit at the beginning of a 5322 message is 'header fields' The ABNF aggregate name is 'fields'. The aggregate used to be called the 'header' but people used the word ambiguously, so the word by itself was dropped. Given that the existing text first does say "header fields", it's saying "header area" in the same sentence (after the semi-colon) is likely to be clear to the reader. However, yeah, it's probably less pristine, in a formal sense, than one might demand. So perhaps, distinct; hence they SHOULD NOT be repeated as as header fields of the message containing the report." >>> In Section 6.2, what is the "purported sender"? >> >> It is a term used with email authentication drafts. We need a reference to >> some document defining it. > > Actually I'd prefer we didn't. What one parsing agent considers to be the > purported sender may differ from the next. I see the word 'purported' used only that one time and it isn't defined. And I've registered my concern with ambiguity of the term 'sender' many times. Since this is a specification and the agent being called 'purported sender' has fundamental semantic and security implications, I do believe the relevant terminology needs to be defined and used carefully. That said, this is a format spec, not a protocol spec. So the obligations about identifying agents of action is limited. However I also note that that section of 5.2 calls on using DKIM for validating content and, technically, DKIM doesn't do that... So I'm going to suggest hacking the paragraph a bit, from: > It is recommended that ARF reports be vetted using common message > authentication schemes such as [DKIM], [SPF] or [SENDERID] to confirm > that they represent a valid message from the purported sender of the > report prior to the undertaking of any kind of automated action in > response to receipt of the report. It is recommended that the ownership of an ARF report be vetted, such as by using common message accountability schemes such as [DKIM], [SPF] or [SENDERID], prior to the undertaking of any kind of automated action in response to receipt of the report. The details of the required validation, to achieve this, are outside the scope of this specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@taugh.com Mon Feb 8 13:46:21 2010 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 EC6763A6E05 for ; Mon, 8 Feb 2010 13:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.322 X-Spam-Level: X-Spam-Status: No, score=-10.322 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] 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 x3ZQMknHX96Z for ; Mon, 8 Feb 2010 13:46:20 -0800 (PST) Received: from gal.iecc.com (l053.n.taugh.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id AC5403A6CD5 for ; Mon, 8 Feb 2010 13:46:19 -0800 (PST) Received: (qmail 13512 invoked from network); 8 Feb 2010 21:47:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=PgSqr/xtOZBnM3ei5WhVWROO5gjRLiDG/QrLwDBnoJo=; b=Guud+P3tIfx8mPZtKItOfGRfVeu1W/zSUZLzuUJ6QZFJCVr4C6XTcdjhdauEslonkfLOIjhjzqUFO9CAHREMtf9e1KivgPp/kr59S+PmulQh39/Yets734yNDCc65a+LLlhcf65vfqmPnkReibd98gH9bT91JRMtdZ3+baCHAcY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=PgSqr/xtOZBnM3ei5WhVWROO5gjRLiDG/QrLwDBnoJo=; b=GMCJCylzxX3o0G+Irgsjs8u8+JCNiVM0HT29vXyvs+n/T8EEzGYYa3hZDWhEdf2QpgQUzXfQCcFNTh4s2fgH0TWHHhD/Npf1P/rUCNwFoZnDwo7nRhc5aINg0Kg82UW3nNvThiKLq+M9i2Y7Zl9RXNHEKLkhVfUC2m2gSP3M3fw= Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Feb 2010 21:47:00 -0000 Date: 8 Feb 2010 16:47:21 -0500 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <6.2.5.6.2.20100207213326.0821dd60@resistor.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "marf@ietf.org" Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 21:46:21 -0000 > I think we'd be much safer to say the third part MUST always be there. multipart/report requires it, but it also says you can send just the headers rather than the entire message. Unless someone thinks there are a) ARF consumers who'd save significant effort if they just got the headers or b) ARF producers who would send feedback if it could just include the headers but not if it had the whole (possibly redacted) message, this strikes me as an option that adds complication without making anything work better. >> they SHOULD NOT be repeated in the header area of the message >> containing the report." >> >> Some implementers can be quite liberal in their interpretation of the >> specification. It is better to have "should not be used" then. I do >> not have a clear definition yet to suggest alternative text. SHOULD NOT is right, don't do it unless you have a really good reason to do so. > If an ARF is generated without a NULL envelope sender but aimed at an address that doesn't work, then the generating address can also get bombed by DSNs. But the tradeoff is that with the NULL sender, legitimate ARFs that don't get delivered are never detected. Mailbombing and bounce storms due to junk mail is hardly a new problem. If we say anything, I'd just make it generic like don't send reports if the recipients can't handle them. R's, John From sm@resistor.net Mon Feb 8 15:52:15 2010 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 12F163A7258 for ; Mon, 8 Feb 2010 15:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] 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 olzuOwSV1Erg for ; Mon, 8 Feb 2010 15:52:14 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 049AE3A7182 for ; Mon, 8 Feb 2010 15:52:14 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4/8.14.4) with ESMTP id o18Nqquj002112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 15:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1265673196; x=1265759596; bh=mEei1L/F4IVEZyS4+jNTJHuFfRRSXhdQv9w5x6PppMk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=OXMfPIznI4gNDOOGbK1G9U08ZifWbMOtwNebiDFs1hqqgkafrWLl/hlUi56A1k0XZ rX3IvDRF9VAeYFWExwuAdUfY2vg+sDhwcUKLYLtzLgdNDe2A7i07OUD2+xlfz2pQrz Ux/u+R/X746qwE65PIKyGscEdjiwb+6OVGtvgjLs= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=VJi7SEZcp7OdoKLeEPkIPWLt6pGBNnOBBRvjyP6cswePDIQlt0ptX23nJXbTdKn3M V+QNSHHs1auC1xe5lZOUOtJ3PNTG+cbTnffnvB/LCdtwpnSHyPdT+TFDvDU45ApDB4V MulQXGQzUBuSO86Ws04WmmLbDAtaZmUUTB8UdQI= Message-Id: <6.2.5.6.2.20100208151819.05666f48@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 Feb 2010 15:39:07 -0800 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 23:52:15 -0000 Hi Murray, At 12:45 08-02-10, Murray S. Kucherawy wrote: >Upon publication, it will be defining something, so I believe it's fine as-is. You can do that in an I-D without having to wait for publication. It's fine with me if you want to wait. >I'll fix the typo and it looks like a current URL has already been >provided in a different reply. But what would the appropriate >section be if not the Informative References? Yes but it is not a stable (long-lived) reference. I suggest moving them to the appropriate section if you want to acknowledge the work. I do not consider a reference to a document that has part of the boilerplate and which has not been submitted as an I-D as an appropriate reference. >Actually I think it's sufficient just to change "MAY" to "may"; the >"SHOULD" semantics seem to allow for that anyway. Yes but keep them in separate sentences. I'll get back to this again after re-reading the text. >Would changing "header area" to just "header" be sufficient? I need to go through some RFCs before I answer. >Are those different things? Yes. >Section 3.2 of RFC5226 says: > > Designated experts are appointed by the IESG (normally upon > recommendation by the relevant Area Director). > >So you're right, but basically I think we're saying the same thing. It's the same. But we generally leave it to the relevant RFC unless we require a different procedure. >It's intentionally not defined here. An agent processing an ARF >report, or indeed any message, makes some conclusion about who/what >sent it based on header field heuristics. I don't think we should >presume to define such heuristics here. Dave commented on this. >As has been pointed out, DSN does the same thing. However, you're >right that we don't specify this anywhere else in the document. It >sounds like this is under discussion now in another thread, but if >this is something we want to assert then it needs to be done so >normatively elsewhere. We'll have to see where that other thread leads us. Okay. >Yep, you're right. How about this? > >"It follows that any attack against an authentication method that >might be used to protect the authenticity of an abuse report is also >a security consideration here." That's fine with me. It might raise a nit during the security review. Regards, -sm From sm@resistor.net Mon Feb 8 15:52:20 2010 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 511CE28C1C4 for ; Mon, 8 Feb 2010 15:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] 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 Pc6u1x6pva+R for ; Mon, 8 Feb 2010 15:52:19 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 9FDC528C10E for ; Mon, 8 Feb 2010 15:52:19 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4/8.14.4) with ESMTP id o18Nqqul002112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 15:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1265673202; x=1265759602; bh=HJ5d77nEtOcvhB5rs+dQumNI/i7WRSZfcBoz1aFfxAU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=U9aboje+G9ufgTH12hL/pnTqDZFZe4XVk/Xk+VhFd2fuWyPHQVIsA6LSW8Je9meZn 9x1homYDUqG/3krCvYzMuw8bVFmPKUGG03PZO+e5OHzEcWl+Eimhn+aLHYF3mbLrQl P77nVg238Rf0cDayPoXvJDht5Vm8u0MCjXXXbG1M= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=kg4nwVSuthEauH6e9MZRLYJt7fT/r0/Rg0S28XiAHv6zoI6EbcsFFDvCGvq2lLoRS ssx/M47/G9Ln+3+AMGyCHZbCqN8KWjlX7C2OhvQfx7Kz/wetD9IXs/mer4ZVw5Bp7Y1 +uZUOO33Bfgwukf871WohS0RtNg0ketHIXCjrN4= Message-Id: <6.2.5.6.2.20100208154002.090a1d80@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 Feb 2010 15:44:24 -0800 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 23:52:20 -0000 Hi Murray, At 13:03 08-02-10, Murray S. Kucherawy wrote: >Consider a message that purports to be ARF, but is missing the third >part. Then a parser can legitimately conclude that the message >conforms to multipart/report, but does not conform to ARF. I think >that's acceptable based on the specifications, and would then be a >matter for local policy to decide how to handle it. That sounds doable. >How about: > >"[EMAIL-ARCH] introduces several terms and concepts that are used in >this memo, and thus readers are advised to become familiar with it as well." That's fine. >So should that be a MUST NOT? I'm not sure we can safely do that, >as that would suggest they are not allowed in the general message >header field registry. That's one of the questions I was thinking about as the I-D creates a "Feedback Report Header Fields" registry. Regards, -sm From sm@resistor.net Mon Feb 8 15:52:31 2010 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 9175528C1C9 for ; Mon, 8 Feb 2010 15:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] 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 tJoOF4a+xrJf for ; Mon, 8 Feb 2010 15:52:30 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id B739228C1C8 for ; Mon, 8 Feb 2010 15:52:30 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4/8.14.4) with ESMTP id o18Nqqun002112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 15:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1265673208; x=1265759608; bh=7z68EHkOYGxyl7JpKiA3T0uoUGuv3vXbAZlP63Z7vs0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ZeOHKqNqQMPKWkbp2eUYRvGHYe3oKQQF7h8BcFK2AyJPVXlfNrA4X5gS0IiVTJMRL iOg/S5AnmRxGJh0MRfOHNOrQ0iTQmOHPikpTZmv3ckZLHaWY7xICUaHwydLhGEJgiN QD975c0zjbL0Hp24lJEq+Esf9QhvJqlg0U+PwTjA= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=FVEpw9t2kyOWE9H1p+EUCWf0OkffbRP8HrVEaNz1XGGxf9E7fTJetDhWM79uPKmJy jOryHJBxYKyzZT6U2UbvNHJxMTNmvhymGvCrM49VQ9J3AN+HhE8UOtzzK8Xn1rsey0I piHO+k5J1TbIMB8o/K10F04Db1NsmWJL2dy8oUk= Message-Id: <6.2.5.6.2.20100208154439.05666c78@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 Feb 2010 15:51:50 -0800 To: dcrocker@bbiw.net From: SM In-Reply-To: <4B70824D.1050201@dcrocker.net> References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <4B70824D.1050201@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 23:52:31 -0000 Hi Dave, At 13:29 08-02-10, Dave CROCKER wrote: >I see the word 'purported' used only that one time and it isn't >defined. And I've registered my concern with ambiguity of the term >'sender' many times. Since this is a specification and the agent >being called 'purported sender' has fundamental semantic and >security implications, I do believe the relevant terminology needs >to be defined and used carefully. Sender would be ambiguous as there is a reference to DKIM and SPF in that sentence. It would be easier to drop "purported sender". >That said, this is a format spec, not a protocol spec. So the >obligations about identifying agents of action is limited. Yes. >However I also note that that section of 5.2 calls on using DKIM for >validating content and, technically, DKIM doesn't do that... > >So I'm going to suggest hacking the paragraph a bit, from: > >> It is recommended that ARF reports be vetted using common message >> authentication schemes such as [DKIM], [SPF] or [SENDERID] to confirm >> that they represent a valid message from the purported sender of the >> report prior to the undertaking of any kind of automated action in >> response to receipt of the report. > > It is recommended that the ownership of an ARF report be vetted, > such as by using common message accountability schemes such as > [DKIM], [SPF] or [SENDERID], prior to the undertaking of any kind > of automated action in response to receipt of the report. The > details of the required validation, to achieve this, are outside > the scope of this specification. That sounds better. Regards, -sm From msk@cloudmark.com Mon Feb 8 15:59:26 2010 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 7738428C1B2 for ; Mon, 8 Feb 2010 15:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599] 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 iOIpU7KzINDr for ; Mon, 8 Feb 2010 15:59:25 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id C0A093A7182 for ; Mon, 8 Feb 2010 15:59:25 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 8 Feb 2010 16:00:29 -0800 From: "Murray S. Kucherawy" To: SM Date: Mon, 8 Feb 2010 16:00:29 -0800 Thread-Topic: [marf] Comments on draft-ietf-marf-base-00 Thread-Index: AcqpGeNps4k0njNpQ36GpNUIyDvBNAAAHMIA Message-ID: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <6.2.5.6.2.20100208151819.05666f48@resistor.net> In-Reply-To: <6.2.5.6.2.20100208151819.05666f48@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Mon, 08 Feb 2010 23:59:26 -0000 > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Monday, February 08, 2010 3:39 PM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: RE: [marf] Comments on draft-ietf-marf-base-00 >=20 > >I'll fix the typo and it looks like a current URL has already been > >provided in a different reply. But what would the appropriate > >section be if not the Informative References? >=20 > Yes but it is not a stable (long-lived) reference. I suggest moving > them to the appropriate section if you want to acknowledge the work. >=20 > I do not consider a reference to a document that has part of the > boilerplate and which has not been submitted as an I-D as an > appropriate reference. I'm at a loss as to how you're suggesting we proceed here. There are only = two references sections, and I don't believe this warrants being classified= as normative. What are you suggesting is "the appropriate section"? > >Would changing "header area" to just "header" be sufficient? >=20 > I need to go through some RFCs before I answer. >=20 > >Are those different things? >=20 > Yes. I'm confused here too. Please elaborate. > >Yep, you're right. How about this? > > > >"It follows that any attack against an authentication method that > >might be used to protect the authenticity of an abuse report is also > >a security consideration here." >=20 > That's fine with me. It might raise a nit during the security review. What nit are you foreseeing? This text was fine for RFC5451, for example. From yakov@shaftek.org Mon Feb 8 16:13:53 2010 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 113DE3A72C0 for ; Mon, 8 Feb 2010 16:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 sEzOvOzWGObl for ; Mon, 8 Feb 2010 16:13:52 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 11AC13A7182 for ; Mon, 8 Feb 2010 16:13:51 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so1605415eye.51 for ; Mon, 08 Feb 2010 16:14:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.85.83 with SMTP id t61mr512693wee.167.1265674492151; Mon, 08 Feb 2010 16:14:52 -0800 (PST) In-Reply-To: References: <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com> <20100207213213.67BFDF580A7@smtp.patriot.net> <501c18e01002071451y7e411c4cy1a08a6ffffc43fcc@mail.gmail.com> From: Yakov Shafranovich Date: Mon, 8 Feb 2010 19:14:32 -0500 Message-ID: <501c18e01002081614x71a7a5bu743ffe1ffc724dcf@mail.gmail.com> To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] [MARF] Additional MIME subparts 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, 09 Feb 2010 00:13:53 -0000 On Mon, Feb 8, 2010 at 1:53 PM, Murray S. Kucherawy wro= te: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of >> Yakov Shafranovich >> Sent: Sunday, February 07, 2010 2:52 PM >> To: marf@ietf.org >> Subject: Re: [marf] [MARF] Additional MIME subparts >> >> I don't think this is a problem at all. The following is a quote from >> RFC 3462, which defines multipart/report used by ARF: >> >> " The text in the first section may be in any MIME standards-track >> =A0 =A0content-type, charset, or language. =A0Where a description of the >> error >> =A0 =A0is desired in several languages or several media, a >> =A0 =A0Multipart/Alternative construct may be used. >> " >> >> Note the last sentence - multipart/alternative can be used to embed >> additional MIME parts inside the first part of a multipart/report. I >> don't see a reason why multipart/mixed cannot be used as well which >> will give you ability to embed files. > > [as participant] > > I don't think this conforms to the general intent of RFC3462, which to me= fairly clearly intended the first MIME part to contain a human-readable de= scription of what's in the other parts. =A0Using multipart/alternative ther= e is consistent with that, but using multipart/mixed to pack parts of the a= ctual report into it seems to deviate from that intent. > I would have to say that multipart/mixed is how regular email messages right now relay attachments, and I don't think it is far fetched to allow this in ARF. > The part where we can define extensions of the nature we're discussing, w= ithin the RFC3462 framework, is the second part. =A0If we want to accommoda= te additional data outside the "name: value" format we have now, we'd have = to say that message/feedback-report is itself a multipart and then establis= h the requisite structure around that. > > Given that one of the chartered goals is to maintain backward compatibili= ty with existing deployments, I suspect we can't accommodate anything that = complex until we're discussing ARF extensions in later draft work. =A0But t= his is something we should revisit at that time. > Perhaps. I do wonder if multipart/mixed has ever been used with DSNs. From sm@resistor.net Tue Feb 9 01:53:47 2010 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 491493A6EEB for ; Tue, 9 Feb 2010 01:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599] 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 GqSF79RkzsKq for ; Tue, 9 Feb 2010 01:53:45 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id B3A7D3A67A8 for ; Tue, 9 Feb 2010 01:53:45 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4/8.14.4) with ESMTP id o199sduK018779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 01:54:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1265709288; x=1265795688; bh=P1rmS/XV8jC5nsD9XK8owCUHzrwj7KbNbFmaExWW/2I=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=VVx1Lv18OMyydzoOdgervgJI710kpzAG42e/B0PuWRsL1z98WspQENIN9lr9imdFS yBkvYzCVwWfjSSF3sC3LXqJ0NmddlfAaA6z3rG4FizUGZt9Ps6C3ZJY862VWVolXJ1 XQuUXAYoz7/d45mmvXN/d0oONcFwDOSMhp7Z7vOA= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=ycVfYu5fwcs1e2OWeiPSDe2GcKJ/PcVnuGTT4Ca+vfXWt7k6ql8CZ93iVBSGGLB8O 6t/GAIgkXT+l6s8pBI8hrHJZiCr2oFDAHuQokDCjKxUg+YK2UoVY6lDJH8rJ5Z5j/8w z4f84Vr+gVVR6YbmSmj18JalwHiLyZ09SE1T5Y0= Message-Id: <6.2.5.6.2.20100209000859.09077d50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 Feb 2010 01:41:43 -0800 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <6.2.5.6.2.20100207213326.0821dd60@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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, 09 Feb 2010 09:53:47 -0000 Hi Murray, At 13:26 08-02-10, Murray S. Kucherawy wrote: >I like this approach, but it needs more thought to be included in a >normative part of a specification such as Section 2d of this >I-D. In particular, I don't think we can use normative language >where the decision is actually subjective; that is, I don't think >one can write "You MUST do X unless you don't think the recipient >will actually need it" because the sender doesn't know what software >or internal processes may exist at the receiver. Yes, it could go in Section 2. The "MUST" excludes the "a very good reason not to do so". >I think we'd be much safer to say the third part MUST always be there. Is the information in the third part important for the feedback report to be meaningful? If so, it has to be included. Dave mentioned protocol and format in another message. As the I-D defines a format, there are some points that could be discussed in other documents. >ADMD is only used for discussion, so expanding it on first use is >fine but I don't think it needs to be normative. (Can an >informational draft be normative anyway?) The short answer is that an information RFC can be normative. If an informational I-D is normative, the I-D referencing it will be on hold (wait for publication). >I can conceive of an automatically-generated ARF report where for >example a spam filter is programmed to generate ARFs for suspect >messages right at the MTA. (We might even want to mention that as a >possible DoS vector.) The potential for a denial of service is worthy of a discussion in the I-D. BTW, Section 3 mentions automated use and Section 6.3 mentions avoiding amplification "attacks". >If an ARF is generated without a NULL envelope sender but aimed at >an address that doesn't work, then the generating address can also >get bombed by DSNs. But the tradeoff is that with the NULL sender, >legitimate ARFs that don't get delivered are never detected. The above or some text along those lines could be discussed in the I-D. You then get around specifying NULL envelope sender (reverse-path) as a requirement. I did not bring up the question of ARF messages generating ARF reports as it doesn't make sense to do that. Regards, -sm From sm@resistor.net Tue Feb 9 01:53:51 2010 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 08D2A3A71D0 for ; Tue, 9 Feb 2010 01:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] 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 LEzmU3+NrYL9 for ; Tue, 9 Feb 2010 01:53:50 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 5DCE23A7170 for ; Tue, 9 Feb 2010 01:53:50 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4/8.14.4) with ESMTP id o199sduM018779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 01:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1265709294; x=1265795694; bh=L5SwvRnUpZdmXqsvlH4sd+6hHP1rw+CvS/GPkgqW3Js=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ursJtux/n5ErhvtQoYHQi1gFMRebxd7HXED3y5PMAPEwt2p+vmw212I9qiyLl35ib pguf0F+vee7+lWF2Gu+Kw+r0cr6Bcr+Eenkc12XRqkxhEKg2CDdKFIeaM70bEaRujH InEypYCnrrnrns9xMvCtGpdLIPCXtfD9f7ZNfSRE= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=Ujk/MaCelzRzeqpod2K07UhwZAQML3CnBt5O2ZtkCAhrWDbLThkLhOxaft0LG4TvG Kogn7Tqu8OZIMN/fg27QB1ymXRG32ppIKU0UvP/zKOsJ0HwuzJLsPUiyNAcMzzwV1Dz votYVwaouQ/gor9upGpYkEbeSJXJrFb5OEFQPds= Message-Id: <6.2.5.6.2.20100209014146.05635a60@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 Feb 2010 01:49:57 -0800 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <6.2.5.6.2.20100208151819.05666f48@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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, 09 Feb 2010 09:53:51 -0000 Hi Murray, At 16:00 08-02-10, Murray S. Kucherawy wrote: >I'm at a loss as to how you're suggesting we proceed here. There >are only two references sections, and I don't believe this warrants >being classified as normative. > >What are you suggesting is "the appropriate section"? This is a nit. You can ignore it. It could be in the Acknowledgements Section. >I'm confused here too. Please elaborate. Dave provided an explanation. I'll elaborate if you still consider this as confusing. >What nit are you foreseeing? This text was fine for RFC5451, for example. It's the kind of nit that was raised during the RFC 5451 discussion. Dave mentioned "message accountability schemes". Getting into "authentication" may not be necessary then. Regards, -sm From vesely@tana.it Tue Feb 9 04:05:22 2010 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 D2C5D3A7258 for ; Tue, 9 Feb 2010 04:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.684 X-Spam-Level: X-Spam-Status: No, score=-4.684 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBVlTAwQiQFR for ; Tue, 9 Feb 2010 04:05:22 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id C3BB53A704B for ; Tue, 9 Feb 2010 04:05:21 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 09 Feb 2010 13:06:27 +0100 id 00000000005DC02B.000000004B714FC3.00002B0F Message-ID: <4B714FC3.6060400@tana.it> Date: Tue, 09 Feb 2010 13:06:27 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <4B703BCF.1070604@tana.it> <10DA6B81-6357-4849-B937-55DBC2814CA0@wordtothewise.com> In-Reply-To: <10DA6B81-6357-4849-B937-55DBC2814CA0@wordtothewise.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Bounces (was: Comments on draft-ietf-marf-base-00 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, 09 Feb 2010 12:05:23 -0000 On 08/Feb/10 20:09, Steve Atkins wrote: > On Feb 8, 2010, at 8:29 AM, Alessandro Vesely wrote: >> +1. A loop-avoidance specification just needs to ensure that ARF reports are never reported as spam. > > It's an even lower bar - it just needs to ensure that inbound ARF reports are > never automatically trigger outbound ones. (If an ARF consumer hits > the TiS button and sends a spam report about an ARF formatted mail > manually it won't break anything). However, an ARF consumer may (automatically) forward a report as part of its processing. IMHO, this deserves rewriting the first two parts, rather than encapsulating the whole message the way a TiS button would. It is quite likely that duplicates or possibly loops may result, one way or another. > I don't see a need for anything ARF-specific to break loops here. Yes, there was consensus about postponing this subject to a subsequent BCP. Will it be able to define any required field it may need? (E.g. a level, a.k.a. stratum or hop number, X-WillBeThere, CC, or any handy way of tracing which recipients have already been considered.) Then, we might just mention that possibility, e.g. When generating an ARF message, it is necessary to construct the message so as to avoid amplification or backscatter attacks, deliberate or otherwise. In particular, per Section 2 of [DSN], when an SMTP transaction is used to send an ARF message, the MAIL FROM command MAY use a NULL return address, i.e. "MAIL FROM:<>". In addition, if processing of ARF messages provides for generating further ARF messages based on the same original message, then the generator MUST ensure that no recipients have already received it. Algorithms for accomplishing such task, based on data contained in the header or the feedback-report fields, are beyond the scope of this specification. From shmuel+gen@patriot.net Tue Feb 9 05:37:18 2010 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 958613A7393 for ; Tue, 9 Feb 2010 05:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 ss1gDy57AjXB for ; Tue, 9 Feb 2010 05:37:17 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 8810C3A738B for ; Tue, 9 Feb 2010 05:37:17 -0800 (PST) Received: from ECS35455305 (core-dc-1-216.dynamic-dialup.coretel.net [69.72.26.216]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 49174F5809B for ; Tue, 9 Feb 2010 08:41:42 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Mon, 08 Feb 2010 12:16:30 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100209134142.49174F5809B@smtp.patriot.net> Subject: Re: [marf] Comments on draft-ietf-marf-base-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 13:37:18 -0000 In , on 02/08/2010 at 08:47 AM, "John R Levine" said: >That horse left the barn years ago. Remember that we don't "allow" >people to do anything, we write specs that we hope that parties hoping >to interoperate will find it worth their while to implement. Part of that is specifying what is and is not compliant. There's nothing wrong dith definig a flag and specifying that the third MIME part MUST NOT be redacted unless the flag is set. -- 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 Tue Feb 9 06:26:47 2010 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 EDD803A71FE for ; Tue, 9 Feb 2010 06:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.685 X-Spam-Level: X-Spam-Status: No, score=-4.685 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oidcaCbAPqX for ; Tue, 9 Feb 2010 06:26:46 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 9373E3A7363 for ; Tue, 9 Feb 2010 06:26:46 -0800 (PST) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 09 Feb 2010 15:27:48 +0100 id 00000000005DC031.000000004B7170E4.00003DD6 Message-ID: <4B7170E4.6020702@tana.it> Date: Tue, 09 Feb 2010 15:27:48 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 09 Feb 2010 14:26:48 -0000 On 08/Feb/10 18:44, Murray S. Kucherawy wrote: > The spec currently says: > > o "Reported-Domain" includes a domain name that the report generator > believes to be relevant to the report, e.g. the domain whose > apparent actions provoked the generation of the report. Domain > format is defined in section 2.3.1 of [DNS]. > > This is a bit vague. If machine parsing is the intent, then the spec should indicate specifically how or why that domain might have been chosen. I'd say "responsible for injecting the original message", rather than "relevant to the report". The how and why would be expressed in the Authentication-Results feedback field (which may match its namesake in the original message's header.) > So how are generators using this field? I've seen "Reported-Domain: mail.tana.it" from AOL SComp. That name is not the helo name of the transmitter, but one of the PTRs associated with its address. They could have set "Reported-Domain: tana.it", based on SPF authentication, which might have been slightly more meaningful. Should the spec get down to detailing such sort of preferences? From jdfalk-lists@cybernothing.org Tue Feb 9 12:38:12 2010 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 095763A6D1D for ; Tue, 9 Feb 2010 12:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.666 X-Spam-Level: X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, 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 BedK+g3X1Og1 for ; Tue, 9 Feb 2010 12:38:11 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id E5AC63A6C7E for ; Tue, 9 Feb 2010 12:38:10 -0800 (PST) Received: from jds-macbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o19KdEnK031325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 9 Feb 2010 13:39:17 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o19KdEnK031325 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1265747957; bh=fkO+42npqC6IK+I75KQ449iwlhlqwPFGYCujWtAk jd8=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=qnOCrNlJDl4DFkg8 9ELsHGFa4G1lXyz4ZCjIDfxN+Mpx4MoLVQPFts7OFrS/8Vwe3YXmDwtdSoNbc67Nlj1 WT/eW/r5l6ttSVJmTrFnzBuYzT+/gulj9azp1VXyQQekK0xRfEIbE+DmeDriP87nJ4l RM6jGyTKpaTEksu6Efav4= References: <20100207213213.67BFDF580A7@smtp.patriot.net> In-Reply-To: <20100207213213.67BFDF580A7@smtp.patriot.net> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 9 Feb 2010 13:39:07 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] [MARF] Additional MIME subparts 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, 09 Feb 2010 20:38:12 -0000 On Feb 7, 2010, at 5:23 AM, Shmuel (Seymour J.) Metz wrote: > In <501c18e01002061622l7ee9ba53w61cbac8f9cc1ed1d@mail.gmail.com>, on > 02/06/2010 > at 07:22 PM, Yakov Shafranovich said: >=20 >> I think he is referring to a different issue - encapsulation.=20 >=20 > Indeed. The results of, e.g., whois, often include non-ASCII data. = Similar > issues may exist for other types of evidence. I hadn't thought of the > possible requirement to provide binary files, but that might also be = an > issue. Are there any ARF recipients interested in receiving "attached" metadata = like this? Perhaps you could define a local extension with them, see = how it works out, and report back to the working group. -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Tue Feb 9 12:43:01 2010 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 8B22B3A7270 for ; Tue, 9 Feb 2010 12:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.67 X-Spam-Level: X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, 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 zQmC5q7+FDsQ for ; Tue, 9 Feb 2010 12:43:00 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 81F9E3A72F4 for ; Tue, 9 Feb 2010 12:43:00 -0800 (PST) Received: from jds-macbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o19Ki51M031414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 9 Feb 2010 13:44:07 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o19Ki51M031414 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1265748247; bh=MhsXppv4T/F8V4ToZ/iSDLniMJCgCxUV1iOk+WlV 0Nk=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=Jrd01pjtJDKBvrCn z3+I+Ql65aFCPHdhhSMkgIpxmyC9BBRrA8TYV0Z4O2SE/Ew2QBNMkBXkDmZjFm1R4Lv wHLvzu8ZzMXOpmbD6jbRI79mK2fLprU0g0qytvolNOODrKnkOM3AUAG01ubOG8AbR0O DyVEOpoHoBnsNsWHSFoHQ= References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <4B703BCF.1070604@tana.it> <10DA6B81-6357-4849-B937-55DBC2814CA0@wordtothewise.com> In-Reply-To: <10DA6B81-6357-4849-B937-55DBC2814CA0@wordtothewise.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <412F8A72-80EB-40AA-8FDE-561664608F54@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 9 Feb 2010 13:44:00 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Bounces (was: Comments on draft-ietf-marf-base-00 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, 09 Feb 2010 20:43:01 -0000 On Feb 8, 2010, at 12:09 PM, Steve Atkins wrote: >> +1. A loop-avoidance specification just needs to ensure that ARF = reports are never reported as spam. >=20 > It's an even lower bar - it just needs to ensure that inbound ARF = reports are > never automatically trigger outbound ones. (If an ARF consumer hits > the TiS button and sends a spam report about an ARF formatted mail > manually it won't break anything). >=20 > I don't see a need for anything ARF-specific to break loops here. +1 -- J.D. Falk Return Path Inc From shmuel+gen@patriot.net Wed Feb 10 04:28:09 2010 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 392A028C112 for ; Wed, 10 Feb 2010 04:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 sAhZq-MmGsJk for ; Wed, 10 Feb 2010 04:28:08 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 380FA3A76D7 for ; Wed, 10 Feb 2010 04:28:08 -0800 (PST) Received: from ECS35455305 (core-dc-1-151.dynamic-dialup.coretel.net [69.72.26.151]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id A9A68F580A9 for ; Wed, 10 Feb 2010 07:32:33 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 09 Feb 2010 11:56:15 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100210123234.A9A68F580A9@smtp.patriot.net> Subject: Re: [marf] Comments on draft-ietf-marf-base-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 12:28:09 -0000 In , on 02/08/2010 at 01:26 PM, "Murray S. Kucherawy" said: >I don't have a problem with that small change, except that it might fly >in the face of later registrations of those names in the IANA header >field registry. "This in no way restricts the use of message header fields that are registered in the IANA header field registry with the same field names." -- 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 shmuel+gen@patriot.net Wed Feb 10 04:28:14 2010 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 05A0828C131 for ; Wed, 10 Feb 2010 04:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.486 X-Spam-Level: X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 EGTfuFXc7uAN for ; Wed, 10 Feb 2010 04:28:13 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 37AA03A735F for ; Wed, 10 Feb 2010 04:28:13 -0800 (PST) Received: from ECS35455305 (core-dc-1-151.dynamic-dialup.coretel.net [69.72.26.151]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 407A7F580A9 for ; Wed, 10 Feb 2010 07:32:38 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 09 Feb 2010 11:39:09 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100210123239.407A7F580A9@smtp.patriot.net> Subject: Re: [marf] Comments on draft-ietf-marf-base-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 12:28:14 -0000 In , on 02/08/2010 at 01:10 PM, "Murray S. Kucherawy" said: >Given that we're tending toward making this format most useful by >machines, how would they use that flag if it were set? If we allow redaction in report-type=feedback-report, then the flag would be useful for automated processing. If we don't, then it would be useful only for human readers. -- 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 shmuel+gen@patriot.net Wed Feb 10 05:02:47 2010 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 E5A5A3A7550 for ; Wed, 10 Feb 2010 05:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_05=-1.11, DATE_IN_PAST_12_24=0.992] 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 TrvNWy2ikJki for ; Wed, 10 Feb 2010 05:02:47 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id F0A063A7375 for ; Wed, 10 Feb 2010 05:02:46 -0800 (PST) Received: from ECS35455305 (core-dc-1-151.dynamic-dialup.coretel.net [69.72.26.151]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 98F8AF580A9 for ; Wed, 10 Feb 2010 08:07:14 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Tue, 09 Feb 2010 11:39:09 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100210130714.98F8AF580A9@smtp.patriot.net> Subject: Re: [marf] Comments on draft-ietf-marf-base-00 X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 13:02:48 -0000 In , on 02/08/2010 at 01:10 PM, "Murray S. Kucherawy" said: >Given that we're tending toward making this format most useful by >machines, how would they use that flag if it were set? If we allow redaction in report-type=feedback-report, then the flag would be useful for automated processing. If we don't, then it would be useful only for human readers. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Wed Feb 10 10:25:19 2010 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 9D4A03A7775 for ; Wed, 10 Feb 2010 10:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599] 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 ON0HX6o7KwHC for ; Wed, 10 Feb 2010 10:25:18 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 53F1A3A777E for ; Wed, 10 Feb 2010 10:25:18 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 10 Feb 2010 10:26:29 -0800 From: "Murray S. Kucherawy" To: SM Date: Wed, 10 Feb 2010 10:26:28 -0800 Thread-Topic: [marf] Comments on draft-ietf-marf-base-00 Thread-Index: AcqpbezFvNAgZxA1TCypwTKl2eOyLQBDvUlw Message-ID: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <6.2.5.6.2.20100207213326.0821dd60@resistor.net> <6.2.5.6.2.20100209000859.09077d50@resistor.net> In-Reply-To: <6.2.5.6.2.20100209000859.09077d50@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "marf@ietf.org" Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Wed, 10 Feb 2010 18:25:19 -0000 > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Tuesday, February 09, 2010 1:42 AM > To: Murray S. Kucherawy > Cc: marf@ietf.org > Subject: RE: [marf] Comments on draft-ietf-marf-base-00 >=20 > >I think we'd be much safer to say the third part MUST always be there. >=20 > Is the information in the third part important for the feedback > report to be meaningful? If so, it has to be included. How does an ARF generator make that decision? I don't think that logic can= be left unspecified. > >I can conceive of an automatically-generated ARF report where for > >example a spam filter is programmed to generate ARFs for suspect > >messages right at the MTA. (We might even want to mention that as a > >possible DoS vector.) >=20 > The potential for a denial of service is worthy of a discussion in > the I-D. BTW, Section 3 mentions automated use and Section 6.3 > mentions avoiding amplification "attacks". Here's a suggested subsection of Security Considerations to discuss this is= sue (pardon the XML and indentation): It is conceivable that a system may be implemen= ted that generates ARF reports automatically in response to an event. For example, software monitoring a honeypot email address might gener= ate an ARF report immediately upon delivery of any message to it. An attacker that becomes aware of such a configuration can exploit it to attack an ARF recipient with automatically generated ARF reports. > >If an ARF is generated without a NULL envelope sender but aimed at > >an address that doesn't work, then the generating address can also > >get bombed by DSNs. But the tradeoff is that with the NULL sender, > >legitimate ARFs that don't get delivered are never detected. >=20 > The above or some text along those lines could be discussed in the > I-D. You then get around specifying NULL envelope sender > (reverse-path) as a requirement. >=20 > I did not bring up the question of ARF messages generating ARF > reports as it doesn't make sense to do that. How about this?
requires that its reports be sent with the empty envelope sender to avoid bounce loops. A similar requirement was considered for this specification, but it seems unlikely that an ARF report would be generated in response to receipt of an ARF report, and furthermor= e such a requirement would prevent an ARF generator from ever determining that an ARF report was not actually received. On the other hand, if an ARF report is generated withou= t the empty envelope sender and is sent to an address tha= t actually does not work, then the generating address can also be overwhelmed by DSNs as a denial of service attack (see ). This specification therefore makes no requirement relat= ed to the envelope sender of a generated report. Operator= s will have to consider what envelope sender to use within the context of their own installations.
From msk@cloudmark.com Wed Feb 10 10:30:48 2010 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 D311B3A777F for ; Wed, 10 Feb 2010 10:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599] 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 9Mq4sdDNy+IE for ; Wed, 10 Feb 2010 10:30:47 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 0C6F03A7778 for ; Wed, 10 Feb 2010 10:30:47 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 10 Feb 2010 10:31:58 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 10 Feb 2010 10:31:57 -0800 Thread-Topic: [marf] Comments on draft-ietf-marf-base-00 Thread-Index: AcqqTK3Q5WJaqhDcRxu9yzuxedvdkgAMqCHw Message-ID: References: <20100210123234.A9A68F580A9@smtp.patriot.net> In-Reply-To: <20100210123234.A9A68F580A9@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Wed, 10 Feb 2010 18:30:49 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Shmuel Metz > Sent: Tuesday, February 09, 2010 8:56 AM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-base-00 >=20 > In > C2.corp.cloudmark.com>, > on 02/08/2010 > at 01:26 PM, "Murray S. Kucherawy" said: >=20 > >I don't have a problem with that small change, except that it might > fly > >in the face of later registrations of those names in the IANA header > >field registry. >=20 > "This in no way restricts the use of message header fields that are > registered in the IANA header field registry with the same field > names." +1. Added. From msk@cloudmark.com Wed Feb 10 10:33:31 2010 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 E9A543A777B for ; Wed, 10 Feb 2010 10:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599] 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 Wa3pTb4ZAlrZ for ; Wed, 10 Feb 2010 10:33:31 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 3B41C3A7780 for ; Wed, 10 Feb 2010 10:33:31 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 10 Feb 2010 10:34:42 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Wed, 10 Feb 2010 10:34:42 -0800 Thread-Topic: "Redacted" flag (was RE: [marf] Comments on draft-ietf-marf-base-00) Thread-Index: AcqpjSmmtvaZ2Gp4T+Obumc5wWrDVgA8jBUg Message-ID: References: <20100209134142.49174F5809B@smtp.patriot.net> In-Reply-To: <20100209134142.49174F5809B@smtp.patriot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [marf] "Redacted" flag (was RE: Comments on draft-ietf-marf-base-00) 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: Wed, 10 Feb 2010 18:33:32 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Shmuel Metz > Sent: Monday, February 08, 2010 9:17 AM > To: marf@ietf.org > Subject: Re: [marf] Comments on draft-ietf-marf-base-00 >=20 > In , on 02/08/2010 > at 08:47 AM, "John R Levine" said: >=20 > >That horse left the barn years ago. Remember that we don't "allow" > >people to do anything, we write specs that we hope that parties > hoping > >to interoperate will find it worth their while to implement. >=20 > Part of that is specifying what is and is not compliant. There's > nothing > wrong dith definig a flag and specifying that the third MIME part MUST > NOT > be redacted unless the flag is set. It seems to me from the discussion that at least some people would use such= a field if present, and I have some doubt that it would harm backward comp= atibility if we were to add it. So a couple of questions are important as = we consider actually making such an update: How would ARF recipients actually use such a flag if it is observed to be s= et? Would ARF generators object to setting that flag when redacting? From msk@cloudmark.com Wed Feb 10 10:35:22 2010 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 065B328C125 for ; Wed, 10 Feb 2010 10:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] 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 7cAILIvDRZIk for ; Wed, 10 Feb 2010 10:35:21 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 3C86328C17A for ; Wed, 10 Feb 2010 10:35:21 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 10 Feb 2010 10:36:32 -0800 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Wed, 10 Feb 2010 10:36:32 -0800 Thread-Topic: [marf] Bounces (was: Comments on draft-ietf-marf-base-00 Thread-Index: AcqpgFCTVhK9YuCPTmqsQdGDJQdcAwA/5Hig Message-ID: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <4B703BCF.1070604@tana.it> <10DA6B81-6357-4849-B937-55DBC2814CA0@wordtothewise.com> <4B714FC3.6060400@tana.it> In-Reply-To: <4B714FC3.6060400@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Bounces (was: Comments on draft-ietf-marf-base-00 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: Wed, 10 Feb 2010 18:35:22 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Tuesday, February 09, 2010 4:06 AM > To: marf@ietf.org > Subject: Re: [marf] Bounces (was: Comments on draft-ietf-marf-base-00 >=20 > Yes, there was consensus about postponing this subject to a subsequent > BCP. Will it be able to define any required field it may need? (E.g. a > level, a.k.a. stratum or hop number, X-WillBeThere, CC, or any handy > way of tracing which recipients have already been considered.) Then, > we might just mention that possibility, e.g. >=20 > When generating an ARF message, it is necessary to construct the > message so as to avoid amplification or backscatter attacks, > deliberate or otherwise. In particular, per Section 2 of [DSN], > when an SMTP transaction is used to send an ARF message, the MAIL > FROM command MAY use a NULL return address, i.e. "MAIL FROM:<>". In > addition, if processing of ARF messages provides for generating > further ARF messages based on the same original message, then the > generator MUST ensure that no recipients have already received it. > Algorithms for accomplishing such task, based on data contained in > the header or the feedback-report fields, are beyond the scope of > this specification. Sorry, I proposed some other text before I saw this one. Let me know if yo= u think that text needs adjustment, or if we should chuck it and go with th= is one, etc. From msk@cloudmark.com Wed Feb 10 10:40:10 2010 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 0790C3A776F for ; Wed, 10 Feb 2010 10:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] 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 ZUCX2lanCj0R for ; Wed, 10 Feb 2010 10:40:07 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 3DA503A73B6 for ; Wed, 10 Feb 2010 10:40:07 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 10 Feb 2010 10:41:18 -0800 From: "Murray S. Kucherawy" To: Alessandro Vesely , "marf@ietf.org" Date: Wed, 10 Feb 2010 10:41:18 -0800 Thread-Topic: [marf] Reported-Domain vs Reported-URI Thread-Index: AcqplBL0hAvGaKwfTCiv5iLcPDK8GgA7ArsQ Message-ID: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> <4B7170E4.6020702@tana.it> In-Reply-To: <4B7170E4.6020702@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 10 Feb 2010 18:40:10 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Alessandro Vesely > Sent: Tuesday, February 09, 2010 6:28 AM > To: marf@ietf.org > Subject: Re: [marf] Reported-Domain vs Reported-URI >=20 > On 08/Feb/10 18:44, Murray S. Kucherawy wrote: > > The spec currently says: > > > > o "Reported-Domain" includes a domain name that the report generat= or > > believes to be relevant to the report, e.g. the domain whose > > apparent actions provoked the generation of the report. Domain > > format is defined in section 2.3.1 of [DNS]. > > > > This is a bit vague. If machine parsing is the intent, then the spec > > should indicate specifically how or why that domain might have been > > chosen. >=20 > I'd say "responsible for injecting the original message", rather than > "relevant to the report". The how and why would be expressed in the > Authentication-Results feedback field (which may match its namesake in > the original message's header.) >=20 > > So how are generators using this field? >=20 > I've seen "Reported-Domain: mail.tana.it" from AOL SComp. That name is > not the helo name of the transmitter, but one of the PTRs associated > with its address. They could have set "Reported-Domain: tana.it", > based on SPF authentication, which might have been slightly more > meaningful. Should the spec get down to detailing such sort of > preferences? I think it should. If an ARF recipient sees this but has no indication of = the origin of the field's value, it has no assurances that it should or sho= uld not use that data in a particular way. Let's say I get a few different ARFs from completely different FBL sources = indicating "Reported-Domain: example.com". Unbeknownst to you, one is repo= rting the HELO, one is reporting domain of a URL it found inside the messag= e, one is the domain from the From: header field, one is the DKIM signature= domain. Is any correlation possible? As a software developer, I would be= tempted to discard that value as its meaning is undefined. From steve@wordtothewise.com Wed Feb 10 10:57:54 2010 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 6FAEB3A745B for ; Wed, 10 Feb 2010 10:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY2JQ4ZJ3Z95 for ; Wed, 10 Feb 2010 10:57:53 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 42BFF3A7389 for ; Wed, 10 Feb 2010 10:57:53 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 7E20C4F81C4 for ; Wed, 10 Feb 2010 10:59:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Wed, 10 Feb 2010 10:59:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> <4B7170E4.6020702@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 10 Feb 2010 18:57:54 -0000 On Feb 10, 2010, at 10:41 AM, Murray S. Kucherawy wrote: >>>=20 >>=20 >> I've seen "Reported-Domain: mail.tana.it" from AOL SComp. That name = is >> not the helo name of the transmitter, but one of the PTRs associated >> with its address. They could have set "Reported-Domain: tana.it", >> based on SPF authentication, which might have been slightly more >> meaningful. Should the spec get down to detailing such sort of >> preferences? >=20 > I think it should. =20 I don't, really. If you get prescriptive to that level of detail then A) = you make it less flexible and B) most everyone will ignore that section = of the spec anyway. :) > If an ARF recipient sees this but has no indication of the origin of = the field's value, it has no assurances that it should or should not use = that data in a particular way. >=20 > Let's say I get a few different ARFs from completely different FBL = sources indicating "Reported-Domain: example.com". Unbeknownst to you, = one is reporting the HELO, one is reporting domain of a URL it found = inside the message, one is the domain from the From: header field, one = is the DKIM signature domain. Is any correlation possible? As a = software developer, I would be tempted to discard that value as its = meaning is undefined. That value is very useful for triage, even if I then need to do some = work to work out why it's reported. If I have 100 reports that all have "Reported-Domain: foo.example.co" = then I know that there's some problem with foo.example.com, and I should = escalate that incident with my staff, even before I've done any parsing = of the individual messages. If, on later parsing, 30 of them have it as a From: field, 20 as a URL, = 30 as a HELO and 20 don't have any mention of it at all that doesn't = really affect the value of the triage step. Cheers, Steve From johnl@taugh.com Wed Feb 10 10:58:39 2010 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 8D4363A7223 for ; Wed, 10 Feb 2010 10:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.809 X-Spam-Level: X-Spam-Status: No, score=-10.809 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] 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 QfLw+QglKCJj for ; Wed, 10 Feb 2010 10:58:38 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 6832C3A6F67 for ; Wed, 10 Feb 2010 10:58:38 -0800 (PST) Received: (qmail 73516 invoked from network); 10 Feb 2010 18:59:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=vKbauqDE61rgfqWbJ6EJMjHVF4vzDcJaIfB5v99tqy0=; b=zWTseROhblrnNOEeu+6yRtTUzAUMtBcRLzGuAwvv9EP42ugTNuxgs2vwWly9Ag4r/tqoDuDtDvMVx/0covYQ0PMY6C+w+68WkxOO3w7PMYzb7/UCgkjQFa5jHLnd9OUXupgqrIhqWV2Ry5A/MaqwfS2CfOxTu55lvXAVtWNIfBk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=vKbauqDE61rgfqWbJ6EJMjHVF4vzDcJaIfB5v99tqy0=; b=fAquBUl+L96UC5Ej7G20z6PKLji3Bg4O1z/SS6N3fH31j1S6onx1yv4ATFKV5wM27JBBmpdnj+3itPM6Ywoy4ivDS/SBISll9SL8YkecN+ph7Gq8qENldxYrKIkByz+TT/eb7TbT+SFymd5a9dkklv03PWFTm+4mrLH43RuaPSg= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Feb 2010 18:59:26 -0000 Date: 10 Feb 2010 13:59:47 -0500 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20100209134142.49174F5809B@smtp.patriot.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Message Abuse Report Format working group Subject: Re: [marf] "Redacted" flag (was RE: Comments on draft-ietf-marf-base-00) 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: Wed, 10 Feb 2010 18:58:39 -0000 > How would ARF recipients actually use such a flag if it is observed to be set? > Would ARF generators object to setting that flag when redacting? I have my doubts about its utility, but AOL already sets it: Content-Type: message/feedback-report Feedback-Type: abuse User-Agent: AOL SComp Version: 0.1 Received-Date: Wed, 13 Jan 2010 03:04:37 -0500 (EST) Source-IP: 208.31.42.54 Reported-Domain: w4.iecc.com Redacted-Address: redacted Redacted-Address: redacted@ Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From msk@cloudmark.com Wed Feb 10 11:06:50 2010 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 EA3AA28C111 for ; Wed, 10 Feb 2010 11:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] 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 i8WVRfuZr7tA for ; Wed, 10 Feb 2010 11:06:49 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 861FD3A7040 for ; Wed, 10 Feb 2010 11:06:49 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 10 Feb 2010 11:08:01 -0800 From: "Murray S. Kucherawy" To: Steve Atkins , Message Abuse Report Format working group Date: Wed, 10 Feb 2010 11:08:00 -0800 Thread-Topic: [marf] Reported-Domain vs Reported-URI Thread-Index: Acqqgx+4KqQr0MHMQHO38WSsRKtJDAAAMsPw Message-ID: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> <4B7170E4.6020702@tana.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 10 Feb 2010 19:06:51 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Steve Atkins > Sent: Wednesday, February 10, 2010 10:59 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] Reported-Domain vs Reported-URI >=20 > > If an ARF recipient sees this but has no indication of the origin of > > the field's value, it has no assurances that it should or should not > > use that data in a particular way. > > > > Let's say I get a few different ARFs from completely different FBL > > sources indicating "Reported-Domain: example.com". Unbeknownst to you, > > one is reporting the HELO, one is reporting domain of a URL it found > > inside the message, one is the domain from the From: header field, one > > is the DKIM signature domain. Is any correlation possible? As a > > software developer, I would be tempted to discard that value as its > > meaning is undefined. >=20 > That value is very useful for triage, even if I then need to do some > work to work out why it's reported. >=20 > If I have 100 reports that all have "Reported-Domain: foo.example.co" > then I know that there's some problem with foo.example.com, and I > should escalate that incident with my staff, even before I've done any > parsing of the individual messages. >=20 > If, on later parsing, 30 of them have it as a From: field, 20 as a URL, > 30 as a HELO and 20 don't have any mention of it at all that doesn't > really affect the value of the triage step. But as has been mentioned here several times, the goal is automated parsing= . Does your statement still apply to someone trying to write code to handl= e ARFs in an automatic fashion when the real meaning of that field is unkno= wn and could've been forged anyway? If the answer (actually, the consensus) is "yes" then I'd like to see the d= ocument be explicit about why the source of that value isn't being specific= ally defined. Would you care to suggest some text to that effect to be add= ed? From steve@wordtothewise.com Wed Feb 10 11:13:07 2010 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 D1E993A75B7 for ; Wed, 10 Feb 2010 11:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRvFpJFVUd7M for ; Wed, 10 Feb 2010 11:13:05 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id C36613A73B5 for ; Wed, 10 Feb 2010 11:13:05 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 5BAAF4F81C8 for ; Wed, 10 Feb 2010 11:14:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Wed, 10 Feb 2010 11:14:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> <4B7170E4.6020702@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 10 Feb 2010 19:13:07 -0000 On Feb 10, 2010, at 11:08 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of >> Steve Atkins >> Sent: Wednesday, February 10, 2010 10:59 AM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] Reported-Domain vs Reported-URI >>=20 >>> If an ARF recipient sees this but has no indication of the origin of >>> the field's value, it has no assurances that it should or should not >>> use that data in a particular way. >>>=20 >>> Let's say I get a few different ARFs from completely different FBL >>> sources indicating "Reported-Domain: example.com". Unbeknownst to = you, >>> one is reporting the HELO, one is reporting domain of a URL it found >>> inside the message, one is the domain from the From: header field, = one >>> is the DKIM signature domain. Is any correlation possible? As a >>> software developer, I would be tempted to discard that value as its >>> meaning is undefined. >>=20 >> That value is very useful for triage, even if I then need to do some >> work to work out why it's reported. >>=20 >> If I have 100 reports that all have "Reported-Domain: foo.example.co" >> then I know that there's some problem with foo.example.com, and I >> should escalate that incident with my staff, even before I've done = any >> parsing of the individual messages. >>=20 >> If, on later parsing, 30 of them have it as a From: field, 20 as a = URL, >> 30 as a HELO and 20 don't have any mention of it at all that doesn't >> really affect the value of the triage step. >=20 > But as has been mentioned here several times, the goal is automated = parsing. Does your statement still apply to someone trying to write = code to handle ARFs in an automatic fashion when the real meaning of = that field is unknown and could've been forged anyway? Absolutely. The meaning of that field, to me anyway, is "This hostname = is why we chose to send the report to you." with the implication that = it's the thing you should key your triage handler on. Anything in the original message could have been forged too, pretty = much, and often is. FBL reports for spam where the spammer has cut and = pasted content from mail you've sent, for use as filter-fodder isn't at = all unusual. > If the answer (actually, the consensus) is "yes" then I'd like to see = the document be explicit about why the source of that value isn't being = specifically defined. Would you care to suggest some text to that = effect to be added? "The hostname in the Reported-Domain: field is the reason the sender of = the report chose to send it to you. The domain may be mentioned = explicitly in the original message, or may be derived from it in some = way. In cases where the derivation isn't obvious the report author is = encouraged to clarify in the human readable section of the report." or = something like that? Cheers, Steve From msk@cloudmark.com Wed Feb 10 12:25:24 2010 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 D8FD028C22C for ; Wed, 10 Feb 2010 12:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] 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 14fpYx0Eid7c for ; Wed, 10 Feb 2010 12:25:24 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id A00AF3A7795 for ; Wed, 10 Feb 2010 12:25:23 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 10 Feb 2010 12:26:35 -0800 From: "Murray S. Kucherawy" To: Steve Atkins , Message Abuse Report Format working group Date: Wed, 10 Feb 2010 12:26:34 -0800 Thread-Topic: [marf] Reported-Domain vs Reported-URI Thread-Index: AcqqhUAB5nQdZq2WT86SgEYItgZqkwACfm8g Message-ID: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> <4B7170E4.6020702@tana.it> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> In-Reply-To: <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 10 Feb 2010 20:25:24 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Steve Atkins > Sent: Wednesday, February 10, 2010 11:14 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] Reported-Domain vs Reported-URI >=20 > "The hostname in the Reported-Domain: field is the reason the sender of > the report chose to send it to you. The domain may be mentioned > explicitly in the original message, or may be derived from it in some > way. In cases where the derivation isn't obvious the report author is > encouraged to clarify in the human readable section of the report." or > something like that? If it's OK that I also say something like "therefore, general automated par= sing based on the value of this field SHOULD NOT be done", I'm fine with th= at. From steve@wordtothewise.com Wed Feb 10 12:37:26 2010 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 1EA8F28C286 for ; Wed, 10 Feb 2010 12:37:26 -0800 (PST) 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 pB3iAYVqEj4C for ; Wed, 10 Feb 2010 12:37:25 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id BC27328C283 for ; Wed, 10 Feb 2010 12:37:21 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 7A63580906 for ; Wed, 10 Feb 2010 12:38:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Wed, 10 Feb 2010 12:38:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> <4B7170E4.6020702@tana.it> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 10 Feb 2010 20:37:26 -0000 On Feb 10, 2010, at 12:26 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of >> Steve Atkins >> Sent: Wednesday, February 10, 2010 11:14 AM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] Reported-Domain vs Reported-URI >>=20 >> "The hostname in the Reported-Domain: field is the reason the sender = of >> the report chose to send it to you. The domain may be mentioned >> explicitly in the original message, or may be derived from it in some >> way. In cases where the derivation isn't obvious the report author is >> encouraged to clarify in the human readable section of the report." = or >> something like that? >=20 > If it's OK that I also say something like "therefore, general = automated parsing based on the value of this field SHOULD NOT be done", = I'm fine with that. No, automated triage is exactly what it's most useful for. It's almost a = SHOULD rather than a SHOULD NOT. :) If I'm a webhoster with 10,000 domains then the very first thing I'm = going to do with a FBL is to choose something to key triage aggregation = on - so I can route and report on incidents efficiently. An IP address = is better than nothing, but the ideal key to use is the domain that's = being reported. It's the cases where it's not immediately obvious from the content of = the original email why you received the report that the Reported-Domain: = field is most useful - as it allows you to triage it and aggregate it = with other reports about the domain in a way that you otherwise couldn't = do. So if there are 100 reports claiming to be about the domain, and you can = mechanically identify why for 60 of those reports then you can do two = things - a) treat the incident as one with 100 reports rather than 60 = and b) treat the remaining 40 reports as "likely correctly categorised" = rather than "need to each be handled manually". Even more extreme, if you get 100 reports claiming to be about the = domain and you can't mechanically identify why in any of them, you can = still aggregate them into a single incident, treat that incident as one = that's received 100 reports and then eyeball a couple of the reports as = "probably representative of the 100" to see what's going on. (I'm probably using some jargon specific to the way we use Abacus to = handle high volume report streams, but the principle is pretty general.) Cheers, Steve From shmuel+gen@patriot.net Wed Feb 10 13:50:50 2010 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 B81A33A77C1 for ; Wed, 10 Feb 2010 13:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] 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 uMU6GjwDiBVj for ; Wed, 10 Feb 2010 13:50:49 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 8C53C3A77BF for ; Wed, 10 Feb 2010 13:50:49 -0800 (PST) Received: from ECS35455305 (core-dc-1-129.dynamic-dialup.coretel.net [69.72.26.129]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id C8943F580BA for ; Wed, 10 Feb 2010 16:55:15 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 10 Feb 2010 09:41:21 -0500 To: marf@ietf.org In-Reply-To: <4B7170E4.6020702@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: <20100210215516.C8943F580BA@smtp.patriot.net> Subject: Re: [marf] Reported-Domain vs Reported-URI X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:50:50 -0000 In <4B7170E4.6020702@tana.it>, on 02/09/2010 at 03:27 PM, Alessandro Vesely said: >I'd say "responsible for injecting the original message", rather than >"relevant to the report". The how and why would be expressed in the >Authentication-Results feedback field (which may match its namesake in >the original message's header.) Does that imply that MARF should not be used to report drop boxes and spamvertised web sites? The phrase "or related to" in 1.1 would suggest that MARF is appropriate for that purpose. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From shmuel+gen@patriot.net Wed Feb 10 14:26:34 2010 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 F280F28C141 for ; Wed, 10 Feb 2010 14:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599] 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 5UpfGnmjSXli for ; Wed, 10 Feb 2010 14:26:33 -0800 (PST) Received: from smtp.patriot.net (smtp.patriot.net [209.249.176.77]) by core3.amsl.com (Postfix) with ESMTP id 07BAF28C0F9 for ; Wed, 10 Feb 2010 14:26:32 -0800 (PST) Received: from ECS35455305 (core-dc-1-176.dynamic-dialup.coretel.net [69.72.26.176]) (Authenticated sender: shmuel@patriot.net) by smtp.patriot.net (Postfix) with ESMTP id 66582F580AF for ; Wed, 10 Feb 2010 17:30:58 -0500 (EST) From: Shmuel (Seymour J.) Metz Date: Wed, 10 Feb 2010 17:15:24 -0500 To: marf@ietf.org In-Reply-To: Mail-Copies-To: nobody Mail-Followup-To: Message Abuse Report Format working group Organization: Atid/2 X-CompuServe-Customer: Yes X-Coriate: NCAE@NewAmerica.org X-Coriate: Mark Griffith X-Punge: Micro$oft X-Terminate: SPA(GIS) X-Treme: C&C,DWS X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v3.00.11.18 BETA/60 Message-Id: <20100210223059.66582F580AF@smtp.patriot.net> Subject: Re: [marf] Reported-Domain vs Reported-URI X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Message Abuse Report Format working group List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 22:26:34 -0000 In , on 02/10/2010 at 12:26 PM, "Murray S. Kucherawy" said: >If it's OK that I also say something like "therefore, general automated >parsing based on the value of this field SHOULD NOT be done", I'm fine >with that. I like that. Would there be value at a later stage in defining fields with more specific meaning, or defining optional flags in the existing field to identify the relevance of the domain name? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2 We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) From msk@cloudmark.com Wed Feb 10 14:54:51 2010 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 C50E73A77C2 for ; Wed, 10 Feb 2010 14:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599] 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 r+dyD71COMHK for ; Wed, 10 Feb 2010 14:54:51 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 0B9993A6A88 for ; Wed, 10 Feb 2010 14:54:51 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 10 Feb 2010 14:56:03 -0800 From: "Murray S. Kucherawy" To: Steve Atkins , Message Abuse Report Format working group Date: Wed, 10 Feb 2010 14:56:02 -0800 Thread-Topic: [marf] Reported-Domain vs Reported-URI Thread-Index: AcqqkQbco9ZDYZMIQGyoSbT56/Pl5QAEtXMw Message-ID: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> <4B7170E4.6020702@tana.it> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> In-Reply-To: <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 10 Feb 2010 22:54:51 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Steve Atkins > Sent: Wednesday, February 10, 2010 12:39 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] Reported-Domain vs Reported-URI >=20 > > If it's OK that I also say something like "therefore, general > > automated parsing based on the value of this field SHOULD NOT be done", > > I'm fine with that. >=20 > No, automated triage is exactly what it's most useful for. It's almost > a SHOULD rather than a SHOULD NOT. :) >=20 > If I'm a webhoster with 10,000 domains then the very first thing I'm > going to do with a FBL is to choose something to key triage aggregation > on - so I can route and report on incidents efficiently. An IP address > is better than nothing, but the ideal key to use is the domain that's > being reported. I guess I have a different idea of automation on receipt, namely immediate = mitigation rather than just bucketing or sorting for human action. If I'm = in the minority though, then that's how it goes. :) So about the text you proposed: "The hostname in the Reported-Domain: field is the reason the sender of the= report chose to send it to you. The domain may be mentioned explicitly in = the original message, or may be derived from it in some way. In cases where= the derivation isn't obvious the report author is encouraged to clarify in= the human readable section of the report." or something like that? Can I get some +1/-1s or suggestions for tweaks? I would prefer to include= language like this to indicate why the WG felt the field was useful even i= f it is not fully formally defined. From yakov@shaftek.org Wed Feb 10 14:59:15 2010 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 F2FEF3A72A6 for ; Wed, 10 Feb 2010 14:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 qqlQeMDEKpLs for ; Wed, 10 Feb 2010 14:59:14 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 6FA5D3A7247 for ; Wed, 10 Feb 2010 14:59:11 -0800 (PST) Received: by ewy28 with SMTP id 28so661567ewy.28 for ; Wed, 10 Feb 2010 15:00:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.137 with SMTP id w9mr571237wee.104.1265842819115; Wed, 10 Feb 2010 15:00:19 -0800 (PST) In-Reply-To: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <4B7170E4.6020702@tana.it> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> From: Yakov Shafranovich Date: Wed, 10 Feb 2010 17:59:59 -0500 Message-ID: <501c18e01002101459u6aab2c96n99a32bd5d8c28060@mail.gmail.com> To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marf@ietf.org Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 10 Feb 2010 22:59:15 -0000 On Wed, Feb 10, 2010 at 5:56 PM, Murray S. Kucherawy wr= ote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of >> Steve Atkins >> Sent: Wednesday, February 10, 2010 12:39 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] Reported-Domain vs Reported-URI >> >> > If it's OK that I also say something like "therefore, general >> > automated parsing based on the value of this field SHOULD NOT be done"= , >> > I'm fine with that. >> >> No, automated triage is exactly what it's most useful for. It's almost >> a SHOULD rather than a SHOULD NOT. :) >> >> If I'm a webhoster with 10,000 domains then the very first thing I'm >> going to do with a FBL is to choose something to key triage aggregation >> on - so I can route and report on incidents efficiently. An IP address >> is better than nothing, but the ideal key to use is the domain that's >> being reported. > > I guess I have a different idea of automation on receipt, namely immediat= e mitigation rather than just bucketing or sorting for human action. =A0If = I'm in the minority though, then that's how it goes. :) > > So about the text you proposed: > > "The hostname in the Reported-Domain: field is the reason the sender of t= he report chose to send it to you. The domain may be mentioned explicitly i= n the original message, or may be derived from it in some way. In cases whe= re the derivation isn't obvious the report author is encouraged to clarify = in the human readable section of the report." or something like that? > > Can I get some +1/-1s or suggestions for tweaks? =A0I would prefer to inc= lude language like this to indicate why the WG felt the field was useful ev= en if it is not fully formally defined. I was actually thinking of telling them to look at the original message instead. Reported-Domain is really a way to flag something to say "hey look at this". They should still consult and parse the original email to be sure. Yakov From steve@wordtothewise.com Wed Feb 10 15:34:56 2010 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 9351B3A748E for ; Wed, 10 Feb 2010 15:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSAUQwh7C+jT for ; Wed, 10 Feb 2010 15:34:53 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id A21583A6816 for ; Wed, 10 Feb 2010 15:34:52 -0800 (PST) Received: from [192.168.1.108] (adsl-99-180-47-182.dsl.pltn13.sbcglobal.net [99.180.47.182]) by m.wordtothewise.com (Postfix) with ESMTP id 958914F81FF for ; Wed, 10 Feb 2010 15:36:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Wed, 10 Feb 2010 15:36:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <20E9B023-307F-4F2B-9155-E05E60840316@wordtothewise.com> References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> <4B7170E4.6020702@tana.it> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 10 Feb 2010 23:34:56 -0000 On Feb 10, 2010, at 2:56 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of >> Steve Atkins >> Sent: Wednesday, February 10, 2010 12:39 PM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] Reported-Domain vs Reported-URI >>=20 >>> If it's OK that I also say something like "therefore, general >>> automated parsing based on the value of this field SHOULD NOT be = done", >>> I'm fine with that. >>=20 >> No, automated triage is exactly what it's most useful for. It's = almost >> a SHOULD rather than a SHOULD NOT. :) >>=20 >> If I'm a webhoster with 10,000 domains then the very first thing I'm >> going to do with a FBL is to choose something to key triage = aggregation >> on - so I can route and report on incidents efficiently. An IP = address >> is better than nothing, but the ideal key to use is the domain that's >> being reported. >=20 > I guess I have a different idea of automation on receipt, namely = immediate mitigation rather than just bucketing or sorting for human = action. If I'm in the minority though, then that's how it goes. :) Yeah, automated triage and automated mitigation and entirely automated = handling are fairly different things, though closely related in some = regards. >=20 > So about the text you proposed: >=20 > "The hostname in the Reported-Domain: field is the reason the sender = of the report chose to send it to you. The domain may be mentioned = explicitly in the original message, or may be derived from it in some = way. In cases where the derivation isn't obvious the report author is = encouraged to clarify in the human readable section of the report." or = something like that? +1 from me. :) >=20 > Can I get some +1/-1s or suggestions for tweaks? I would prefer to = include language like this to indicate why the WG felt the field was = useful even if it is not fully formally defined. >=20 Some of that is BCP material, I suspect. Some of the reasoning behind = why it may be useful to handle reports in this manner is subtle and = lengthy. Cheers, Steve= From msk@cloudmark.com Wed Feb 10 15:37:43 2010 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 AEF5C3A7618 for ; Wed, 10 Feb 2010 15:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] 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 WmkEuibr9C+D for ; Wed, 10 Feb 2010 15:37:42 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 4442A3A7572 for ; Wed, 10 Feb 2010 15:37:42 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 10 Feb 2010 15:38:54 -0800 From: "Murray S. Kucherawy" To: Steve Atkins , Message Abuse Report Format working group Date: Wed, 10 Feb 2010 15:38:53 -0800 Thread-Topic: [marf] Reported-Domain vs Reported-URI Thread-Index: AcqqqdODK6iXWwUhRjmkmdgbDMeGLgAADBdw Message-ID: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> <4B7170E4.6020702@tana.it> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> <20E9B023-307F-4F2B-9155-E05E60840316@wordtothewise.com> In-Reply-To: <20E9B023-307F-4F2B-9155-E05E60840316@wordtothewise.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Reported-Domain vs Reported-URI 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: Wed, 10 Feb 2010 23:37:43 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Steve Atkins > Sent: Wednesday, February 10, 2010 3:36 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] Reported-Domain vs Reported-URI >=20 > Some of that is BCP material, I suspect. Some of the reasoning behind > why it may be useful to handle reports in this manner is subtle and > lengthy. My interest is just including something rudimentary to explain why we weren= 't more formal with the definition of this field, so that during IETF last = call or IESG review they don't get to block publication based on that issue= . :) We do have in our charter some BCP/Informational work, and a more detailed = treatise can, and probably should, be included there. From vesely@tana.it Thu Feb 11 06:17:04 2010 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 F2D233A783F for ; Thu, 11 Feb 2010 06:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.68 X-Spam-Level: X-Spam-Status: No, score=-4.68 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blLSAdOPBjkq for ; Thu, 11 Feb 2010 06:17:03 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id C31763A783E for ; Thu, 11 Feb 2010 06:17:02 -0800 (PST) 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, 11 Feb 2010 15:18:10 +0100 id 00000000005DC043.000000004B7411A2.00007A74 Message-ID: <4B7411A1.2080804@tana.it> Date: Thu, 11 Feb 2010 15:18:09 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <501c18e01002030952g4f6bbb4cj3299cd3da7acc0ae@mail.gmail.com> <4B6BF907.1070906@tana.it> <501c18e01002050830w33b3d673jb13d46420f998cff@mail.gmail.com> <4B7170E4.6020702@tana.it> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 11 Feb 2010 14:17:04 -0000 On 10/Feb/10 23:56, Murray S. Kucherawy wrote: > I guess I have a different idea of automation on receipt, namely immediate mitigation rather than just bucketing or sorting for human action. IMHO, automatic action should only occur after the original message has been confirmed, e.g. a signature verified or a log matched. > So about the text you proposed: > > "The hostname in the Reported-Domain: field is the reason the sender of the report chose to send it to you. The domain may be mentioned explicitly in the original message, or may be derived from it in some way. In cases where the derivation isn't obvious the report author is encouraged to clarify in the human readable section of the report." or something like that? There's a couple of points that that text doesn't clarify. Firstly, the meaning. We could say that it is the helo-name, an rDNS PTR of the connecting address, or even an authenticated DKIM or SPF derivation _as opposed to_ being explicitly mentioned in the "From", "Sender", "Reply-To", header fields, or in the message body, which would be eligible for Reported-URI. Or the other way around. Both of those fields can be a reason for sending the report to the relevant abuse team. BTW, the production rule in the draft currently says reported-uri = "Reported-Domain:" [CFWS] URI [CFWS] CRLF ^^^^^^^^^^^^^^^ Secondly, the exhibit. Is it necessarily a hostname? DKIM and SPF may authenticate a domain. Is it allowed an IP address as Reported-Domain? As an alternative proposal: "Reported-Domain" indicates the host that transmitted the original message. It may be the the RFC5321.HELO/.EHLO or the PTR resulting from an rDNS lookup. The name is formatted as defined in section 2.3.1 of [DNS]. This name MUST have been verified using the "iprev" method defined in [AUTH-RESULTS]. In case no verification is possible or available, an address literal, in the format specified by section 4.1.3 of [SMTP], MAY be acceptable. (BTW, shouldn't references used this way be normative?) From vesely@tana.it Thu Feb 11 06:28:03 2010 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 D22BC3A71E9 for ; Thu, 11 Feb 2010 06:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.681 X-Spam-Level: X-Spam-Status: No, score=-4.681 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywqNFgYVP27m for ; Thu, 11 Feb 2010 06:28:03 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id F2A1E3A71B0 for ; Thu, 11 Feb 2010 06:28:02 -0800 (PST) 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, 11 Feb 2010 15:29:16 +0100 id 00000000005DC043.000000004B74143C.00003025 Message-ID: <4B74143C.6070002@tana.it> Date: Thu, 11 Feb 2010 15:29:16 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20100210215516.C8943F580BA@smtp.patriot.net> In-Reply-To: <20100210215516.C8943F580BA@smtp.patriot.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 11 Feb 2010 14:28:03 -0000 On 10/Feb/10 15:41, Shmuel (Seymour J.) Metz wrote: > In<4B7170E4.6020702@tana.it>, on 02/09/2010 at 03:27 PM, Alessandro Vesely said: >>I'd say "responsible for injecting the original message", rather than >>"relevant to the report". > > Does that imply that MARF should not be used to report drop boxes and > spamvertised web sites? No. Just not in that field. > The phrase "or related to" in 1.1 would suggest > that MARF is appropriate for that purpose. Yes. From johnl@iecc.com Thu Feb 11 07:41:45 2010 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 54DFD3A7710 for ; Thu, 11 Feb 2010 07:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.88 X-Spam-Level: X-Spam-Status: No, score=-10.88 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] 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 XNA4FOJ6EJLS for ; Thu, 11 Feb 2010 07:41:44 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 14ECD3A76FA for ; Thu, 11 Feb 2010 07:41:43 -0800 (PST) Received: (qmail 32633 invoked from network); 11 Feb 2010 15:42:58 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 11 Feb 2010 15:42:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1002; olt=johnl@user.iecc.com; bh=EhBXLBExgGs3vV3mpbU9M65jZXdQu4CbMqGewEtV41w=; b=LanY2ARfZBNJXOKRasPrFkwcc/PxNNcTAjfIT+dBRSGP+be0av9Hn+utGbPAvXxMv9SSLJR7waV8dhPBRbYTIP09mmVz+dH9Xwv5+7OAmJbuqsDShTOFBfNTSkZ94T20zTZQOn7gg8BCHdfZ0KSNwvPTyd3GwS7Kx6DnTe9Cqz0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1002; bh=EhBXLBExgGs3vV3mpbU9M65jZXdQu4CbMqGewEtV41w=; b=JV+i1WGK0mBClhccFf0PfMJ793WX/Xzt+S82f49fGhkSLFudqa7ypzItJp7OhsZrGc+TU+Pi1OlAsheQDc80b4/3McxYr2FGbFVp9hGb6w2vMhOOHd0CoIIZwecRbMk4HLm7nnn/Fv4/7rHNmAhDae/2GmkVbjfzSxSItumz0Dc= Date: 11 Feb 2010 15:42:57 -0000 Message-ID: <20100211154257.8520.qmail@simone.iecc.com> From: John Levine To: marf@ietf.org In-Reply-To: <4B7411A1.2080804@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 11 Feb 2010 15:41:45 -0000 In article <4B7411A1.2080804@tana.it> you write: >On 10/Feb/10 23:56, Murray S. Kucherawy wrote: >> I guess I have a different idea of automation on receipt, namely immediate >mitigation rather than just bucketing or sorting for human action. > >IMHO, automatic action should only occur after the original message >has been confirmed, e.g. a signature verified or a log matched. I'm pretty sure you will find that current ARF usage is mostly or entirely automated. I know it is here. Like Steve said, Reported-Domain: is very useful for identifying domains that are doing something strange, even with its current somewhat ambiguous definition. R's, John From jdfalk-lists@cybernothing.org Thu Feb 11 11:17:02 2010 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 070CF3A720C for ; Thu, 11 Feb 2010 11:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.624 X-Spam-Level: X-Spam-Status: No, score=-6.624 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 RsR4Idu3mmGO for ; Thu, 11 Feb 2010 11:17:00 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 645ED28C1CA for ; Thu, 11 Feb 2010 11:17:00 -0800 (PST) Received: from jds-macbook.rpcorp.local (np54.co.returnpath.net [38.109.196.54]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o1BJICki006387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 11 Feb 2010 12:18:13 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o1BJICki006387 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1265915895; bh=iGkKhtuL2JveTWSpVifanG8j/YW80+KCPgbboRFl oGA=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=p6vx/N+luL/3MYIE W4LWVkHUBdsx8L/rHTnd5aFclBS1sytbc73bN8LC2cMC13MyMqfMMnA+2z+GcqEqpJT wldhOEjGb8Tc3nET9SIdTy/X6WZVIeWgfIJCainiX4I/jLLe5GUMm9XJ95jF/qd9Xbl 76nGm0nHLNR3qf4xlFdkc= References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <6.2.5.6.2.20100207213326.0821dd60@resistor.net> <6.2.5.6.2.20100209000859.09077d50@resistor.net> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Thu, 11 Feb 2010 12:18:06 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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, 11 Feb 2010 19:17:02 -0000 On Feb 10, 2010, at 11:26 AM, Murray S. Kucherawy wrote: > Here's a suggested subsection of Security Considerations to discuss = this issue (pardon the XML and indentation): >=20 > It is conceivable that a system may be = implemented > that generates ARF reports automatically in > response to an event. For example, = software > monitoring a honeypot email address might = generate > an ARF report immediately upon delivery of = any > message to it. An attacker that becomes = aware > of such a configuration can exploit it to > attack an ARF recipient with automatically > generated ARF reports. Not merely conceivable -- these already exist. In any case, +1 to this language & location in the draft. > How about this? >=20 >
> requires that its reports > be sent with the empty = envelope > sender to avoid bounce loops. A similar = requirement > was considered for this specification, but it seems > unlikely that an ARF report would be generated > in response to receipt of an ARF report, and = furthermore > such a requirement would prevent an ARF generator = from > ever determining that an ARF report was not = actually > received. >=20 > On the other hand, if an ARF report is generated = without > the empty envelope sender and is sent to an address = that > actually does not work, then the generating address > can also be overwhelmed by DSNs as a denial of = service > attack (see ). >=20 > This specification therefore makes no requirement = related > to the envelope sender of a generated report. = Operators > will have to consider what envelope sender to use > within the context of their own installations. = >
I'm tempted to go a bit further, and RECOMMEND that ARF generators use = VERP, BATV, or similar methods to handle non-deliverable recipients, = just like other mailing lists or transactional messages. That matches = many of the current deployments, and just generally seems like a good = idea (though still not a MUST.) -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Thu Feb 11 11:22:12 2010 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 078733A787E for ; Thu, 11 Feb 2010 11:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.621 X-Spam-Level: X-Spam-Status: No, score=-6.621 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 ujHguRcit-xM for ; Thu, 11 Feb 2010 11:22:11 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id EBC963A7882 for ; Thu, 11 Feb 2010 11:22:10 -0800 (PST) Received: from jds-macbook.rpcorp.local (np54.co.returnpath.net [38.109.196.54]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o1BJNOGV006464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 11 Feb 2010 12:23:25 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o1BJNOGV006464 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1265916206; bh=dFkp8yKG4Z2NfaG9642cSYgECLdaMl1lViZJPrlU 3+4=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=Zv8rkXi/TppsWWVO L8ADgwpSRy7ekyX8EBF5TpOAUesMs2rQdS6iERYu/u8ArDsfJIUnB+80mmpavFmPHOK racgaRxcR/y25NTBY4RaS4Vob+C0fz00c1EK4yRtUo6X5doEvOODBDv/ISW3sSO24c+ qhJpWZbp/MdFsgyy79K3o= References: <20100209134142.49174F5809B@smtp.patriot.net> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Thu, 11 Feb 2010 12:23:18 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] "Redacted" flag (was RE: Comments on draft-ietf-marf-base-00) 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, 11 Feb 2010 19:22:12 -0000 On Feb 10, 2010, at 11:59 AM, John R Levine wrote: >> How would ARF recipients actually use such a flag if it is observed = to be set? >> Would ARF generators object to setting that flag when redacting? >=20 > I have my doubts about its utility, but AOL already sets it: I've no objection, so long as it's optional. Making it optional does create some complication, however. Consider: - redaction is optional - stating whether or not redaction has occurred is optional - therefore, an ARF consumer has no way of knowing whether a message = without the redacted flag might be redacted, UNLESS they discuss it with = the ARF generator beforehand So we're back to recommending that both ends talk to each other about = redaction -- which matches current practice perfectly. -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Thu Feb 11 11:26:32 2010 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 7D0583A6926 for ; Thu, 11 Feb 2010 11:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.619 X-Spam-Level: X-Spam-Status: No, score=-6.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 cUeR66nmg2bL for ; Thu, 11 Feb 2010 11:26:31 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 5FD5D3A7440 for ; Thu, 11 Feb 2010 11:26:31 -0800 (PST) Received: from jds-macbook.rpcorp.local (np54.co.returnpath.net [38.109.196.54]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o1BJRhnO006513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 11 Feb 2010 12:27:46 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o1BJRhnO006513 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1265916466; bh=Dx4dSsu7jL5OpIg68Bdnp3Rf4RkCd3HHIP7Cuy2n gOw=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=BMPy+N2g57fth0VK E3FCRQG08zsO5pGwn2fzdh4VSKu9TO452KPQ0RMEBwKP+1XRSY+yN/MO14dGBUcBvA2 0mKNTbTBTYD+AKM04JJzwL1aagibJOWNDjPdXp0sKBTNNA9fxEpno7W0A87uy6bVWgL k2ddZi6tQpuIzN+pXAD+M= References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <4B7170E4.6020702@tana.it> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> <501c18e01002101459u6aab2c96n99a32bd5d8c28060@mail.gmail.com> In-Reply-To: <501c18e01002101459u6aab2c96n99a32bd5d8c28060@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <45127546-0643-47E8-AC07-1EEF63D658FE@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Thu, 11 Feb 2010 12:27:38 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 11 Feb 2010 19:26:32 -0000 On Feb 10, 2010, at 3:59 PM, Yakov Shafranovich wrote: > I was actually thinking of telling them to look at the original > message instead. Reported-Domain is really a way to flag something to > say "hey look at this". They should still consult and parse the > original email to be sure. Right! I think this gets back to our original intent: the metadata is = there to provide some hints/pointers that the ARF generator thinks will = be helpful, but the ARF consumer still needs to apply their own internal = logic to the original message to decide what to do. -- J.D. Falk Return Path Inc From msk@cloudmark.com Thu Feb 11 11:31:33 2010 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 D623B28C223 for ; Thu, 11 Feb 2010 11:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599] 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 aUsyKoZARhI8 for ; Thu, 11 Feb 2010 11:31:33 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 2388728C227 for ; Thu, 11 Feb 2010 11:31:33 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 11 Feb 2010 11:32:48 -0800 From: "Murray S. Kucherawy" To: "J.D. Falk" , Message Abuse Report Format working group Date: Thu, 11 Feb 2010 11:32:47 -0800 Thread-Topic: [marf] "Redacted" flag (was RE: Comments on draft-ietf-marf-base-00) Thread-Index: AcqrT7Eqb7vjEsl9TPusvIsuU6GpBwAAT87Q Message-ID: References: <20100209134142.49174F5809B@smtp.patriot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] "Redacted" flag (was RE: Comments on draft-ietf-marf-base-00) 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, 11 Feb 2010 19:31:34 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > J.D. Falk > Sent: Thursday, February 11, 2010 11:23 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] "Redacted" flag (was RE: Comments on draft-ietf- > marf-base-00) >=20 > On Feb 10, 2010, at 11:59 AM, John R Levine wrote: > >> How would ARF recipients actually use such a flag if it is observed > to be set? > >> Would ARF generators object to setting that flag when redacting? > > > > I have my doubts about its utility, but AOL already sets it: >=20 > I've no objection, so long as it's optional. Does that mean it would be a burden to current implementations to make it m= andatory? From msk@cloudmark.com Thu Feb 11 11:34:11 2010 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 C80993A7519 for ; Thu, 11 Feb 2010 11:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] 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 NYilM-ZWRoKj for ; Thu, 11 Feb 2010 11:34:11 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 205303A7193 for ; Thu, 11 Feb 2010 11:34:11 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 11 Feb 2010 11:35:26 -0800 From: "Murray S. Kucherawy" To: "J.D. Falk" , Message Abuse Report Format working group Date: Thu, 11 Feb 2010 11:35:25 -0800 Thread-Topic: [marf] Comments on draft-ietf-marf-base-00 Thread-Index: AcqrTvhgHfyn86aOQFiCgcMWDRHvEAAAh43w Message-ID: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <6.2.5.6.2.20100207213326.0821dd60@resistor.net> <6.2.5.6.2.20100209000859.09077d50@resistor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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, 11 Feb 2010 19:34:11 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > J.D. Falk > Sent: Thursday, February 11, 2010 11:18 AM > To: Message Abuse Report Format working group > Subject: Re: [marf] Comments on draft-ietf-marf-base-00 >=20 > [...] > I'm tempted to go a bit further, and RECOMMEND that ARF generators use > VERP, BATV, or similar methods to handle non-deliverable recipients, > just like other mailing lists or transactional messages. That matches > many of the current deployments, and just generally seems like a good > idea (though still not a MUST.) That's not a bad idea though I don't know that we can cite those two specif= ic ones since they're not RFCs or even current I-Ds (BATV expired a long ti= me ago, and I don't think VERP ever got standardized). Maybe just a generi= c remark about putting some thought into such methods would be sufficient? From steve@wordtothewise.com Thu Feb 11 11:34:18 2010 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 377DE3A7701 for ; Thu, 11 Feb 2010 11:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ-OFZrygY9w for ; Thu, 11 Feb 2010 11:34:16 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id D659D3A75BC for ; Thu, 11 Feb 2010 11:34:15 -0800 (PST) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 72F2E4F82B3 for ; Thu, 11 Feb 2010 11:35:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: Date: Thu, 11 Feb 2010 11:35:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5DB12D5C-6E32-49A3-B10A-76B803239414@wordtothewise.com> References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <6.2.5.6.2.20100207213326.0821dd60@resistor.net> <6.2.5.6.2.20100209000859.09077d50@resistor.net> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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, 11 Feb 2010 19:34:18 -0000 On Feb 11, 2010, at 11:18 AM, J.D. Falk wrote: > On Feb 10, 2010, at 11:26 AM, Murray S. Kucherawy wrote: >=20 >> Here's a suggested subsection of Security Considerations to discuss = this issue (pardon the XML and indentation): >>=20 >> It is conceivable that a system may be = implemented >> that generates ARF reports automatically in >> response to an event. For example, = software >> monitoring a honeypot email address might = generate >> an ARF report immediately upon delivery of = any >> message to it. An attacker that becomes = aware >> of such a configuration can exploit it to >> attack an ARF recipient with automatically >> generated ARF reports. >=20 > Not merely conceivable -- these already exist. >=20 > In any case, +1 to this language & location in the draft. >=20 >> How about this? >>=20 >>
>> requires that its reports >> be sent with the empty = envelope >> sender to avoid bounce loops. A similar = requirement >> was considered for this specification, but it seems >> unlikely that an ARF report would be generated >> in response to receipt of an ARF report, and = furthermore >> such a requirement would prevent an ARF generator = from >> ever determining that an ARF report was not = actually >> received. >>=20 >> On the other hand, if an ARF report is generated = without >> the empty envelope sender and is sent to an address = that >> actually does not work, then the generating address >> can also be overwhelmed by DSNs as a denial of = service >> attack (see ). >>=20 >> This specification therefore makes no requirement = related >> to the envelope sender of a generated report. = Operators >> will have to consider what envelope sender to use >> within the context of their own installations. = >>
>=20 > I'm tempted to go a bit further, and RECOMMEND that ARF generators use = VERP, BATV, or similar methods to handle non-deliverable recipients, = just like other mailing lists or transactional messages. That matches = many of the current deployments, and just generally seems like a good = idea (though still not a MUST.) This is all SMTP level stuff, handled in a normal SMTP manner in the case where the ARF formatted payload is sent via SMTP, isn't it? It's all good solid best practices, but it's two levels removed from = what we're talking about with ARF (SMTP -> MIME -> ARF). We're just a subset of RFC3462, after all. Or are we just being as broad as possible in the security section, to = make sure we're covered? (In which case, a +1 on the language). Cheers, Steve From jdfalk-lists@cybernothing.org Thu Feb 11 11:36:32 2010 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 8904F28C227 for ; Thu, 11 Feb 2010 11:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 2SYCGC9QXOIf for ; Thu, 11 Feb 2010 11:36:31 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 6884F28C201 for ; Thu, 11 Feb 2010 11:36:31 -0800 (PST) Received: from jds-macbook.rpcorp.local (np54.co.returnpath.net [38.109.196.54]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o1BJbiQL006615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 11 Feb 2010 12:37:46 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o1BJbiQL006615 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1265917066; bh=hyKrPBt89Ttq1glrutm0KGv6544ZtgQnG8jW95A7 cZo=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=VOlftrJA8wBu2IBz 4JbhVc2lUv9jrr+H331/BVvNyxKFCnsX+0uRyzgwbOq/E2JuSeQbLWdfk0d5Uikhed2 gnDH7pBxYaXB2Ts+IGwZ2rGiITi8yUY9MiuBxeWcLs29ef1HbPgNB4pFTTdYz6kiVr+ yn8vBXeR2oXL1pye16/hY= References: <20100209134142.49174F5809B@smtp.patriot.net> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Thu, 11 Feb 2010 12:37:38 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] "Redacted" flag (was RE: Comments on draft-ietf-marf-base-00) 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, 11 Feb 2010 19:36:32 -0000 On Feb 11, 2010, at 12:32 PM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf = Of >> J.D. Falk >> Sent: Thursday, February 11, 2010 11:23 AM >> To: Message Abuse Report Format working group >> Subject: Re: [marf] "Redacted" flag (was RE: Comments on draft-ietf- >> marf-base-00) >>=20 >> On Feb 10, 2010, at 11:59 AM, John R Levine wrote: >>>> How would ARF recipients actually use such a flag if it is observed >> to be set? >>>> Would ARF generators object to setting that flag when redacting? >>>=20 >>> I have my doubts about its utility, but AOL already sets it: >>=20 >> I've no objection, so long as it's optional. >=20 > Does that mean it would be a burden to current implementations to make = it mandatory? It might, in the same way that anything entirely new might be a burden. = For our implementation, we'll ask our ISP partners (on whose behalf we = operate complaint feedback loops) what they'd each prefer. I'm also assuming that the same lawyers who say messages have to be = redacted might also say the generator shouldn't use the flag. Illogical = to us techies, I know, but this is the political layer. -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Thu Feb 11 11:37:13 2010 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 86D7528C228 for ; Thu, 11 Feb 2010 11:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.616 X-Spam-Level: X-Spam-Status: No, score=-6.616 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 XXG28DEPzQNi for ; Thu, 11 Feb 2010 11:37:12 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id ACB1D3A75BC for ; Thu, 11 Feb 2010 11:37:12 -0800 (PST) Received: from jds-macbook.rpcorp.local (np54.co.returnpath.net [38.109.196.54]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o1BJbiQM006615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 11 Feb 2010 12:38:27 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o1BJbiQM006615 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cybernothing.org; s=satori; t=1265917107; bh=lssNqIV2EfZiPW5mJgbp6eJosmoqZ4ULZMFPehJe g68=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=AVTJkhRPWhmjqxGO mKsElZjjJQ32X8qT8IJ2rb+RuL6yj47dToZlRDDLs7NoV9NzC2CvqzDpppRwDzLvyX+ PhwhTjAbUuzfUuqHluw3PNpEnCDfJfRMkXEKHQ2S0lXR2nSzkHxqzpYX2RgDoIKGxD4 t/GtBLsyBXhs1vj89T2Gs= References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <6.2.5.6.2.20100207213326.0821dd60@resistor.net> <6.2.5.6.2.20100209000859.09077d50@resistor.net> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Thu, 11 Feb 2010 12:38:27 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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, 11 Feb 2010 19:37:13 -0000 On Feb 11, 2010, at 12:35 PM, Murray S. Kucherawy wrote: >> I'm tempted to go a bit further, and RECOMMEND that ARF generators = use >> VERP, BATV, or similar methods to handle non-deliverable recipients, >> just like other mailing lists or transactional messages. That = matches >> many of the current deployments, and just generally seems like a good >> idea (though still not a MUST.) >=20 > That's not a bad idea though I don't know that we can cite those two = specific ones since they're not RFCs or even current I-Ds (BATV expired = a long time ago, and I don't think VERP ever got standardized). Maybe = just a generic remark about putting some thought into such methods would = be sufficient? Works for me. -- J.D. Falk Return Path Inc From yakov@shaftek.org Thu Feb 11 14:39:50 2010 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 9ECCE3A726B for ; Thu, 11 Feb 2010 14:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 REtkp2jZM9bj for ; Thu, 11 Feb 2010 14:39:50 -0800 (PST) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id B58CB3A682A for ; Thu, 11 Feb 2010 14:39:49 -0800 (PST) Received: by ewy28 with SMTP id 28so529049ewy.28 for ; Thu, 11 Feb 2010 14:41:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.88.6 with SMTP id z6mr323786wee.52.1265928061029; Thu, 11 Feb 2010 14:41:01 -0800 (PST) In-Reply-To: <45127546-0643-47E8-AC07-1EEF63D658FE@cybernothing.org> References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> <501c18e01002101459u6aab2c96n99a32bd5d8c28060@mail.gmail.com> <45127546-0643-47E8-AC07-1EEF63D658FE@cybernothing.org> From: Yakov Shafranovich Date: Thu, 11 Feb 2010 17:40:40 -0500 Message-ID: <501c18e01002111440p7e1d7de1p2637837c419369f7@mail.gmail.com> To: "J.D. Falk" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 11 Feb 2010 22:39:50 -0000 On Thu, Feb 11, 2010 at 2:27 PM, J.D. Falk wrote: > On Feb 10, 2010, at 3:59 PM, Yakov Shafranovich wrote: > >> I was actually thinking of telling them to look at the original >> message instead. Reported-Domain is really a way to flag something to >> say "hey look at this". They should still consult and parse the >> original email to be sure. > > Right! =A0I think this gets back to our original intent: the metadata is = there to provide some hints/pointers that the ARF generator thinks will be = helpful, but the ARF consumer still needs to apply their own internal logic= to the original message to decide what to do. > Perhaps we need to make this explicit in the document From yakov@shaftek.org Thu Feb 11 14:50:13 2010 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 7B73928C251 for ; Thu, 11 Feb 2010 14:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 BXeMR0U0jFbl for ; Thu, 11 Feb 2010 14:50:12 -0800 (PST) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id 6032828C250 for ; Thu, 11 Feb 2010 14:50:11 -0800 (PST) Received: by ewy3 with SMTP id 3so1879207ewy.13 for ; Thu, 11 Feb 2010 14:51:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.87.131 with SMTP id y3mr354746wee.9.1265928680180; Thu, 11 Feb 2010 14:51:20 -0800 (PST) In-Reply-To: <5DB12D5C-6E32-49A3-B10A-76B803239414@wordtothewise.com> References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <6.2.5.6.2.20100207213326.0821dd60@resistor.net> <6.2.5.6.2.20100209000859.09077d50@resistor.net> <5DB12D5C-6E32-49A3-B10A-76B803239414@wordtothewise.com> From: Yakov Shafranovich Date: Thu, 11 Feb 2010 17:51:00 -0500 Message-ID: <501c18e01002111451s668b0e2bt379031b3aefe22d9@mail.gmail.com> To: Steve Atkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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, 11 Feb 2010 22:50:13 -0000 On Thu, Feb 11, 2010 at 2:35 PM, Steve Atkins wro= te: >> I'm tempted to go a bit further, and RECOMMEND that ARF generators use V= ERP, BATV, or similar methods to handle non-deliverable recipients, just li= ke other mailing lists or transactional messages. =A0That matches many of t= he current deployments, and just generally seems like a good idea (though s= till not a MUST.) > > > This is all SMTP level stuff, handled in a normal SMTP manner in the > case where the ARF formatted payload is sent via SMTP, isn't it? > > It's all good solid best practices, =A0but it's two levels removed from w= hat > we're talking about with ARF (SMTP -> MIME -> ARF). We're just a > subset of RFC3462, after all. > > Or are we just being as broad as possible in the security section, to mak= e > sure we're covered? (In which case, a +1 on the language). In RFC 3464, it gets into details about SMTP level transactions even though the DSNs themselves are encoded on a higher level. We are just following a similar approach. Yakov From msk@cloudmark.com Thu Feb 11 15:04:07 2010 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 F3A703A753F for ; Thu, 11 Feb 2010 15:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] 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 elM1+L3U7HWd for ; Thu, 11 Feb 2010 15:04:06 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 3E2D43A749C for ; Thu, 11 Feb 2010 15:04:06 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 11 Feb 2010 15:05:22 -0800 From: "Murray S. Kucherawy" To: Yakov Shafranovich , "J.D. Falk" Date: Thu, 11 Feb 2010 15:05:22 -0800 Thread-Topic: [marf] Reported-Domain vs Reported-URI Thread-Index: Acqra02JK4fEMAVwSX6FpBRuOrWsKwAAzSWA Message-ID: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> <501c18e01002101459u6aab2c96n99a32bd5d8c28060@mail.gmail.com> <45127546-0643-47E8-AC07-1EEF63D658FE@cybernothing.org> <501c18e01002111440p7e1d7de1p2637837c419369f7@mail.gmail.com> In-Reply-To: <501c18e01002111440p7e1d7de1p2637837c419369f7@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Message Abuse Report Format working group Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 11 Feb 2010 23:04:07 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > Yakov Shafranovich > Sent: Thursday, February 11, 2010 2:41 PM > To: J.D. Falk > Cc: Message Abuse Report Format working group > Subject: Re: [marf] Reported-Domain vs Reported-URI >=20 > > Right! =A0I think this gets back to our original intent: the metadata > > is there to provide some hints/pointers that the ARF generator thinks > > will be helpful, but the ARF consumer still needs to apply their own > > internal logic to the original message to decide what to do. >=20 > Perhaps we need to make this explicit in the document I think that's really what I'm getting at. It's awkward to define a field = that has no rigid semantics without at least explaining why that was done t= hat way and/or how it might be used despite the absence of such structure. From yakov@shaftek.org Thu Feb 11 15:06:05 2010 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 BD53428C25B for ; Thu, 11 Feb 2010 15:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ghiwBn1hZ+KS for ; Thu, 11 Feb 2010 15:06:05 -0800 (PST) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by core3.amsl.com (Postfix) with ESMTP id CEEA428C242 for ; Thu, 11 Feb 2010 15:06:04 -0800 (PST) Received: by ewy3 with SMTP id 3so1898052ewy.13 for ; Thu, 11 Feb 2010 15:07:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.89.82 with SMTP id b60mr315390wef.170.1265929640222; Thu, 11 Feb 2010 15:07:20 -0800 (PST) In-Reply-To: References: <501c18e01002030748x5690ba63uc332b6366e9c13ea@mail.gmail.com> <1F3D4E90-C0D4-4D3E-B032-05D373EB2E9C@wordtothewise.com> <429D9386-501C-4B5B-8E52-3D68E739AEBA@wordtothewise.com> <501c18e01002101459u6aab2c96n99a32bd5d8c28060@mail.gmail.com> <45127546-0643-47E8-AC07-1EEF63D658FE@cybernothing.org> <501c18e01002111440p7e1d7de1p2637837c419369f7@mail.gmail.com> From: Yakov Shafranovich Date: Thu, 11 Feb 2010 18:07:00 -0500 Message-ID: <501c18e01002111507o453a9b0eg4eca3eb682e62df8@mail.gmail.com> To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 11 Feb 2010 23:06:05 -0000 On Thu, Feb 11, 2010 at 6:05 PM, Murray S. Kucherawy wr= ote: >> -----Original Message----- >> From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of >> Yakov Shafranovich >> Sent: Thursday, February 11, 2010 2:41 PM >> To: J.D. Falk >> Cc: Message Abuse Report Format working group >> Subject: Re: [marf] Reported-Domain vs Reported-URI >> >> > Right! =A0I think this gets back to our original intent: the metadata >> > is there to provide some hints/pointers that the ARF generator thinks >> > will be helpful, but the ARF consumer still needs to apply their own >> > internal logic to the original message to decide what to do. >> >> Perhaps we need to make this explicit in the document > > I think that's really what I'm getting at. =A0It's awkward to define a fi= eld that has no rigid semantics without at least explaining why that was do= ne that way and/or how it might be used despite the absence of such structu= re. > I meant that we should probably write this up somewhere that the intent of the fields in the second area is two fold: 1. Some carry data that cannot be derived from the original message like the connecting IP or the MAIL FROM. 2. Some are pointers but the original message should be parsed. Yakov From vesely@tana.it Fri Feb 12 00:02:16 2010 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 E1FB228C11D for ; Fri, 12 Feb 2010 00:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.682 X-Spam-Level: X-Spam-Status: No, score=-4.682 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIrOr62E57bQ for ; Fri, 12 Feb 2010 00:02:16 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id CAB7328C110 for ; Fri, 12 Feb 2010 00:02:15 -0800 (PST) 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, 12 Feb 2010 09:03:32 +0100 id 00000000005DC039.000000004B750B54.00003FFD Message-ID: <4B750B54.7030905@tana.it> Date: Fri, 12 Feb 2010 09:03:32 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20100211154257.8520.qmail@simone.iecc.com> In-Reply-To: <20100211154257.8520.qmail@simone.iecc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 12 Feb 2010 08:02:17 -0000 On 11/Feb/10 16:42, John Levine wrote: > In article<4B7411A1.2080804@tana.it> you write: >>On 10/Feb/10 23:56, Murray S. Kucherawy wrote: >>> I guess I have a different idea of automation on receipt, namely immediate >>mitigation rather than just bucketing or sorting for human action. >> >>IMHO, automatic action should only occur after the original message >>has been confirmed, e.g. a signature verified or a log matched. > > I'm pretty sure you will find that current ARF usage is mostly or > entirely automated. I know it is here. I can imagine it. However, I'd also guess that immediate mitigation is not carried out blindly upon receiving any ARF report. It may be worth to mention verification practices that experience has proved to be good or bad (for example, redaction breaks signatures, so it may be bad to check them.) > Like Steve said, Reported-Domain: is very useful for identifying > domains that are doing something strange, even with its current > somewhat ambiguous definition. I sharper definition shouldn't worsen that. Does the definition I proposed in http://www.ietf.org/mail-archive/web/marf/current/msg00658.html break existing implementations? From johnl@iecc.com Fri Feb 12 07:18:05 2010 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 91BED28C131 for ; Fri, 12 Feb 2010 07:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.929 X-Spam-Level: X-Spam-Status: No, score=-10.929 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3] 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 1cBTN5dsgysc for ; Fri, 12 Feb 2010 07:18:03 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 8C0C028B23E for ; Fri, 12 Feb 2010 07:18:03 -0800 (PST) Received: (qmail 75207 invoked from network); 12 Feb 2010 15:19:21 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 12 Feb 2010 15:19:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1002; olt=johnl@user.iecc.com; bh=LppIKv/QIUSW8JdDhMwgALftWJvEKBccOTsi4tFjs1w=; b=C0lmQ046n20ncHSEnHTIreD7S7UEnrQRde/Hkj8dW2iSNIUF2IVlTHh2l3c43qbVV8iKNn+nkYt0/F7VacTx+OISXfnFL1743Cb2CW0Qi9uoa/7xc1Sjx1Lvs/ICUgRbriRjPvsrdwGFPv6miPuxdvS2Nn9usxL2e++lXMeqNT8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1002; bh=LppIKv/QIUSW8JdDhMwgALftWJvEKBccOTsi4tFjs1w=; b=cflUShMBokboB1+luTtk1gdOcABAZqWPCQ0v8sdIvkQe2XmlhEF1Z+8rasithVATBmjYpo5CIjDeXnHOJmZWVd3C11wm6VAWiEkf9jqbHzb+OfKCtXziWJWKQ9vwiuYUz04Cl3cqAbv43NymnhQ9TBwUYSQ65JzPPqyYGp7tVgc= Date: 12 Feb 2010 15:19:21 -0000 Message-ID: <20100212151921.63875.qmail@simone.iecc.com> From: John Levine To: marf@ietf.org In-Reply-To: <4B750B54.7030905@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [marf] Reported-Domain vs Reported-URI 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, 12 Feb 2010 15:18:05 -0000 > It may be worth to mention verification practices that experience > has proved to be good or bad That would be fine, if there are any such practices. Since the vast majority of ARF messages are sent through FBLs from known senders, I would be surprised if there was a problem with fake ones. But neither you nor I know, so perhaps someone with more experience can inform us. > Does the definition I proposed in >http://www.ietf.org/mail-archive/web/marf/current/msg00658.html break >existing implementations? I believe it does. People send what they think is relevant, which may not be something you've thought of. R's, John From sm@resistor.net Sat Feb 13 00:17:00 2010 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 A54D228C119 for ; Sat, 13 Feb 2010 00:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] 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 5CodTaIv2+K9 for ; Sat, 13 Feb 2010 00:16:59 -0800 (PST) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id A01DF3A74EE for ; Sat, 13 Feb 2010 00:16:59 -0800 (PST) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4/8.14.4) with ESMTP id o1D8I7Nw021255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Feb 2010 00:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1266049098; x=1266135498; bh=pKZT1RobY/0DTBOgCWhHEYdz1Pm6m7qCIBBjY09hSf8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ap2iC+OZWdlKsUbI0miMI32mCI3igXs9LUzqXL/UtTK6y3oC3wF0nSRbvB1c5QRby TTi6q12xB9FDGjtUPZg3WG0MVgQDmjenSuAEhDCXaxcHYQOgAwbN2XcugtVQac52I/ 4O9M5ZeFiM7yUV1FUy/7O2QOvLgElE1AXTyHpypQ= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=CaHmV+bI09kH7XupEL1cDLIt9bJmdehK6hvenllunUvBXO7vQa3TSLTisaL6tdbJh fWN00QeTg8jXvnlb32fsctoVMYIFYHyjlqAHZZ//ptmPh0qP+q+DDZ/bm4dXLjkWQZo xrbc6UPdUSl5vy3uVZ+fSUgqpOshmBvXplLzgfQ= Message-Id: <6.2.5.6.2.20100212235445.0885bd30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 13 Feb 2010 00:17:48 -0800 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <6.2.5.6.2.20100207093735.09314ad8@elandnews.com> <501c18e01002071511k53a80df5n98ee113b73599428@mail.gmail.com> <6.2.5.6.2.20100207213326.0821dd60@resistor.net> <6.2.5.6.2.20100209000859.09077d50@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: marf@ietf.org Subject: Re: [marf] Comments on draft-ietf-marf-base-00 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: Sat, 13 Feb 2010 08:17:00 -0000 Hi Murray, At 10:26 10-02-10, Murray S. Kucherawy wrote: >How does an ARF generator make that decision? I don't think that >logic can be left unspecified. There are two types of reports: (i) by agreement (between the sender and the receiver) (ii) A report is sent to the receiver without any prior agreement between the two parties. I'll leave the question of whether item (ii) should be directly addressed by the draft open. As mentioned in the discussion about "Reported-Domain", the report will probably use the domain as a key to determine who should receive the report. Some receivers may consider redacted information as still meaningful to identify the source of the abuse. Some may not. It is better for the two parties to work things out if they are going to exchange a significant number of reports. >Here's a suggested subsection of Security Considerations to discuss >this issue (pardon the XML and indentation): > > It is conceivable that a system may be > implemented > that generates ARF reports automatically in > response to an event. For example, software > monitoring a honeypot email address > might generate > an ARF report immediately upon delivery of any > message to it. An attacker that becomes aware > of such a configuration can exploit it to > attack an ARF recipient with automatically > generated ARF reports. I suggest a minor change: A system might be generating reports automatically in response to an event. I did not use a proper definition of "system" as there is an example in the second sentence. >How about this? > >
> requires that its reports > be sent with the empty envelope > sender to avoid bounce loops. A similar requirement > was considered for this specification, but it seems > unlikely that an ARF report would be generated > in response to receipt of an ARF report, and furthermore > such a requirement would prevent an ARF generator from > ever determining that an ARF report was not actually > received. > On the other hand, if an ARF report is generated without > the empty envelope sender and is sent to an address that > actually does not work, then the generating address > can also be overwhelmed by DSNs as a denial of service > attack (see ). > > This specification therefore makes no requirement related > to the envelope sender of a generated report. Operators > will have to consider what envelope sender to use > within the context of their own installations. >
The text looks fine. Regards, -sm From vesely@tana.it Sat Feb 13 01:08:20 2010 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 4609728C1BB for ; Sat, 13 Feb 2010 01:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.682 X-Spam-Level: X-Spam-Status: No, score=-4.682 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twlJR5Gcku07 for ; Sat, 13 Feb 2010 01:08:19 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 682C328C1BA for ; Sat, 13 Feb 2010 01:08:19 -0800 (PST) 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; Sat, 13 Feb 2010 10:09:36 +0100 id 00000000005DC031.000000004B766C50.00001CE1 Message-ID: <4B766C50.2030301@tana.it> Date: Sat, 13 Feb 2010 10:09:36 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: marf@ietf.org References: <20100212151921.63875.qmail@simone.iecc.com> In-Reply-To: <20100212151921.63875.qmail@simone.iecc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [marf] Circumvent redaction (was: Reported-Domain vs Reported-URI 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: Sat, 13 Feb 2010 09:08:20 -0000 On 12/Feb/10 16:19, John Levine wrote: >> It may be worth to mention verification practices that experience has proved to be good or bad > > That would be fine, if there are any such practices. AOL suggests to insert an /opaque identifier/ to circumvent redaction. If cleverly designed, it can also confirm the message's origin. Does this subject belong to the ARF's RFC or to the accompanying BCP? > Since the vast majority of ARF messages are sent through FBLs from known senders, I would be surprised if there was a problem with fake ones. Correct. In this peculiar situation there is a small number of known operators. Did they subscribe to this list? From steve@wordtothewise.com Sat Feb 13 08:52:18 2010 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 2E4C83A735F for ; Sat, 13 Feb 2010 08:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+1yQwKBy6Xa for ; Sat, 13 Feb 2010 08:52:17 -0800 (PST) Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 6D3E33A7315 for ; Sat, 13 Feb 2010 08:52:17 -0800 (PST) Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 7F5E04F84A7 for ; Sat, 13 Feb 2010 08:53:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Steve Atkins In-Reply-To: <4B766C50.2030301@tana.it> Date: Sat, 13 Feb 2010 08:53:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <65F4B3E2-09D1-4231-81C9-14077FC8B799@wordtothewise.com> References: <20100212151921.63875.qmail@simone.iecc.com> <4B766C50.2030301@tana.it> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Circumvent redaction (was: Reported-Domain vs Reported-URI 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: Sat, 13 Feb 2010 16:52:18 -0000 On Feb 13, 2010, at 1:09 AM, Alessandro Vesely wrote: > On 12/Feb/10 16:19, John Levine wrote: >>> It may be worth to mention verification practices that experience = has proved to be good or bad >>=20 >> That would be fine, if there are any such practices. >=20 > AOL suggests to insert an /opaque identifier/ to circumvent redaction. = If cleverly designed, it can also confirm the message's origin. Does = this subject belong to the ARF's RFC or to the accompanying BCP? The details don't really belong in the RFC, though a mention of the = concept makes sense. I suspect there'll be some difficulty getting actual BCPs for it. There = have been corporations who did their best to delete those opaque = identifiers out of reports prior to sending them, to ensure the report = recipient could take no action based on them, and then those = corporations used that lack of action to justify blacklisting the report = recipient.=20 Given that, some report recipients are likely to be wary of discussing = their approaches in a forum with a persistent, public archive. >=20 >> Since the vast majority of ARF messages are sent through FBLs from = known senders, I would be surprised if there was a problem with fake = ones. >=20 > Correct. In this peculiar situation there is a small number of known = operators. Did they subscribe to this list? There's not really much point in crafting up a fake FBL report in order = to implicate someone when you can simply send out spam that implicates = them and wait for the inevitable result. Cheers, Steve From jdfalk-lists@cybernothing.org Sun Feb 14 16:26:11 2010 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 23D3328C170 for ; Sun, 14 Feb 2010 16:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 k4VEsP0d4LYr for ; Sun, 14 Feb 2010 16:26:10 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 219A328C16B for ; Sun, 14 Feb 2010 16:26:10 -0800 (PST) Received: from [10.0.218.24] (69-170-62-67.static-ip.telepacific.net [69.170.62.67]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5) with ESMTP id o1F0RY4n005794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 14 Feb 2010 17:27:36 -0700 References: <20100212151921.63875.qmail@simone.iecc.com> <4B766C50.2030301@tana.it> In-Reply-To: <4B766C50.2030301@tana.it> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <00D87996-8EF7-43FD-8FAD-5FCF82308DBE@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Sun, 14 Feb 2010 13:49:08 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Circumvent redaction (was: Reported-Domain vs Reported-URI 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: Mon, 15 Feb 2010 00:26:11 -0000 On Feb 13, 2010, at 2:09 AM, Alessandro Vesely wrote: > On 12/Feb/10 16:19, John Levine wrote: >>> It may be worth to mention verification practices that experience = has proved to be good or bad >>=20 >> That would be fine, if there are any such practices. >=20 > AOL suggests to insert an /opaque identifier/ to circumvent redaction. = If cleverly designed, it can also confirm the message's origin. Does = this subject belong to the ARF's RFC or to the accompanying BCP? BCP, if anywhere. It's already in many non-IETF BCP documents. >> Since the vast majority of ARF messages are sent through FBLs from = known senders, I would be surprised if there was a problem with fake = ones. >=20 > Correct. In this peculiar situation there is a small number of known = operators. Did they subscribe to this list? Some are, and we'll take care to update the others at MAAWG & similar = conferences -- plus, of course, encourage them to join this WG if = they're interested in participating. -- J.D. Falk Return Path Inc From msk@cloudmark.com Thu Feb 18 15:41:38 2010 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 80A053A7248 for ; Thu, 18 Feb 2010 15:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599] 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 utR+O81K4HuZ for ; Thu, 18 Feb 2010 15:41:37 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id BB7C43A7375 for ; Thu, 18 Feb 2010 15:41:37 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Thu, 18 Feb 2010 15:43:21 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 18 Feb 2010 15:42:08 -0800 Thread-Topic: Possible attendees, and a draft agenda Thread-Index: AQHKsPQnp+G6R75Q10G9nGy4sjFrWw== Message-ID: 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: [marf] Possible attendees, and a draft agenda 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, 18 Feb 2010 23:41:38 -0000 Can we get some idea who might be attending our inaugural meeting in Anahei= m next month? I know Barry and I are certainly going to be there.= From msk@cloudmark.com Thu Feb 18 15:49:06 2010 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 A68D83A7DEB for ; Thu, 18 Feb 2010 15:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599] 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 MZtl0O0RI-Wt for ; Thu, 18 Feb 2010 15:49:06 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id B820C3A7BED for ; Thu, 18 Feb 2010 15:49:05 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 18 Feb 2010 15:50:50 -0800 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Thu, 18 Feb 2010 15:50:49 -0800 Thread-Topic: ...and that draft agenda Thread-Index: AQHKsPUyonOq76pIhEel0O/e3IIL0Q== Message-ID: 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: [marf] ...and that draft agenda 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, 18 Feb 2010 23:49:06 -0000 (hit "Send" a little too soon) We've requested a 90-minute session for Anaheim. Here's a draft agenda fol= lowed by a few topics that might warrant some agenda time. Feel free to ma= ke other suggestions. 0:20 - History of the work, overview of the current document, overview of c= urrent deployment (Barry?) 0:10 - Outstanding issues (redaction flag, Reported-Domain:) (Murray) 0:05 - Start WGLC on -base document 0:15 - Current parallel work at the GSMA and OMA (?) 0:15 - Discussion of topics to be covered in a BCP draft (maybe the MAAWG F= BL BCP?) 0:15 - Discussion of DKIM extensions draft 0:10 - Any other business From yakov@shaftek.org Thu Feb 18 18:08:46 2010 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 967393A7E2A for ; Thu, 18 Feb 2010 18:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 i33WFx4xsY-E for ; Thu, 18 Feb 2010 18:08:46 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id A49163A71D3 for ; Thu, 18 Feb 2010 18:08:45 -0800 (PST) Received: by ewy8 with SMTP id 8so10215094ewy.29 for ; Thu, 18 Feb 2010 18:10:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.88.68 with SMTP id z46mr1179388wee.215.1266545426113; Thu, 18 Feb 2010 18:10:26 -0800 (PST) In-Reply-To: References: From: Yakov Shafranovich Date: Thu, 18 Feb 2010 21:10:06 -0500 Message-ID: <501c18e01002181810q4d5d845evfce31d833d529ff@mail.gmail.com> To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Message Abuse Report Format working group Subject: Re: [marf] ...and that draft agenda 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, 19 Feb 2010 02:08:46 -0000 Is there going to be any sort of hookup for remote attendees? On Thu, Feb 18, 2010 at 6:50 PM, Murray S. Kucherawy wr= ote: > (hit "Send" a little too soon) > > We've requested a 90-minute session for Anaheim. =A0Here's a draft agenda= followed by a few topics that might warrant some agenda time. =A0Feel free= to make other suggestions. > > 0:20 - History of the work, overview of the current document, overview of= current deployment (Barry?) > 0:10 - Outstanding issues (redaction flag, Reported-Domain:) (Murray) > 0:05 - Start WGLC on -base document > 0:15 - Current parallel work at the GSMA and OMA (?) > 0:15 - Discussion of topics to be covered in a BCP draft (maybe the MAAWG= FBL BCP?) > 0:15 - Discussion of DKIM extensions draft > 0:10 - Any other business > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From msk@cloudmark.com Fri Feb 19 09:54:18 2010 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 EC83D3A81AC for ; Fri, 19 Feb 2010 09:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599] 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 llgzXJRLIeIq for ; Fri, 19 Feb 2010 09:54:18 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 3EC8B3A7ADF for ; Fri, 19 Feb 2010 09:54:18 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Fri, 19 Feb 2010 09:56:05 -0800 From: "Murray S. Kucherawy" To: Yakov Shafranovich Date: Fri, 19 Feb 2010 09:55:18 -0800 Thread-Topic: [marf] ...and that draft agenda Thread-Index: AcqxCLSLpOAsbdA5TqyT4Z0MmPBc+AAg/4by Message-ID: References: , <501c18e01002181810q4d5d845evfce31d833d529ff@mail.gmail.com> In-Reply-To: <501c18e01002181810q4d5d845evfce31d833d529ff@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Message Abuse Report Format working group Subject: Re: [marf] ...and that draft agenda 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, 19 Feb 2010 17:54:19 -0000 There's always both an audio feed (read-only) and a Jabber room set up; the= Jabber room will have someone transcribing what goes on in the room as wel= l as relaying questions from Jabber into the microphone. ________________________________________ From: Yakov Shafranovich [yakov@shaftek.org] Sent: Thursday, February 18, 2010 6:10 PM To: Murray S. Kucherawy Cc: Message Abuse Report Format working group Subject: Re: [marf] ...and that draft agenda Is there going to be any sort of hookup for remote attendees? On Thu, Feb 18, 2010 at 6:50 PM, Murray S. Kucherawy wr= ote: > (hit "Send" a little too soon) > > We've requested a 90-minute session for Anaheim. Here's a draft agenda f= ollowed by a few topics that might warrant some agenda time. Feel free to = make other suggestions. > > 0:20 - History of the work, overview of the current document, overview of= current deployment (Barry?) > 0:10 - Outstanding issues (redaction flag, Reported-Domain:) (Murray) > 0:05 - Start WGLC on -base document > 0:15 - Current parallel work at the GSMA and OMA (?) > 0:15 - Discussion of topics to be covered in a BCP draft (maybe the MAAWG= FBL BCP?) > 0:15 - Discussion of DKIM extensions draft > 0:10 - Any other business > _______________________________________________ > marf mailing list > marf@ietf.org > https://www.ietf.org/mailman/listinfo/marf > From msk@cloudmark.com Tue Feb 23 10:16:27 2010 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 65A683A84B1 for ; Tue, 23 Feb 2010 10:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 IqDAdXByFSyQ for ; Tue, 23 Feb 2010 10:16:23 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 757893A8497 for ; Tue, 23 Feb 2010 10:16:20 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Tue, 23 Feb 2010 10:18:24 -0800 From: "Murray S. Kucherawy" To: "MARF@ietf.org" Date: Tue, 23 Feb 2010 10:18:22 -0800 Thread-Topic: base-01 coming your way Thread-Index: Acq0tJV572ayPGpJTr6v0e0mFzp3SA== 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_BB012BD379D7B046ABE1472D8093C61C01C43AFD8CEXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] base-01 coming your way 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, 23 Feb 2010 18:16:27 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01C43AFD8CEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm about to post a revision of the base draft, including all of the discus= sion so far. The issue of adding a "redacted" indicator remains open. I don't believe w= e have a solid consensus either up or down on that issue yet, so I've defau= lted to leaving it off since we're trying to document current practice as m= uch as possible. Please give it a look once you see the posting notice and let me know if th= ere are any other editorial changes we should pursue. I hope to start Working Group Last Call on this document at our Anaheim mee= ting next month. --_000_BB012BD379D7B046ABE1472D8093C61C01C43AFD8CEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m about to post a revision of the base draft, including all of the discussion so far.

 

The issue of adding a “redacted” indicator remains open.  I don’t believe we have a solid consensus either = up or down on that issue yet, so I’ve defaulted to leaving it off since we&= #8217;re trying to document current practice as much as possible.

 

Please give it a look once you see the posting notice = and let me know if there are any other editorial changes we should pursue.=

 

I hope to start Working Group Last Call on this docume= nt at our Anaheim meeting next month.

--_000_BB012BD379D7B046ABE1472D8093C61C01C43AFD8CEXCHC2corpclo_-- From root@core3.amsl.com Tue Feb 23 10:30:07 2010 Return-Path: X-Original-To: marf@ietf.org Delivered-To: marf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1DE083A84BC; Tue, 23 Feb 2010 10:30:05 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100223183007.1DE083A84BC@core3.amsl.com> Date: Tue, 23 Feb 2010 10:30:06 -0800 (PST) Cc: marf@ietf.org Subject: [marf] I-D Action:draft-ietf-marf-base-01.txt 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, 23 Feb 2010 18:30:07 -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 : An Extensible Format for Email Feedback Reports Author(s) : Y. Shafranovich, et al. Filename : draft-ietf-marf-base-01.txt Pages : 33 Date : 2010-02-23 This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-marf-base-01.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-base-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-23102025.I-D@ietf.org> --NextPart-- From jdfalk-lists@cybernothing.org Wed Feb 24 15:36:44 2010 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 B61233A8608 for ; Wed, 24 Feb 2010 15:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.664 X-Spam-Level: X-Spam-Status: No, score=-6.664 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, 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 fjl7Cl9fzM9a for ; Wed, 24 Feb 2010 15:36:43 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id F2AB53A8607 for ; Wed, 24 Feb 2010 15:36:41 -0800 (PST) Received: from jds-macbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o1ONcKxS029149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 24 Feb 2010 16:38:49 -0700 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <2B08588B-95C0-44F1-A871-475B4144089A@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Wed, 24 Feb 2010 16:38:49 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] Possible attendees, and a draft agenda 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: Wed, 24 Feb 2010 23:36:44 -0000 On Feb 18, 2010, at 4:42 PM, Murray S. Kucherawy wrote: > Can we get some idea who might be attending our inaugural meeting in = Anaheim next month? >=20 > I know Barry and I are certainly going to be there. I'll be there. -- J.D. Falk Return Path Inc From jdfalk-lists@cybernothing.org Wed Feb 24 15:45:00 2010 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 29F6328C197 for ; Wed, 24 Feb 2010 15:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.667 X-Spam-Level: X-Spam-Status: No, score=-6.667 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_BSP_OTHER=-0.1, 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 FZ6EplKy0svW for ; Wed, 24 Feb 2010 15:44:55 -0800 (PST) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 0F55728C0DE for ; Wed, 24 Feb 2010 15:44:54 -0800 (PST) Received: from jds-macbook.rpcorp.local (np34.co.returnpath.net [38.109.196.34]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o1ONl1vR029238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 24 Feb 2010 16:47:03 -0700 References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Wed, 24 Feb 2010 16:46:55 -0700 To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1077) Subject: Re: [marf] ...and that draft agenda 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: Wed, 24 Feb 2010 23:45:00 -0000 On Feb 18, 2010, at 4:50 PM, Murray S. Kucherawy wrote: > We've requested a 90-minute session for Anaheim. Here's a draft = agenda followed by a few topics that might warrant some agenda time. = Feel free to make other suggestions. >=20 > 0:20 - History of the work, overview of the current document, overview = of current deployment (Barry?) I could help with this part, if needed. > 0:10 - Outstanding issues (redaction flag, Reported-Domain:) (Murray) > 0:05 - Start WGLC on -base document > 0:15 - Current parallel work at the GSMA and OMA (?) I'll reach out to one of the people leading that effort, and see if = there'll be someone appropriate in Anaheim. > 0:15 - Discussion of topics to be covered in a BCP draft (maybe the = MAAWG FBL BCP?) MAAWG's document may not be approved for public distribution in time. = I'll keep y'all updated. > 0:15 - Discussion of DKIM extensions draft > 0:10 - Any other business Looks good. Sorry about the late reply. -- J.D. Falk Return Path Inc From msk@cloudmark.com Wed Feb 24 16:13:23 2010 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 B844A28C28E for ; Wed, 24 Feb 2010 16:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599] 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 b5RctElRbBMz for ; Wed, 24 Feb 2010 16:13:22 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 55BB228C284 for ; Wed, 24 Feb 2010 16:13:22 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Wed, 24 Feb 2010 16:15:30 -0800 From: "Murray S. Kucherawy" To: "J.D. Falk" , Message Abuse Report Format working group Date: Wed, 24 Feb 2010 16:15:29 -0800 Thread-Topic: [marf] ...and that draft agenda Thread-Index: Acq1q7d48+68arPPTxW6Fu7gQwGarwAA9dMQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] ...and that draft agenda 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, 25 Feb 2010 00:13:23 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of > J.D. Falk > Sent: Wednesday, February 24, 2010 3:47 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] ...and that draft agenda >=20 > On Feb 18, 2010, at 4:50 PM, Murray S. Kucherawy wrote: >=20 > > We've requested a 90-minute session for Anaheim. Here's a draft > agenda followed by a few topics that might warrant some agenda time. > Feel free to make other suggestions. > > > > 0:20 - History of the work, overview of the current document, > overview of current deployment (Barry?) >=20 > I could help with this part, if needed. Great! > > 0:10 - Outstanding issues (redaction flag, Reported-Domain:) (Murray) > > 0:05 - Start WGLC on -base document > > 0:15 - Current parallel work at the GSMA and OMA (?) >=20 > I'll reach out to one of the people leading that effort, and see if > there'll be someone appropriate in Anaheim. That would also be great. Just in case, I'm gathering information about it= as well so I can cover it if nobody else picks it up. From msk@cloudmark.com Thu Feb 25 14:16:45 2010 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 062B93A8727 for ; Thu, 25 Feb 2010 14:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] 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 7I8DMQ0FTvuQ for ; Thu, 25 Feb 2010 14:16:44 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 35FFD3A8726 for ; Thu, 25 Feb 2010 14:16:41 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 25 Feb 2010 14:18:53 -0800 From: "Murray S. Kucherawy" To: Spocksynder , Yakov Shafranovich Date: Thu, 25 Feb 2010 14:18:51 -0800 Thread-Topic: [feedback-report] Repeated optional fields distribution in feedback-report, and typo in IETF draft Thread-Index: Acq2NRbjjn4UuCo+TmSw/RtyN3QoVQAMz9jQ Message-ID: References: <501c18e01002241933p79f3ff33s46bc4353362c36af@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abuse-feedback-report@mipassoc.org" , "marf@ietf.org" Subject: Re: [marf] [feedback-report] Repeated optional fields distribution in feedback-report, and typo in IETF 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: Thu, 25 Feb 2010 22:16:45 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of Spocksynder > Sent: Thursday, February 25, 2010 8:10 AM > To: Yakov Shafranovich > Cc: abuse-feedback-report@mipassoc.org > Subject: Re: [feedback-report] Repeated optional fields distribution in > feedback-report, and typo in IETF draft >=20 > Hi, > My question is: >=20 > Is this a valid report(with fields being repeated, but other fields > being in between)? >=20 > Authentication-Results: [ authres-header-1 ] > Original-Rcpt-To: [orig-rcpt-to-1] > Authentication-Results: [ authres-header-2 ] > Original-Rcpt-To: [orig-rcpt-to-2] >=20 > Or should the repeated fields be placed consecutively like below? >=20 > Authentication-Results: [ authres-header-1 ] > Authentication-Results: [ authres-header-2 ] > Original-Rcpt-To: [orig-rcpt-to-1] > Original-Rcpt-To: [orig-rcpt-to-2] >=20 > I was not very clear about this from the document. Could you please > clarify? It is so far unspecified, which probably means it hasn't been an important = point to any of the current implementers. Is this an important thing to restrict by specifying it? From msk@cloudmark.com Thu Feb 25 14:19:17 2010 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 A53BA3A8727 for ; Thu, 25 Feb 2010 14:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599] 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 COBXYWcVnswe for ; Thu, 25 Feb 2010 14:19:16 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id D8A5E3A8726 for ; Thu, 25 Feb 2010 14:19:16 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.1.72]) with mapi; Thu, 25 Feb 2010 14:21:29 -0800 From: "Murray S. Kucherawy" To: Yakov Shafranovich , Spocksynder Date: Thu, 25 Feb 2010 14:21:28 -0800 Thread-Topic: [feedback-report] Repeated optional fields distribution in feedback-report, and typo in IETF draft Thread-Index: Acq1y2nAjET8ivrHSsK1nTZdGVp6dgAnVwPg Message-ID: References: <501c18e01002241933p79f3ff33s46bc4353362c36af@mail.gmail.com> In-Reply-To: <501c18e01002241933p79f3ff33s46bc4353362c36af@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abuse-feedback-report@mipassoc.org" , "marf@ietf.org" Subject: Re: [marf] [feedback-report] Repeated optional fields distribution in feedback-report, and typo in IETF 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: Thu, 25 Feb 2010 22:19:17 -0000 > -----Original Message----- > From: abuse-feedback-report-bounces@mipassoc.org [mailto:abuse- > feedback-report-bounces@mipassoc.org] On Behalf Of Yakov Shafranovich > Sent: Wednesday, February 24, 2010 7:34 PM > To: Spocksynder > Cc: abuse-feedback-report@mipassoc.org > Subject: Re: [feedback-report] Repeated optional fields distribution in > feedback-report, and typo in IETF draft >=20 > As per the ABNF grammar the non-repeatable fields appear first, and > then the optional ones. There is no order for the optional ones. >=20 > I believe we need to make this more explicit, just like it was done in > RFC 3464: >=20 > "The per-message fields appear first, followed by a > blank line. Following the per-message fields are one or more groups > of per-recipient fields. Each group of per-recipient fields is > preceded by a blank line. > " To some degree we're documenting current usage. So what are current implem= enters doing around this issue? From Mark.Martinec+ietf@ijs.si Fri Feb 26 10:15:37 2010 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 2351C28C2EA for ; Fri, 26 Feb 2010 10:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6] 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 I7k8prrBP8yy for ; Fri, 26 Feb 2010 10:15:36 -0800 (PST) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by core3.amsl.com (Postfix) with ESMTP id D6E5828C2E5 for ; Fri, 26 Feb 2010 10:15:35 -0800 (PST) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id A28771D1CBC; Fri, 26 Feb 2010 19:17:49 +0100 (CET) Authentication-Results: mail.ijs.si; dkim=pass (1024-bit key) header.i=@ijs.si; dkim-adsp=pass DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:date:date:organization:from:from:subject:subject :received:received:received; s=jakla2; t=1267208268; x= 1269800268; bh=/5yxo5y72DraVGsnh23IDbKGO4Kf8YmFe5SMWR7NnUc=; b=p h7Tcq3I/+J+dI9G7dlGZGVPUSUHZLgxSn1evhzvW55EDMiKPg7qKabhLa1/UmR5Z XfQzq1xB2zEUmQ3IQnnFPWQZ2p/TadCaA/Kw1ZgMDUgFRH5us7tvG8YkgmY2xYmu u8Y9yGqcQppCdnoG7NGmVdPfuo4O6jnlXJjT8QrPmo= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([127.0.0.1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [127.0.0.1]) (amavisd-new, port 10012) with ESMTP id r-6TrjbGUGQN; Fri, 26 Feb 2010 19:17:48 +0100 (CET) Received: from edina.ijs.si (unknown [IPv6:2001:1470:ff80:0:2e0:81ff:fe72:51d]) by mail.ijs.si (Postfix) with ESMTP; Fri, 26 Feb 2010 19:17:47 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by edina.ijs.si (Postfix) with ESMTPSA id DF1E422EC71; Fri, 26 Feb 2010 19:17:47 +0100 (CET) To: "marf@ietf.org" From: Mark Martinec Organization: J. Stefan Institute Date: Fri, 26 Feb 2010 19:17:47 +0100 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002261917.47774.Mark.Martinec+ietf@ijs.si> Cc: abuse-feedback-report@mipassoc.org Subject: Re: [marf] [feedback-report] Repeated optional fields distribution in feedback-report, and typo in IETF 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, 26 Feb 2010 18:15:37 -0000 (sorry if this is a duplicate) > Is this a valid report(with fields being repeated, but other fields > being in between)? > > Authentication-Results: [ authres-header-1 ] > Original-Rcpt-To: [orig-rcpt-to-1] > Authentication-Results: [ authres-header-2 ] > Original-Rcpt-To: [orig-rcpt-to-2] > > Or should the repeated fields be placed consecutively like below? > > Authentication-Results: [ authres-header-1 ] > Authentication-Results: [ authres-header-2 ] > Original-Rcpt-To: [orig-rcpt-to-1] > Original-Rcpt-To: [orig-rcpt-to-2] Murray S. Kucherawy wrote: > To some degree we're documenting current usage. So what are current > implementers doing around this issue? It doesn't make semantic sense to interleave them, as the Original-Rcpt-To go one-per-recipient, and the Authentication-Results are one-per-signature. Amavisd-new does all the Original-Rcpt-To first, then all Authentication-Results. Mark