Re: Review of: draft-otis-dkim-harmful
On Jun 4, 2013, at 7:16 PM, Sam Hartman hartmans-i...@mit.edu wrote: So, I'd like to encourage Doug to refine his work, fix errors of precision, but to say I think this is worth writing down. Dear Sam, Thank you for your interest. I have updated the draft and, and as requested by Dave Crocker, included references to prior statements by Dave Crocker and Barry Leiba made public subsequent to the conclusion of the WG DKIM specification in response to comments about the phishing threat DKIM permits. In reviewing some of Dave Crocker's responses, it appears differences between validated the SDID and authenticated the SDID could use some clarification since this is awkwardly described in RFC6376 section 6.3. Quoting the abstract of RFC5863 co-authored by Dave Crocker, DKIM's authentication of email identity can assist in the global control of spam and phishing. This document provides implementation, deployment, operational, and migration considerations for DKIM. Section 5.4 Inbound Mail Filtering of RFC5863 states: ,--- DKIM is frequently employed in a mail filtering strategy to avoid performing content analysis on email originating from trusted sources. Messages that carry a valid DKIM signature from a trusted source can be whitelisted, avoiding the need to perform computation and hence energy-intensive content analysis to determine the disposition of the message. '--- This is exactly how DKIM is being used and why DKIM is harmful! Additional information is being acquired, but will not alter conclusions reached. http://tools.ietf.org/html/draft-otis-dkim-harmful-03 Regards, Douglas Otis
Re: Review of: draft-otis-dkim-harmful
On Sun, Jun 9, 2013 at 10:42 AM, Douglas Otis doug.mtv...@gmail.com wrote: Procedurally speaking, what path do you anticipate your draft following? To require messages with invalidly repeated header fields to not return a pass for DKIM signature validation. That's a technical response. What I asked was a procedural question.
Re: Review of: draft-otis-dkim-harmful
On Jun 4, 2013, at 9:13 AM, Murray S. Kucherawy m...@blackops.org wrote: On Tue, Jun 4, 2013 at 4:08 AM, Douglas Otis doug.mtv...@gmail.com wrote: In its current form, DKIM simply attaches a domain name in an unseen message fragment, not a message. The ease in which the only assured visible fragment of the message signed by the domain being forged makes it impossible for appropriate handling to be applied or likely harm prevented. There are existence proofs that contradict this claim. They have been brought to your attention in the past. Thank you for your response. Could I trouble you for a reference to the proofs or for you to expand on what you specifically mean? The draft otis-dkim-harmful addendum captured actual DKIM From header field spoofing delivered to the in-box for several major providers. It appears you're continuing to assign semantics to DKIM signatures that simply aren't there. I don't know what else can be done to clarify this. The semantics of d=domain and dkim=pass appear to be at the root of the problem.What other semantics are you suggesting? Procedurally speaking, what path do you anticipate your draft following? To require messages with invalidly repeated header fields to not return a pass for DKIM signature validation. I apologize if I missed your response to a private query. I hope to post an update shortly covering all expressed concerns. Regards, Douglas Otis
Re: Review of: draft-otis-dkim-harmful
The problems with this draft persist... Organizations such as M3AAWG hope to use DKIM will be able as a required acceptance requirement to offer better ensure a domain identity to provide offers a I happen to be sitting in a M3AAWG meeting as I write this note and it happens that I just came out of a session in which someone tried to assert the use of DKIM (or SPF) as a 'requirement' and the group was very clear that no such 'requirement' exists or is a goal. of coure, this is quite different from seeking to promote greater use of such authentication, but the word 'required', above, is wrong. This is worth noting since the premise of the I-D concerns problematic policies and practices. Certainly some individuals advocate such a requirement, but that's different from saying that a primary anti-abuse organization advocates it. There are proposals within the IETF aimed at establishing DKIM as a basis for reputation schemes in the Repute WG (i.e. section 3.2 of [I-D.ietf-repute-email-identifiers] which introduces DKIM domains being used along with SMTP client IP addresses and rfc5321.helo also identifying the SMTP client. Identifying the SMTP client encompasses both Who Initiated and To Whom message elements to support fair negative assertions. However, DKIM does not encompass this essential information. The repute drafts specify a query mechanisms; they don't establish use of the information being queried. DKIM is already used for reputation. Worse, the draft here seems to conflate address-based reputation and role-based reputation with dkim-based reputation. That's probably because any handling agent can add a dkim signature to a message, including an SMTP client. However DKIM does not specify the role of the signing agent and doesn't care. Consequently the concern apparently being raised here seems to be fundamentally confused about what DKIM is doing. Simply publishing this draft appears to have already increase the level of multiple FROM header field abuse seen where it is now at 21% of signed DKIM messages. Sounds pretty scary. No doubt the assertion is publicly verifiable, including the basis for asserting that it is causing problem? DKIM signs only fragments of an email message, so it is more proper to refer to DKIM Signed Fragments, and not DKIM Signed Messages. Normal DKIM signature validation offers a simple PASS/FAIL associating it with a specific domain. When a recipient receives a PASS status, only the last FROM header field message fragment is ensured to have been included in the DKIM signature process. This continues the draft's fundamental failure in understanding what DKIM does. DKIM does not validate the message; it uses crypto-signing methodology to affix a domain name to the message. In other words, it validates the attached domain name, not the message. As such, the choice of what message parts to include in the signing hash is more like deciding how strong the glue on the stamp should be, than deciding how to prove the message is valid. DKIM's trust related role is to better ensure message delivery to a user's in-box. Unless DKIM ensures this trust is not used to perpetrate deception, no positive assertions regarding a DKIM domain is safe. As a result, DKIM can not be used with either positive or negative reputation assertions in its current form. As logic sequences go, this paragraph is difficult reading. At least one of it's key errors is in claiming that a validation technique has a responsibility for how the validated information is used. DKIM has a responsibility for provide a validated domain name. It does that. Policies and practices for the /use/ of that domain name are outside of the scope of the DKIM signing specification. When you show your drivers license to validate your identity, it does not mean you are a good credit risk. Nor does it mean that the Department of Motor Vehicles has a responsibility to ensure that you are. The FROM header field is the Author identifier in section 11.1 of [I-D.kucherawy-dmarc-base]. The DMARC specification offers normative language that a message SHOULD be rejected when multiple FROM header fields are detected. This requirement would not be necessary or impose protocol layer violations if DKIM did not offer valid signature results when repeated header fields violate [RFC5322]. It's good to see this text refer to a layer violation, since the text is one. Discussion of DMARC is entirely outside of the scope of DKIM, unless use of DMARC uncovers some technical flaw in DKIM. It hasn't done that so far and the text in the draft doesn't offer any. At the least, the draft appears to be claiming that DKIM validates the author (rfc5322.From) field. It doesn't do that validation and it doesn't purport to. It appears the authors have some concerns about the way DMARC
Re: Review of: draft-otis-dkim-harmful
Dear Dave, On Jun 4, 2013, at 11:44 AM, Dave Crocker d...@dcrocker.net wrote: The problems with this draft persist... Organizations such as M3AAWG hope to use DKIM will be able as a required acceptance requirement to offer better ensure a domain identity to provide offers a I happen to be sitting in a M3AAWG meeting as I write this note and it happens that I just came out of a session in which someone tried to assert the use of DKIM (or SPF) as a 'requirement' and the group was very clear that no such 'requirement' exists or is a goal. of coure, this is quite different from seeking to promote greater use of such authentication, but the word 'required', above, is wrong. This is worth noting since the premise of the I-D concerns problematic policies and practices. Certainly some individuals advocate such a requirement, but that's different from saying that a primary anti-abuse organization advocates it. Hope to use, rather than advocates. We stand by the assertion, but we can further modify this statement. There are proposals within the IETF aimed at establishing DKIM as a basis for reputation schemes in the Repute WG (i.e. section 3.2 of [I-D.ietf-repute-email-identifiers] which introduces DKIM domains being used along with SMTP client IP addresses and rfc5321.helo also identifying the SMTP client. Identifying the SMTP client encompasses both Who Initiated and To Whom message elements to support fair negative assertions. However, DKIM does not encompass this essential information. The repute drafts specify a query mechanisms; they don't establish use of the information being queried. DKIM is already used for reputation. Worse, the draft here seems to conflate address-based reputation and role-based reputation with dkim-based reputation. That's probably because any handling agent can add a dkim signature to a message, including an SMTP client. However DKIM does not specify the role of the signing agent and doesn't care. Consequently the concern apparently being raised here seems to be fundamentally confused about what DKIM is doing. The combination of an assertion a message fragment is authenticated and conflation of that assertion is happening today. More on this in a bit. The authors are in no way confused. Simply publishing this draft appears to have already increase the level of multiple FROM header field abuse seen where it is now at 21% of signed DKIM messages. Sounds pretty scary. No doubt the assertion is publicly verifiable, including the basis for asserting that it is causing problem? Sure. Simply observe the increasing signed DKIM messages that have multiple From:'s. DKIM signs only fragments of an email message, so it is more proper to refer to DKIM Signed Fragments, and not DKIM Signed Messages. Normal DKIM signature validation offers a simple PASS/FAIL associating it with a specific domain. When a recipient receives a PASS status, only the last FROM header field message fragment is ensured to have been included in the DKIM signature process. This continues the draft's fundamental failure in understanding what DKIM does. DKIM does not validate the message; it uses crypto-signing methodology to affix a domain name to the message. In other words, it validates the attached domain name, not the message. As such, the choice of what message parts to include in the signing hash is more like deciding how strong the glue on the stamp should be, than deciding how to prove the message is valid. Unfortunately, affixation of the domain name to the message is the root of the issue. More on this in a bit. DKIM's trust related role is to better ensure message delivery to a user's in-box. Unless DKIM ensures this trust is not used to perpetrate deception, no positive assertions regarding a DKIM domain is safe. As a result, DKIM can not be used with either positive or negative reputation assertions in its current form. As logic sequences go, this paragraph is difficult reading. At least one of it's key errors is in claiming that a validation technique has a responsibility for how the validated information is used. DKIM has a responsibility for provide a validated domain name. It does that. Policies and practices for the /use/ of that domain name are outside of the scope of the DKIM signing specification. When you show your drivers license to validate your identity, it does not mean you are a good credit risk. Nor does it mean that the Department of Motor Vehicles has a responsibility to ensure that you are. There's quite a difference between the use of a Department of Motor Vehicles driver's license to validate your identity, and using a [insert theme park of your choice] driver's license to validate your identity. In one, significant thought has gone into the process, including several field verifiable methods
Review of: draft-otis-dkim-harmful
The draft continues to make broad, onerous claims like this, but provides no documentation to indicate that the DKIM signing specification is flawed in the function it is performing: attaching a validated domain name to a message. DKIM does not, in its current form, attach a validated domain name to a message. By adding one line MUST NOT validate a message with multiple From:'s, DKIM will attach a validated domain name to a message. Here's the part of this I don't understand: A DKIM signature does two things. It *does* attach a validated domain name (the domain in the d= tag). And it tells the verifier what parts of the message are covered by the signature (h= and l= tags). There is no claim in DKIM that the d= domain has any relation to the RFC 5322 From. But the h= tag does tell you how many From header fields are covered by te signature. Any verifier that wants to consider a message suspicious if the message contains more From fields than are covered by the signature can do so, and the DKIM spec does describe this situation. You would like the spec to REQUIRE that a message be considered suspicious under those circumstances. You made your case for this at least twice to the working group and at least once more to the IETF community during Last Call of the draft that became RFC 6376. Your opinion wasn't agreed with: you were in the rough. You're now bringing it up a fourth time (at least), and you still appear to be in the rough. The decision was to allow the verifier to decide how to handle this. Being in the rough doesn't make you wrong. But DKIM isn't wrong either, and at some point you have to accept that you're standing alone, and accept the consensus. Barry
Re: Review of: draft-otis-dkim-harmful
On 6/4/2013 1:08 PM, Douglas Otis wrote: Dear Dave, On Jun 4, 2013, at 11:44 AM, Dave Crocker d...@dcrocker.net wrote: I happen to be sitting in a M3AAWG meeting as I write this note and it happens that I just came out of a session in which someone tried to assert the use of DKIM (or SPF) as a 'requirement' and the group was very clear that no such 'requirement' exists or is a goal. ... Hope to use, rather than advocates. We stand by the assertion, but we can further modify this statement. You can invent any sort of claim you want. What you can't do is substantiate it, because it has no objective basis. I made a point of citing minutes-old group discussion that I had first-person knowledge of and that was explicitly contrary to your claim. However DKIM does not specify the role of the signing agent and doesn't care. Consequently the concern apparently being raised here seems to be fundamentally confused about what DKIM is doing. The combination of an assertion a message fragment is authenticated and conflation of that assertion is happening today. More on this in a bit. The authors are in no way confused. People mis-use specifications all the time. The issue here is what the spec says and does, not how people some stray folk somewhere choose to mis-use it. DKIM makes no 'assertion a message fragment is authenticated'. Period. Simply publishing this draft appears to have already increase the level of multiple FROM header field abuse seen where it is now at 21% of signed DKIM messages. Sounds pretty scary. No doubt the assertion is publicly verifiable, including the basis for asserting that it is causing problem? Sure. Simply observe the increasing signed DKIM messages that have multiple From:'s. The challenge I placed was on documenting the claim. The point is to permit community assessment of the claim. DKIM does not, in its current form, attach a validated domain name to a message. By adding one line MUST NOT validate a message with multiple From:'s, DKIM will attach a validated domain name to a message. One of the hallmarks of serious participation in IETF processes is respect for the outcome of a legitimate discussion that happen to go against one's preference. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Review of: draft-otis-dkim-harmful
On Jun 4, 2013, at 3:08 PM, Barry Leiba barryle...@computer.org wrote: The draft continues to make broad, onerous claims like this, but provides no documentation to indicate that the DKIM signing specification is flawed in the function it is performing: attaching a validated domain name to a message. DKIM does not, in its current form, attach a validated domain name to a message. By adding one line MUST NOT validate a message with multiple From:'s, DKIM will attach a validated domain name to a message. Dear Barry, Thank you for your response. Here's the part of this I don't understand: A DKIM signature does two things. It *does* attach a validated domain name (the domain in the d= tag). And it tells the verifier what parts of the message are covered by the signature (h= and l= tags). There is no claim in DKIM that the d= domain has any relation to the RFC 5322 From. But the h= tag does tell you how many From header fields are covered by te signature. Of course it is incorrect for a DKIM signature to be valid when a message has multiple From header fields. DKIM requires AT LEAST the From header field to be the minimal portion of the message signed. Every other part of the message is optional. DKIM was intended not to require ANY change of other mail components. None. When the DKIM signature is trusted and changes how the message is handled, it would be wrong to suggest special consideration is then given other message fragments. In addition, recipients will not see the signature header field nor should they be expected to understand what it contains. They will see and understand the From header field however. Of course dkim=pass is placed in an Authentication-Results header where many suggest this indicates the message has been authenticated! Any verifier that wants to consider a message suspicious if the message contains more From fields than are covered by the signature can do so, and the DKIM spec does describe this situation. DKIM does NOT score messages. Either the signature is valid or not. The spec wrongly justifies allowing invalid repeated headers to result in a DKIM signature verified as valid. You would like the spec to REQUIRE that a message be considered suspicious under those circumstances. No. Just indicate the signature is NOT valid. This is the only sure way to ensure trust is not misapplied and cause harm. You made your case for this at least twice to the working group and at least once more to the IETF community during Last Call of the draft that became RFC 6376. Your opinion wasn't agreed with: you were in the rough. You're now bringing it up a fourth time (at least), and you still appear to be in the rough. The decision was to allow the verifier to decide how to handle this. You and Dave Crocker made assurances this issue would not be abused. It is being abused and NO other protocol layer ensures message structures are valid. None. It was negligent for DKIM to ignore occurrences of highly deceptive invalidly repeated header fields as it walks up and down the header field stack. It is also wrong to suggest some other protocol layer handles this checking. Such suggestion represents a waste of resources as ONLY DKIM should determine signature validity which MUST consider invalidly repeated header fields. It also appears most even expect DKIM signature validation checks message structure, but this ONLY happens by double listing singleton header fields in the signed header list. MOST domains don't bother with this ugly hack, especially larger domains where checking message structure is critical. Being in the rough doesn't make you wrong. But DKIM isn't wrong either, and at some point you have to accept that you're standing alone, and accept the consensus. Putting people at risk in some race to obtain Standard status can not be justified. Getting this right is far far more important. Allowing this to become a standard will make specification modification even more difficult. Regards, Douglas Otis
Re: Review of: draft-otis-dkim-harmful
Of course it is incorrect for a DKIM signature to be valid when a message has multiple From header fields. DKIM requires AT LEAST the From header field to be the minimal portion of the message signed. Every other part of the message is optional. In retrospect, I think that requirement was a mistake, because it encourages misunderstandings such as yours. Whether or not a header field is signed has nothing whatever to do with the validity of the signature or the fact that the signature attaches the d= domain to the message. Having an (extra) unsigned From should no more invalidate the signature than having an unsigned Subject should. But the information that there's a valid signature and an unsigned whatever header field can certainly be two pieces of information that are passed to an evaluator, which decides what to do with the message. DKIM does NOT score messages. Either the signature is valid or not. The spec wrongly justifies allowing invalid repeated headers to result in a DKIM signature verified as valid. Indeed; the signature is valid. That and the list of what bits are covered by the signature are the two things that DKIM provides. An evaluator built on top of DKIM can use that information in any way it likes, including throwing away the DKIM validation if certain header fields weren't covered. That was the working group's decision, which you don't seem to accept. As I said, you're in the rough on that. You and Dave Crocker made assurances this issue would not be abused. That's not an accurate characterization. No one made any assurances; certainly I didn't, as chair. The working group understood the potential for abuse. The working group decided that the risk of abuse and damage from that abuse was less than the problems that would be cause by the proposed fixes. The text that's in the document was put there to explain the problem, and to allow implementors to address it if they want to (or think they need to). Putting people at risk in some race to obtain Standard status can not be justified. Getting this right is far far more important. Getting it right is, indeed, important, and the working group does think it got it right. The rest of that is hyperbole, as best I can tell.I see no evidence that has been presented that shows me how this puts people at risk. (And remember that DKIM provides a relatively low level of security, and is meant to be used as one piece of information that forms a *part* of an overall system.) Barry
Re: Review of: draft-otis-dkim-harmful
On 6/4/2013 4:51 PM, Douglas Otis wrote: Of course it is incorrect for a DKIM signature to be valid when a message has multiple From header fields. You lost that debate in the working group. Multiple times. Saying of course at the beginning of your claim does not make you win the argument. DKIM was intended not to require ANY change of other mail components. None. It doesn't. When the DKIM signature is trusted and changes how the message is handled, it would be wrong to suggest special consideration is then given other message fragments. So it's a good thing the DKIM spec doesn't do that. In addition, recipients will not see the signature header field nor should they be expected to understand what it contains. They will see and understand the From header field however. Quite possibly. And it's why the DKIM signing specification says: 3.8. Input Requirements A message that is not compliant with [RFC5322], [RFC2045], and [RFC2047] can be subject to attempts by intermediaries to correct or interpret such content. See Section 8 of [RFC4409] for examples of changes that are commonly made. Such corrections may invalidate DKIM signatures or have other undesirable effects, including some that involve changes to the way a message is presented to an end user. Accordingly, DKIM's design is predicated on valid input. Of course dkim=pass is placed in an Authentication-Results header where many suggest this indicates the message has been authenticated! So, you are criticizing the DKIM Signature specification for wording in a separate specification that was developed independently? You made your case for this at least twice to the working group and at least once more to the IETF community during Last Call of the draft that became RFC 6376. Your opinion wasn't agreed with: you were in the rough. You're now bringing it up a fourth time (at least), and you still appear to be in the rough. The decision was to allow the verifier to decide how to handle this. You and Dave Crocker made assurances this issue would not be abused. Please document that claim. It is being abused Please document that claim, and more importantly please substantiate the implication that it is causing a problem in the operation of Internet mail. and NO other protocol layer ensures message structures are valid. Perhaps you have heard of RFC5322 and MIME? Those are the specifications that define valid message formats. Software that implements those specs ensures message structure validity. Your issue is with software that enforces those standards -- or doesn't -- rather than a separate specification that calls on them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Review of: draft-otis-dkim-harmful
On Tue, Jun 4, 2013 at 6:48 AM, Dave Crocker d...@dcrocker.net wrote: Simply publishing this draft appears to have already increase the level of multiple FROM header field abuse seen where it is now at 21% of signed DKIM messages. Sounds pretty scary. No doubt the assertion is publicly verifiable, including the basis for asserting that it is causing problem? Sure. Simply observe the increasing signed DKIM messages that have multiple From:'s. The challenge I placed was on documenting the claim. The point is to permit community assessment of the claim. As another data point, when Doug's claim of increased appearance of multi-From messages surfaced, I instrumented my own MTAs to detect the same sort of thing to see if he's right. My data don't concur with the claim; it's still nearly zero. I will release the source code for this in an update to OpenDKIM soon, so others can collect their own data. -MSK
Re: Review of: draft-otis-dkim-harmful
On Tue, Jun 4, 2013 at 4:08 AM, Douglas Otis doug.mtv...@gmail.com wrote: In its current form, DKIM simply attaches a domain name in an unseen message fragment, not a message. The ease in which the only assured visible fragment of the message signed by the domain being forged makes it impossible for appropriate handling to be applied or likely harm prevented. There are existence proofs that contradict this claim. They have been brought to your attention in the past. It appears you're continuing to assign semantics to DKIM signatures that simply aren't there. I don't know what else can be done to clarify this. Procedurally speaking, what path do you anticipate your draft following? -MSK
Re: Review of: draft-otis-dkim-harmful
I'm jumping into this particular branch of the conversation late. I've followed Doug's concerns against DKIM somewhat over the years. It seems fairly clear that Doug has a long-standing concern regarding DKIM and how it interacts with e-mail. It seems fairly clear he's in the rough within the IETF. If Doug is asking the IETF to get consensus behind his draft, that seems like it will be a hard sell. However, I strongly support writing down Doug's argument in a draft and assuming it is sufficiently coherent publishing it somewhere. I tend to think the ISR process of the RFC editor would do a good job evaluating the question of coherency and that the independent stream of the RFC series is a great place to publish the opinion of someone who has been involved in the process for a long time and still believes we've made a mistake. Sure, lots of people in the IETF will disagree with doug; that's what makes Doug in the rough. Interestingly, reading Dave's review and criticism of Doug's draft increases my confidence that there's something in what Doug has been thinking worth writing down and publishing. I think it's fine if Dave wants to write up his own draft about why Doug is wrong. So, I'd like to encourage Doug to refine his work, fix errors of precision, but to say I think this is worth writing down. --Sam
Re: Review of: draft-otis-dkim-harmful
On May 12, 2013, at 9:59 PM, Dave Crocker d...@dcrocker.net wrote: Dear Dave, Thank you for your thoughtful review, it was most helpful. I have updated the draft in hopes of adding greater clarity and to address your concerns. The new information not available to the WG at the time is how the DKIM specification would likely be implemented despite the precautions given, and the level of growing abuse being received. http://tools.ietf.org/html/draft-otis-dkim-harmful-01 Best Regards, Douglas Otis
Review of: draft-otis-dkim-harmful
Review of: DKIM is Harmful as Specified I-D: draft-otis-dkim-harmful-00 Reviewed by: D. Crocker Review Date: 12 May 2013 Summary: DKIM is in wide use for email operations today; it is currently at Draft Standard and has been submitted for elevation to full Internet Standard. The nature and purpose of DKIM is described in the opening lines of the Abstract for its core specification (RFC 6376): DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. The current document expresses concerns about DKIM's limitations and its use, and it re-raises issues that were extensively discussed and rejected in the original DKIM working group. The document essentially criticizes DKIM's performance for message validation, rather than for its stated purpose of affixing a domain name to the message. The document also cites some exploits that are not prevented/detected by DKIM, in spite of their being entirely of the scope of the DKIM specification. The document seems to be basing its justification for this criticism on the fact there there are some unspecified people or organizations that misunderstand DKIM functions. Much of the text in this document is factually incorrect, confused and/or confusing, including architectural layer confusion; some of it is simply irrelevant to the stated purpose of the document. Given DKIM's 6+ years of extensive production experience, flaws as deep as this document claims exist should be more widely perceived by now. Detailed Comments: Abstract Currently, email lacks conventions ensuring SMTP clients can be identified by an authenticated domain. Unfortunately many hope to use DKIM as an alternative, but it is independent of intended DKIM is associated with the message object; in technical terms, it is independent of the message channel, such as SMTP client. (As a handling agent, an SMTP client might affix a DKIM signature, but the associated identifier does not carry any explicit or implicit statement of the handling role.) Hence, the opening sentence is misguided or, at least, misleading. Also, who are the 'many' and what is the evidence of the claimed confusion? DKIM has been in production deployment since 2006. If the dangers and damages threatened in this document were as real and serious as claimed, surely we'd have heard of them from others in the community. recipients and domains accountable for sending the message. This DKIM is explicitly defined to be affixed by domains declaring 'some' responsibility for the message; this may include domains that send the message. Hence, the assertion here is wrong. means DKIM is poorly suited for establishing abuse assessments for unsolicited messaging of commercial email otherwise known as SPAM, Actually, DKIM is for making trust assessments, not abuse assessments, as acknowledged a bit farther down in the text... nor was this initially DKIM's intent. DKIM lacks message context essential to ensure fair assessment and to ensure this assessment is not poisoned. I don't know what message context means here. Taken on its own, this sentence sounds portentous but it has no obvious meaning or substantiation. DKIM was instead intended to establish increased levels of trust Exactly. based upon valid DKIM signatures controlling acceptance and what a user sees within the FROM header field. But DKIM failed to guard The identifier used by DKIM is independent of the rfc5322.From field and the specification is explicit that it carries no relationship to it. Hence this sentence is wrong. against pre-pended header fields where any acceptance based on valid DKIM signatures is sure to exclude header field spoofing, especially It's true that DKIM does not protect against all possible attacks... that of the FROM. This weakness allows malefactors to exploit DKIM signature acceptance established by high-volume DKIM domains to spoof ANY other domain, even when prohibited within the Signer's network. It's true that attacks through vectors not covered by DKIM will not be prevented or detected by DKIM use... It's also true that none of these limitations have been noted as problems by the DKIM operations community. 1. Introduction Currently, IPv4 address reputation provides the primary basis for defending SMTP open services. Use of IP addresses in this role I do not understand
