ietf-dkim
[Top] [All Lists]

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

2011-04-01 16:10:40
I would suggest we deprecate i= and add st= (if not already used) that would 
let the sender specify a stream category. It would be limited to say 20 (or so) 
chars and we could specify a set of standard words (but not limited to). I'm 
thinking of things like transactional, marketing, password-reminder, 
sub-confirmation, billing, corporate, personal,...

It would be left to the receiver to use them or not of course.

I understand some of these words could be abused, but then the receiver could 
build a confidence factor in domain/stream association, etc...

With IPv6 we may loose IP reputation, this is a way to bring it back within 
DKIM.

PS: http://postmaster.facebook.com/outbound gives a good idea of streams in 
IPv4 world with DKIM equivalent, but they may be about the only ones to do that 
with DKIM.

----- Original Message -----
From: "Rolf E. Sonneveld" <R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl>
To: "Franck Martin" <franck(_at_)genius(_dot_)com>
Cc: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>, "IETF DKIM WG" 
<ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Saturday, 2 April, 2011 8:14:45 AM
Subject: Re: [ietf-dkim] Proposal:  Removal of AUID (i= tag/value)

On 4/1/11 1:31 AM, Franck Martin wrote:
I had the feeling that Y! was using the local part of i= to do 
differentiation in reputation. ie various streams within the same domain.

I know the spec intent recommends, different domains for different streams, 
but then....

Intuition would tell me, that few people are willing (or understand) to have 
different domains for different streams.

+1. And as DKIM d= information already is shown to end users by some UA 
implementations (e.g. Gmail shows 'this message was signed by <domain>, 
when clicking on details) the need/advise to use different domains for 
different streams conflicts with the threat of phishers registering 
look-alike domains.

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

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