Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
SM wrote: Hi Dave, At 15:49 26-03-2009, Dave CROCKER wrote: The best I can find is two kinds of distinction. The term hostname refers to a constraint on use of the full Domain Name namespace. The term registered appears to be the way of distinguishing names that appear in the operational service, ie, the public database. The problem with this document is that it is not a specification about DNS and the reader may not restrict his/her interpretation to that only. Who is the document addressed to? I must be the only one here that is having trouble with the new lingo in communications. Imagine when its all said and done, someone getting into this may need to take out a dictionary and print out a legend of new acronyms and stick it on his monitor, learn how to pronounced the syllables of the new acronyms and to thinking 2-3 times to understand what they mean and reflect in email. Its all nuts. But I am the only person here that feels that way, so proceed. -- Sincerely Hector Santos http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
well, now I'm completely confused. to my eyes, your example fits exactly what 'registered' and 'resolvable' mean, but I guess you have something else in mind. Steve is quite right. Since the DKIM key records are at different names from the related MX or A record, the existence of one doesn't require or imply the existence of the other. I don't want to hold up this errata/update/whatever any more than it already is, so I'd suggest taking out any wording about the DNS status of the SDID. One of us should send in a separate technical erratum saying that DKIM key records SHOULD be published only for SDID domains that have corresponding MX or A records and can receive mail. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Hi Hector, At 23:22 26-03-2009, Hector Santos wrote: Who is the document addressed to? I must be the only one here that is having trouble with the new lingo in communications. The document is addressed to DKIM implementors. The document can also be used as a base for extensions built upon DKIM. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Sorry for top-posting, but couldn't we sidestep all of the analysis by simply
saying that the *syntax* (rather than the *semantics*) matches that of domain
names?
Ellen
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Dave CROCKER
Sent: Thursday, March 26, 2009 6:50 PM
To: Jim Fenton
Cc: DKIM IETF WG
Subject: [ietf-dkim] (registered) domain name (Re: errata revision:
opaque)
Jim Fenton wrote:
Just for completeness, I'll point out that some might feel that the
(indirect) statement that the domain name portion of the AUID has domain
name semantics is too strong. The subdomain portion (the portion, if
any, that is a subdomain of the SDID) doesn't need to be an actual
domain at all.
I'm not sure it's necessary to clutter the definition with this detail,
however. I'm happy with it the way it is.
Well, I think we should make sure that clarification text doesn't wind up
diverging from the precise semantics of what it is trying to clarify, lest
we
create ambiguity.
So while this might be a pain, I think it's good you caught this issue and
raised it.
I don't claim to know the nuances of this issue well enough. For
starters, I
did some searching around, which might or might not have improved my
understanding...
The best I can find is two kinds of distinction. The term hostname
refers to
a constraint on use of the full Domain Name namespace. The term
registered
appears to be the way of distinguishing names that appear in the
operational
service, ie, the public database.
That is, the former refers to names and the latter refers to a query
mechanism.
When we say actual, I think it translates into what the documents I'm
seeing
are calling registered.
RFC4871's i= text says:
The domain part of the address MUST be the same as or a subdomain
of the
value of the d= tag
which does not imply registration or non-registration. Either appears to
be legal.
I think this does motivate two improvements to the draft language, one for
SDID
and one for AUID:
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
...
New:
A single domain name that is the mandatory payload output of
DKIM and that refers to the identity claiming responsibility for
introduction of a message into the mail stream. For DKIM
processing, the name has only basic domain name semantics; any
possible owner-specific semantics is outside the scope of DKIM.
A single domain name - A single, registered domain name
7. RFC4871 Section 2.10 Agent or User Identifier (AUID)
...
New:
A single domain name that identifies the agent or user on behalf
of whom the SDID has taken responsibility. For DKIM
processing, the name has only basic domain name semantics; any
possible owner-specific semantics is outside the scope of DKIM.
A single domain name - A single, syntactically valid domain name
{{ no, I'm not in love that that wording choice. /d }}
How much indigestion does this cause?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
SM wrote: Hi Hector, At 23:22 26-03-2009, Hector Santos wrote: Who is the document addressed to? I must be the only one here that is having trouble with the new lingo in communications. The document is addressed to DKIM implementors. The document can also be used as a base for extensions built upon DKIM. Well, before you can have DKIM implementators, they probably have something to first with electronic mail, and at some point it all has to revert back to layman terms (as we know it today) for customers to enjoy. The question I ask to myself is this: Can someone successful implement DKIM using RFC 4871 without having to resort to this errata? Or does errata significant enough in fixing the original functional specifications that makes it mandatory to have? -- Sincerely Hector Santos http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
before we get too semantically bogged down, a domain name implys dns registration otherwise it is a label of convenience Bill Oxley Messaging Engineer Cox Communications, Inc 404-847-6397 -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Thursday, March 26, 2009 9:21 PM To: DKIM IETF WG Subject: Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque) On Mar 26, 2009, at 6:10 PM, Dave CROCKER wrote: Steve Atkins wrote: On Mar 26, 2009, at 3:49 PM, Dave CROCKER wrote: 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) ... New: A single domain name that is the mandatory payload output of DKIM and that refers to the identity claiming responsibility for introduction of a message into the mail stream. For DKIM processing, the name has only basic domain name semantics; any possible owner-specific semantics is outside the scope of DKIM. A single domain name - A single, registered domain name Registered with who? If the SDID is, say, hatstand.beartrap.blighty.com? Registered with the DNS, the global distributed hierarchical service. From the other uses of this language I'm seeing on the net, this isn't said explicitly. Do you really feel that the meaning is not clear? Registered means that the string is registered with a registry. That's not something I'd want the language to even hint at, let alone actually say. It's going to lead to confusion when explaining this to people, as you'll need to directly contradict the wording in the spec when you reassure them that, no, there is no central DKIM registry. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Consensus point on ADSP
In the IETF 74 DKIM meeting, we had a brief discussion about the current state of ADSP, given the recent discussions on i= (and other things). It seems to the chairs that ADSP isn't severely affected, and that changes would be needed only in section 2.7, Author Signature, which is the only place that d= and i= are mentioned. Here's the current text (from -09), for reference: 2.7. Author Signature An author signature is a Valid Signature that has the same domain name in the DKIM signing identity as the domain name in the Author Address. If the DKIM signing identity has a Local-part, it is be identical to the Local-part in the Author Address. Following [RFC5321], Local-part comparisons are case sensitive, but domain comparisons are case insensitive. For example, if a message has a Valid Signature, with the DKIM- Signature field containing i...@domain.example, then domain.example is asserting that it takes responsibility for the message. If the message's From: field contains the address b...@domain.example, that would mean that the message does not have a valid Author Signature. Even though the message is signed by the same domain, it will not satisfy ADSP that specifies dkim=all or dkim=discardable. Note: ADSP is incompatible with valid DKIM usage in which a signer uses i= with values that are not the same as addresses in mail headers. In that case, a possible workaround could be to add a second DKIM signature a d= value that matches the Author Address, but no i=. The current proposal is to remove i= here, and rework the text so that ADSP uses d= only. We note the following: 1. If, after some implementation and operational experience, the group decides that i= does need to be there, it can be added back in as an extension. 2. Alternatively, if, after some implementation and operational experience, the group decides that the function needs to be there, it can be added as an extension, with a new tag (as with Jim's example of r=). 3. We don't have that operational experience at this point. The chairs recommend going ahead with this proposal. The chairs' recommendation aside, the decision is, as always, with the working group. Please begin discussing this, in this thread, forthwith, and desist next Friday, 3 April, at which point we'll evaluate the consensus and proceed with ADSP. strikeGo wild./strike strikeKnock yourselves out./strike Proceed with the discussion. Barry -- Barry Leiba, DKIM working group chair (barryle...@computer.org) http://internetmessagingtechnology.org/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Mar 27, 2009, at 4:37 AM, John Levine wrote: well, now I'm completely confused. to my eyes, your example fits exactly what 'registered' and 'resolvable' mean, but I guess you have something else in mind. Steve is quite right. Since the DKIM key records are at different names from the related MX or A record, the existence of one doesn't require or imply the existence of the other. I don't want to hold up this errata/update/whatever any more than it already is, so I'd suggest taking out any wording about the DNS status of the SDID. +1 One of us should send in a separate technical erratum saying that DKIM key records SHOULD be published only for SDID domains that have corresponding MX or A records and can receive mail. Any reason for that? It doesn't strike me as an obviously good idea. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Siegel, Ellen wrote: Sorry for top-posting, but couldn't we sidestep all of the analysis by simply saying that the *syntax* (rather than the *semantics*) matches that of domain names? When all is said and done, it's the combination of the selector + _domainkey + SDID that must be a valid domain name whose TXT records can be accessed using DNS. This is the *only* name out of all of these that MUST be in the DNS. Tony Hansen t...@att.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Tony Hansen wrote: Siegel, Ellen wrote: Sorry for top-posting, but couldn't we sidestep all of the analysis by simply saying that the *syntax* (rather than the *semantics*) matches that of domain names? When all is said and done, it's the combination of the selector + _domainkey + SDID that must be a valid domain name whose TXT records can be accessed using DNS. This is the *only* name out of all of these that MUST be in the DNS. Has any reader of this spec actually been confused? I sure haven't seen it, and the advent of zillions of web resources in case there were any question at all makes this seem like a rather academic debate. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Has any reader of this spec actually been confused? I sure haven't seen it, and the advent of zillions of web resources in case there were any question at all makes this seem like a rather academic debate. I agree with Mike. Let's leave the text as it is, and move on. Barry (participant) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Consensus point on ADSP
DKIM Chair wrote: 2.7. Author Signature An author signature is a Valid Signature that has the same domain name in the DKIM signing identity as the domain name in the Author Address. If the DKIM signing identity has a Local-part, it is be identical to the Local-part in the Author Address. Following [RFC5321], Local-part comparisons are case sensitive, but domain comparisons are case insensitive. For example, if a message has a Valid Signature, with the DKIM- Signature field containing i...@domain.example, then domain.example is asserting that it takes responsibility for the message. If the message's From: field contains the address b...@domain.example, that would mean that the message does not have a valid Author Signature. Even though the message is signed by the same domain, it will not satisfy ADSP that specifies dkim=all or dkim=discardable. Note: ADSP is incompatible with valid DKIM usage in which a signer uses i= with values that are not the same as addresses in mail headers. In that case, a possible workaround could be to add a second DKIM signature a d= value that matches the Author Address, but no i=. The current proposal is to remove i= here, and rework the text so that ADSP uses d= only. I guess what I didn't quite get in these discussions is use d= only for what purpose? Are we saying the change would reflect this instead: For example, if a message has a Valid Signature, with the DKIM- Signature field containing d=domain.example, then domain.example is asserting that it takes responsibility for the message. What has been confusing to me is getting the (possibly wrong) idea that the domain lookup is no longer the From: domain, but rather the d= domain. I guess what is lost to me is who is really responsible for the message. This is the right way to understand it? - The Author Domain is responsible for the content of the message. - The DKIM d= domain is responsible for signing the message. For ADSP purposes: - Authorization is determine by looking up the Author Domain record. -- Sincerely Hector Santos http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
I understand the desire to constrain the SDID to be a registered name or under one, but is there a need to make this normative? DKIM verification simply won't work if the SDID doesn't meet that criterion, and perhaps that's good enough. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] what I said about i= at the DKIM meeting
I was asked to post what I said at the DKIM meeting about opacity and the AUID (i=) value. Take it as input into your thought processes as you consider the issues around the Errata. The following is only slightly expanded over what I said on Tuesday. == Part 1 The definition of i= contains several parts to it. The semantic description is Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed The syntax description is (dkim-quoted-printable; ...) The syntax is a standard email address where the Local-part MAY be omitted. The constraints are: (OPTIONAL, default is an empty Local-part followed by an @ followed by the domain from the d= tag). The domain part of the address MUST be the same as or a subdomain of the value of the d= tag. The semantics constrain the AUID to be an identifier for the agent/user. This MAY be the email address of the agent/user of the message, or it may be some other value that also represents the identity of the agent/user but is not an email address of the agent/user. If it is the latter, it is still required by the semantics to be an identity for the user and must LOOK like an email address. But otherwise the localpart and subdomain portion of the value are totally opaque in sense to DKIM or users of DKIM. There is nothing else that tells us how we can look into it and figure out what pieces of it means. I also noted that some vendors that are signing messages today ARE using i= values with the actual email address of the authenticated user (if available), some are putting different values into i=, and others are not using i= at all. Which one is most useful is subject to debate. (For the record, I prefer using the actual email address of the authenticated user if it's available.) == Part 2 I also made comments about the different fields found in the DKIM signature. This was a reminder to folks about various aspects of those fields. Some of the fields in the DKIM signature (v=, t=, x=, z=) are supportive, ancillary information for the signature. Some of the fields (bh=, c=, h=, l=) provide information on calculating the hash to be compared with b=. Some of the fields (a=, q=) provide information on how to access the public key. The actual authentication that occurs is performed using three fields: the value of the hash (b=) is verified using the public key found using the selector and domain (s=, d=) and the hash calculated on the message. When this authentication is finished, you've verified that the d= domain signed the message. And then there's i=, the AUID. The value of i= is an assertion by the signing domain as to an identity of the agent/user. There is nothing that can be tested to cryptographically verify it. It's a simple claim; it's by definition the identity that's been purported and alleged by the signing domain. How much you believe that i= value will necessarily be related to how much you trust the verified d= value. As Doug Otis noted, if you find that identity in the From: header or Sender: header, you have a high certainty that the i= value is the email address of the agent/user instead of some other representation of the identity of the agent/user. This is a positive confirmation test that an implementation may choose to do. But all you've shown is that they are the same; how much you trust the From: value is also necessarily related to how much you trust the verified d= value. But that's the only thing you really get to say from comparing the From: value with the i= value. You cannot make the obverse statement that the From: address is necessarily representing the same user as the agent/user identified by the i= value -- the sending domain isn't required to ensure that the From: value matches the i= value and nothing we say can force it to do so. Tony Hansen t...@att.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Mar 27, 2009, at 8:04 AM, Tony Hansen wrote: Siegel, Ellen wrote: Sorry for top-posting, but couldn't we sidestep all of the analysis by simply saying that the *syntax* (rather than the *semantics*) matches that of domain names? When all is said and done, it's the combination of the selector +_domainkey + SDID that must be a valid domain name whose TXT records can be accessed using DNS. This is the *only* name out of all of these that MUST be in the DNS. A valid DKIM signature confirms the signing agent is controlled by the domain indicated in SDID. A valid signature also establishes an authority to assert UAID values that must reside at or under the domain. (A valid DKIM signature verifies the UAID assertion by the SDID.) When UAID values do not match against email-addresses within signed header fields, portions of the UAID namespace below the SDID may not represent an valid email destination. However, the UAID value always represents an SDID identifier for on whose behalf their signature was added. The SDID value could be seen as analogous to a State issuing a drivers license. A valid signature could be analogous to untampered laser- scribed laminate and seals. The License Number could be analogous to that of the UAID, where it might be replaced by a State email-address of the driver. Such replacement can be denoted by its use within signed header fields. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Consensus point on ADSP
The current proposal is to remove i= here, and rework the text so that ADSP uses d= only. We note the following: That's fine with me. I still don't see much utility in ADSP but this keeps it from damaging DKIM. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what is a standard, was errata revision: Assessor
John Levine wrote: My concern is this: what do identity assessors use today? An IP address. They might want that tidbid of information as well. How, then, not to exclude it? [ . . . ] We tell senders that's the handle to put in signatures so receivers recognize them, and we tell receivers that's the handle to check to best know who's trying to talk to you. Assessors will certainly do all sorts of other stuff as well, but this is the best advice on how to interoperate with DKIM. With specific reference to DKIM, what I most want to discourage is awful IP/domain hybrid hacks like only validating a signature if the Sender-ID or SPF passes. So our interop advice is when you're thinking about DKIM, don't think about IP addresses. Speaking as an assessor (does anyone else here do that?), and as someone who has put a lot of thought into assessing the reputation of authenticated domains...I couldn't agree more. That way madness lies. Yet even so, assessors are going to use whatever data we think is relevant, no matter what the RFCs say. The bad guys don't care about standards, so when we're assessing badness we MUST look for non-compliant behavior -- and most assessors exempt behavior which may be non-compliant, but still extremely common. When assessing goodness we still look for non-compliant behavior, for basically the same reasons -- and often warn those good guys that they've screwed up somewhere. Concern about assessors thinking we can't use data just because the DKIM spec doesn't explicitly say we can, or vice versa, is a non-issue. -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] errata revision: Identity Assessor vs. Message Filtering engine
Jim Fenton wrote: +1 with Ellen's change. +1 -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
Steve Atkins wrote: Not only does hatstand.beartrap.blighty.com not resolve, it's not registered anywhere. It exists solely as a substring of the string that's actually queried - banjo.aardvark._domainkey.hatstand.beartrap.blighty.com The only thing that can be said about the SDID in DNS terms is that the signer of the mail has the ability to add TXT records in the subtree rooted at that domain. Given that, trying to make more specific statements about what the SDID is than something vague like a domain name is likely to lead to something that's misleading or plain wrong. -1 on registered or resolvable. Sounds like the real requirement is that a DKIM verifier be able to figure out which key to use, based on that string. There must be an IETF standard way to describe that -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] what I said about i= at the DKIM meeting
Tony Hansen wrote: The semantics constrain the AUID to be an identifier for the agent/user. This MAY be the email address of the agent/user of the message, or it may be some other value that also represents the identity of the agent/user but is not an email address of the agent/user. If it is the latter, it is still required by the semantics to be an identity for the user and must LOOK like an email address. But otherwise the localpart and subdomain portion of the value are totally opaque in sense to DKIM or users of DKIM. There is nothing else that tells us how we can look into it and figure out what pieces of it means. [ . . . ] How much you believe that i= value will necessarily be related to how much you trust the verified d= value. To put it another way: '...DKIM itself includes an additional identifier, the i= value, which looks like (but isn't) an email address. The signer can set i= to whatever they want, as long as the part after the @ is the same as the d= domain. Cisco uses this to identify individual users: i=santacl...@cisco.com. More common, I'd expect, will be use of i= to denote distinct mailstreams or internal divisions: i=transactio...@example.com, i=market...@example.com, i=nyc-off...@example.com. Thing is, i= is an opaque identifier. There's simply no way for anyone outside of the signing domain to know whether market...@example.com is a mailstream, a department, a individual email address, or simply a string of randomly generated characters. DKIM does not tell you what it means, or if it'll mean the same thing in the signature of another message. DKIM does not tell you if i= is truth' http://www.returnpath.net/blog/2009/03/searching-for-truth-in-dkim-pa-3.php (which is actually part 4.) Is anyone actually disagreeing with this? If not, what are we arguing about? -- J.D. Falk Return Path Inc http://www.returnpath.net/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Consensus point on ADSP
DKIM Chair wrote: In the IETF 74 DKIM meeting, we had a brief discussion about the current state of ADSP, given the recent discussions on i= (and other things). It seems to the chairs that ADSP isn't severely affected, and that changes would be needed only in section 2.7, Author Signature, which is the only place that d= and i= are mentioned. Here's the current text (from -09), for reference: 2.7. Author Signature An author signature is a Valid Signature that has the same domain name in the DKIM signing identity as the domain name in the Author Address. If the DKIM signing identity has a Local-part, it is be identical to the Local-part in the Author Address. Following [RFC5321], Local-part comparisons are case sensitive, but domain comparisons are case insensitive. For example, if a message has a Valid Signature, with the DKIM- Signature field containing i...@domain.example, then domain.example is asserting that it takes responsibility for the message. If the message's From: field contains the address b...@domain.example, that would mean that the message does not have a valid Author Signature. Even though the message is signed by the same domain, it will not satisfy ADSP that specifies dkim=all or dkim=discardable. Note: ADSP is incompatible with valid DKIM usage in which a signer uses i= with values that are not the same as addresses in mail headers. In that case, a possible workaround could be to add a second DKIM signature a d= value that matches the Author Address, but no i=. I'll start by proposing text that we could use if we adopted an alternate definition of Author Signature based on the d= value only. Then I'll describe what I think we'll lose by going to that definition. Here's alternate text based on d=: = 2.7 Author Signature An author signature is a Valid Signature where the domain of the signing entity (d= value) is the same as the domain name in the Author Address. This comparison is case insensitive. For example, if a message has a Valid Signature with the DKIM-Signature field containing d=example.com then example.com is asserting that it takes responsibility for the message. If the message's From field contains the address b...@sub.example.com, that would mean that the message does not have a valid Author Signature because the message is not signed by the same domain. Informative Note: ADSP is incompatible with DKIM signing by parent domains described in section 3.8 of [RFC4871] in which a signer uses i= to assert that a parent domain is signing for a subdomain. = Here is what I see are the problems with this alternative: 1. As noted above, the use of d= means that signing by parent domains, specifically called out in RFC 4871, doesn't result in Author Signatures. This is arguably less of a problem because ADSP by parent domains (the ability of a domain to assert ADSP for a subdomain) was eliminated some time ago, so ADSP records would need to each for each subdomain. However, management of key (selector) records in each subdomain would still be required, while ADSP records require little or no management such as key rotation or revocation. 2. It has been noted that a domain might have different reasons for signing a message. It might, for example, sign a message on behalf of a mailing list manager operating in that domain. When Author Signature is based on a d= comparison alone, any signature from the same domain as the author is assumed to be a signature representing the original introduction of the message into the mail stream. That may or may not be an important distinction, but I'm pointing out that information is lost and I'm not sure we have enough experience to say that we don't need it. In the words of Dave Crocker, OK. Start shooting. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Consensus point on ADSP
Note: ADSP is incompatible with valid DKIM usage in which a signer uses i= with values that are not the same as addresses in mail headers. In that case, a possible workaround could be to add a second DKIM signature a d= value that matches the Author Address, but no i=. I'll start by proposing text that we could use if we adopted an alternate definition of Author Signature based on the d= value only. Then I'll describe what I think we'll lose by going to that definition. Given that i= is an arbitrary value assigned by the signer, the question to me is what value does it add beyond what signed RFC2822 headers can do just as well. Eg, why not set an rfc2822.Sender Field and sign that rather than invent i=? IOW, what is the value-add in inventing yet another identity called DKIM.i= when we already have rfc2822.From, rfc2822.sender, rfc2822.resent-from, rfc2822.resent-sender and rfc2821.mailfrom? Are you suggesting that DKIM.i= should have preference over signed RFC2822 identifiers? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
