Subject: Re: [ietf-dkim] Proposal to amend SSP draft with a reporting address (fwd)

From: SM <[email-masked]>
Date: Sun, 02 Mar 2008 06:24:07 -0800

At 14:15 28-02-2008, Murray S. Kucherawy wrote:
>On Thu, 28 Feb 2008, Florian Sager wrote:
> > Thanks for this reminder, I forgot about this draft: maybe section 4.1
> > can be extended by s.th. like "a Reports are requested for passed
> > signatures inside mails with suspicious content". The same intent may
> > already be included in 4.2 "s ... signed and Suspicious".
>
>Not a bad idea.  Any comments from others?

This draft is for reporting DKIM verification issues.  Wouldn't the 
above change the purpose of the draft?

Regards,
-sm 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Florian Sager <[email-masked]>
Date: Fri, 07 Mar 2008 14:06:15 +0100

Murray S. Kucherawy schrieb:
>> Thanks for this reminder, I forgot about this draft: maybe section 
>> 4.1 can be extended by s.th. like "a Reports are requested for passed 

I wrote a small script that reports spam mails - received in spam traps 
- to the optional r-address defined in 
draft-kucherawy-dkim-reporting-01.txt in ARF format (currently ro=all 
has to be set).

http://www.mipassoc.org/arf/specs/draft-shafranovich-feedback-report-02.html#rfc.section.4 
claims that the original email has to be contained (with rather few 
modifications). Unfortunately any information sent back to the signing 
authority (that should be linked to the reporting address) can be used 
to detect the spamtraps (even the subject, the DKIM identity or the date 
contained in the first section of the ARF report could be correlated to 
a spam trap address).

Any ideas how to handle this? I guess "give no feedback" is the 
unsatisfying solution.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Mar 2008 07:34:46 -0700

> Not a bad idea.  Any comments from others?

It's unrelated to the existing published information.

That doesn't mean that it is a bad idea, but it does mean that it inherently 
expands the scope of the current ASP draft.

Since,

      a) reporting is a topic still being developed and is broader than this one 
idea, and

      b) ASP provides an extensible mechanism for later enhancement,

this seems like a fine topic for... later enhancement.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Mar 2008 06:51:04 -0800

> this seems like a fine topic for... later enhancement.

I'm pretty much of the same mindset, but it does beg the question
of when we're free to recharter (or not)?

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Mar 2008 08:57:36 -0700

> of when we're free to recharter (or not)?

A worthy task... perhaps after we complete the challenging draft that we are so 
close to completing and wouldn't want to get distracted from...?

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Mar 2008 08:06:20 -0800

Dave Crocker wrote:
> A worthy task... perhaps after we complete the challenging draft that we 
> are so close to completing and wouldn't want to get distracted from...?

Yeah, I guess what I'm asking whether it's before or after -overview...
definitely not before ASP. I'm with John that this reporting thing has
a lot more to it than first meets the eye. Maybe a separate mailing list
should be formed before then to preliminarily hash it out? I wouldn't
mind coding some stuff up along the way to see how it goes.

		Mike

---

From: John Levine <[email-masked]>
Date: 7 Mar 2008 15:37:36 -0000

>of when we're free to recharter (or not)?

SSP desperately needs real life experience before we start twiddling it.

I'd like to go with the current modest version and come back after
we've found out what's useful and what isn't.

The reporting address sounds like a fine idea, but as we've already
seen there's all sorts of questions that would benefit from
experience, like how much you redact, and to what extent asking for
reports would be an invitation to be mailbombed.

R's,
John

---

From: "J D Falk" <[email-masked]>
Date: Fri, 7 Mar 2008 13:07:39 -0500

> we've found out what's useful and what isn't.

+1

> reports would be an invitation to be mailbombed.

I'd think we can gain reporting experience on an ad-hoc basis without
outwardly modifying ASP.  This is probably more of an interop topic,
though.

--
J.D. Falk
Receiver Products
Return Path

---

From: "J D Falk" <[email-masked]>
Date: Fri, 7 Mar 2008 13:01:40 -0500

Florian Sager wrote:

> http://www.mipassoc.org/arf/specs/draft-shafranovich-feedback-
> report-02.html#rfc.section.4 claims that the original email has to be
> contained (with rather few modifications). Unfortunately any
information
> sent back to the signing authority (that should be linked to the
> reporting address) can be used to detect the spamtraps (even the
> subject, the DKIM identity or the date contained in the first section
of
> the ARF report could be correlated to a spam trap address).
> 

The report doesn't reveal whether that address is a spamtrap, an end
user, a role account, or even whether or not that address would ever
accept any non-spam message.  Or, to stay related to this proposal, it
doesn't reveal whether or not that address would ever accept a message
which passed DKIM verification.

(Some ARF report generators have chosen to redact the recipient address.
This is technically a violation of the spec, but they do it anyway and
it's pretty clear that nobody's going to talk their lawyers out of it.)

--
J.D. Falk
Receiver Products
Return Path

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 7 Mar 2008 13:06:10 -0500

>I'd like to go with the current modest version and come back 
>after we've found out what's useful and what isn't.
>
>The reporting address sounds like a fine idea, but as we've 
>already seen there's all sorts of questions that would benefit 
>from experience, like how much you redact, and to what extent 
>asking for reports would be an invitation to be mailbombed.
>
>R's,
>John

I agree with John about getting more real world experience and noit
holding up the current version. 

I also believe reporting/feedback is critical to getting adoption of SSP
(and DKIM) moving forward. Even reporting in the aggregate (pass/fail)
is extremely useful. At ISOI4 I presented some very preliminary numbers
on DKIM fails that were based on feedback by a handful of receivers.
There was a very strong response from people and lots of interest.

Basically, senders that will take advantage of SSP with stronger
assertions have no way of knowing upfront what sort of breakage from
forwarding they might encounter.

Hopefully we will see some receivers providing feedback as part of their
whitelisting programs and/or feedback services like Return Path is
planning.

Just a few thoughts.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Mar 2008 11:39:14 +0000

> of when we're free to recharter (or not)?

Barry and I chatted briefly with Tim on this recently. We were all
of the opinion that any re-chartering (other than milestone changes)
should follow A/SSP being done.

Once we get through WGLC on that, I guess we can chat again with
Tim about what exactly "done" might mean (assuming there is in fact
a demand to add stuff to the charter at that point).

Stephen.