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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Nov 2007 16:38:48 -0800 (PST)

This time with feeling!  (and the attachment)

---------- Forwarded message ----------
Date: Thu, 8 Nov 2007 16:13:41 -0800 (PST)
From: Murray S. Kucherawy <[email-masked]>
To: [email-masked]
Subject: Proposal to amend SSP draft with a reporting address

At MAAWG someone pointed out that a sender might be interested in knowing when 
his/her domain is being abused, i.e. if something appears to be Suspicious.

In line with this and having talked to Jim about it, attached is some proposed 
amended text versus the ssp-01 draft which adds an optional reporting address 
to be used when the SSP algorithm results in something being labeled 
Suspicious.

I intend to come up with a subsequent draft that has two purposes:

a) add something similar to DKIM key records;

b) define a format for such reports (i.e. ARF or something similar)

Comments welcome.

--
Murray S. Kucherawy ========================================= [email-masked]
Principal Engineer           Sendmail, Inc.                Emeryville, CA, USA
(510) 594-5400                                         http://www.sendmail.com

Index: draft-ietf-dkim-ssp-01.txt
===================================================================
RCS file: /cvs/DKIMFilter/draft-ietf-dkim-ssp-01.txt,v
retrieving revision 1.1
diff -u -r1.1 draft-ietf-dkim-ssp-01.txt
--- draft-ietf-dkim-ssp-01.txt	20 Sep 2007 21:36:04 -0000	1.1
+++ draft-ietf-dkim-ssp-01.txt	8 Nov 2007 23:26:12 -0000
@@ -631,6 +631,20 @@
 
       Unrecognized flags MUST be ignored.
 
+   report=  A reporting address (OPTIONAL; no default).  When a Verifier
+      determines that a message is Suspicious according to the procedure
+      described in Section 4.4, the Verifier MAY generate a message to this
+      reporting address containing a report about the candidate message and
+      indicating what part of the evaluation failed.  The format of this
+      report is not defined in this specification but is expected in a
+      subsequent one.
+
+      ABNF:
+
+        report-address = local-part "@" domain-name
+
+      "local-part" and "domain-name" are as defined in RFC2822.
+
 4.4.  Sender Signing Practices Check Procedure
 
    Verifiers MUST produce a result that is semantically equivalent to
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Nov 2007 16:55:36 -0800

Murray,

I'd be really concerned about drinking from this particular firehose, and
most especially the law of unintended consequences.

Maybe rather than proposing a change, it might be more productive to
talk through what the problem actually is? I'm not convinced that random
reports from potentially untrustworthy outsiders is what's wanted here.

       Mike

Murray S. Kucherawy wrote:
> At MAAWG someone pointed out that a sender might be interested in 
> knowing when his/her domain is being abused, i.e. if something appears 
> to be Suspicious.
>
> In line with this and having talked to Jim about it, attached is some 
> proposed amended text versus the ssp-01 draft which adds an optional 
> reporting address to be used when the SSP algorithm results in 
> something being labeled Suspicious.
>
> ------------------------------------------------------------------------
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Nov 2007 17:02:05 -0800 (PST)

> reports from potentially untrustworthy outsiders is what's wanted here.

I'm not sure I should defend someone else's position directly.  I just 
said I'd provide language as a starting point given the suggestion I 
received at MAAWG and thus initiate this discussion.

That said, originally I had some motivation during the initial 
interoperability testing of DKIM over a year ago; specifically, it was 
nice to have someplace to send diagnostic reports (canonicalizations, 
etc.) when verifications failed.  I still find that practise useful, and 
that's the motivation for adding something like "report=" (probably just 
"r=") to key records as well.

That's till my own motivation, but there are now others such as the one 
described in my previous message.  Those people (hopefully they're 
subscribed here) should provide their own support for the proposal.

Moreover, I would think an SSP publisher who elects to use the "report=" 
option does so knowing the risks involved.  Perhaps we have to enumerate 
some of those risks in this specification, but that doesn't make it an 
entirely bad idea.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eric Allman <[email-masked]>
Date: Thu, 08 Nov 2007 17:19:14 -0800

