idnits 2.17.1 draft-vesely-authmethod-dnswl-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2019) is 1798 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF A. Vesely 3 Internet-Draft May 18, 2019 4 Intended status: Informational 5 Expires: November 19, 2019 7 DNSWL Email Authentication Method Extension 8 draft-vesely-authmethod-dnswl-08 10 Abstract 12 This document describes an additional Email Authentication Method 13 compliant with RFC 8601. The method consists in looking up the 14 sender'IP in a DNS whitelist. 16 This document describes does not consider black lists. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 19, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Method Details . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. TXT Record Contents . . . . . . . . . . . . . . . . . . . . . 3 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 59 6.2. Informative References . . . . . . . . . . . . . . . . . 6 60 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 One of the many checks that mail servers carry out is to query DNS 66 whitelists (DNSWL, [RFC5782]). The lookup is based on the connecting 67 client's IP address, so this check can occur very early in an SMTP 68 transaction. The result can be used to counterweight policies that 69 typically occur at early stages too, such as the Sender Policy 70 Framework (SPF, the last paragraph of Appendix D.3 of [RFC7208] is 71 illustrated in Appendix A). In addition, the result of a DNSWL 72 lookup can also be used at later stages; for example, a delivery 73 agent can use it to estimate the spamminess of an email message. The 74 latter possibility needs a place to collect query results for 75 downstream use, which is precisely what the Authentication-Results 76 header field aims at providing. 78 Results often contain additional data, encoded according to DNSWL- 79 specific criteria. The present method considers only whitelists 80 --one of the major branches considered by [RFC5782]. In case of 81 DNSxL, the boundary MTA (see [RFC5598]) which carries out the check 82 and possibly stores the result, has to be able to discern at least 83 the color of "x", which is required to make accept/reject decisions. 85 Data conveyed in A and TXT records can be stored as result's 86 parameters. In effect, they are tantamount to local policies, albeit 87 outsourced. Downstream agents need to know DNSWL-specific encoding 88 to understand the meaning of that data. In order to smooth 89 operations, this document endorses a usage of TXT fields consistent 90 with other authentication methods. Namely, to serve the domain name 91 in the TXT record. 93 2. Method Details 95 The following ptype.property items define the relevant parameters 96 where additional data can be stored. They augment the "pass" result 97 with information about the entry found. 99 dns.zone: DNSWL query root domain, which defines the meaning of the 100 result. Note that an MTA can use a local mirror with a 101 different name. The name stored here has to be the best 102 available reference for all foreseeable downstream 103 consumers. If the message is handed outside the internal 104 network, dns.zone had better be the global zone. 106 policy.ip: The bit mask value received in type A response, in dotted 107 quad. Multiple entries can be arranged in a comma- 108 separated list. 110 policy.txt: The TXT record, if any. Multiple records are 111 concatenated as usual. See Section 3 for the resulting 112 content and query options. 114 The result of the method states how the query did, up to the 115 interpretation of the result. In particular, some DNSBLs are known 116 to return special codes to signal over quota, for example 117 127.0.0.255. If the result producer cannot interpret that value, 118 that case results in a false positive. 120 pass: The query successfully returned applicable records. The 121 sender is whitelisted, up to differing interpretation. 123 none: The query worked but yielded no record, or returned 124 NXDOMAIN, so the sender is not whitelisted. 126 temperror: The DNS evaluation could not be completed due to some 127 error that is likely transient in nature, such as a 128 temporary DNS error, e.g., a DNS RCODE of 2, commonly 129 known as SERVFAIL, or other error condition resulted. A 130 later attempt may produce a final result. 132 permerror: The DNS evaluation cannot work because test entries don't 133 work, that is, DNSWL is broken, or because queries are 134 overquota, e.g., a DNS RCODE of 5, commonly known as 135 REFUSED, or a DNSWL-specific policy.ip was returned. A 136 later attempt is unlikely to produce a final result. 137 Human intervention is required. 139 3. TXT Record Contents 141 According to [RFC5782], TXT records describe the reason why IP 142 addresses are listed in a DNSWL. The TXT record is useful if it 143 contains the domain name(s). The domain name would correspond to the 144 DNS domain name used by or within the ADMD operating the relevant 145 MTA, sometimes called the "organizational domain". In that case, the 146 authentication provided by this method is equivalent to a DKIM 147 signature ([RFC6376]) or an SPF check host ([RFC7208]). When no 148 domain names are known, some DNSWLs use a subdomain of .INVALID 149 ([RFC2606]) where the leftmost label hints at why an address is 150 whitelisted given that its operating organization is not known. If 151 the TXT record(s) contain non-ASCII characters, they need to be 152 encoded as appropriate. 154 Queries with a QTYPE of ANY may lead to inconsistent replies, 155 depending on the cache status. In addition, ANY is not "all", and 156 the provisions for queries that have QTYPE=ANY ([RFC8482]) don't 157 cover DNSxLs. A mail server can issue two simultaneous queries, A 158 and TXT. Otherwise, a downstream filter can issue a TXT query on its 159 own if it knows that an A query was successful, and that the DNSWL 160 serves useful TXT records. It is unlikely that a TXT record exist if 161 a query for QTYPE A failed. 163 4. IANA Considerations 165 There is a registry of Email Authentication Methods. The method 166 described in this document is referred by Table 1, along with its 167 ptype.property values. 169 +--------+--------+----------+-------------------+--------+---------+ 170 | Method | ptype | property | Value | Status | Version | 171 +--------+--------+----------+-------------------+--------+---------+ 172 | dnswl | dns | zone | DNSWL publicly | active | 1 | 173 | | | | accessible query | | | 174 | | | | root domain | | | 175 | dnswl | policy | ip | type A response | active | 1 | 176 | | | | received (or | | | 177 | | | | comma-separated | | | 178 | | | | list thereof) | | | 179 | dnswl | policy | txt | type TXT query | active | 1 | 180 | | | | response | | | 181 +--------+--------+----------+-------------------+--------+---------+ 183 Table 1: Email Authentication Method 185 A new ptype, "dns" is introduced in Table 2. It is meant to be used 186 for properties related to the Domain Name System (DNS [RFC1034]). 188 +-------+------------+----------------------------------------------+ 189 | ptype | Definition | Description | 190 +-------+------------+----------------------------------------------+ 191 | dns | [this doc] | The property being reported belongs to the | 192 | | | Domain Name System | 193 +-------+------------+----------------------------------------------+ 195 Table 2: Email Authentication Property Type 197 This method reuses four of the values already defined in the Email 198 Authentication Result Names associated registry. They are listed in 199 Table 3. 201 +---------+-----------+------------------------------------+--------+ 202 | Auth | Code | Specification | Status | 203 | Method | | | | 204 +---------+-----------+------------------------------------+--------+ 205 | dnswl | pass | Sender is whitelisted, up to | active | 206 | | | returned code interpretation | | 207 | dnswl | none | NXDOMAIN or no record, sender is | active | 208 | | | not whitelisted | | 209 | dnswl | temperror | Transient DNS error during the | active | 210 | | | query | | 211 | dnswl | permerror | Query cannot work, human | active | 212 | | | intervention needed | | 213 +---------+-----------+------------------------------------+--------+ 215 Table 3: Email Authentication Result Names 217 5. Security Considerations 219 All of the considerations described in Section 7 of [RFC8601] apply. 221 In addition, the usual caveats apply about importing text from 222 external online sources. Although queried DNSWLs are well known, 223 trusted entities, it is suggested that TXT records be reported only 224 if, upon inspection, their content is deemed actually actionable. 226 6. References 228 6.1. Normative References 230 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 231 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 232 . 234 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 235 DOI 10.17487/RFC5782, February 2010, . 238 [RFC8601] Kucherawy, M., "Message Header Field for Indicating 239 Message Authentication Status", RFC 8601, 240 DOI 10.17487/RFC8601, August 2019, . 243 6.2. Informative References 245 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 246 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 247 . 249 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 250 DOI 10.17487/RFC5598, July 2009, . 253 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 254 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 255 RFC 6376, DOI 10.17487/RFC6376, September 2011, 256 . 258 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 259 Authorizing Use of Domains in Email, Version 1", RFC 7208, 260 DOI 10.17487/RFC7208, April 2014, . 263 [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, 264 "Providing Minimal-Sized Responses to DNS Queries That 265 Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 266 2019, . 268 Appendix A. Example 269 Delivered-To: recipient@example.org 270 Return-Path: 271 Authentication-Results: mta.example.org; 272 dkim=pass (whitelisted) header.i=@example.com 273 Authentication-Results: mta.example.org; 274 dnswl=pass dns.zone=list.dnswl.example 275 policy.ip=127.0.10.1 276 policy.txt="fwd.example http://fwd.example/s?s=100" 277 Received-SPF: fail (Address does not pass Sender Policy Framework) 278 client-ip=192.0.2.1; 279 envelope-from="sender@example.com"; 280 helo=mailout.fwd.example; 281 receiver=mta.example.org; 282 Received: from mailout.fwd.example (mailout.fwd.example [192.0.2.1]) 283 (TLS: TLSv1/SSLv3,128bits,ECDHE-RSA-AES128-GCM-SHA256) 284 by mta.example.org with ESMTPS; Mon, 04 Apr 2016 23:11:24 +0200 285 id 00000000005DC044.000000005702D87C.000007FC 287 Trace fields added at the top of the header by multiple agents at 288 various stages during processing at the final MTA 290 The message went through a third party, fwd.example, which forwarded 291 it to the final MTA. Such mail path was not arranged beforehand with 292 the involved MTAs, it emerged spontaneously. This message would not 293 have made it to the target without whitelisting, because: 295 o the author domain published a strict SPF policy (-all), 297 o the forwarder did not alter the bounce address, and 299 o the target usually honors reject-on-fail, according to Section 8.4 300 of [RFC7208]. 302 However, the target also implemented the last paragraph of 303 Appendix D.3 of [RFC7208]. Rather than rejecting the message 304 outright before DATA, the MTA received it, recorded the SPF fail 305 result, and indicated the local policy mechanism which was applied in 306 order to override that result. Subsequent filtering detected no 307 malware and verified DKIM [RFC6376]. It would still have been 308 possible to reject the message, based on its content. It is at these 309 later stages, after receiving the body and also during delivery, that 310 a deeper knowledge of the policy values obtained from dnswl.example 311 can allow weighting that score against other factors. 313 Author's Address 315 Alessandro Vesely 316 v. L. Anelli 13 317 Milano, MI 20122 318 IT 320 Email: vesely@tana.it