Individual D. Otis Internet-Draft D. Rand Intended status: Informational Trend Micro Expires: November 3, 2013 May 2, 2013 IPv6 Email Authentication draft-otis-ipv6-email-authent-00 Abstract IPv6 facilitates network routing over an incredibly vast address space, but abuse mitigation resolving to underlying structures of routes or blocks of prefixes would be highly disruptive due to collateral effects. Use of domains minimizes unintended coincidental blocking while offering the consolidation necessary to facilitate connection management. Currently, email lacks conventions ensuring SMTP clients can be identified by an authenticated domain. DKIM is independent of intended recipients and domains accountable for having sent email. SPF normally requires several text based responses imposing high overhead to query various locations. These locations can be constructed by email-address local-part macros which can flood caches or leverage DNS name compression to further increase network DDoS amplifications when receivers' attempt to verify message sources which may then only offer authorization, not authentication of accountable domains. Most email abuse, including what might be imposed by SPF, is prevented with comprehensive mapping of the address space, but such mapping is impractical with IPv6. An effective authenticated domain name alternative is needed to provide basis for assessing and reacting to abusive behavior. For most high scale protocols, this involves cryptography. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Otis & Rand Expires November 3, 2013 [Page 1] Internet-Draft IPv6 EMAIL AUTHENT May 2013 Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 3, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Otis & Rand Expires November 3, 2013 [Page 2] Internet-Draft IPv6 EMAIL AUTHENT May 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Maintaining Trust . . . . . . . . . . . . . . . . . . . . . . 5 3. Responding to Defects and Exploitation . . . . . . . . . . . . 5 4. SMTP Can't . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. DKIM Vulnerability . . . . . . . . . . . . . . . . . . . . . . 6 6. Barriers to an Authenticated Domain . . . . . . . . . . . . . 7 7. Mail From Parameter and SPF . . . . . . . . . . . . . . . . . 8 8. IPv6 and SPF with PTR or local-part Macros . . . . . . . . . . 8 9. Domains as a Basis for Managing Traffic . . . . . . . . . . . 10 10. XMPP Shows the Way Forward . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 13. References - Informative . . . . . . . . . . . . . . . . . . . 11 Appendix A. DKIM Examples . . . . . . . . . . . . . . . . . . . . 13 Appendix B. Stats . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Otis & Rand Expires November 3, 2013 [Page 3] Internet-Draft IPv6 EMAIL AUTHENT May 2013 1. Introduction There are currently 18,206,379,106,009,090 /64 equivalent IPv6 [RFC2460] 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.09% of the available /64 prefix routed and 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 exclude about 38%, or about 1,000,000,000 IPv4 addresses. Comparing IPv6 /64 prefixes with the remainder of rout-able IPv4 addresses shows there are 11.3 million times more IPv6 /64 prefixes needing categorization that also happen to lack a practical means for facilitating this effort. Management of either a list of names or a list of numbers involves logging the associated connections for subsequent review. Often limits are imposed over some period to constrain overall log growth when establishing behavior. When based on currently routed IPv6 /64 prefixes, storing just a single bit per rout-able prefix requires 6 million billion bytes or 5,650 Terra-bytes of storage just to track simple use. Storage requirements for simple address use is likely to grow another seven fold as more providers adopt IPv6. Categorization of this use will require additional bits to retain counts and indexes further multiplying storage needs. Some suggest there will not be a significant increase in the number of servers running over IPv6 and since the overall number should be comparable, email should 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 life of its operation while also having an ability to effortlessly change /64 prefixes. The increase may prove explosive. Extending IP address reputation to IPv6 would also indicate which mailboxes are used to detect abuse and afford malefactors a means to wash mailing lists to sidestep enforcement of subscription policies. Detection of unsolicited commercial email is a fundamental element in email reputation. Traditional address reputation techniques with IPv6 will not retain effective detection. Even if detection were Otis & Rand Expires November 3, 2013 [Page 4] Internet-Draft IPv6 EMAIL AUTHENT May 2013 practical, no scheme can distribute highly sparse IP address information quickly enough to counter an IPv6 source's agility at evading IP address based mitigation. Checking reverse DNS entries per SMTP connection requires queries against the entire IP address. For IPv6, reverse DNS checks by SMTP servers may inadvertently induce DDoS effects against DNS while also consuming the server's connection resources waiting for reverse DNS responses. Prior IPv4 mapping of reverse DNS avoided a sizable waste of resources while defending open services. However, prior mapping of reverse DNS is not practical with IPv6 making it impossible to defended against DDoS effects or excessive resource loss while checking the reverse namespace. Alternatively, costs related to blocking port 25 by Customer-Premises Equipment should be negligible. Network providers should offer different services to isolate residential from commercial use, in a manner analogous to IPv4 reverse PTR records designating dynamic and static assignments. Residential systems sending email to SMTP's public port 25, for the most part, represent compromised systems. Blocking this category of traffic would be much safer than expecting recipients to check the reverse namespace. Windows, OS X, and iOS employ the IPv6 privacy extensions [RFC4941] where any problematic IP address is likely to be reassigned different addresses regularly and remain valid beyond the reassignment interval. 2. Maintaining Trust Not every subsystem or protocol layer should be expected to repeat previous security checks, however critical checks should not be assumed, especial those that involve a trivial amount of effort. 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. 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 Otis & Rand Expires November 3, 2013 [Page 5] Internet-Draft IPv6 EMAIL AUTHENT May 2013 has risen to great heights. Email has became an integral component 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. 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], [RFC6530], and [RFC6854]; the second to last paragraph in section 3 of [RFC5321] provides a definitive statement 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 unknown. This information was implied within the then-new ABNF 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. 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 signature process must walk both down and then up the header 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 the "listing non-existent header fields as signed" hack added in non-normative language together with opinions that checking for invalid repeated header fields is to be considered SMTP's problem. This issue was expressed as not an attack against Otis & Rand Expires November 3, 2013 [Page 6] Internet-Draft IPv6 EMAIL AUTHENT May 2013 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. DKIM incorrectly assumed the header field stack's starting conditions, which itself is best able to determine. This is likely to astonish most recipients that DKIM failed to make a robust effort to maintain the trust it is attempting to convey. As such, DKIM Signers may sign malformed messages (e.g., violate [RFC5322]). In addition, receivers will verify these messages as having valid signatures despite multiple instances of a header field only permitted to occur once. See addendum for examples. Use of DKIM on such messages exposes a vulnerability in the evaluation process. Rather 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 DKIM the 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 Many advocate either SPF or DKIM as a means to obtain domain references based on the increased prevalence of these protocols. DKIM is independent of the domain actually sending the message and Otis & Rand Expires November 3, 2013 [Page 7] Internet-Draft IPv6 EMAIL AUTHENT May 2013 the 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 such, DKIM signing domains can not be held accountable for incidents of abuse appearing to violate subscription policies or that spoof other domains. 7. Mail From Parameter and SPF Access to outbound SMTP servers may or may not restrict the Mail Parameter use. The strategy used to control abuse might rely upon rate limits and denial of access subsequent to abuse reports. Reasons for publishing SPF records might be to mitigate backscatter based on records that offer Non-Delivery-Notifications (NDNs) authorization by the Mail From parameter where the loss of some of these notifications is considered acceptable. This mechanism does not offer a positive basis for identification. Its intent is to constrain the number of invalid NDNs being returned when someone spoofs their domain. Evidence of this intent might be denoted by SPF record's ending or providers overriding them with "?all". SPF failure rates of even a few percent are too high for it to offer a solid basis for either acceptance or rejection. There are some policy strategies that attempt to combine SPF and DKIM where when either of their related domains manage to pass, only then is the message to be placed in the in-box. Domains that reference SPF resource records should not be considered authenticated because the SPF process authorized the SMTP client. Often an SMTP client is shared by many domains. As such, it would be incorrect to assume SPFv1 records that authorize a provider by way of the Mail Parameters is only permitted by authenticated accounts from that domain. As a result, no domain information in SPF or DKIM, under current circumstances, can be used as a domain reference for either acceptance or reputation. 8. IPv6 and SPF with PTR or local-part Macros When IPv6 becomes more commonly used, some will attempt white-listing IP addresses as a practical albeit non-scalable method to deal with the highly increased address range that is confronted when dealing with IPv6. There are currently no practical solutions able to scale to the challenging range of IP addresses that might be controlled by Otis & Rand Expires November 3, 2013 [Page 8] Internet-Draft IPv6 EMAIL AUTHENT May 2013 malefactors. Unlike most DNS resources that segregate IPv4 and IPv6 datasets, SPF consolidates both IPv4 and IPv6 addresses into a common list comprised of a chain of DNS transactions. SPF also includes macros run by recipients that can expand the local-part of the Mail From parameter or the IP address of the SMTP client into labels used in subsequent DNS queries. Expressing an IPv6 address using the SPF macro in the reverse order nibble form can comprise a query containing more than 32 labels. If local-part macros are used to locate 10 MX records, the combined targets for these MX records can comprise a set of 100 separate hostnames. Local-part macros can also be used to chain SPF record sets making forensic review difficult. The SPF review documented in [RFC6686] failed to provide a breakdown on the macro use. SPF's macros can prove hazardous, especially with IPv6. Rather than permitting the receiver to decide the method used for acceptance, an SPF resource record based upon the Mail From parameter can induce 100 DNS transactions using labels constructed from random strings found in the message local-part. These transactions may also decide to use the reverse namespace to place an extreme burden on DNS, its cache, and the SMTP server's connection resources. The SPF-bis draft purports to be documenting current use. It dropped the SPF resource record (99) due to sparse use. If a similar threshold were applied, the SPF macro expansion aspects of this protocol would be removed as well. Several large providers have offered their assurance that their SPF libraries had these macros removed. Any effort hoping to define current use MUST carefully reconsider the inclusion of this ill-considered feature. Otherwise, it can not be suggested SPF-bis simply documents current use. The danger imposed by the use of the local-part macro is inherent in the query required to support both an IPv6 expansion, in conjunction with the expansion of local-part macros induced by possibly cached SPF records. The local-part, along with a range of IP addresses made readily possible by IPv6, can be manipulated to induce a flurry of large DNS transactions directed toward any otherwise uninvolved domain, all directed by cached DNS records that contain active content. It is never a good idea to allow free attacks. The SPF local-part macro would allow a cached DNS record to be repeatedly exploited by a spam campaign with an attacker consuming little of their resources beyond what they already use in their spam campaign. In this case, their recipients change the domains queried on behalf of the attackers based upon the same SPF resource record. High levels of Otis & Rand Expires November 3, 2013 [Page 9] Internet-Draft IPv6 EMAIL AUTHENT May 2013 amplification still apply if SPF specifications are not changed and resulting implementation are then assumed part of some greater security requirement and no longer experimental. The SPF macro DOS overview demonstrated in 2006 [I-D.otis-spf-dos-exploit] did not consider IPv6 use which offers higher gain, where the gain achieved sending a single 1KB message to a single recipient offered a 1:156 reflected gain over IPv4 that can never be filtered or blocked by using BCP38 [RFC2827]. Logically, local-part macros would not safely provide a positive result without the query being combined with an IP address list of SMTP clients in some form. A list structure would need to be repeated for each of the users. Rcpt To using schemes like BATV provides an expedient way where the purported sender determines whether a NDN can be returned without the risk associated with active content placed within DNS resource records. Several parsers ignore local-part macro expansion since they rarely play any role in providing positive results. 9. 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 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 this technology can offer. 10. 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 port 465 is where a new authentication and international requirement can be resolved together. Otis & Rand Expires November 3, 2013 [Page 10] Internet-Draft IPv6 EMAIL AUTHENT May 2013 11. IANA Considerations This document requires no IANA consideration. 12. Security Considerations This draft intends to describe serious security concerns raised with use of IPv6 email. The contained recommendations are expected to reduce the security concerns. 13. References - Informative [I-D.otis-spf-dos-exploit] Otis, D., "SPF DoS Exploitation", June 2006. [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. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [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. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. Otis & Rand Expires November 3, 2013 [Page 11] Internet-Draft IPv6 EMAIL AUTHENT May 2013 [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. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [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 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 Otis & Rand Expires November 3, 2013 [Page 12] Internet-Draft IPv6 EMAIL AUTHENT May 2013 Identified Mail (DKIM) Signatures", RFC 6376, September 2011. [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012. [RFC6577] Kucherawy, M., "Authentication-Results Registration Update for Sender Policy Framework (SPF) Results", RFC 6577, March 2012. [RFC6686] Kucherawy, M., "Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments", RFC 6686, July 2012. [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 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/, "BGP Routing Table Analysis Reports/IPv6/AS6447 views", April 2013. Appendix A. DKIM Examples From Random User Tue Mar 12 12:07:37 2013 X-Apparently-To: just4spamdlr@yahoo.com via 72.30.237.8; Tue, 12 Mar 2013 12:08:37 -0700 Return-Path: Received-SPF: neutral (192.83.249.65 is neither permitted nor denied by domain of gmail.com) A3RleHQvcGxhaW4DAzACA3RleHQvaHRtbAMDMQ-- 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 Otis & Rand Expires November 3, 2013 [Page 13] Internet-Draft IPv6 EMAIL AUTHENT May 2013 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 for Just4spamdlr@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: Subject: An example signed message From: Random User To: just4spamdlr@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@yahoo.com via 72.30.237.8; Tue, 12 Mar 2013 12:09:01 -0700 Return-Path: Received-SPF: neutral (192.83.249.65 is neither permitted nor denied by domain of gmail.com) A3RleHQvcGxhaW4DAzACA3RleHQvaHRtbAMDMQ-- X-YMailISG: gFqc.ysWLDtqkdjDpSCH39uGWhgFfnsGdWobzNb5os6sP0We Otis & Rand Expires November 3, 2013 [Page 14] Internet-Draft IPv6 EMAIL AUTHENT May 2013 _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 for Just4spamdlr@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 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: Subject: An example signed message Otis & Rand Expires November 3, 2013 [Page 15] Internet-Draft IPv6 EMAIL AUTHENT May 2013 From: Random User To: just4spamdlr@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@trendmicro.com Dave Rand Trend Micro 10101 N. De Anza Blvd Cupertino, CA 95014 USA Phone: +1.408.257-1500 Email: dave_rand@trendmicro.com Otis & Rand Expires November 3, 2013 [Page 16]