[ietf-dkim] Proposal to amend SSP draft with areporting address
pbaker at verisign.com
Tue Nov 13 06:47:39 PST 2007
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)"
I can revise my NOMAIL extension draft to include service discovery reporting extensions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ietf-dkim