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
jon(_at_)iecc(_dot_)com to jon(_at_)corp(_dot_)ieec(_dot_)com 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:
jon(_at_)iecc(_dot_)com 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 dean(_at_)vital(_dot_)edu
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