On 4/4/11 10: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.
Correct.
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.
Please let's make a clear distinction between DKIM as the protocol and
DKIM as it can be used to provide this or that functionality. Of course
it's not always easy to draw a line between the two, but let's try it,
in order to get the discussion right:
1. RFC4871bis defines the core DKIM spec. That's what the protocol
is, providing various options, tags, possible tag values,
canonicalizations, hash options, selector options, signing
options, selector choices, etc.
2. Second, we can build upon that DKIM foundation to provide use
profiles. These use profiles need to be described within their own
RFC's which can have status informational, experimental etc. Each
of the RFCs will reference 4871bis and from that starting point,
define a set of restrictions to model the proposed functionality.
Ad 2. To give some examples of use profiles:
* of course, the first thing that comes to mind is to use DKIM as
mechanism to build reputation services on. For this use profile
not many restrictions will be required, but restrictions like MUST
NOT or SHOULD NOT use l= can be part of that spec. Such a spec
could also give some guidance re. the use of i=
* define such a thing as 'first party signing'; that use profile RFC
will restrict the d= to be the same as the domainpart of the From
address.
* idem, for 'third party signing', describing do's and dont's for
this particular use profile
* use an ADSP-like policy combined with DKIM, for example to advise
recipients to discard all mail from the d= domain. I know of one
big bank here in NL using an spf record "v=spf1 -all" to notify
the recipients they never send mail with that domain. An
equivalent of this could be designed as DKIM use profile, using a
policy like ADSP or some other yet-to-be-defined policy.
* define a use profile which defines a restriction in the key
retrieval protocol, with a 'verifier MUST use DNSSEC' to retrieve
the public key; if no DNSSEC communication path is available,
treat the message as unsigned, or treat it with a confidentiality
level 'none'.
* a use profile that describe the use of domains and subdomains to
differentiate between streams
* a use profile that describe the use of a new st= tag to
differentiate between streams
* etc. etc.
It seems to me that we're constantly mixing the possible uses of DKIM
with the core specification of DKIM. By differentiating the two, 4871bis
can be finished and DKIM can start to bear fruit.
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html