I'm told that adding something like this to 4871bis would require that it go around again at Proposed Standard, rather than progress to Draft Standard.
It might be possible as a separate extension to DKIM, however. I have an expired draft along these lines, draft-fenton-dkim-reputation-hint-00. But it didn't include the specific stream names. -Jim On 4/1/11 2:04 PM, Franck Martin wrote: > 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.e.sonnev...@sonnection.nl> > To: "Franck Martin"<fra...@genius.com> > Cc: "Jim Fenton"<fen...@cisco.com>, "IETF DKIM WG"<ietf-dkim@mipassoc.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
