DNS Whitelist (DNSWL) Email Authentication Method Extension
RFC 8904

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10
• 11
• 12
• 13
• 14
• 15
• 16



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 that