idnits 2.17.1 draft-vesely-authmethod-dnswl-15.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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 335: '...h the DO bit set MUST NOT be taken to ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 30, 2020) is 1486 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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 March 30, 2020 4 Intended status: Informational 5 Expires: October 1, 2020 7 DNSWL Email Authentication Method Extension 8 draft-vesely-authmethod-dnswl-15 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 October 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/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. Now, the core procedures of a mail transfer agent (MTA) 98 tend to be quite general, leaving particular cases to be handled by 99 add-on modules. In the case of combined lists, the boundary MTA (see 100 [RFC5598]) which carries out the check and possibly stores the 101 result, has to be able to discern at least the color of each entry, 102 as that is required to make accept/reject decisions. This document 103 provides for storing the result when the DNSxL record to be reported 104 is a 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 data, can use it to make delivery or display decisions. For example, 114 a mail filter which detected heuristic evidence of 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 the policy 139 properties described below. Agents unable to interpret 140 those properties can still derive a positive value from 141 the fact that the sender is whitelisted. 142 none: The query worked but yielded no A record, or returned 143 NXDOMAIN, so the sender is not whitelisted. 145 temperror: The DNS evaluation could not be completed due to some 146 error that is likely transient in nature, such as a 147 temporary DNS error, e.g., a DNS RCODE of 2, commonly 148 known as SERVFAIL, or other error condition. A later 149 attempt may produce a final result. 150 permerror: The DNS evaluation cannot work because test entries don't 151 work, that is, DNSWL is broken, or because queries are 152 over quota, e.g., a DNS RCODE of 5, commonly known as 153 REFUSED, or a DNSWL-specific policy.ip with the same 154 meaning. A later attempt is unlikely to produce a final 155 result. Human intervention is required. 157 Note that there is no fail result. 159 The following ptype.property items define how the data provided by 160 the whitelist lookup can be saved. 162 dns.zone: DNSWL query root domain, which defines the meaning of the 163 policy.ip property below. Note that an MTA can use a 164 local mirror with a different name. The name stored here 165 has to be the best available reference for all 166 foreseeable downstream consumers. If the message is 167 handed outside the internal network, dns.zone had better 168 be the global zone. 169 policy.ip: The bit mask value received in type A response, in dotted 170 quad. Multiple entries can be arranged in a quoted, 171 comma separated list (quotes are necessary because commas 172 are not allowed in a token.) 173 policy.txt: The TXT record, if any. Multiple records are 174 concatenated in the usual way (explained, for example, in 175 Section 3.3 of [RFC7208]). See Section 3 for the 176 resulting content and query options. 177 dns.sec: This is a generic property stating whether the relevant 178 data was validated using DNSSEC ([RFC4033]). For the 179 present method, the relevant data consists of the 180 reported policy properties above, or, if the method 181 result is "none", their non-existence. This property has 182 three possible values: 184 yes: DNSSEC validation confirms the integrity of data. 185 Section 5.2 considers how that is related to the DNS 186 response. 187 no: The data is not signed. See Section 5.2. 188 na: Not applicable. No DNSSEC validation can be 189 performed, possibly because the lookup is run 190 through a different means than a security-aware DNS 191 resolver. This does not necessarily imply less 192 security. In particular, "na" is used if the data 193 was downloaded in bulk and then loaded on a local 194 nameserver --which is the case of an MTA querying a 195 local zone different from the reported dns.zone. 196 DNS errors, including validation errors, can also 197 report "na". This is also the value assumed by 198 default. 200 3. TXT Record Contents 202 According to [RFC5782], TXT records describe the reason why IP 203 addresses are listed in a DNSWL. The TXT record is useful if it 204 contains the domain names. The domain name would correspond to the 205 DNS domain name used by or within the administrative domain (ADMD) 206 operating the relevant MTA, sometimes called the "organizational 207 domain". In that case, the authentication provided by this method is 208 equivalent to a DKIM signature ([RFC6376]) or an SPF check host 209 ([RFC7208]), if the DNSWL is trusted. 211 According to a DNSWL's policy, attributing responsibility of an IP 212 address to an organization may require something more than a mere PTR 213 record consistency. If no domain names can be responsibly associated 214 to a given IP address, for example because the IP address was added 215 without direct involvement of the organization concerned, DNSWLs can 216 use a subdomain of .INVALID ([RFC2606]) where the leftmost label 217 hints at why an address is whitelisted. For example, if the address 218 192.0.2.38 was added by the list managers solely based on their 219 knowledge, the corresponding TXT record might be 220 AUTOPROMOTED.INVALID, so as to avoid to explicitly identify an entity 221 who didn't opt-in. 223 Following the example of Multicast DNS (see the second paragraph of 224 Section 16 of [RFC6762]) names containing non-ASCII characters can be 225 encoded in UTF-8 [RFC3629] using the normalization form canonical 226 composition (NFC) as described in Unicode Format for Network 227 Interchange ([RFC5198]). Inclusion of unaltered UTF-8 TXT values in 228 the header entails an environment compatible with EAI [RFC6530]. 230 DNS queries with a QTYPE of ANY may lead to inconsistent replies, 231 depending on the cache status. In addition, ANY is not "all", and 232 the provisions for queries that have QTYPE=ANY ([RFC8482]) don't 233 cover DNSxLs. A mail server can issue two simultaneous queries, A 234 and TXT. Otherwise, a downstream filter can issue a TXT query on its 235 own, if it knows that an A query was successful and that the DNSWL 236 serves useful TXT records. It is unlikely that TXT records exist if 237 a query for QTYPE A brought a result of none. 239 4. IANA Considerations 241 IANA maintains the "Email Authentication Parameters" registry with 242 several subregistries. IANA is requested to make assignments as set 243 out in the following sections. 245 4.1. Email Authentication Methods 247 IANA is requested to create four new entries in the "Email 248 Authentication Methods" registry as follows. 250 ------+----------+------+--------+-------------------+------+------- 251 Method|Definition|ptype |property| Value |Status|Version 252 ------+----------+------+--------+-------------------+------+------- 253 dnswl |[This.I-D]|dns |zone | DNSWL publicly |active| 1 254 | | | | accessible query | | 255 | | | | root domain | | 256 dnswl |[This.I-D]|policy|ip | type A response |active| 1 257 | | | | received (or a | | 258 | | | | quoted, comma | | 259 | | | | separated list | | 260 | | | | thereof) | | 261 dnswl |[This.I-D]|policy|txt | type TXT query |active| 1 262 | | | | response | | 263 dnswl |[This.I-D]|dns |sec | one of "yes" for |active| 1 264 | | | | DNSSEC | | 265 | | | | authenticated | | 266 | | | | data, "no" for | | 267 | | | | not signed, or | | 268 | | | | "na" for not | | 269 | | | | applicable | | 270 ------+----------+------+--------+-------------------+------+------- 272 4.2. Email Authentication Property Type 274 IANA is requested to create a new entry in the "Email Authentication 275 Property Types" registry as follows. 277 +-------+------------+----------------------------------------------+ 278 | ptype | Definition | Description | 279 +-------+------------+----------------------------------------------+ 280 | dns | [This.I-D] | The property being reported belongs to the | 281 | | | Domain Name System | 282 +-------+------------+----------------------------------------------+ 284 4.3. Email Authentication Result Names 286 IANA is requested to create four new entries in the "Email 287 Authentication Result Names" registry as follows. 289 +-------------+-----------+---------------+--------+ 290 | Auth Method | Code | Specification | Status | 291 +-------------+-----------+---------------+--------+ 292 | dnswl | pass | [This.I-D] | active | 293 | | | | | 294 | dnswl | none | [This.I-D] | active | 295 | | | | | 296 | dnswl | temperror | [This.I-D] | active | 297 | | | | | 298 | dnswl | permerror | [This.I-D] | active | 299 +-------------+-----------+---------------+--------+ 301 5. Security Considerations 303 5.1. Over Quota Signaling 305 Some DNSWLs which provide for free access below a given quota, are 306 known to return special codes to signal over quota, for example 307 127.0.0.255. If the MTA cannot interpret that value, that case 308 results in a false positive. It will accept messages having spf=fail 309 if configured to do so. A DNSWL-specific module would realize the 310 fact and call for human intervention. 312 Returning an RCODE 5 (REFUSED) conveys the concept that the query is 313 "unauthorized", and human intervention required. 315 5.2. Security of DNSSEC Validation 317 The dns.sec property is meant to be as secure as DNSSEC results. It 318 makes sense to use it in an environment where the DNSSEC validation 319 can succeed. 321 Section 7 of [RFC4033] examines various ways of setting up a stub 322 resolver which either validates DNSSEC locally or trusts the 323 validation provided through a secure channel. For a different class, 324 it is possible to set up a dedicated, caching, dnssec-enabled 325 resolver reachable by the mail server through interprocess 326 communication on 127.0.0.1. In such cases, the property dns.sec=yes 327 corresponds to the Authenticated Data (AD) bit in the DNS response 328 header. 330 When the response contains no DNSSEC data, a security-aware resolver 331 seeks a signed proof of the non-existence of a DS record, at some 332 delegation point. If no error is returned, the zone is unsigned and 333 dns.sec=no can be set. Quoting the Security Considerations 334 Section of [RFC3225]: The absence of DNSSEC data in response to a 335 query with the DO bit set MUST NOT be taken to mean no security 336 information is available for that zone as the response may be forged 337 or a non-forged response of an altered (DO bit cleared) query. 339 If the application verifies the DNSSEC signatures on its own, it 340 effectively behaves like a validating stub resolver, and hence can 341 set dns.sec correspondingly. 343 When the data is downloaded in bulk and made available on a trusted 344 channel without using DNSSEC, set dns.sec=na or not at all. DNSWL 345 who publish bulk versions of their data can also sign that data, for 346 example using OpenPGP ([RFC4880]). It is the responsibility of 347 system administrators to authenticate the data by downloading and 348 validating the signature. The result of such validation is not 349 reported using dns.sec. 351 5.3. Inherited Security Considerations 353 For DNSSEC, the considerations of Section 12 of [RFC4033] apply. 355 All of the considerations described in Section 7 of [RFC8601] apply. 356 That includes securing against tampering all the channels after the 357 production of this Authentication-Results header field. 359 In addition, the usual caveats apply about importing text from 360 external online sources. Although queried DNSWLs are well known, 361 trusted entities, it is suggested that TXT records be reported only 362 if, upon inspection, their content is deemed actually actionable, and 363 their format compatible with the computing environment. 365 6. References 367 6.1. Normative References 369 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 370 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 371 . 373 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 374 DOI 10.17487/RFC5782, February 2010, . 377 [RFC8601] Kucherawy, M., "Message Header Field for Indicating 378 Message Authentication Status", RFC 8601, 379 DOI 10.17487/RFC8601, May 2019, . 382 6.2. Informative References 384 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 385 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 386 . 388 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 389 RFC 3225, DOI 10.17487/RFC3225, December 2001, 390 . 392 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 393 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 394 2003, . 396 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 397 Rose, "DNS Security Introduction and Requirements", 398 RFC 4033, DOI 10.17487/RFC4033, March 2005, 399 . 401 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 402 Thayer, "OpenPGP Message Format", RFC 4880, 403 DOI 10.17487/RFC4880, November 2007, . 406 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 407 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 408 . 410 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 411 DOI 10.17487/RFC5598, July 2009, . 414 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 415 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 416 RFC 6376, DOI 10.17487/RFC6376, September 2011, 417 . 419 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 420 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 421 February 2012, . 423 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 424 DOI 10.17487/RFC6762, February 2013, . 427 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 428 Authorizing Use of Domains in Email, Version 1", RFC 7208, 429 DOI 10.17487/RFC7208, April 2014, . 432 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 433 Message Authentication, Reporting, and Conformance 434 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 435 . 437 [RFC8460] Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., 438 and M. Risher, "SMTP TLS Reporting", RFC 8460, 439 DOI 10.17487/RFC8460, September 2018, . 442 [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, 443 "Providing Minimal-Sized Responses to DNS Queries That 444 Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 445 2019, . 447 [Courier-MTA] 448 "Courier Mail Server", . 450 [dnswl.org] 451 "DNSWL.ORG", . 453 Appendix A. Example 454 Delivered-To: recipient@example.org 455 Return-Path: 456 Authentication-Results: mta.example.org; 457 dkim=pass (whitelisted) header.i=@example.com 458 Authentication-Results: mta.example.org; 459 dnswl=pass dns.zone=list.dnswl.example dns.sec=na 460 policy.ip=127.0.10.1 461 policy.txt="fwd.example https://dnswl.example/?d=fwd.example" 462 Received-SPF: fail (Address does not pass Sender Policy Framework) 463 client-ip=2001:db8::2:1; 464 envelope-from="sender@example.com"; 465 helo=mail.fwd.example; 466 receiver=mta.example.org; 467 Received: from mail.fwd.example (mail.fwd.example [2001:db8::2:1]) 468 (TLS: TLSv1/SSLv3,128bits,ECDHE-RSA-AES128-GCM-SHA256) 469 by mta.example.org with ESMTPS; Thu, 03 Oct 2019 19:23:11 +0200 470 id 00000000005DC044.000000005702D87C.000007FC 472 Trace fields at the top of the header 474 The message went through a third party, fwd.example, which forwarded 475 it to the final MTA. Such mail path was not arranged beforehand with 476 the involved MTAs, it emerged spontaneously. This message would not 477 have made it to the target without whitelisting, because: 479 o the author domain published a strict SPF policy (-all), 480 o the forwarder did not alter the bounce address, and 481 o the target usually honors reject-on-fail, according to Section 8.4 482 of [RFC7208]. 484 However, the target also implemented the last paragraph of 485 Appendix D.3 of [RFC7208]. Its behavior hinges on the following DNS 486 entries: 488 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. 489 list.dnswl.example. 490 IN A 127.0.10.1 491 IN TXT "fwd.example https://dnswl.example/?d=fwd.example" 493 DNS resource records for 2001:db8::2:1 494 (line breaks for editorial reasons) 496 If mail.fwd.example had connected from address 192.0.2.1, then the 497 query name would have been 1.2.0.192.list.dnswl.example. See full 498 description in [RFC5782] 500 At connection time, because the remote IP address is whitelisted, the 501 target MTA did not reject the message before DATA. Instead, it 502 recorded the SPF fail result, and indicated the local policy 503 mechanism which was applied in order to override that result. 504 Subsequent filtering verified DKIM [RFC6376]. 506 At later stages, mail filters can reject or quarantine the message 507 based on its content. A deeper knowledge of the policy values 508 obtained from dnswl.example allows to interpret the values of 509 policy.ip and weight them against other factors so as to make better 510 decisions. 512 Appendix B. Known Implementation 514 Implementation details mentioned in this section have been stable for 515 several years. Yet, this description is necessarily superficial, 516 version dependent, and subject to change. 518 [Courier-MTA] can be configured to lookup DNSBL and DNSWL, with 519 similar command line switches: 521 -block=zone[=displayzone][,var[/n.n.n.n][,msg]] 522 -allow=zone[=displayzone][,var[/n.n.n.n[,]]] 524 zone is the zone to be queried. 526 displayzone is only used for -allow, it is the value to be set in the 527 dns.zone property. 529 var stands for the environment variable whose existence triggers a 530 special action. The default variable names result in a conventional 531 behavior implemented by Courier-MTA. By setting different 532 environment variables, users can customize the behavior. 533 Conventional behavior differs widely between -block and -allow. The 534 former rejects the message, the latter produces Authentication- 535 Results header fields. 537 The n.n.n.n IP address requires a precise A record response. If not 538 given, any response results in setting the corresponding variable. 539 If given, variables are set only if the response matches exactly. 540 Such syntax provides for a very limited interpretation of the 541 information encoded in A records. However, it is considered to be 542 too complicated already. Even specifying a range, an enumeration of 543 values, or a regular expression would require something beyond what a 544 normal user would be willing to manage. 546 Finally, the trailing message, which overrides the 5xx SMTP reply for 547 -block, is not used for -allow, except that its mere presence 548 requires to query TXT records to be registered in policy.txt. 550 SPF is part of Courier-MTA's core. It is configured separately, and 551 provides for an "allowok" keyword to indicate to override rejection 552 in case of SPF failure and -allow whitelisting. 554 A customary whitelist is [dnswl.org]. It serves A records encoded as 555 follows: 557 1st octect: 127. 558 2nd octect: 0. 559 3rd octect: Category of business, 15 values. 560 4th octect: Trusworthiness/score, 4 values. 562 They also serve TXT records containing the domain name followed by an 563 URL pointing to further info about the relevant organization, such as 564 what other IP addresses of theirs are being whitelisted. They don't 565 use UTF-8. 567 dnswl.org provides for free registration and free access below 568 100,000 queries per day. They use the special return code 569 127.0.0.255 exemplified above to signal over quota. Although 570 Courier-MTA itself does not recognize it, it has a mail filter 571 (zdkimfilter, named after its main usage) where recognition of that 572 code, as well as that of trusworthiness in the 4th octect are hard- 573 coded. 575 Appendix C. Future possibilities of the 'dns' ptype 577 The description of the new ptype proposed in Section 4.2 just says 578 "The property being reported belongs to the Domain Name System". 579 That definition can broadly include any tag found in a domain's TXT 580 record. For example, auth methods designers can agree that within a 581 resinfo of a given method, any dns ptype refers to tags in the 582 relevant DNS record, unless otherwise specified. So one could have, 583 say: 585 Authentication-Results: example.com; 586 spf=pass smtp.mailfrom=example.net dns.sec=y; 587 dkim=pass header.i=@example.org header.b=jIvx30NG dns.s=tlsrpt 589 While dns.sec is defined above, albeit not for the spf method, the 590 use of tlsrpt in the DKIM record is exemplified in Section 3 of 591 [RFC8460]. The tag s= is part of the DKIM TXT record, not to be 592 confused with the selector s=, which is part of a DKIM-Signature. 593 Just like the latter can be reported as header.s because the DKIM 594 header field is in the message header, it may make sense to report 595 the former as dns.s because the DKIM DNS record is in the DNS. 597 NOTE: This is only a hint at what may become a consistent naming 598 convention around the new ptype. In any case, any new property using 599 this ptype requires its own formal definition. This document does 600 NOT define the property dns.s=, let alone the service tlsrpt. 602 Author's Address 604 Alessandro Vesely 605 v. L. Anelli 13 606 Milano, MI 20122 607 IT 609 Email: vesely@tana.it