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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html