[ietf-dkim] Proposal: Removal of AUID (i= tag/value)
fmartin at linkedin.com
Fri Apr 8 11:55:09 PDT 2011
On 4/8/11 23:38 , "Charles Lindsey" <chl at clerew.man.ac.uk> wrote:
>On Thu, 07 Apr 2011 16:44:56 +0100, Steve Atkins
><steve at wordtothewise.com>
>> 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
>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
>1. FROM = Alice at whatever i=sales.example.com d=example.com
>2. FROM = Alice at example.com i=sales at example.com d=example.com
>3. From = Alice at example.com i=bob at example.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.com to be a working email
>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
More information about the ietf-dkim