idnits 2.17.1 draft-vesely-authmethod-dnswl-16.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 6 instances 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 (April 30, 2020) is 1456 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 April 30, 2020 4 Intended status: Informational 5 Expires: November 1, 2020 7 DNSWL Email Authentication Method Extension 8 draft-vesely-authmethod-dnswl-16 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's IP address in a DNS whitelist. This document is provided 15 for information in case the method is seen in the field, as well as 16 to suggest a useful practice and register the relevant keywords. 18 This document does not consider black lists. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 1, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Method Details . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. TXT Record Contents . . . . . . . . . . . . . . . . . . . . . 5 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 55 4.1. Email Authentication Methods . . . . . . . . . . . . . . 6 56 4.2. Email Authentication Property Type . . . . . . . . . . . 6 57 4.3. Email Authentication Result Names . . . . . . . . . . . . 7 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 5.1. Over Quota Signaling . . . . . . . . . . . . . . . . . . 7 60 5.2. Security of DNSSEC Validation . . . . . . . . . . . . . . 7 61 5.3. Inherited Security Considerations . . . . . . . . . . . . 8 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 6.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10 66 Appendix B. Known Implementation . . . . . . . . . . . . . . . . 12 67 Appendix C. Future possibilities of the 'dns' ptype . . . . . . 13 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 70 1. Introduction 72 One of the many checks that mail servers carry out is to query domain 73 name system whitelists (DNSWL). That method is fully discussed in 74 [RFC5782]. The DNS [RFC1034] lookup is based on the connecting 75 client's IP address, IPv4 or IPv6, and returns zero or more A 76 records. The latter are IPv4 IP addresses in the range 127.0.0.0/8. 77 Depending on the query, TXT records with varying content can also be 78 retrieved. Query examples are given in Appendix A. 80 Since the IP address is known as soon as the connection is accepted, 81 this check can occur very early in an SMTP transaction. Its result 82 can be used to counterweight policies that typically occur at early 83 stages too, such as the Sender Policy Framework (SPF, the last 84 paragraph of Appendix D.3 of [RFC7208] is also illustrated in 85 Appendix A). In addition, the result of a DNSWL lookup can also be 86 used at later stages; for example, a delivery agent can use it to 87 learn the trustworthiness of a mail relay in order to estimate the 88 spamminess of an email message. The latter possibility needs a place 89 to collect query results for downstream use, which is precisely what 90 the Authentication-Results header field aims at providing. 92 Results often contain additional data, encoded according to DNSWL- 93 specific criteria. The method described in this document considers 94 only whitelists --one of the major branches described by [RFC5782]. 95 There are also black/block lists, DNSBL, and combined lists. Since 96 they all have the same structure, the abbreviation DNSxL is used to 97 mean any. The core procedures of a mail transfer agent (MTA) tend to 98 be quite general, leaving particular cases to be handled by add-on 99 modules. In the case of combined lists, the boundary MTA (see 100 [RFC5598]) which carries out the check and possibly stores the result 101 has to be able to discern at least the color of each entry, as that 102 is required to make accept/reject decisions. This document provides 103 for storing the result when the DNSxL record to be reported is a 104 whitelisting one. 106 Data conveyed in A and TXT records can be stored as method's 107 properties. The meaning of such data varies widely at the mercy of 108 the list operator, hence the queried zone has to be stored as well. 109 Mail site operators who configure their MTAs to query specific DNWSLs 110 marry the policies of those lists, as, in effect, they become 111 tantamount to local policies, albeit outsourced. Downstream agents 112 who know DNSWL-specific encoding and understand the meaning of that 113 datum can use it to make delivery or display decisions. For example, 114 a mail filter which detected heuristic evidence of a scam can 115 counterweight such information with the trustworthiness score encoded 116 in the A response, so as to protect agains false positives. MUAs can 117 display those results, or use them to decide how to report abusive 118 messages, if configured to do so. 120 This document describes a usage of TXT fields consistent with other 121 authentication methods, namely to serve the domain name in the TXT 122 record. That way, a downstream filter could also consider whether 123 the sending agent is aligned with the author domain, with semantics 124 similar to [RFC7489]. 126 At the time of this writing, this method is implemented by 127 [Courier-MTA]. An outline of the implementation is given in 128 Appendix B. 130 2. Method Details 132 The result of the method states how the query did, up to the 133 interpretation of the returned data. 135 The method has four possible results: 137 pass: The query successfully returned applicable records. This 138 result is usually accompanied by one or both of the 139 policy properties described below. Since the list is 140 configured as a DNSWL, agents unable to interpret list- 141 specifc properties can still derive a positive value from 142 the fact that the sender is whitelisted. 143 none: The query worked but yielded no A record, or returned 144 NXDOMAIN, so the sender is not whitelisted. 146 temperror: The DNS evaluation could not be completed due to some 147 error that is likely transient in nature, such as a 148 temporary DNS error, e.g., a DNS RCODE of 2, commonly 149 known as SERVFAIL, or other error condition. A later 150 attempt may produce a final result. 151 permerror: The DNS evaluation cannot work because test entries don't 152 work, that is, DNSWL is broken, or because queries are 153 over quota, e.g., a DNS RCODE of 5, commonly known as 154 REFUSED, or a DNSWL-specific property (policy.ip, defined 155 below) with the same meaning. A later attempt is 156 unlikely to produce a final result. Human intervention 157 is required. 159 Note that there is no "fail" result. 161 The following ptype.property items define how the data provided by 162 the whitelist lookup can be saved. 164 dns.zone: DNSWL query root domain, which defines the meaning of the 165 policy.ip property below. Note that an MTA can use a 166 local mirror with a different name. The name stored here 167 has to be the best available reference for all 168 foreseeable downstream consumers. Setting dns.zone to 169 the global zone makes the result intelligible even if the 170 message is handed outside of the internal network. 171 policy.ip: The bit mask value received in type A response, in dotted 172 quad notation. Multiple entries can be arranged in a 173 quoted, comma separated list (quotes are necessary 174 because commas are not allowed in a token.) 175 policy.txt: The TXT record, if any. Multiple records are 176 concatenated in the usual way (explained, for example, in 177 Section 3.3 of [RFC7208]). See Section 3 for the 178 resulting content and query options. 179 dns.sec: This is a generic property stating whether the relevant 180 data was validated using DNSSEC ([RFC4033]). For the 181 present method, the relevant data consists of the 182 reported policy properties above, or, if the method 183 result is "none", their non-existence. This property has 184 three possible values: 186 yes: DNSSEC validation confirms the integrity of data. 187 Section 5.2 considers how that is related to the DNS 188 response. 189 no: The data are not signed. See Section 5.2. 190 na: Not applicable. No DNSSEC validation can be 191 performed, possibly because the lookup is run 192 through a different means than a security-aware DNS 193 resolver. This does not necessarily imply less 194 security. In particular, "na" is used if the data 195 were downloaded in bulk and then loaded on a local 196 nameserver --which is the case of an MTA querying a 197 local zone different from the reported dns.zone. 198 DNS errors, including validation errors, can also 199 report "na". This is also the value assumed by 200 default. 202 3. TXT Record Contents 204 According to [RFC5782], TXT records describe the reason why IP 205 addresses are listed in a DNSWL. An example of a DNSWL whose TXT 206 records contain the domain name of the organization assignee of the 207 sending IP is given in Appendix B. The domain name would correspond 208 to the DNS domain name used by or within the administrative domain 209 (ADMD) operating the relevant MTA, sometimes called the 210 "organizational domain". In that case, the authentication provided 211 by this method is equivalent to a DKIM signature ([RFC6376]) or an 212 SPF check host ([RFC7208]), if the DNSWL is trusted. 214 According to a DNSWL's policy, attributing responsibility of an IP 215 address to an organization may require something more than a mere PTR 216 record consistency. If no domain names can be responsibly associated 217 to a given IP address, for example because the IP address was added 218 without direct involvement of the organization concerned, DNSWLs can 219 use a subdomain of .INVALID ([RFC2606]) where the leftmost label 220 hints at why an address is whitelisted. For example, if the address 221 192.0.2.38 was added by the list managers solely based on their 222 knowledge, the corresponding TXT record might be 223 AUTOPROMOTED.INVALID, so as to avoid to explicitly identify an entity 224 who didn't opt-in. 226 Following the example of Multicast DNS (see the second paragraph of 227 Section 16 of [RFC6762]) names containing non-ASCII characters can be 228 encoded in UTF-8 [RFC3629] using the normalization form canonical 229 composition (NFC) as described in Unicode Format for Network 230 Interchange ([RFC5198]). Inclusion of unaltered UTF-8 TXT values in 231 the header entails an environment compatible with EAI [RFC6530]. 233 DNS queries with a QTYPE of ANY may lead to inconsistent replies, 234 depending on the cache status. In addition, ANY is not "all", and 235 the provisions for queries that have QTYPE=ANY ([RFC8482]) don't 236 cover DNSxLs. A mail server can issue two simultaneous queries, A 237 and TXT. Otherwise, a downstream filter can issue a TXT query on its 238 own, if it knows that an A query was successful and that the DNSWL 239 serves useful TXT records. It is unlikely that TXT records exist if 240 a query for QTYPE A brought a result of none. 242 4. IANA Considerations 244 IANA maintains the "Email Authentication Parameters" registry with 245 several subregistries. IANA is requested to make assignments as set 246 out in the following sections. 248 4.1. Email Authentication Methods 250 IANA is requested to create four new entries in the "Email 251 Authentication Methods" registry as follows. 253 ------+----------+------+--------+-------------------+------+------- 254 Method|Definition|ptype |property| Value |Status|Version 255 ------+----------+------+--------+-------------------+------+------- 256 dnswl |[This.I-D]|dns |zone | DNSWL publicly |active| 1 257 | | | | accessible query | | 258 | | | | root domain | | 259 dnswl |[This.I-D]|policy|ip | type A response |active| 1 260 | | | | received (or a | | 261 | | | | quoted, comma | | 262 | | | | separated list | | 263 | | | | thereof) | | 264 dnswl |[This.I-D]|policy|txt | type TXT query |active| 1 265 | | | | response | | 266 dnswl |[This.I-D]|dns |sec | one of "yes" for |active| 1 267 | | | | DNSSEC | | 268 | | | | authenticated | | 269 | | | | data, "no" for | | 270 | | | | not signed, or | | 271 | | | | "na" for not | | 272 | | | | applicable | | 273 ------+----------+------+--------+-------------------+------+------- 275 4.2. Email Authentication Property Type 277 IANA is requested to create a new entry in the "Email Authentication 278 Property Types" registry as follows. 280 +-------+------------+----------------------------------------------+ 281 | ptype | Definition | Description | 282 +-------+------------+----------------------------------------------+ 283 | dns | [This.I-D] | The property being reported belongs to the | 284 | | | Domain Name System | 285 +-------+------------+----------------------------------------------+ 287 4.3. Email Authentication Result Names 289 IANA is requested to create four new entries in the "Email 290 Authentication Result Names" registry as follows. 292 +-------------+-----------+---------------+--------+ 293 | Auth Method | Code | Specification | Status | 294 +-------------+-----------+---------------+--------+ 295 | dnswl | pass | [This.I-D] | active | 296 | | | | | 297 | dnswl | none | [This.I-D] | active | 298 | | | | | 299 | dnswl | temperror | [This.I-D] | active | 300 | | | | | 301 | dnswl | permerror | [This.I-D] | active | 302 +-------------+-----------+---------------+--------+ 304 5. Security Considerations 306 5.1. Over Quota Signaling 308 Some DNSWLs which provide for free access below a given quota are 309 known to return special codes to signal over quota, for example 310 127.0.0.255. If the MTA cannot interpret that value, that case 311 results in a false positive. It can accept messages that it would 312 otherwise reject. A DNSWL-specific module would realize the fact and 313 call for human intervention. 315 Returning an RCODE 5 (REFUSED) conveys the concept that the query is 316 "unauthorized", and human intervention required. 318 5.2. Security of DNSSEC Validation 320 The dns.sec property is meant to be as secure as DNSSEC results. It 321 makes sense to use it in an environment where the DNSSEC validation 322 can succeed. 324 Section 7 of [RFC4033] examines various ways of setting up a stub 325 resolver which either validates DNSSEC locally or trusts the 326 validation provided through a secure channel. For a different class, 327 it is possible to set up a dedicated, caching, dnssec-enabled 328 resolver reachable by the mail server through interprocess 329 communication on 127.0.0.1. In such cases, the property dns.sec=yes 330 corresponds to the Authenticated Data (AD) bit in the DNS response 331 header. 333 When the response contains no DNSSEC data, a security-aware resolver 334 seeks a signed proof of the non-existence of a DS record, at some 335 delegation point. If no error is returned, the zone is unsigned and 336 dns.sec=no can be set. According to the Security Considerations 337 Section of [RFC3225]: The absence of DNSSEC data in response to a 338 query with the DO bit set must not be taken to mean no security 339 information is available for that zone as the response may be forged 340 or a non-forged response of an altered (DO bit cleared) query. 342 If the application verifies the DNSSEC signatures on its own, it 343 effectively behaves like a validating stub resolver, and hence can 344 set dns.sec correspondingly. 346 When the data are downloaded in bulk and made available on a trusted 347 channel without using DNSSEC, set dns.sec=na or not at all. DNSWL 348 who publish bulk versions of their data can also sign that data, for 349 example using OpenPGP ([RFC4880]). It is the responsibility of 350 system administrators to authenticate the data by downloading and 351 validating the signature. The result of such validation is not 352 reported using dns.sec. 354 5.3. Inherited Security Considerations 356 For DNSSEC, the considerations of Section 12 of [RFC4033] apply. 358 All of the considerations described in Section 7 of [RFC8601] apply. 359 That includes securing against tampering all the channels after the 360 production of this Authentication-Results header field. 362 In addition, the usual caveats apply about importing text from 363 external online sources. Although queried DNSWLs are well known, 364 trusted entities, it is suggested that TXT records be reported only 365 if, upon inspection, their content is deemed actually actionable, and 366 their format compatible with the computing environment. 368 6. References 370 6.1. Normative References 372 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 373 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 374 . 376 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 377 DOI 10.17487/RFC5782, February 2010, . 380 [RFC8601] Kucherawy, M., "Message Header Field for Indicating 381 Message Authentication Status", RFC 8601, 382 DOI 10.17487/RFC8601, May 2019, . 385 6.2. Informative References 387 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 388 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 389 . 391 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 392 RFC 3225, DOI 10.17487/RFC3225, December 2001, 393 . 395 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 396 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 397 2003, . 399 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 400 Rose, "DNS Security Introduction and Requirements", 401 RFC 4033, DOI 10.17487/RFC4033, March 2005, 402 . 404 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 405 Thayer, "OpenPGP Message Format", RFC 4880, 406 DOI 10.17487/RFC4880, November 2007, . 409 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 410 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 411 . 413 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 414 DOI 10.17487/RFC5598, July 2009, . 417 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 418 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 419 RFC 6376, DOI 10.17487/RFC6376, September 2011, 420 . 422 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 423 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 424 February 2012, . 426 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 427 DOI 10.17487/RFC6762, February 2013, . 430 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 431 Authorizing Use of Domains in Email, Version 1", RFC 7208, 432 DOI 10.17487/RFC7208, April 2014, . 435 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 436 Message Authentication, Reporting, and Conformance 437 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 438 . 440 [RFC8460] Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., 441 and M. Risher, "SMTP TLS Reporting", RFC 8460, 442 DOI 10.17487/RFC8460, September 2018, . 445 [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, 446 "Providing Minimal-Sized Responses to DNS Queries That 447 Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 448 2019, . 450 [Courier-MTA] 451 "Courier Mail Server", . 453 [dnswl.org] 454 "DNSWL.ORG", . 456 Appendix A. Example 457 Delivered-To: recipient@example.org 458 Return-Path: 459 Authentication-Results: mta.example.org; 460 dkim=pass (whitelisted) header.i=@example.com 461 Authentication-Results: mta.example.org; 462 dnswl=pass dns.zone=list.dnswl.example dns.sec=na 463 policy.ip=127.0.10.1 464 policy.txt="fwd.example https://dnswl.example/?d=fwd.example" 465 Received-SPF: fail (Address does not pass Sender Policy Framework) 466 client-ip=2001:db8::2:1; 467 envelope-from="sender@example.com"; 468 helo=mail.fwd.example; 469 receiver=mta.example.org; 470 Received: from mail.fwd.example (mail.fwd.example [2001:db8::2:1]) 471 (TLS: TLSv1/SSLv3,128bits,ECDHE-RSA-AES128-GCM-SHA256) 472 by mta.example.org with ESMTPS; Thu, 03 Oct 2019 19:23:11 +0200 473 id 00000000005DC044.000000005702D87C.000007FC 475 Trace fields at the top of the header 477 The message went through a third party, fwd.example, which forwarded 478 it to the final MTA. Such mail path was not arranged beforehand with 479 the involved MTAs, it emerged spontaneously. This message would not 480 have made it to the target without whitelisting, because: 482 o the author domain published a strict SPF policy (-all), 483 o the forwarder did not alter the bounce address, and 484 o the target usually honors reject-on-fail, according to Section 8.4 485 of [RFC7208]. 487 However, the target also implemented the last paragraph of 488 Appendix D.3 of [RFC7208]. Its behavior hinges on the following DNS 489 entries: 491 1.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.b.8.2.0.0.1. 492 list.dnswl.example. 493 IN A 127.0.10.1 494 IN TXT "fwd.example https://dnswl.example/?d=fwd.example" 496 DNS resource records for 2001:db8::2:1 497 (line breaks for editorial reasons) 499 If mail.fwd.example had connected from address 192.0.2.1, then the 500 query name would have been 1.2.0.192.list.dnswl.example. See full 501 description in [RFC5782] 503 At connection time, because the remote IP address is whitelisted, the 504 target MTA did not reject the message before DATA. Instead, it 505 recorded the SPF fail result, and indicated the local policy 506 mechanism which was applied in order to override that result. 507 Subsequent filtering verified DKIM [RFC6376]. 509 At later stages, mail filters can reject or quarantine the message 510 based on its content. A deeper knowledge of the policy values 511 obtained from dnswl.example allows to interpret the values of 512 policy.ip and weight them against other factors so as to make better 513 decisions. 515 Appendix B. Known Implementation 517 Implementation details mentioned in this section have been stable for 518 several years. Yet, this description is necessarily superficial, 519 version dependent, and subject to change. 521 [Courier-MTA] can be configured to lookup DNSBL and DNSWL, with 522 similar command line switches: 524 -block=zone[=displayzone][,var[/n.n.n.n][,msg]] 525 -allow=zone[=displayzone][,var[/n.n.n.n[,]]] 527 zone is the zone to be queried. 529 displayzone is only used for -allow, it is the value to be set in the 530 dns.zone property. 532 var stands for the environment variable whose existence triggers a 533 special action. The default variable names result in a conventional 534 behavior implemented by Courier-MTA. By setting different 535 environment variables, users can customize the behavior. 536 Conventional behavior differs widely between -block and -allow. The 537 former rejects the message, the latter produces Authentication- 538 Results header fields. 540 The n.n.n.n IP address requires a precise A record response. If not 541 given, any response results in setting the corresponding variable. 542 If given, variables are set only if the response matches exactly. 543 Such syntax provides for a very limited interpretation of the 544 information encoded in A records. However, it is considered to be 545 too complicated already. Even specifying a range, an enumeration of 546 values, or a regular expression would require something beyond what a 547 normal user would be willing to manage. 549 Finally, the trailing message, which overrides the 5xx SMTP reply for 550 -block, is not used for -allow, except that its mere presence 551 requires to query TXT records to be registered in policy.txt. 553 SPF is part of Courier-MTA's core. It is configured separately, and 554 provides for an "allowok" keyword to indicate to override rejection 555 in case of SPF failure and -allow whitelisting. 557 A customary whitelist is [dnswl.org]. It serves A records encoded as 558 follows: 560 1st octect: 127. 561 2nd octect: 0. 562 3rd octect: Category of business, 15 values. 563 4th octect: Trusworthiness/score, 4 values. 565 They also serve TXT records containing the domain name followed by an 566 URL pointing to further info about the relevant organization, such as 567 what other IP addresses of theirs are being whitelisted. They don't 568 use UTF-8. 570 dnswl.org provides for free registration and free access below 571 100,000 queries per day. They use the special return code 572 127.0.0.255 exemplified above to signal over quota. Although 573 Courier-MTA itself does not recognize it, it has a mail filter 574 (zdkimfilter, named after its main usage) where recognition of that 575 code, as well as that of trusworthiness in the 4th octect are hard- 576 coded. 578 Appendix C. Future possibilities of the 'dns' ptype 580 The description of the new ptype proposed in Section 4.2 just says 581 "The property being reported belongs to the Domain Name System". 582 That definition can broadly include any tag found in a domain's TXT 583 record. For example, auth methods designers can agree that within a 584 resinfo of a given method, any dns ptype refers to tags in the 585 relevant DNS record, unless otherwise specified. So one could have, 586 say: 588 Authentication-Results: example.com; 589 spf=pass smtp.mailfrom=example.net dns.sec=y; 590 dkim=pass header.i=@example.org header.b=jIvx30NG dns.s=tlsrpt 592 While dns.sec is defined above, albeit not for the spf method, the 593 use of tlsrpt in the DKIM record is exemplified in Section 3 of 594 [RFC8460]. The tag s= is part of the DKIM TXT record, not to be 595 confused with the selector s=, which is part of a DKIM-Signature. 596 Just like the latter can be reported as header.s because the DKIM 597 header field is in the message header, it may make sense to report 598 the former as dns.s because the DKIM DNS record is in the DNS. 600 NOTE: This is only a hint at what may become a consistent naming 601 convention around the new ptype. In any case, any new property using 602 this ptype requires its own formal definition. This document does 603 NOT define the property dns.s=, let alone the service tlsrpt. 605 Author's Address 607 Alessandro Vesely 608 v. L. Anelli 13 609 Milano, MI 20122 610 IT 612 Email: vesely@tana.it