Subject: [marf] draft-jdfalk-marf-redaction

From: "J.D. Falk" <[email-masked]>
Date: Tue, 8 Mar 2011 09:43:03 -0800

I was in the mood for xml the other day, so I took section 10 of draft-ietf-marf-dkim-reporting and added the minimum necessary additional text and formatting to make it a stand-alone draft:

http://tools.ietf.org/html/draft-jdfalk-marf-redaction-00

(Oops, just noticed I forgot to acknowledge the original authors.  Many apologies; that'll be fixed in the next version.)

My thought is that by making this a stand-alone Informational RFC, it'll be easy to reference from other documents.

Any thoughts?

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

---

From: John Levine <[email-masked]>
Date: 8 Mar 2011 18:41:40 -0000

It's a clever idea.  Any chance ISPs will actually do this?

R's,
John

---

From: Michael Adkins <[email-masked]>
Date: Tue, 8 Mar 2011 18:48:54 +0000

Facebook already does.  Granted, it's just for vendor report feeds but I
doubt we'll change the redaction method for general ARF feeds once we
start offering them.

On 3/8/11 10:41 AM, "John Levine" <[email-masked]> wrote:

>_______________________________________________
>marf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/marf

---

From: Tobias Knecht <[email-masked]>
Date: Tue, 08 Mar 2011 21:08:35 +0100

Hello everybody,

> It's a clever idea.  Any chance ISPs will actually do this?

I think that will be the biggest problem.

Never the less I like the idea, but I think it's trying to solve a
problem from the wrong side.

Okay, I' from Germany ;-), so I fully understand that sometimes
redacting is necessary, but I do not understand, why the redacting
problem has to be solved by the feedbackloop offering party. I see the
problem that putting the threshold higher for ISPs that already have
legal trouble offering feedbackloops does not make it any better.

Wouldn't it make more sense to add an encrypted ID to every single
outgoing mail header? That's what some European ISPs already do. Some of
them call it X-Abuse-ID. This ID contains everything that is necessary
for abuse handling, unsubscribing, whatever else.

Such an ID is solving the redacting problem for everybody completely and
prevents feedbackloop offering ISPs to change their existing systems.

Thanks,

Tobias

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 8 Mar 2011 14:23:17 -0800

> for abuse handling, unsubscribing, whatever else.

That's common outside of Europe, too, but it doesn't address the Feedback Generator's lawyers' requirement that potentially personally identifying information be redacted from the feedback message.

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 8 Mar 2011 14:25:30 -0800

> It's a clever idea.  Any chance ISPs will actually do this?

Maybe.  The main thing is to introduce the redaction concept in a reference-able document, and suggest at least one alternative to xxxxxxxx.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 12 Mar 2011 13:28:43 +0100

On 08/Mar/11 18:43, J.D. Falk wrote:
> I was in the mood for xml the other day, so I took section 10 of
> draft-ietf-marf-dkim-reporting and added the minimum necessary
> additional text and formatting to make it a stand-alone draft:
> 

What strings should be identified as private data?  I'd suggest to
redact atoms, rather than strings that contain special characters.

How do consumers identify redacted parts?  Are they expected to be
able to verify DKIM signatures after replacing the redacted parts?
(Don't they need the redaction key to check they identified each part
correctly?)

What about line length limits?  Should the encoded hash be truncated
to the length of the redacted token?

After private data has been identified, should it be redacted in the
whole message, that is, including the body?  For example, I think I
can hide some text <[email-masked]>.
Should we standardize such practice, since we are at it?

We should explicitly say what parts should never be redacted. This
includes header fields names, boundaries, and most parts of /some/
fields, for example DKIM signatures possibly except z=, Received
fields possibly except "for" clauses.

As a security consideration, I'd mention that the scope of redaction
is limited to casual eavesdropper, including low-privileged abuse
teams staffers.  Using logs or purposely added opaque fields, one can
learn who were the original recipients, which is the reason why abuse
messages are sent in the first place.

Just mumbling...

---

From: Jacqui Caren-home <[email-masked]>
Date: Sun, 13 Mar 2011 10:30:03 +0000

> messages are sent in the first place.

The below discusses the case of hitting a spamtrap of email being rejected
internally by AVAS systems.

I disagree - I report spam to the MSP so that they can take action aginst
the spammer or at least ask the spammer to prove they are not spamming by
providng COI details for a random number of recently send email recipients.
They should NOT need my (spamtrap) details to confirm a customer is
breaking the MSP's TOS.

I would recommend that redaction be based upon the anti-spam score the
orginal message gets and what level of trust you place in the MSP.

 > Just mumbling...

Given the fiasco while trying to report abusive (inline image heavy to botnet/scraper
spamtraps) spam to messagelabs I would recommend redaction of all identifying marks
when dealing with a spamtrap of obvious spam.
This includes the "name" part of the recipent which is being used by some commercial
spammers (including the said ML spammer) as a unique "tag" back into thier list. Such
tricks are being used by spammers and some bulk MSP's who buy in lists and wish to
detect the spamtraps hit. Even worse are the list cleanse businesses who are using said
tricks to generate lists of know spamtraps for resale or reuse to cleanse commercial
list data. I am afraid that detecting spamtraps is big business and people like ML
seem to be quite happy to help paying "customers" detect them.

http://caren.ddns.me.uk/index.php/spam/2-messagelabs.html

Jacqui