ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

2011-04-08 14:29:03


On 4/8/11 23:38 , "Charles Lindsey" 
<chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk> wrote:

On Thu, 07 Apr 2011 16:44:56 +0100, Steve Atkins
<steve(_at_)wordtothewise(_dot_)com>
wrote:

On Apr 7, 2011, at 5:13 AM, Charles Lindsey wrote:



Yes, I thought of that. But my intent was that at least this tag would be

reported in any Authentication-Results header, and that header is
normally  
the first place people will look to resolve suspicions concerning
signatures. Essentially, it is for human interpretation, but good luck to

anyone who finds some way to use it automatically.

The 'i=' tag is in a similar state. For sure it is useful to have some
signed indication of who the actual author was (in situations where the
signer can be sure of that). That was what 'i=' was supposed to achieve,
but its semantics are a bit too weak for that. Nevertheless if (as seems
to be the case) it is shown in the Authentication-Results it would have
some value for humans (and even for automata when used with care).

In practice, there are three usages which seem to be common; are there
others?

1. FROM = Alice@whatever  i=sales.example.com d=example.com

2. FROM = Alice(_at_)example(_dot_)com  i=sales(_at_)example(_dot_)com 
d=example.com

3. From = Alice(_at_)example(_dot_)com  i=bob(_at_)example(_dot_)com 
d=example.com.

1. Gives some clue, and avoids a different key for the sales subdomain

2. Is fine, but don't expect sales(_at_)example(_dot_)com to be a working email
address.

3. Is a cause for suspicion, but it takes a human to realise the
distinction between "bob" and "sales".

So my inclination is to leave 'i=' there. It is currently used, and will
continue to be used even if we remove it. It is not actually broke - just

not quite fit for purpose.

This is outside the current DKIM spec, but from your example, we could
define 3 level of reputations for the domain d=example.com (I'll exclude
case 1. As I don't know yet what to do with it)

Level 1) Alice
Level 2) sales or bob
Level 3) the whole domain example.com

It is then possible to decide if we should block (or whitelist) all emails
from alice, or all emails coming from sales (or bob) stream, or all emails
signed by d=example.com



_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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