Subject: Re: [marf] draft-ietf-marf-base-00

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 1 Feb 2010 11:38:29 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, January 26, 2010 3:12 PM
To: [email-masked]
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 modifications, as draft-ietf-marf-base-00.

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'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

---

From: Steve Atkins <[email-masked]>
Date: Mon, 1 Feb 2010 11:47:06 -0800

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?

... 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

> As you can see I’ve posted the revised draft, i.e. draft-shafranovich-feedback-report with the recently discussed modifications, as draft-ietf-marf-base-00.
>  
> 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’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
>  
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 1 Feb 2010 12:38:04 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Steve Atkins
> Sent: Monday, February 01, 2010 11:47 AM
> To: [email-masked]
> Subject: Re: [marf] draft-ietf-marf-base-00
> 
> 

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.

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.

?

---

From: Steve Atkins <[email-masked]>
Date: Mon, 1 Feb 2010 12:43:11 -0800

> 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 peop…

Right.

> 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…

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: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 1 Feb 2010 12:48:02 -0800

> Sent: Monday, February 01, 2010 12:43 PM
> To: [email-masked]
> (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 the actual operators of an FBL and the lawyers that influence their choices. :)

---

From: Michael Adkins <[email-masked]>
Date: Mon, 01 Feb 2010 16:06:12 -0500

> Much better, yes. It gets the message across nicely without exaggerating the issue.
+1

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 02 Feb 2010 09:59:38 +0100

> 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 t…

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…

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: "John R Levine" <[email-masked]>
Date: 2 Feb 2010 11:56:12 -0500

>> 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, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Feb 2010 15:13:11 -0800

[as participant]

> Alessandro Vesely
> Sent: Tuesday, February 02, 2010 1:00 AM
> To: [email-masked]
> > 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.
> 

Actually I think including an example is useful here, but it doesn't need to be this one if there's a better one.  Can someone suggest a better one?

> present in the examples and in the Removal-Recipient field name.

Thanks, I'll fix that.

> 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 documenting a current, widely-deployed system, so it's appropriate to include it.

>    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: Alessandro Vesely <[email-masked]>
Date: Wed, 03 Feb 2010 10:56:46 +0100

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: Alessandro Vesely <[email-masked]>
Date: Wed, 03 Feb 2010 10:58:00 +0100

On 03/Feb/10 00:13, Murray S. Kucherawy wrote:
>>  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 (Seymour J.) Metz <[email-masked]>
Date: Tue, 02 Feb 2010 05:49:06 -0500

In
<[email-masked]>,
on 02/01/2010

>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        <http://patriot.net/~shmuel>
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 Shafranovich <[email-masked]>
Date: Wed, 3 Feb 2010 10:57:36 -0500

> report-type=feedback-report; redacted=yes.

We discussed this a few weeks ago and the consensus seems to be that
such flag is useless.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 3 Feb 2010 09:44:52 -0800

> present in the examples and in the Removal-Recipient field name.

Thanks; removed.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 3 Feb 2010 09:48:18 -0800

> Sent: Wednesday, February 03, 2010 1:58 AM
> To: [email-masked]

What do existing FBL operators do in terms of testing a new FBL?

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 3 Feb 2010 13:21:42 -0700

+1

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 3 Feb 2010 13:26:56 -0700

> 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.