Subject: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.txt

From: [email-masked]
Date: Tue, 28 Jun 2011 06:35:07 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF.

	Title           : SPF Authentication Failure Reporting using the Abuse Report Format
	Author(s)       : Scott Kitterman
	Filename        : draft-ietf-marf-spf-reporting-00.txt
	Pages           : 16
	Date            : 2011-06-28

   This memo presents extensions to the Abuse Reporting Format (ARF),
   and Sender Policy Framework (SPF) specifications to allow for
   detailed reporting of message authentication failures in an on-demand
   fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-spf-reporting-00.txt

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Jun 2011 09:42:03 -0400

On Tuesday, June 28, 2011 09:35:07 AM [email-masked] wrote:
...
> 	Title           : SPF Authentication Failure Reporting using the Abuse
> Report Format Author(s)       : Scott Kitterman
...

This is the first draft of the split out document.  Please review and let me 
know how it can be improved.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Jun 2011 18:44:18 +0200

> know how it can be improved.

I have some comments on both I-Ds.  Actually, there should be three
I-Ds, so my comments perhaps are about the missing one.  One point is
the reference to [I-D.MARF-DKIM-REPORTING].  Shouldn't that refer to
the missing I-D, i.e. RFCxxxx "Abuse Report Format (ARF) Extensions
for Authentication Failure Reporting" instead?

I liked the idea of splitting the documents, but would now recommend
factoring some text where possible.

A second point is the idea of a "conditional" report.  That may mean,
e.g., only send me an SPF-failure report if you verified a DKIM
signature for the same domain name.  By enabling reporting, one will
likely receive an inordinate amount of spam generated notifications:
it will be useful to check mail settings of a new domain, but will
turned off after a short time.  Conditional reporting, instead, can be
kept permanently enabled.  What do you think?

Third point, an example of a complete report would be appreciated.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Jun 2011 12:52:22 -0400

On Tuesday, June 28, 2011 12:44:18 PM Alessandro Vesely wrote:
> > This is the first draft of the split out document.  Please review and let
> > me know how it can be improved.
> 

Yes.  It should.  I'm hoping that one will be done soon (I'm not the one doing 
it).  I also have a couple of downrefs to sort out.

> kept permanently enabled.  What do you think?

I'm not sure how useful that would be since that would get you reports for any 
mail that was forwarded as well.  I suspect the reverse, send a DKIM failure 
report if SPF passed for the same domain might be useful, but I suspect 
complex enough to take up as a separate topic.

> Third point, an example of a complete report would be appreciated.

I think that goes in the still missing Abuse Report Format (ARF) Extensions 
for Authentication Failure Reporting.  Once I see what's covered in that 
draft, I may have additions for this one, we'll see.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Jun 2011 16:26:52 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, June 28, 2011 9:44 AM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-spf-reporting-00.txt
> 

I'm wary of going down this road.  Although the current suite of extension drafts goes into only DKIM and SPF, it's possible (maybe likely) that other message evaluation schemes will be added here later.  A true-false table of just DKIM and SPF has a size of four; adding one more makes it eight, etc.  Eventually putting policy information able to account for all combinations into the DNS will become completely ugly.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 Jun 2011 20:46:06 -0400

"Murray S. Kucherawy" <[email-masked]> wrote:

>I'm wary of going down this road. Although the current suite of
>extension drafts goes into only DKIM and SPF, it's possible (maybe
>likely) that other message evaluation schemes will be added here later.
>A true-false table of just DKIM and SPF has a size of four; adding one
>more makes it eight, etc. Eventually putting policy information able
>to account for all combinations into the DNS will become completely
>ugly.

This is generally true, but think send a feedback report on SPF Pass without a valid DKIM signature could be useful to answer the question "Let me know about stuff coming out of my IP space that isn't DKIM signed". This is a real question I know is getting asked. It might be useful to have a standardized way to ask and answer it.

I don't support addressing this now. I don't support a general solution for all possible combinations. Perhaps after the current work is done we'll know what makes sense.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 29 Jun 2011 01:35:11 -0000

>This is generally true, but think send a feedback report on SPF Pass
>without a valid DKIM signature could be useful to answer the question
>"Let me know about stuff coming out of my IP space that isn't DKIM
>signed". This is a real question I know is getting asked. It might be
>useful to have a standardized way to ask and answer it.

But how often is it asked outside the context of setting up an FBL?
If you're already making private arrangements between the sender
and the recipient, you can handle the policy stuff out of line.

The reason to put it in the protocol is to say "Hey, world! I want you
to run this complex state machine to decide when to send me stuff that
I might or might not accept!" That doesn't seem very useful to me.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 29 Jun 2011 00:00:11 -0400

> I might or might not accept!" That doesn't seem very useful to me.

I'd say that's A reason.  The entire MARF WG is somewhat vulnerable to these 
same sentiments.  If such arrangements are a set once and forget it setup then 
perhaps.  OTOH, if these are things that are subject to change (perhaps, for 
example, reporting requirements are different during a particular system 
upgrade rollout) then there is utility is having a standardized set of knobs 
to turn so that software support adjustments without a lot of customization or 
cost.

We absolutely can save this argument for later, so we probably should.  We may 
collectively know more by then.

Scott K