DNS Whitelist (DNSWL) Email Authentication Method Extension
RFC 8904
Document | Type |
RFC - Informational
(September 2020; No errata)
Was draft-vesely-authmethod-dnswl (individual)
|
|
---|---|---|---|
Author | Alessandro Vesely | ||
Last updated | 2020-09-17 | ||
Stream | ISE | ||
Formats | plain text html xml pdf htmlized bibtex | ||
IETF conflict review | conflict-review-vesely-authmethod-dnswl | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2019-11-28) | ||
IESG | IESG state | RFC 8904 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | Adrian Farrel <rfc-ise@rfc-editor.org> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack |
Independent Submission A. Vesely Request for Comments: 8904 September 2020 Category: Informational ISSN: 2070-1721 DNS Whitelist (DNSWL) Email Authentication Method Extension Abstract This document describes an email authentication method compliant with RFC 8601. The method consists of looking up the sender's IP address in a DNS whitelist. This document provides information in case the method is seen in the field, suggests a useful practice, and registers the relevant keywords. This document does not consider blacklists. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8904. Copyright Notice Copyright (c) 2020 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 (https://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. Table of Contents 1. Introduction 2. Method Details 3. TXT Record Contents 4. IANA Considerations 4.1. Email Authentication Methods 4.2. Email Authentication Property Type 4.3. Email Authentication Result Names 5. Security Considerations 5.1. Over-Quota Signaling 5.2. Security of DNSSEC Validation 5.3. Inherited Security Considerations 6. References 6.1. Normative References 6.2. Informative References Appendix A. Example Appendix B. Known Implementation Appendix C. Future Possibilities of the 'dns' ptype Author's Address 1. Introduction One of the many checks that mail servers carry out is to query DNS whitelists (DNSWLs). That method is fully discussed in [RFC5782]. The DNS [RFC1034] lookup is based on the connecting client's IP address, IPv4 or IPv6, and returns zero or more A records. The latter are IPv4 IP addresses in the range 127.0.0.0/8. Depending on the query, TXT records with varying content can also be retrieved. Query examples are given in Appendix A. Since the IP address is known as soon as the connection is accepted, this check can occur very early in an SMTP transaction. Its result can be used to counterweight policies that typically occur at early stages too, such as the Sender Policy Framework (SPF) (the last paragraph of Appendix D.3 of [RFC7208] is also illustrated in Appendix A). In addition, the result of a DNSWL lookup can be used at later stages; for example, a delivery agent can use it to learn the trustworthiness of a mail relay in order 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 to provide. Results often contain additional data, encoded according to DNSWL- specific criteria. The method described in this document considers only whitelists -- one of the major branches described by [RFC5782]. There are also blacklists/blocklists (DNSBLs) and combined lists. Since they all have the same structure, the abbreviation DNSxL is used to mean any. The core procedures of a Mail Transfer Agent (MTA) tend to be quite general, leaving particular cases to be handled by add-on modules. In the case of combined lists, the boundary MTA (see [RFC5598]), which carries out the check and possibly stores the result, has to be able to discern at least the color of each entry, as that is required to make accept/reject decisions. This document provides for storing the result when the DNSxL record to be reported is a whitelisting one. Data conveyed in A and TXT records can be stored as properties of the method. The meaning of such data varies widely at the mercy of the list operator; hence, the queried zone has to be stored as well. Mail site operators who configure their MTAs to query specific DNWSLs marry the policies of those lists, as, in effect, they become tantamount to local policies, albeit outsourced. Downstream agents who know DNSWL-specific encoding and understand the meaning of thatShow full document text