On Oct 1, 2010, at 8:11 AM, Jeff Macdonald wrote: > On Fri, Oct 1, 2010 at 2:48 AM, Murray S. Kucherawy <m...@cloudmark.com> > wrote: >>> The results in Section 4.1.2 mention "Author vs. Third-Party". That >>> is more about ADSP than DKIM. >> >> True. It should probably come out. >> > > It could mean that or that most implementations default to d= From: > domain. I strongly believe that is a holdover of implementations being > based on DomainKeys code which had that constraint.
+1 Also, I've talked to several people who want to use DKIM with varying d= for the same 822.From, but can't because the signers they're using can only sign with a single domain for any given 822.From domain, or can only sign with the domain in the 822.From. I don't know how widespread this misbehaviour is in DKIM signers, but it's there. > Author vs. Third-Party: 73% of the signatures observed were author > signatures, meaning the "d=" value in the signature matched the > domain found in the From: header field. The remainder, therefore, > were third-party signatures. > > I do believe the DKIM draft warns about having d= be related to other > headers in the message. Perhaps this stat could be restated as: > > d= relations: 73% of the signatures observed had a direct > correspondence to the From: header , meaning the "d=" value in the > signature matched the > domain found in the From: header field. I might even say "was identical to" rather than "matched" - so as to make it clear that the d= value wasn't a subdomain of the 822.From domain. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
