[Top] [All Lists]

Re: [ietf-dkim] Weird i= in client mail

2013-06-21 13:02:24
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.


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 

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.

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='.

Douglas Otis

NOTE WELL: This list operates according to

NOTE WELL: This list operates according to

<Prev in Thread] Current Thread [Next in Thread>