--On November 8, 2007 4:55:36 PM -0800 Michael Thomas <[email-masked]> 
wrote:

> Maybe rather than proposing a change, it might be more productive
> to talk through what the problem actually is? I'm not convinced
> that random reports from potentially untrustworthy outsiders is
> what's wanted here.

The MAAWG people who want this are hardly "untrustworthy outsiders" 
--- they are the people who have to deal with this on a daily basis. 
ISPs and large senders are already doing this by bi-lateral 
arrangements.  This is no more than an attempt to codify what is 
happening already and which is going to expand.  We can sit around 
arguing about whether this is the theoretically "right" thing to do 
and have the world pass us by, or we can try to do something useful. 
Personally, I'm going for useful.

eric

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Nov 2007 17:25:37 -0800

> --- they are the people who have to deal with this on a daily basis. 

I'm talking about whoever it would be that generated the report. A field in
SSP is invitation for any and all to send that (undefined) abuse report for
whatever motivates them, good or ill.

       Mike

---

From: Hector Santos <[email-masked]>
Date: Fri, 09 Nov 2007 09:30:41 -0500

Eric Allman wrote:
> The MAAWG people who want this are hardly "untrustworthy outsiders" --- 
> they are the people who have to deal with this on a daily basis. ISPs 
> and large senders are already doing this by bi-lateral arrangements.  
> This is no more than an attempt to codify what is happening already and 
> which is going to expand.  We can sit around arguing about whether this 
> is the theoretically "right" thing to do and have the world pass us by, 
> or we can try to do something useful. Personally, I'm going for useful.

+1

Eric, do you have any info, technical material on how the existing 
pre-arrange reporting is being done?   Proprietary, open standard?

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Eric Allman <[email-masked]>
Date: Fri, 09 Nov 2007 07:05:14 -0800

> pre-arrange reporting is being done?   Proprietary, open standard

Unfortunately nothing official that I can share --- all the MAAWG 
information is explicitly non-disclosure.  However, it's not hard to 
find information about ARF (Abuse Reporting Format).

I gather that AOL has something where you (a sender) can sign up to 
receive an ARF feed of stuff you are sending that is generating spam 
reports.  It's probably a good guess that this or something close to 
it is what the big guys are using to share information between 
themselves.  (Honestly, I don't know for sure if this is what they do 
use, but I assume so.)

eric

---

From: Steve Atkins <[email-masked]>
Date: Fri, 9 Nov 2007 07:13:10 -0800

On Nov 9, 2007, at 7:05 AM, Eric Allman wrote:

> receive an ARF feed of stuff you are sending that is generating  
> spam reports.  It's probably a good guess that this or something  
> close to it is what the big guys are using to share information  
> between themselves.  (Honestly, I don't know for sure if this is  
> what they do use, but I assume so.)

That's a user-driven feedback loop ("scomp" in AOLs case). No  
connection with email authentication at all.

The current state of the art for DKIM interop testing in the wild,  
for senders at least, seems to be sign with dkim and send to test  
mailboxes at several large ISPs, then look at how those ISPs perceive  
the mail.

Cheers,
   Steve

---

From: SM <[email-masked]>
Date: Fri, 09 Nov 2007 07:22:30 -0800

At 07:05 09-11-2007, Eric Allman wrote:
>  explicitly non-disclosure.  However, it's not hard to find 
> information about ARF (Abuse Reporting Format).

http://www.ietf.org/internet-drafts/draft-shafranovich-feedback-report-03.txt

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 10 Nov 2007 05:23:01 -0000

