There are a number of domains supporting ADSP, ATPS and ASL records.
There is a healthy set of world-wide usage at our ADSP Wizard [1].
The problem is I doubt anyone is "ACTING" on any strong policy rule.
That was one of the chief complaint among the policy advocates (vendors)
with the first separation, then deemphasis and WG work product
abandonment of the singular policy (SSP/ADSP proposals) layer for DKIM.
Unfortunately, until DMARC can be trusted to work with a strong handler
expectation, it will continue to have no payoff, high processing
overhead and it will be slow to be adopted with the true source of what
makes a standard - everyone from small to large using it, not just a
relatively handful of *currently* larger businesses who for the most
part are just now using something for marketing purposes. We spent tons
of man-years dollars on DKIM and POLICY. I'm going to be a little more
careful and slower, possible never, before getting into DMARC.
I personally do not care for the reporting aspects, that's not the
business I believe we need to build. The business is addressing the
protection of mail, with automated deterministic "mail policy fault"
filtering. That is what I outlined in the 2006 DSAP proposal [2] which
for the most part dealt with the idea of filtering the most obvious
faults of the transport mail at the system level and then use at an
additional operational secondary layer a reputation filter which
currently is a "Battery Required" concept - it doesn't exist
persistently nor consistently. An Author Domain Policy layer is the
only anchor we can use for a persistent and consistent mode of
expectation, design and operation.
[1] http://www.winserver.com/public/wcadsp
[2] http://tools.ietf.org/html/draft-santos-dkim-dsap-00
On 6/20/2013 7:03 PM, Douglas Otis wrote:
On Jun 20, 2013, at 11:28 AM, John Levine <johnl(_at_)taugh(_dot_)com> wrote:
It has many potential uses, but within DKIM itself, it's an expansion
socket.
Keep in mind that there are IANA registries for the tag names in both
the signatures and the key records. If you want to try something new,
just pick a tag name or two and have at it. RFCs 6541 and 6651 have
recently added signature tags.
I would think that i= would be a poor tag to use since a lot of people
already have opinions about what it means or doesn't mean.
Dear John and Jon,
Jon and John are right, in that web providers often track users using
synthetic subdomains or some type of cookie (which may offends users), and
that the 'i=' tag has already been defined and constrained by things like
ADSP. There is extensive revenue generated aggregating and trading in the
correlation of user information after all. There is also a basic reality
large providers are not likely to review logs based on timestamps to
determine which of their users caused a particular complaint. Overcoming
that reluctance was the motivation in creating either a static or transitive
opaque originator tag contained within the DKIM signature as expressed in an
I-D created back in 2005 that listed various option concepts.
http://tools.ietf.org/html/draft-otis-dkim-options-00
There are currently ongoing problems caused by compromised email accounts.
Some of the other concepts may offer ideas for various remedies when needs
arise. While the i= parameter has morphed to partially provide this role, it
also conflicts with intended uses defined by RFC5617 (ADSP). Too bad. The
idea of the signing domain offering an evolving opaque identifier designated
specifically for this purpose has merit. Perhaps it could use a newly
defined 'o=' tag. Unfortunately, this may offend those who want to feel
their emails are anonymous and yet signed using DKIM.
The best that can be hoped would be to officially deprecate ADSP as it is
being supplanted by DMARC with a lower failure rate, and then offer a BCP for
use of 'i='.
Regards,
Douglas Otis
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html