[ietf-dkim] Proposal to amend SSP draft with a reportingaddress(fwd)

[Michael Thomas]

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.
>  
> I dislike argument by aphorism. If something is worth saying it is 
> worth saying clearly.

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:mike at mtcc.com]
> *Sent:* Wed 14/11/2007 2:53 PM
> *To:* Hallam-Baker, Phillip
> *Cc:* Eliot Lear; O'Reirdan, Michael; ietf-dkim at mipassoc.org
> *Subject:* Re: [ietf-dkim] Proposal to amend SSP draft with a 
> reportingaddress(fwd)
>
> 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:
> > 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:lear at cisco.com]
> > *Sent:* Wed 14/11/2007 10:37 AM
> > *To:* Hallam-Baker, Phillip
> > *Cc:* Damon; O'Reirdan, Michael; ietf-dkim at mipassoc.org
> > *Subject:* Re: [ietf-dkim] Proposal to amend SSP draft with a
> > reportingaddress(fwd)
> >
> > Hallam-Baker, Phillip wrote:
> > > 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.
> > > 
> >
> > Ok, but let's proceed cautiously here, Phillip.  This is an area where
> > more standards != better.  How would you propose we manage
> > interoperability?
> >
> > Eliot
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > NOTE WELL: This list operates according to
> > http://mipassoc.org/dkim/ietf-list-rules.html
> >  
>