>themselves.  (Honestly, I don't know for sure if this is what they do 

AOL, Hotmail, and Earthlink all have feedback loops that return mail
reported as spam in ARF format.  Works great.  (Nothing secret about
this, by the way.)

Largely as an experiment, I've been sending all my spam reports in ARF
for the past year or so.  Other than the occasional ISP who still is
afraid to open attachments, they've been accepted very well, even
without any prearrangement with the recipients.

If you're going to send back reports about messages, via SSP or
otherwise, it'd be nuts to use any format other than ARF.  You might
want to add another couple of items to the report info, but ARF is
designed to be easily extensible.

R's,
John

---

From: "O'Reirdan, Michael" <[email-masked]>
Date: Sat, 10 Nov 2007 13:38:44 -0500

I agree. It would be a massive hassle for us to have to do something else.
 
Mike O'Reirdan

________________________________

From: [email-masked] on behalf of John Levine
Sent: Sat 11/10/2007 12:23 AM
To: [email-masked]
Subject: Re: [ietf-dkim] Proposal to amend SSP draft with a reporting address(fwd)

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Nov 2007 14:30:33 -0800

John Levine wrote:
> otherwise, 

Just realized I did not understand one tidbit in your note:

    What does it mean to send back a report "via" SSP?

d/

-- 

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

---

From: "John L" <[email-masked]>
Date: 10 Nov 2007 18:17:01 -0500

>   What does it mean to send back a report "via" SSP?

Whatever this reporting address add-on is supposed to be.

R's,
John

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 13 Nov 2007 06:47:39 -0800

There are a lot of threads here, rather than reply to individual emails I will attempt to be comprehensive

1: Should we do this?

As always there is the 'half a loaf' view that argues for delivering what we said we will deliver rather than solve the problem we are trying to solve. When reporting and other essential components necessary to make DKIM effective were left out of the initial specification it was argued that this was in order to focus on the core. Now core is done it is time to return to unfinished business.

Likewise arguments to the effect that the 'law of unexpected consequences' is relevant must be ignored. We have nothing to fear but fear itself. If we allow unexpected consequences to exercise a veto we will never do anything and more importantly never learn anything. We can fail in two ways, we can fail by making a mistake or we can fail by refusing to make any mistakes and thus make the biggest mistake of all - inaction. Simply do what other groups have done and sit on a problem and solution area for a decade or so, neither solving the problem nor allowing others to work on it.

That type of behavior is allowed in archeology. The group who sat on the dead sea scrolls for four decades became particularly notorious. It is not acceptable in Internet security. Either we act or we let someone else do so.

2. What reporting format?

We should not pick any reporting format, that is not ourt job. Rather we should look to create a system that enables the use of any reporting format that might do the job.

At this point there are essentialy two syntactical approaches that are viable, RFC 822 and XML. RFC 822 is clearly simpler but comes to a sticky end when attempting to exchange structured data. XML has a somewhat higher overhead but not as great as some claim.

We really should not pick a reporting format. What is optimal to solve email in isolation is not going to be useful as a general purpose abuse reporting format. AOL and co may be saying that they only want ARF today, lets see what they want in five years time or so when they have six different reporting infrastructures optimized for different types of abuse. Or more specifically, the AOL person who is only responsible for email may ask for an optimized scheme but its a mistake to imagine thats a corporate position or even a permanent one. 

3. Reporting Service Discovery

So we need a mechanism that allows us to plug in multiple reporting options. How do we achieve discovery?

One option is to use SSP to achieve discovery:

_dkim_policy.example.com   TXT  "ssp/1.0 DKIM=always ARF=arf-abuse.example.com"

I don't l;ike this because it means we are stuck with a single service point or end up specifying fallover configuration in the policy record. A better option is to use SRV:

_dkim_policy.example.com   TXT  "ssp/1.0 DKIM=always REPORT=(ARF,INCH)"

Next Steps

I can revise my NOMAIL extension draft to include service discovery reporting extensions.

---

From: Damon <[email-masked]>
Date: Tue, 13 Nov 2007 22:44:00 -0500

+1

 I believe that I was the one that asked for the feedback loop a long time ago.
I like the ARF format.
Not really concerned about it being abused. I have far worse in the
postmaster box just as it is. It is just another tool to help.

Regards,
Damon Sauer

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 14 Nov 2007 07:23:45 -0800

I am happy to say that DKIM MUST support the use of ARF as A reporting format 

I disagree that it should be the only reporting format supported. What we want today and what we will want in five years time are going to be different. ARF is a decent start but its limited. To go much further it is going to be necessary to use structured data.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Damon
> Sent: Tuesday, November 13, 2007 10:44 PM
> To: O'Reirdan, Michael
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Proposal to amend SSP draft with a 
> reportingaddress(fwd)
> 
> +1
> 
> Not really concerned about it being abused. I have far worse 
> in the postmaster box just as it is. It is just another tool to help.
> 
> Regards,
> Damon Sauer
> 
> > Subject: Re: [ietf-dkim] Proposal to amend SSP draft with a 
> reporting 
> > address(fwd)
> >
> >
> >

---

From: Eliot Lear <[email-masked]>
Date: Wed, 14 Nov 2007 16:37:39 +0100

> I disagree that it should be the only reporting format supported. What we want today and what we will want in five years time are going to be different. ARF is a decent start but its limited. To go…

Ok, but let's proceed cautiously here, Phillip.  This is an area where
more standards != better.  How would you propose we manage interoperability?

Eliot

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 14 Nov 2007 7:45:48 -0800

>I am happy to say that DKIM MUST support the use of ARF as A reporting 
format 
Is this format standardized or does it at least have a stable specification 
somewhere?

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Nov 2007 16:03:00 +0000

> Is this format standardized or does it at least have a stable specification 

I think someone posted a link a few messages back.

My question on this is whether it'd really be needed now, as a part
of SSP, or whether it'd be ok to have it as an extension, defined
separately (I'm thinking of the milestones in our charter).

If the latter, then a personal I-D would be the place to start
and the WG can consider that when we see it.

If the former, then I think we need to start by justifying why
the feature is needed but not mentioned in RFC 5016.

Stephen.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 14 Nov 2007 11:28:25 -0800

I propose that there are the following requirements:
 
1) Mechanism for announcing that a service is available to accept reports of DKIM verification failures
2) Mechanism for specifying which reporting protocols are supported
3) Mechanism for discovery of the reporting service of a given protocol
4) Specification of the reporting protocol
 
