On 4/4/11 1:59 PM, Steve Atkins wrote: > On Apr 4, 2011, at 1:21 PM, Franck Martin wrote >> I think you are thinking it as only a DNS issue. >> >> But creating a sub-domain, means that the from needs to match too, therefore >> you may need to remap all your corporate email addresses from [email protected] >> to [email protected] to separate from the emails sent by your application >> at iecc.com (if you want to keep the first party signing) > There's a tautology there. > > You're saying "I'd have to do<first part signing> (if I want to do first > party signing)." > > There's no DKIM requirement to do that, and signing an email From: > [email protected] with d=corp.iecc.com (or d=foo.blighty.com) is just fine. Don't assume public keys referenced from subdomains are authoritative and equal to public keys referenced from the domain in question.
The domain name scape is becoming fairly complex with introduction of new TLD, SLD, and aliased domains written in different languages using different encoding. There is a difference from [email protected] signed by <vital.edu>, and the same message signed by <alumni.vital.edu>. The later case might call into question the validity of the From, especially from an authority standpoint. When dealing with a new name space defined in truly foreign languages, it may be hard to judge whether a second level domain represent a new "dot", "co", or essentially a domain that might be controlled by completely different entities. > If someone chooses to do solely "first party signing" (for some non-DKIM > related reason) they're sacrificing many of the advantages of using DKIM to > authenticate email, and the ability to differentiate streams of email is one > of those advantages. There is no requirement that the i= matches with the From local-part, where the i= parameter could be used to differentiate message streams as well. The benefit found using i= over the signing by subdomains is it does not _assume_ two domains are controlled by the same entity. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
