Subject: Re: [marf] draft-ietf-marf-dkim-reporting feedback

From: "John R Levine" <[email-masked]>
Date: 2 Oct 2011 11:58:52 -0400

I presume the motivation for this is that you have a few people who want to use 
it to debug DKIM failures.  That's perfectly reasonable, but if people already 
know each other, they can use private agreements with no need to standardize 
anything.

This strikes me as a poor thing to standardize for a variety of reasons. One is 
that the number of people debugging a protocol is less by many orders of 
magnitude than the number who are just using it, and to the users, debugging 
features are just cruft.  Also, to some extent this is an invitation to 
mailbomb anyone who uses it, and as Steve noted, the people who you'd most want 
to implement this, the ones who are smashing signatures on the way in, are the 
least likely to do so.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Oct 2011 21:48:12 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R Levine
> Sent: Sunday, October 02, 2011 8:59 AM
> To: ARF mailing list
> Subject: Re: [marf] draft-ietf-marf-dkim-reporting feedback
> 

That is indeed the prime motivation.  It also has helped to have this sort of information around so that future implementations can add similar debugging features, as this expedites the exchange of exactly the kind of data that's needed to find problems.

So you're right that the target population is small, but the need to interoperate properly in that context out of the starting gate is pretty valuable.  But, admittedly, there's not much harm to getting it wrong, or indeed not doing it at all.

> features are just cruft.

Would it perhaps be better to make it Informational rather than Standards Track?  It's been in use (though with the aforementioned small audience) for several years now, so it at least seems useful to write it down.

> Also, to some extent this is an invitation to
> mailbomb anyone who uses it,

True, but that could also be argued about email addresses in SOA records, RFC2142 reporting addresses, etc.  I think that ship has sailed.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2011 00:03:57 -0000

>Would it perhaps be better to make it Informational rather than
>Standards Track?  It's been in use (though with the aforementioned
>small audience) for several years now, so it at least seems useful to
>write it down.

Sure.  That gives people a place to start in the (to me, unlikely) event
that there's enough demand for this to standardize it.

>True, but that could also be argued about email addresses in SOA
>records, RFC2142 reporting addresses, etc.  I think that ship has
>sailed.

I suppose you're right, there.

R's,
John

---

From: "Hill, Brad" <[email-masked]>
Date: Fri, 7 Oct 2011 17:10:36 -0600

PayPal would plan to implement and would like to see this on Standards Track.  "Debugging" is often an edge use case, but it isn't for financial institutions relying on email delivery for required notifications, etc.  The ability to debug and receive feedback is almost a precondition of adoption.   Standardization of reporting ensures that that it can be supported in common email products and participation can be extended beyond custom implementations based on private agreements.

Brad Hill
Senior Member of Technical Staff
PayPal
[email-masked] 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murray S. Kucherawy
> Sent: Wednesday, October 05, 2011 9:48 PM
> To: ARF mailing list
> > I presume the motivation for this is that you have a few people who
> > want to use it to debug DKIM failures.  That's perfectly reasonable,
> > but if people already know each other, they can use private agreements
> > with no need to standardize anything.
> 
> That is indeed the prime motivation.  It also has helped to have this sort of
> information around so that future implementations can add similar
> debugging features, as this expedites the exchange of exactly the kind of
> data that's needed to find problems.
> 
> So you're right that the target population is small, but the need to
> interoperate properly in that context out of the starting gate is pretty
> valuable.  But, admittedly, there's not much harm to getting it wrong, or
> indeed not doing it at all.
> 
> > This strikes me as a poor thing to standardize for a variety of
> > reasons. One is that the number of people debugging a protocol is less
> > by many orders of magnitude than the number who are just using it, and
> > to the users, debugging features are just cruft.
> 
> Would it perhaps be better to make it Informational rather than Standards
> Track?  It's been in use (though with the aforementioned small audience) for
> several years now, so it at least seems useful to write it down.
> 
> > Also, to some extent this is an invitation to mailbomb anyone who uses
> > it,
> 
> True, but that could also be argued about email addresses in SOA records,
> RFC2142 reporting addresses, etc.  I think that ship has sailed.
> 
> -MSK
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 08 Oct 2011 12:53:36 +0200

On 08/Oct/11 01:10, Hill, Brad wrote:
> PayPal would plan to implement and would like to see this on
> Standards Track.

Thanks for this declaration of intent.

> "Debugging" is often an edge use case, but it isn't for financial
> institutions relying on email delivery for required notifications,
> etc.  The ability to debug and receive feedback is almost a
> precondition of adoption.

Yes, if we mean not only debugging of code, but also of
configurations.  In addition, monitoring how users comply with
policies is quite a different case than debugging.  For example, a
domain may monitor what its users post to mailing lists like this[*].

Do we address all cases in the same way?

[*] if the following triggers an ARF:
Authentication-Results: wmail.tana.it;
  spf=pass smtp.mailfrom=ietf.org;
  dkim=pass header.i=@ietf.org;
  dkim-adsp=fail header.from=[email-masked]