I regard 4 as being out of scope for DKIM, we should not develop a protocol.
 
I regard 3 as being solved by DNS SRV, its what it is for
 
So that leaves 1 and 2. I consider these to be a DKIM responsibility, in particular an SSP responsibility.

In an ideal world there would be an ideal reporting protocol. I don't think that we are an ideal world and so I beleive that DKIM must support some means of reporting protocol agility just like we would regard protocol versioning a good thing. 
 
The difference is not at all complicated, it means writing REPORT=ARF or REPORT=ARF|INCH 

There is a philosophical design issue here, clearly it is a bad thing for DKIM to provide more options than is necessary to address DKIM functions. But it is also a bad thing for DKIM to force the use of a particular support infrastructure. This is why we made sure that we can in fact use DKIM with XKMS or with X.509 pki even though we have a key record mechanism.
 
I don't want to get into the design of the reporting protocol here. I am not even sure that ARF is what a standard would look like, we already have INCH after all. If we decide to design DKIM to only use ARF we create a dependency and have to ensure that ARF is at equivalent standards level. Weak coupling is what we need, provide a slot to allow interaction with ARF but don't force a choice.

From: Eliot Lear [mailto:[email-masked]]
Sent: Wed 14/11/2007 10:37 AM
To: Hallam-Baker, Phillip
Cc: Damon; O'Reirdan, Michael; [email-masked]
Subject: Re: [ietf-dkim] Proposal to amend SSP draft with a reportingaddress(fwd)

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Nov 2007 11:53:31 -0800

Well, this pretty much confirms my suspicions of the law of unintended
consequences, even if this a layer 8 example rather than a layer <= 7
example.

       Mike, seeming simple proposals masking a huge undefined problem

