IETF A. Vesely Internet-Draft Intended status: Informational January 20, 2016 Expires: July 23, 2016 DNSWL Email Authentication Method Extension draft-vesely-authmethod-dnswl-03 Abstract This document describes an additional Email Authentication Method compliant with RFC 7601. The method consists in looking up the sender'IP in a DNS whitelist. 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- 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 July 23, 2016. Copyright Notice Copyright (c) 2016 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. Vesely Expires July 23, 2016 [Page 1] Internet-Draft DNSWL email-auth-method extension January 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Method Details . . . . . . . . . . . . . . . . . . . . . . . 2 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 5.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction One of the many checks that mail servers carry out is to query DNS whitelists (DNSWL, [RFC6471]). The lookup is based on the sender's IP address, so this check can occur very early in an SMTP transaction, and can be used to counterweight policies that typically occur at early stages too, such as the Sender Policy Framework (SPF, [RFC7208]). Nevertheless, the result of a DNSWL lookup can be used at later stages as well; for example, a delivery agent can use it to estimate the spamminess of an email message. The latter possibility needs a place to collect query results for downstream use, which is precisely what the Authentication-Results header field aims at providing. Results can contain more than pass/fail, but they are encoded according to list-specific criteria. The present method considers only whitelists --one of the major branches exemplified by [RFC6471]. That way, at least the meaning of pass/fail is clear and actionable. Additional query results can be stored as parameters. In effect, they are tantamount to local policies, albeit outsourced, and as such they have to be interpreted locally, based on list-specific knowledge. 2. Method Details dns.zone: DNSWL query root domain, which defines the meaning of the result. Note that if the MTA uses a local mirror, this can be different from the zone actually queried. MTAs need to map query root domains to local zones in order to minimize external queries. policy.ip: The bit mask value, in dotted quad. This entry can be repeated if the DNSWL returns multiple A records. Vesely Expires July 23, 2016 [Page 2] Internet-Draft DNSWL email-auth-method extension January 2016 policy.txt: The TXT record, if any. Multiple records are concatenated. The result of the method states how the query did, up to the interpretation of the result. In particular, some DNSBLs are known to return special codes to signal over quota, for example 127.0.0.255. If the result producer cannot interpret that value, that case results in a false positive. pass: The query successfully returned applicable records. The sender is whitelisted, up to differing interpretation. fail: The query worked but yelded no record, or returned NXDOMAIN, so the sender is not whitelisted. temperror: There was a transient problem with the query. permerror: There is a setup problem, the query cannot work. This possibly includes over quota cases interpreted by the result producer. 3. IANA Considerations There is a registry of Email Authentication Methods created by RFC7601. The method described in this document is referred by Table 1, along its ptype.property values. A new "ptype" is introduced in Table 2. +--------+--------+----------+-------------------+--------+---------+ | Method | ptype | property | Value | Status | Version | +--------+--------+----------+-------------------+--------+---------+ | dnswl | dns | zone | DNSWL publicly | active | 1 | | | | | accessible query | | | | | | | root domain | | | | dnswl | policy | ip | type A query | active | 1 | | | | | result in dotted | | | | | | | quad | | | | dnswl | policy | txt | type TXT query | active | 1 | | | | | result | | | +--------+--------+----------+-------------------+--------+---------+ Table 1: Email Authentication Method Vesely Expires July 23, 2016 [Page 3] Internet-Draft DNSWL email-auth-method extension January 2016 +-------+------------+----------------------------------------------+ | ptype | Definition | Description | +-------+------------+----------------------------------------------+ | dns | [this doc] | The property being reported is a domain name | +-------+------------+----------------------------------------------+ Table 2: Email Authentication Property Type This method reuses four of the values already defined in the Email Authentication Result Names associated registry. They are listed in Table 3. +---------+-----------+------------------------------------+--------+ | Auth | Code | Specification | Status | | Method | | | | +---------+-----------+------------------------------------+--------+ | dnswl | pass | Sender is whitelisted, up to | active | | | | returned code interpretation | | | dnswl | fail | NXDOMAIN or no record, sender is | active | | | | not whitelisted | | | dnswl | temperror | Transient DNS error during the | active | | | | query | | | dnswl | permerror | Query cannot work, human | active | | | | intervention needed | | +---------+-----------+------------------------------------+--------+ Table 3: Email Authentication Result Names 4. Security Considerations All of the considerations described in Section 7 of [RFC7601] apply. In addition, the usual caveats apply about importing text from external online sources. Although queried DNSWLs are well known, trusted entities, it is suggested that TXT records be reported only if, upon inspection, their content is deemed actually actionable. If they contain non-ASCII characters, they need to be encoded as appropriate. 5. References 5.1. Normative References [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . Vesely Expires July 23, 2016 [Page 4] Internet-Draft DNSWL email-auth-method extension January 2016 [RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/ RFC7601, August 2015, . 5.2. Informative References [RFC6471] Lewis, C. and M. Sergeant, "Overview of Best Email DNS- Based List (DNSBL) Operational Practices", RFC 6471, DOI 10.17487/RFC6471, January 2012, . Appendix A. Example Authentication-Results: mta.example.com; dnswl=pass dns.zone=list.dnswl.example policy.ip=127.0.10.1 policy.txt="example.org http://dnswl.example/s?s=100" Author's Address Alessandro Vesely v. L. Anelli 13 Milano, MI 20122 IT Email: vesely@tana.it Vesely Expires July 23, 2016 [Page 5]