Subject: Re: [marf] Feedback Loops BCP document

From: John Levine <[email-masked]>
Date: 3 Mar 2011 04:00:18 -0000

>I would like this group to review the draft and determine how much we
>agree with it and would like to have it as an IETF BCP product of
>MARF.

The basic contents are fine, but if this is intended to be a BCP, it
needs to be recast in BCP-ese, with more explicit SHOULD and SHOULD NOT
advice about specific practices.

I'd also like it to note that redacting FBL reports is pointless, since
in a properly operating FBL you're sending them back to someone who has
already seen all of them.

Nits:

 title of sec 3.6.1 is wrong

 item 5 in sec 4.1 is surely true, but seems a bit much

 in 4.3.1 the first line refers to commercial email, but the section
 is equally applicable to non-commercial mail, e.g., political or
 religious bulk mail

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Wed, 2 Mar 2011 20:11:24 -0800

> already seen all of them.

Redacting them reduces the
PII leakage in those (fairly common) cases where the FBL goes
to someone other than the original author of the email.

That doesn't mean that redacting (or not-redacting) is necessarily
a good idea, but it's not pointless.

Cheers,
  Steve

---

From: "McDowell, Brett" <[email-masked]>
Date: Thu, 3 Mar 2011 08:53:26 -0700

I agree with Steve.

On Mar 2, 2011, at 11:11 PM, Steve Atkins wrote:

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

---

From: Dotzero <[email-masked]>
Date: Thu, 3 Mar 2011 11:24:52 -0500

I would agree with Steve as well. It can be frustrating as a
sender/brand but I realize that there are potential concerns for FBL
providers. We use the timestamp that we generate on the original email
to allow us to match up where information has been redacted (no other
use is made of this ability with the timestamp). Some FBL providers do
get a little redact happy though.

---

From: Michael Adkins <[email-masked]>
Date: Thu, 3 Mar 2011 17:44:28 +0000

Not all FBLs go to the organization that runs the SMTP servers.  Some are
sent to third party data aggregators by request of the original mail
sending organization.  Some are also sent to upstream network providers
who want to monitor their customers or whoever their customers are
reallocating space to.  I don't consider either of those use cases
improper.

On 3/2/11 8:00 PM, "John Levine" <[email-masked]> wrote:

>'d also like it to note that redacting FBL reports is pointless, since

---

From: "John R Levine" <[email-masked]>
Date: 3 Mar 2011 13:22:50 -0500

> reallocating space to.  I don't consider either of those use cases

Good point.  "Never mind."

But I do wish that places like A*L would redact consistently.  It's a pain 
tweaking my processing scripts every time they change what they do.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 3 Mar 2011 10:26:10 -0800

On Mar 3, 2011, at 10:22 AM, John R Levine wrote:

> But I do wish that places like A*L would redact consistently.  It's a pain tweaking my processing scripts every time they change what they do.

If you're automating it's rare that you should be looking at email addresses anyway. Inject an opaque cookie header at your mlm[1] or smarthost and rely on that.

Cheers,
  Steve

[1] Given you're about a third of the mj2 userbase you must have some pull to get that added :)

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 3 Mar 2011 11:03:40 -0800

> If you're automating it's rare that you should be looking at email addresses anyway. Inject an opaque cookie header at your mlm[1] or smarthost and rely on that.

...which I believe is what the document says.  Did you write that part?  *grin*

Still not seeing many opinions for or against bringing the MAAWG document into this WG....

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

---

From: John Levine <[email-masked]>
Date: 3 Mar 2011 20:04:40 -0000

>Still not seeing many opinions for or against bringing the MAAWG document into this WG....

My opinion is that it would make a good IETF BCP, but we'd have to
rewrite it, which might pose a problem for MAAWG.

R's,
John