Hallam-Baker, Phillip wrote:
> In an ideal world there would be an ideal reporting protocol. I don't 
> think that we are an ideal world and so I beleive that DKIM must 
> support some means of reporting protocol agility just like we would 
> regard protocol versioning a good thing.
>  
> There is a philosophical design issue here, clearly it is a bad thing 
> for DKIM to provide more options than is necessary to address DKIM 
> functions. But it is also a bad thing for DKIM to force the use of a 
> particular support infrastructure. This is why we made sure that we 
> can in fact use DKIM with XKMS or with X.509 pki even though we have a 
> key record mechanism.
>  
> I don't want to get into the design of the reporting protocol here. I 
> am not even sure that ARF is what a standard would look like, we 
> already have INCH after all. If we decide to design DKIM to only use 
> ARF we create a dependency and have to ensure that ARF is at 
> equivalent standards level. Weak coupling is what we need, provide a 
> slot to allow interaction with ARF but don't force a choice.
>  
>
> *From:* Eliot Lear [mailto:[email-masked]]
> *Sent:* Wed 14/11/2007 10:37 AM
> *To:* Hallam-Baker, Phillip
> *Cc:* Damon; O'Reirdan, Michael; [email-masked]
> *Subject:* Re: [ietf-dkim] Proposal to amend SSP draft with a 
> reportingaddress(fwd)
>
> > I disagree that it should be the only reporting format supported. 
> What we want today and what we will want in five years time are going 
> to be different. ARF is a decent start but its limited. To go much 
> further it is going to be necessary to use structured data.
> >  
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 14 Nov 2007 13:40:50 -0800

I have no idea what the law of intended consequences might be or what conclusions you might believe we should draw from it.
 
I dislike argument by aphorism. If something is worth saying it is worth saying clearly.

From: Michael Thomas [mailto:[email-masked]]
Sent: Wed 14/11/2007 2:53 PM
To: Hallam-Baker, Phillip
Cc: Eliot Lear; O'Reirdan, Michael; [email-masked]
Subject: Re: [ietf-dkim] Proposal to amend SSP draft with a reportingaddress(fwd)

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Nov 2007 13:44:23 -0800

Hallam-Baker, Phillip wrote:
> I have no idea what the law of intended consequences might be or what 
> conclusions you might believe we should draw from it.
>  

Ok. This is spinning rapidly out of control and far, far away from what
we agreed were the requirements for the protocol.

       Mike
> *From:* Michael Thomas [mailto:[email-masked]]
> *Sent:* Wed 14/11/2007 2:53 PM
> *Cc:* Eliot Lear; O'Reirdan, Michael; [email-masked]

---

From: Jim Fenton <[email-masked]>
Date: Wed, 14 Nov 2007 15:44:38 -0800

Stephen Farrell wrote:
>>> I am happy to say that DKIM MUST support the use of ARF as A reporting 
>> format Is this format standardized or does it at least have a stable
>> specification somewhere?
>

which was
> and the WG can consider that when we see it.

I'm probably responsible for opening Pandora's box on this.  In a
private conversation, I suggested to Murray that while an extension I-D
would be necessary to describe the addition of a reporting address to
DKIM key records, we might still have time to get this in SSP if there
was rough consensus to do so.  The discussion has certainly raised
enough issues so that consensus is far from clear.
> the feature is needed but not mentioned in RFC 5016.

The short answer, for those who are in favor of adding it, is probably
"Sorry, we didn't think of it then".

Does a requirements document like 5016 describe ALL the requirements, or
a necessary subset?

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Nov 2007 00:12:37 +0000

Jim Fenton wrote:
> Stephen Farrell wrote:
> I'm probably responsible for opening Pandora's box on this.  

Well, you've done enough work on this to not get too beaten
up for that:-)

 > In a

Neither; its the "rough consensus" set (which may or may not be a
subset if there is in fact a larger set on which we might agree,
but that's an unknown).

It is ok to add stuff, but the barrier post-5016 is a lot higher
IMO,

Cheers,
S.