ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Next steps for draft-ietf-dkim-ssp

2008-12-30 12:14:18
(The main implication being that just signing all your outgoing email
may not allow you to advertise "dkim=all", if you e.g. use the "i="
tag to identify a mailing list manager -- the only example of its use
given in RFC 4871.)

Ah, good point.  That's straightforward to fix.

I suppose the alternative, now that we have some experience with i= in 
real life, is to adjust the language in ADSP to match the experience. 
Dunno how the other authors feel about that.

2) Protecting subdomains
Something like this, perhaps? (added after 2nd para in Section 3.1)

  Note: If an organization wants to publish Author Domain Signing
  Practices for all its subdomains, too, it needs to create ADSP
  records for every _adsp._domainkey_.<subdomain>.domain.example.
  Note that wildcards cannot be used (see Section 6.3); however,
  creating the ADSP records could be automated with suitable DNS
  management tools.

OK.

4) Minor clarifications/nits

I think clearly explaining when an organization that signs all
its outgoing email can actually publish a "dkim=all" policy is pretty
important --  although ADSP doesn't (and shouldn't) do everything,
we need to be clear about what it does.

It's when the signature matches the From: address.  Shouldn't be too hard 
to say it again.

Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet 
for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html