Review of: draft-otis-dkim-harmful
Dave Crocker <dhc <at> dcrocker.net>
2013-05-13 04:59:17 GMT
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 what "SMTP open services" means here.
> completely breaks down when dealing with IPv6 [RFC2460]. There are
That's a prediction, not yet an observable fact.
Although the prediction is reasonable, it's not appropriate to assert it
as fact. For example there have been some analyses which suggest that
adaptation of IPv4-based mechanisms might still prove useful.
> currently 18,209,237,415,985,168 /64 equivalent IPv6 prefixes routed.
> [v6-BGP-Rpts]. In comparison, for IPv4 there are 2,614,711,792 IP
> addresses routed. While IPv4 is reaching its maximum, IPv6 has about
> 0.1% of the available /64 prefix routed and this continues to grow
> rapidly. Unlike IPv4, there is no practical means to scan reverse
> DNS namespace within IPv6 since each /64 prefix may contain any
> number of PTR records ranging up to 184,000,000,000,000,000,000.
>
> A technique commonly employed to automate IPv4 address categorization
> of suitable hosts is to check whether reverse PTR records appear to
> represent valid hostnames. Those that represent 4 decimal numbers
> are often considered unacceptable, for example. Our processing of
> reverse DNS namespace in cooperation with network providers now
> excludes about 38%, or about 1,000,000,000 IPv4 addresses. Comparing
> IPv6 /64 prefixes with the remainder of routable IPv4 addresses shows
> there are 11.3 million times more IPv6 /64 prefixes needing
> categorization. In addition, there is no practical means to
> facilitate this effort.
>
> Some also suggest there will not be a significant increase in the
> number of servers running over IPv6 and since their overall number
> should be comparable, email should still be dealing with a similar
> number of IP addresses. Unlike IPv4, IPv6 does not constrain the
> number of IP addresses assigned to a network interface. This feature
> allows each connection from a server to originate from a different IP
> address over the entire life of its operation while also having an
> ability to effortlessly change /64 prefixes. The potential increase
> allowed by IPv6 may prove explosive.
All three of the above paragraphs are essentially irrelevant to a
critique of DKIM...
>
> Many now hope DKIM will be able to offer a domain identity to provide
> a basis for acceptance to replace that of the IP address used by SMTP
awkward sentence construction...
> clients. With a lack of uptake by commercial reputation services,
> there are proposals within the IETF aimed at establishing DKIM as a
Both claims in this sentence are false.
> basis for reputation schemes in the Repute WG. When such an ill-
> considered effort is combined with DKIM's inability to detect invalid
> prefixed header fields, the results can prove highly harmful.
The 'ill-considered' apparently refers to the Repute working group, but
there's no explanation of its flaws. Since this is offered as the basis
for harm, it undermines the entire document.
It's also not clear how reference to the Repute WG is relevant to a
criticism of DKIM.
>
> 2. Maintaining Trust
>
> Not every subsystem or protocol layer should be expected to repeat
> previous security checks, however critical checks should not be
> assumed, especially those that involve a trivial amount of effort.
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 4]
>
> Internet-Draft DKIM-HARMFUL May 2013
>
>
> With high levels of abuse resulting from email's open nature,
> delegating checks in a structured manner better conserves essential
> resources. However, email's highly distributed store and forward
> protocol could not function if rigid message structures were enforced
> by the transport. New authentication or presentation requirements
> may involve small structural adjustments. For example,
> internationalization introduced a format negotiation not assured to
> survive beyond the next hop.
I do not understand the applicability of the text in this section to to
the premise of the document, and especially not to the title of the section.
>
> 3. Responding to Defects and Exploitation
>
> With the advent of aviation, the world marveled at the skill and
> intellect taking us to ever greater heights. With aviation, faults
> threatening security, that when found, demanded our attention and
> diligence to effect repair. As with aviation, the success of email
> has risen to great heights. Email has become an integral component
Email does not travel via airplanes, except for those few passengers
using their laptops, connected during flight. But perhaps I'm confused
about the meaning and relevance of this section...
> in general commerce and the maintenance of security such as reporting
> system failures, break-in attempts, and facilitating account access
> recovery.
>
> Reporting or predicting failure should not be viewed as exhibiting a
> lack of respect for achieved accomplishments. Noting and repairing
> faults only signify the importance of email's prominent role. As
> with most security related protocols, responding to noted defects is
> fairly common. Not responding to discovered defects in a security
> related protocol would be shocking.
I do not understand the applicability of the text in this section to to
the premise of the document.
>
> 4. SMTP Can't
>
> SMTP [RFC5321] recommends against rejecting messages based upon
> perceived defects in the message structure. This liberal acceptance
> permits evolutionary changes in message specifications starting at
> [RFC0822] that was based on [RFC0733] replaced by [RFC2822] and again
> by [RFC5322], [RFC6152], [RFC6532], and [RFC6854]; the second to last
> paragraph in section 3 of [RFC5321] provides a definitive statement
Section 3.3, not Section 3.
> messages should not be rejected due to perceived defects in the
> [RFC0822] message structure. The initial reference to [RFC0822] in
> this paragraph offers two foot notes with the second referencing the
> latest version of [RFC0822] which is [RFC5322] which itself has
> recently been updated. The impact of initially removing text
> specifically indicating which header fields are not to repeat is
I do not understand what 'removing' is meant here.
> unknown. This information was implied within the then-new ABNF
ABNF was new in 1977, not 1982...
> notation. Clarifying text for this requirement did not return until
> the [RFC0822] revision 19 years later which also indicates this
> specification's success at providing a foundation that allowed email
> to flourish.
I do not understand the point of the text here. It seems to be irrelevant.
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 5]
>
> Internet-Draft DKIM-HARMFUL May 2013
>
>
> There are many SMTP servers that have been in operation for decades
> with years passing between security patches. Such an accomplishment
> is most remarkable considering the volume of traffic being handled,
> often from highly malicious sources. This amazing stability and
> scalability with high levels of security would not have been possible
> if SMTP had been expected to validate message formats.
>
> Expecting SMTP to validate message formats to protect against
> vulnerabilities pertaining to protocols such as DKIM does not scale.
DKIM has essentially nothing to do with SMTP. As such, all of the above
text is irrelevant to a critique of DKIM.
> The general use of DKIM permits signature checks subsequent to
> acceptance where only the status of signatures determines internal
> placement. As such, it becomes critical to ensure a valid signature
> is never declared having malformed header field stacks. To
I can't parse this "As such" sentence.
> accomplish this, the DKIM specification must change.
>
>
> 5. DKIM Vulnerability
>
> DKIM permits a vulnerability by not checking the message header field
> stack for invalid repeats when signing or verifying a signature. The
DKIM does not "validate" a message. It associates a domain name with the
message. The difference is fundamental and essential. Again, there are
many attacks DKIM does not protect against, since it isn't trying to
protect against them...
> DKIM signature process must walk both down and then up the header
No, it is not required to; alternative approaches are viable and permitted.
> field stack while selecting the header fields to be included in the
> hash process of the signature. The DKIM process will even ignore
> prefixed FROM header fields which is the only header field always
> included.
>
> The WG concluded that "listing non-existent header fields as signed"
> hack added in non-normative language together with opinions that
FWIW, this also had AD support...
> checking for invalid repeated header fields is not to be considered
> DKIM's problem. See section 8.15 of [RFC6376] where this issue was
> expressed as not an attack against the trust DKIM intends to convey,
> and thus not a concern for DKIM. Nevertheless, improperly formed
> messages may display only the first of multiple header fields that,
> as a result of erroneous assumptions of there being no invalid
> repeated header fields, the prefixed header fields are likely to be
> displayed in lieu of those signed while not impacting DKIM's
> signature validity.
This text appears to be irrelevant to DKIM's functions, if only because
DKIM does not cover displays to users.
>
> DKIM incorrectly assumed the header field stack's starting condition,
> which DKIM itself is best able to determine, and is an option in the
I don't understand what this sentence is trying to say.
> OpenDKIM implementation. This is likely to astonish most recipients
> that DKIM failed to make a robust effort to maintain the trust it is
> attempting to convey. Three members of the WG authored proposed
Small nit: IETF working group have participants, not 'members'...
> changes aimed specifically at addressing this issue [DKIM-MH-Attack].
> At the time, some expressed concerns about whether this might set
This appears to be an attempt to re-raise an issue that was considered
and rejected by the working group. How is that productive?
> back DKIM's standardization process. As such, DKIM Signers may sign
> malformed messages (e.g., violate [RFC5322]) and be in compliance
DKIM's RFC 6376, Section 3.8:
Accordingly, DKIM's design is predicated on valid input.
So the assertion being made here appears to be incorrect.
> with DKIM specifications. In addition, receivers may verify these
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 6]
>
> Internet-Draft DKIM-HARMFUL May 2013
>
>
> messages as having valid signatures despite multiple instances of a
> header field only permitted to occur once and also be in compliance
> with DKIM specifications. See addendum for examples.
>
> Use of DKIM on such messages exposes a vulnerability in the
> evaluation process. Rather than ensuring essential checks are made
> prior to producing a result, a wasteful hack was later suggested
> where extra non-existent header fields could be included in the list
> of signed header fields. Any pre-pended header field added after
> signing would thereby change resulting hashes and invalidate the
> signature. Not all domains are attempting to achieve the same level
> of trust and may be more sensitive to incurring incremental storage
> requirements. Some domains may even inadvertently sign invalid
> repeated header fields because this check had not been required in
> the DKIM process. These same DKIM domains are also likely to
> establish themselves as being Too Big To Block. These TBTB domains
> can then be used to spoof other domains that may have otherwise
> established a high level of trust by implementing the hack where, due
> to this defect in DKIM, can still do nothing in their defense from
> the perspective of now deceived recipients.
>
> This vulnerability in DKIM represents an exploit allowing serious
> attacks caused by erroneous assumptions made in DKIM's signature
> process. There is also a header field, which because of its label,
> may potentially mislead recipients into believing it contains valid
> "Authentication-Results" [RFC5451]. Common phrases such as
> "Authentication-Results", "pass", and "fail", rather than use of
> result codes belies introductory claims this header is not intended
> for direct human consumption.
>
>
> 6. Barriers to an Authenticated Domain
>
> Some advocate use of DKIM as a means to obtain domain references
I do not understand what "a means to obtain domain references" means here?
> based on the increased prevalence of this protocol. DKIM is
> independent of the domain actually sending the message and the
exactly.
> recipient by design. Unfortunately, DKIM also does not attempt to
> protect against likely abuses that are also beyond the control of the
> signing domain in which DKIM signature validity conveys no assurance
> pre-fixed header fields have not changed what recipients see. As
It's true that there are many abuses that DKIM does not protect against
and does not attempt to protect against.
> such, DKIM signing domains can not be held accountable for incidents
> of abuse appearing to violate subscription policies or that spoof
> other domains.
>
> Because of DKIM's vulnerability to header field spoofing, it would
> never be safe to express positive reputations either. Any such
> assurance could be exploited by malefactors to deceive those trusting
> DKIM results. In short, a DKIM signed domain as currently defined,
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 7]
>
> Internet-Draft DKIM-HARMFUL May 2013
>
>
> can never be safely used in any context, other than the most rigid
> exclusion of any unsigned content which is well beyond any existing
> implementation. It can never be used for email reputation as
> currently defined.
>
>
> 7. Domains as a Basis for Managing Traffic
>
> A manageable basis for assessments can leverage a smaller number of
> related domains, compared to IPv6 or even IPv4 addresses. Although
I do not understand what "a smaller number of related domains" means
here, nor especially how being 'related' is relevant.
> technically the domain name space can be larger than the massively
> large IPv6 address space, in practice it is not. One hundred
> thousand domains control 90% of Internet traffic out of approximately
> 100 million domains active each month. The top 150 domains control
> 50% of the traffic, and the top 2,500 domains control 75%. This
> level of domain consolidation permits effective fast-path white-
> listing. Improvements achieved using domains to consolidate the
> threat landscape can easily justify added cryptographic
> authentication burdens. Even APL resource records [RFC3123] can
> authenticate EHLO using a single DNS transaction, but this would not
> allow IPv6 email to be more easily managed, which cryptographic
> technology can offer.
>
>
> 8. XMPP Shows the Way Forward
>
> In addition to SMTP [RFC5321] using StartTLS [RFC3207] XMPP [RFC6122]
> uses StartTLS [RFC6120] over a different port with many of the
> features used by web servers such as [RFC2560] as one means to
> increase scalability. It seems plausible that by defining SMTP
> access over a different port is where a new authentication and
> international requirements can be resolved together. Of course, port
> 25 can be used, where it might require StartTLS in the case of IPv6
> connections.
This appears to be proposing a channel-based, one-hop authentication
mechanism. One problem is that TLS is rarely used for authentication of
the client...
In any event, this section is irrelevant to the stated topic of the
document, namely DKIM 'harm'.
> Many administrators overlook a serious problem made much worse by
> chatty protocols that impose processing delays. Examining server
> logs will not reveal any problem either, because the limited resource
> being consumed is the number of outstanding connections TCP is able
> to support. Reaching this limit will prevent new connections from
> being instantiated but this is not logged as an event. Over time
> administrators may hear complaints email is not being delivered or
> just see an ever growing percentage of spam.
>
>
> 9. IANA Considerations
>
> This document requires no IANA consideration.
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 8]
>
> Internet-Draft DKIM-HARMFUL May 2013
>
>
> 10. Security Considerations
>
> This draft intends to describe serious security concerns raised with
> use of DKIM exacerbated with IPv6 email. The contained
> recommendations are expected to reduce the security concerns. To
> ensure security, the DKIM specification must change.
>
>
> 11. References - Informative
>
> [DKIM-MH-Attack]
> http://trac.tools.ietf.org/wg/dkim/trac/ticket/24,
> "Multiple-header-attack alternative proposal", April 2011.
>
> [RFC0733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
> "Standard for the format of ARPA network text messages",
> RFC 733, November 1977.
>
> [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
> text messages", STD 11, RFC 822, August 1982.
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Levels", BCP 14, RFC 2119, March 1997.
>
> [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
> (IPv6) Specification", RFC 2460, December 1998.
>
> [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
> Adams, "X.509 Internet Public Key Infrastructure Online
> Certificate Status Protocol - OCSP", RFC 2560, June 1999.
>
> [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
> April 2001.
>
> [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes
> (APL RR)", RFC 3123, June 2001.
>
> [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
> Transport Layer Security", RFC 3207, February 2002.
>
> [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
> Architecture", RFC 4291, February 2006.
>
> [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
> for Authorizing Use of Domains in E-Mail, Version 1",
> RFC 4408, April 2006.
>
> [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 9]
>
> Internet-Draft DKIM-HARMFUL May 2013
>
>
> Extensions for Stateless Address Autoconfiguration in
> IPv6", RFC 4941, September 2007.
>
> [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
> for Authentication", RFC 4954, July 2007.
>
> [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
> October 2008.
>
> [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
> October 2008.
>
> [RFC5451] Kucherawy, M., "Message Header Field for Indicating
> Message Authentication Status", RFC 5451, April 2009.
>
> [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
> Protocol (XMPP): Core", RFC 6120, March 2011.
>
> [RFC6122] Saint-Andre, P., "Extensible Messaging and Presence
> Protocol (XMPP): Address Format", RFC 6122, March 2011.
>
> [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
> Service Extension for 8-bit MIME Transport", STD 71,
> RFC 6152, March 2011.
>
> [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
> Identified Mail (DKIM) Signatures", RFC 6376,
> September 2011.
>
> [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
> Email Headers", RFC 6532, February 2012.
>
> [RFC6854] Leiba, B., "Update to Internet Message Format to Allow
> Group Syntax in the "From:" and "Sender:" Header Fields",
> RFC 6854, March 2013.
>
> [v6-BGP-Rpts]
> http://bgp.potaroo.net/v6/as6447/, "BGP Routing Table
> Analysis Reports/IPv6/AS6447 views", May 2013.
>
>
> Appendix A. DKIM Examples
>
> From Random User Tue Mar 12 12:07:37 2013
> X-Apparently-To: just4spamdlr <at> yahoo.com via 72.30.237.8; Tue, 12 Mar 2013 12:08:37 -0700
> Return-Path: <Fake.user <at> gmail.com>
> Received-SPF: neutral (192.83.249.65 is neither permitted nor denied by domain of gmail.com)
> A3RleHQvcGxhaW4DAzACA3RleHQvaHRtbAMDMQ--
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 10]
>
> Internet-Draft DKIM-HARMFUL May 2013
>
>
> X-YMailISG: Po8J_9cWLDuz5QIo_tChc7OagZYPBIscsK7APx8FMj835hEX
> clyJxoQr6Ojy40ccEugqmkym_ayJu65fKm.KJY73k6aprxb9s7Bj6P32lpml
> 6yGzxWFYdNXCwcxHtFGdhKe3v7Tjh8x051jkxjIqfuS0vo8J5rZOr.Z__6vD
> 4wiGFDUwFHNUWAwuz_pwp7pZ5HCivuuuyszYVvH0eIFsrQ9crR.rrk_3EQU2
> Xkv_fInlGDFR8fafFPMOgQ7QOrHhy0zQUbptDEFGdh1QVOyLwIpjwEC7264k
> 4MqxUH7zz_M5JOQzj6dJslH0.iz5y9Sgp6y6kTUHAVP2f_t1hMeRvf3F7WJ6
> 1yY2rZJALIME1CtiNKQJoDctzgGFRnh_5mo415MvUcEIH7qqS5RFgWtXEQpd
> JIpyYlECDXVUcuASoLmzbuGSiCEVLq7f4EiBTAsaMwXJ07OgXBR.QYDw3VfA
> Z0AcfnFrUVHNLZtLaFukQKzdk9c6SpHFHSuCAsvLPuZeRy4Ij5ndXd7viyCS
> IkAHsnhG_u3.nZr3zUDFOrqw8sEKphobj6ZJ8KEXtuhr_tx.94abE1JRJYi5
> fukj2h8y9s.K10ZxoTClaw41_DD8fxESbyfyTRPytiEXUdK1WEjgS3rAZ0TA
> WPJPDr063xLYk20UY0V.N5J15lBCtqZcde_9pdXwxVySyXo1KEQOaH3TNRBZ
> AKMFuCC7NF56aklkiUgk2EWm8iYoHsFez5_HtOz1zmc1dv4mNFOPTaNrXF2X
> qjFiwfdUipupIlAEc6pIdv0_le.xvz1jnaewEOyxo4dKd2XLVvybLfsLY16U
> FzLS9MJJ1wC0Cmf3G2SbOmT4ZiAvPjyv8QnHzbSDDDy3hqg8F0uEE03sJ5dm
> on5FxOHZZ1wCH7DL1QAXpZYxYWKV.h3q69dKQMl6HbnmfT_WZQY4X8uKXqkZ
> o34v.YmvJxHSRCSmhFpug1EstpJ4gHVitl_eJzT_n6xYQwhNAuMZ9uRjN2xE
> 1Lf7NpgzRf9bFvOpJAlyLoK5Xvxbx711cMgEUfGIha_JtL1P7hyfncRszHDv
> txgUYzcsVvRyAyVvwDAM.TEBsFhAtqqwOibqo2l5xCBj2yXRbKJ0EOC1JDMs
> HA--
> X-Originating-IP: [192.83.249.65]
> Authentication-Results: mta1225.mail.bf1.yahoo.com from=gmail.com; domainkeys=neutral (no sig);
> from=gmail.com; dkim=pass (ok)
> Received: from 127.0.0.1 (EHLO rdaver.bungi.com) (192.83.249.65)
> by mta1225.mail.bf1.yahoo.com with SMTP; Tue, 12 Mar 2013 12:08:36 -0700
> Received: by rdaver.bungi.com
> via smail with stdio
> id <m1UFUYr-00KeXPC <at> rdaver.bungi.com>
> for Just4spamdlr <at> yahoo.com; Tue, 12 Mar 2013 12:08:33 -0700 (PDT)
> (Smail-3.2.0.94 1997-Apr-22 #591 built 2011-Feb-5)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=gmail.com; s=20120113;
> h=mime-version:x-received:date:message-id:subject:from:to
> :content-type;
> bh=PS9xMxYwwTGwWXbCd8bjBBm2rwb79wVOSDLhmp+k4b4=;
> b=qnYVUccLSAi2DGJdUgDDIP9A3uPk3PaxgqhYLBn6xU382MsCi/ICFgKAoFPuwM7BvL
> AuSuqL6P54cIJ3Pn36h2xmXy+ucNr5r5OqIY63rtvj6Apjr4uW1PzG47J7BGEiP9iwDZ
> PLTzl9ZLpZXvZZpTCJOXUQP2HF8q6aivCblYZIQcCdVRCftG+A4z0+dEyTHbxoAMx9U3
> GFISRRHcZ7k7GAyYmLrSr3fUTjvpa1YWoNK+IcSALC2tKVSW5FP1IQAT07f1e8+bOgHh
> JleaQIw8b1Vjlzhs4hFKLdedmjQqjDJXVP/K3J+t/ggfYn4H547fu6Pb5syKZIiuPf1e
> yJqA==
>
> MIME-Version: 1.0
> X-Received: by 10.220.221.143 with SMTP id ic15mr6773333vcb.32.1363115257152;
> Tue, 12 Mar 2013 12:07:37 -0700 (PDT)
> Received: by 10.52.70.169 with HTTP; Tue, 12 Mar 2013 12:07:37 -0700 (PDT)
> Date: Tue, 12 Mar 2013 09:07:37 -1000
> Message-ID: <CA+VnpPKv0s-p2nKkAkNHS4V2SxZehw_6S9QF5p1p2ji+FMof=Q <at> mail.gmail.com>
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 11]
>
> Internet-Draft DKIM-HARMFUL May 2013
>
>
> Subject: An example signed message
> From: Random User <random.j.user.994 <at> gmail.com>
> To: just4spamdlr <at> yahoo.com
> Content-Type: multipart/alternative; boundary=14dae9cdc33bb0ff5204d7bf00ff
> Content-Length: 280
>
> reporting valid signature
>
>
> From Fake User Tue Mar 12 12:07:37 2013
> X-Apparently-To: just4spamdlr <at> yahoo.com via 72.30.237.8; Tue, 12 Mar 2013 12:09:01 -0700
> Return-Path: <Fake.user <at> gmail.com>
> Received-SPF: neutral (192.83.249.65 is neither permitted nor denied by domain of gmail.com)
> A3RleHQvcGxhaW4DAzACA3RleHQvaHRtbAMDMQ--
> X-YMailISG: gFqc.ysWLDtqkdjDpSCH39uGWhgFfnsGdWobzNb5os6sP0We
> _L38eAdX.VKZWQ2F75gFwoipcPyj4g0uKMm_vSayLjrnps9lBxMGLvtTE8kT
> XYxIw6vZb4aFZ_jEcpoRntvJDkZQl4XSGWGakfmJ5G2blTWZ_i1BVkBvj0Sv
> jEymvhoIXZTb_l8C0Jh69ot3MgrNBvjhrBmhCK3sziUtDPpKQPJb_lxCnYKN
> O0SiArQ_TUXrCRFRNsyEiJxzVfSgJWIdsCV5BN3cp..NZ17X8fguB.YxNQjt
> qjVcGMd4IjQioY.a4f1luQxuiCN1yWvYqiLpP6eOCQhMrHt9XOdk32HAXNuJ
> GBraVtjrySTl9Db7PpRC46wlMs3iIUHl3z0d4o6293sMA5qFmnbczGoLRGFs
> RUVlBJuRoJCSYZh5LOwbj0RPQNX2Nmw.LHwF7SY3XcZWFUjvUQQ2sdx63m_J
> Mgy7JHAwBTVH6ytULsbXvu38a5GIYHccfNnDKVjtsrIg9qBDpVASHrRkncL0
> MFLy5FHLb_XBW1TPztCFtlRViKr_HFxMob6aZIte6T57AMqlV2YAHwVNObwx
> WE8ZWTkKNWbXqJYytd3vyuyAHfuseBFP_Jfmj0zVtg52EXpIlDiTANEOTamP
> zeu23QbeRWJd_Gpz9bbGw_OorPdcV.WJOQ29DHpiYAQRgWjJNLjkd8dI.vuM
> vs1Fr7LOiE3wRpSU5AW_hrR4anvGrnwSPOQaFmpNE0pl8n.Vomrp.5NU8cgU
> QYI1UCSPoE_HK5Som2HMPYZFQv0pJSu1NeitXlRM3DHkIMvW4aVYqrHSNVjl
> gGCFFx77c25QW.XAGtySBYWcTzcUlHP4fMa7Wli4u06C4N3pDPiQoXKOC10U
> koXUMKFYmedaZYvEeQRPO3_8xHwKyZ.QInDsnQRwPFWYKvcWCJu4c5zxDMG4
> h1AsyT3CM80nZXk8.ZGhzfTgo810Xjn_OJVgUfkG1z3..ReN990deaWJY8F5
> _j6lRWLZZRzCMwOGpJ6I.jgaN5mNk38Kj6.NYLFCpMTEIt28jIRHD85cfpa3
> iOL3drg1TIKQWrEhS9u3H29niQ_hjHbk7ys6uSJvowilRwO8eB2s.Wz0
> X-Originating-IP: [192.83.249.65]
> Authentication-Results: mta1266.mail.bf1.yahoo.com
> from=gmail.com; domainkeys=neutral (no sig);
> from=gmail.com; dkim=pass (ok)
> Received: from 127.0.0.1 (EHLO rdaver.bungi.com) (192.83.249.65)
> by mta1266.mail.bf1.yahoo.com with SMTP; Tue, 12 Mar 2013 12:09:00 -0700
> Received: by rdaver.bungi.com
> via smail with stdio
> id <m1UFUZI-00KeXRC <at> rdaver.bungi.com>
> for Just4spamdlr <at> yahoo.com; Tue, 12 Mar 2013 12:09:00 -0700 (PDT)
> (Smail-3.2.0.94 1997-Apr-22 #591 built 2011-Feb-5)
> From: Fake User <fake.user <at> gmail.com>
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=gmail.com; s=20120113;
> h=mime-version:x-received:date:message-id:subject:from:to
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 12]
>
> Internet-Draft DKIM-HARMFUL May 2013
>
>
> :content-type;
> bh=PS9xMxYwwTGwWXbCd8bjBBm2rwb79wVOSDLhmp+k4b4=;
> b=qnYVUccLSAi2DGJdUgDDIP9A3uPk3PaxgqhYLBn6xU382MsCi/ICFgKAoFPuwM7BvL
> AuSuqL6P54cIJ3Pn36h2xmXy+ucNr5r5OqIY63rtvj6Apjr4uW1PzG47J7BGEiP9iwDZ
> PLTzl9ZLpZXvZZpTCJOXUQP2HF8q6aivCblYZIQcCdVRCftG+A4z0+dEyTHbxoAMx9U3
> GFISRRHcZ7k7GAyYmLrSr3fUTjvpa1YWoNK+IcSALC2tKVSW5FP1IQAT07f1e8+bOgHh
> JleaQIw8b1Vjlzhs4hFKLdedmjQqjDJXVP/K3J+t/ggfYn4H547fu6Pb5syKZIiuPf1e
> yJqA==
> MIME-Version: 1.0
> X-Received: by 10.220.221.143 with SMTP id ic15mr6773333vcb.32.1363115257152;
> Tue, 12 Mar 2013 12:07:37 -0700 (PDT)
> Received: by 10.52.70.169 with HTTP; Tue, 12 Mar 2013 12:07:37 -0700 (PDT)
> Date: Tue, 12 Mar 2013 09:07:37 -1000
> Message-ID: <CA+VnpPKv0s-p2nKkAkNHS4V2SxZehw_6S9QF5p1p2ji+FMof=Q <at> mail.gmail.com>
> Subject: An example signed message
> From: Random User <random.j.user.994 <at> gmail.com>
> To: just4spamdlr <at> yahoo.com
> Content-Type: multipart/alternative; boundary=14dae9cdc33bb0ff5204d7bf00ff
> Content-Length: 280
>
> spoofed DKIM with valid signature
>
>
> Appendix B. Stats
>
> Total spams: 9438
> DKIM pass: 688 (about 25% relayed from large ESPs)
> DKIM fail: 189
> DKIM pass w/multiple from: 28 (about 2% on average)
> Unsigned: 8561
>
> Looking at a few minutes of spam.
>
>
> Authors' Addresses
>
> Douglas Otis
> Trend Micro
> 10101 N. De Anza Blvd
> Cupertino, CA 95014
> USA
>
> Phone: +1.408.257-1500
> Email: doug_otis <at> trendmicro.com
>
>
>
>
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 13]
>
> Internet-Draft DKIM-HARMFUL May 2013
>
>
> Dave Rand
> Trend Micro
> 10101 N. De Anza Blvd
> Cupertino, CA 95014
> USA
>
> Phone: +1.408.257-1500
> Email: dave_rand <at> trendmicro.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Otis & Rand Expires November 13, 2013 [Page 14]
>
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
RSS Feed