5Independent Submission A. Vesely
6Request for Comments: 8904 September 2020
11 DNS Whitelist (DNSWL) Email Authentication Method Extension
15 This document describes an email authentication method compliant with
16 RFC 8601. The method consists of looking up the sender's IP address
17 in a DNS whitelist. This document provides information in case the
18 method is seen in the field, suggests a useful practice, and
19 registers the relevant keywords.
21 This document does not consider blacklists.
25 This document is not an Internet Standards Track specification; it is
26 published for informational purposes.
28 This is a contribution to the RFC Series, independently of any other
29 RFC stream. The RFC Editor has chosen to publish this document at
30 its discretion and makes no statement about its value for
31 implementation or deployment. Documents approved for publication by
32 the RFC Editor are not candidates for any level of Internet Standard;
33 see Section 2 of RFC 7841.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 https://www.rfc-editor.org/info/rfc8904.
41 Copyright (c) 2020 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (https://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
55 3. TXT Record Contents
56 4. IANA Considerations
57 4.1. Email Authentication Methods
58 4.2. Email Authentication Property Type
59 4.3. Email Authentication Result Names
60 5. Security Considerations
61 5.1. Over-Quota Signaling
62 5.2. Security of DNSSEC Validation
63 5.3. Inherited Security Considerations
65 6.1. Normative References
66 6.2. Informative References
68 Appendix B. Known Implementation
69 Appendix C. Future Possibilities of the 'dns' ptype
74 One of the many checks that mail servers carry out is to query DNS
75 whitelists (DNSWLs). That method is fully discussed in [RFC5782].
76 The DNS [RFC1034] lookup is based on the connecting client's IP
77 address, IPv4 or IPv6, and returns zero or more A records. The
78 latter are IPv4 IP addresses in the range 127.0.0.0/8. Depending on
79 the query, TXT records with varying content can also be retrieved.
80 Query examples are given in Appendix A.
82 Since the IP address is known as soon as the connection is accepted,
83 this check can occur very early in an SMTP transaction. Its result
84 can be used to counterweight policies that typically occur at early
85 stages too, such as the Sender Policy Framework (SPF) (the last
86 paragraph of Appendix D.3 of [RFC7208] is also illustrated in
87 Appendix A). In addition, the result of a DNSWL lookup can be used
88 at later stages; for example, a delivery agent can use it to learn
89 the trustworthiness of a mail relay in order to estimate the
90 spamminess of an email message. The latter possibility needs a place
91 to collect query results for downstream use, which is precisely what
92 the Authentication-Results header field aims to provide.
94 Results often contain additional data, encoded according to DNSWL-
95 specific criteria. The method described in this document considers
96 only whitelists -- one of the major branches described by [RFC5782].
97 There are also blacklists/blocklists (DNSBLs) and combined lists.
98 Since they all have the same structure, the abbreviation DNSxL is
99 used to mean any. The core procedures of a Mail Transfer Agent (MTA)
100 tend to be quite general, leaving particular cases to be handled by
101 add-on modules. In the case of combined lists, the boundary MTA (see
102 [RFC5598]), which carries out the check and possibly stores the
103 result, has to be able to discern at least the color of each entry,
104 as that is required to make accept/reject decisions. This document
105 provides for storing the result when the DNSxL record to be reported
106 is a whitelisting one.
108 Data conveyed in A and TXT records can be stored as properties of the
109 method. The meaning of such data varies widely at the mercy of the
110 list operator; hence, the queried zone has to be stored as well.
111 Mail site operators who configure their MTAs to query specific DNWSLs
112 marry the policies of those lists, as, in effect, they become
113 tantamount to local policies, albeit outsourced. Downstream agents
114 who know DNSWL-specific encoding and understand the meaning of that
115 data can use it to make delivery or display decisions. For example,
116 a mail filter that detects heuristic evidence of a scam can
117 counterweight such information with the trustworthiness score encoded
118 in the A response so as to protect against false positives. Mail
119 User Agents (MUAs) can display those results or use them to decide
120 how to report abusive messages, if configured to do so.
122 This document describes a usage of TXT fields consistent with other
123 authentication methods, namely to serve the domain name in the TXT
124 record. That way, a downstream filter could also consider whether
125 the sending agent is aligned with the author domain, with semantics
126 similar to [RFC7489].
128 At the time of this writing, this method is implemented by Courier-
129 MTA [Courier-MTA]. An outline of the implementation is given in
134 The result of the method states how the query did, up to the
135 interpretation of the returned data.
137 The method has four possible results:
139 pass: The query successfully returned applicable records.
140 This result is usually accompanied by one or both of the
141 policy properties described below. Since the list is
142 configured as a DNSWL, agents unable to interpret list-
143 specific properties can still derive a positive value
144 from the fact that the sender is whitelisted.
146 none: The query worked but yielded no A record or returned
147 NXDOMAIN, so the sender is not whitelisted.
149 temperror: The DNS evaluation could not be completed due to some
150 error that is likely transient in nature, such as a
151 temporary DNS error (e.g., a DNS RCODE of 2, commonly
152 known as SERVFAIL) or other error condition. A later
153 attempt may produce a final result.
155 permerror: The DNS evaluation cannot work because test entries
156 don't work (that is, DNSWL is broken) or because queries
157 are over quota (reported by a DNS RCODE of 5, commonly
158 known as REFUSED, or by a DNSWL-specific property
159 (policy.ip, defined below) with the same meaning). A
160 later attempt is unlikely to produce a final result.
161 Human intervention is required.
163 Note that there is no "fail" result.
165 The following ptype.property items define how the data provided by
166 the whitelist lookup can be saved.
168 dns.zone: DNSWL query root domain, which defines the meaning of
169 the policy.ip property below. Note that an MTA can use
170 a local mirror with a different name. The name stored
171 here has to be the best available reference for all
172 foreseeable downstream consumers. Setting dns.zone to
173 the global zone makes the result intelligible even if
174 the message is handed outside of the internal network.
176 policy.ip: The bit mask value received in type A response, in
177 dotted quad notation. Multiple entries can be arranged
178 in a quoted, comma-separated list (quotes are necessary
179 because commas are not allowed in a token).
181 policy.txt: The TXT record, if any. Multiple records are
182 concatenated in the usual way (explained, for example,
183 in Section 3.3 of [RFC7208]). See Section 3 for the
184 resulting content and query options.
186 dns.sec: This is a generic property stating whether the relevant
187 data was validated using DNSSEC [RFC4033]. For the
188 present method, the relevant data consists of the
189 reported policy properties above or, if the method
190 result is "none", its nonexistence. This property has
191 three possible values:
193 yes: DNSSEC validation confirms the integrity of data.
194 Section 5.2 considers how that is related to the
197 no: The data is not signed. See Section 5.2.
199 na: Not applicable. No DNSSEC validation can be
200 performed, possibly because the lookup is run
201 through a different means than a security-aware
202 DNS resolver. This does not necessarily imply
203 less security. In particular, "na" is used if the
204 data was downloaded in bulk and then loaded on a
205 local nameserver, which is the case of an MTA
206 querying a local zone different from the reported
207 dns.zone. DNS errors, including validation
208 errors, can also report "na". This is also the
209 value assumed by default.
2113. TXT Record Contents
213 According to [RFC5782], TXT records describe the reason why IP
214 addresses are listed in a DNSWL. An example of a DNSWL whose TXT
215 records contain the domain name of the organization assignee of the
216 sending IP is given in Appendix B. The domain name would correspond
217 to the DNS domain name used by or within the Administrative
218 Management Domain (ADMD) operating the relevant MTA, sometimes called
219 the "organizational domain". In that case, the authentication
220 provided by this method is equivalent to a DomainKeys Identified Mail
221 (DKIM) signature [RFC6376] or an SPF check host [RFC7208], if the
224 According to a DNSWL's policy, attributing responsibility of an IP
225 address to an organization may require something more than a mere PTR
226 record consistency. If no domain names can be responsibly associated
227 to a given IP address, for example, because the IP address was added
228 without direct involvement of the organization concerned, DNSWLs can
229 use a subdomain of .INVALID [RFC2606] where the leftmost label hints
230 at why an address is whitelisted. For example, if the address
231 192.0.2.38 was added by the list managers solely based on their
232 knowledge, the corresponding TXT record might be AUTOPROMOTED.INVALID
233 so as to avoid explicitly identifying an entity that didn't opt in.
235 Following the example of Multicast DNS (see the second paragraph of
236 Section 16 of [RFC6762]), names containing non-ASCII characters can
237 be encoded in UTF-8 [RFC3629] using the Normalization Form C [NFC],
238 as described in "Unicode Format for Network Interchange" [RFC5198].
239 Inclusion of unaltered UTF-8 TXT values in the header entails an
240 environment compatible with Email Address Internationalization (EAI)
243 DNS queries with a QTYPE of ANY may lead to inconsistent replies,
244 depending on the cache status. In addition, ANY is not "all", and
245 the provisions for queries that have QTYPE=ANY [RFC8482] don't cover
246 DNSxLs. A mail server can issue two simultaneous queries, A and TXT.
247 Otherwise, a downstream filter can issue a TXT query on its own, if
248 it knows that an A query was successful and that the DNSWL serves
249 useful TXT records. It is unlikely that TXT records exist if a query
250 for QTYPE A brought a result of "none".
2524. IANA Considerations
254 IANA maintains the "Email Authentication Parameters" registry with
255 several subregistries. IANA has made the assignments set out in the
2584.1. Email Authentication Methods
260 IANA has created four new entries in the "Email Authentication
261 Methods" registry as follows.
263 +======+===========+======+========+=================+======+=======+
264 |Method|Definition |ptype |property|Value |Status|Version|
265 +======+===========+======+========+=================+======+=======+
266 |dnswl |RFC 8904 |dns |zone |DNSWL publicly |active| 1 |
267 | | | | |accessible query | | |
268 | | | | |root domain | | |
269 +------+-----------+------+--------+-----------------+------+-------+
270 |dnswl |RFC 8904 |policy|ip |type A response |active| 1 |
271 | | | | |received (or a | | |
272 | | | | |quoted, comma- | | |
273 | | | | |separated list | | |
274 | | | | |thereof) | | |
275 +------+-----------+------+--------+-----------------+------+-------+
276 |dnswl |RFC 8904 |policy|txt |type TXT query |active| 1 |
277 | | | | |response | | |
278 +------+-----------+------+--------+-----------------+------+-------+
279 |dnswl |RFC 8904 |dns |sec |one of "yes" for |active| 1 |
280 | | | | |DNSSEC | | |
281 | | | | |authenticated | | |
282 | | | | |data, "no" for | | |
283 | | | | |not signed, or | | |
284 | | | | |"na" for not | | |
285 | | | | |applicable | | |
286 +------+-----------+------+--------+-----------------+------+-------+
2904.2. Email Authentication Property Type
292 IANA has created a new entry in the "Email Authentication Property
293 Types" registry as follows.
295 +=======+============+====================================+
296 | ptype | Definition | Description |
297 +=======+============+====================================+
298 | dns | RFC 8904 | The property being reported |
299 | | | belongs to the Domain Name System. |
300 +-------+------------+------------------------------------+
3044.3. Email Authentication Result Names
306 IANA has created four new entries in the "Email Authentication Result
307 Names" registry as follows.
309 +=============+===========+===============+========+
310 | Auth Method | Code | Specification | Status |
311 +=============+===========+===============+========+
312 | dnswl | pass | RFC 8904 | active |
313 +-------------+-----------+---------------+--------+
314 | dnswl | none | RFC 8904 | active |
315 +-------------+-----------+---------------+--------+
316 | dnswl | temperror | RFC 8904 | active |
317 +-------------+-----------+---------------+--------+
318 | dnswl | permerror | RFC 8904 | active |
319 +-------------+-----------+---------------+--------+
3235. Security Considerations
3255.1. Over-Quota Signaling
327 Some DNSWLs that provide for free access below a given quota are
328 known to return special codes to signal that the quota has been
329 exceeded (for example, 127.0.0.255). If the MTA cannot interpret
330 that value, that case results in a false positive. It can accept
331 messages that it would otherwise reject. A DNSWL-specific module
332 would realize this fact and call for human intervention.
334 Returning an RCODE 5 (REFUSED) conveys the concept that the query is
335 "unauthorized" and human intervention required.
3375.2. Security of DNSSEC Validation
339 The dns.sec property is meant to be as secure as DNSSEC results. It
340 makes sense to use it in an environment where the DNSSEC validation
343 Section 7 of [RFC4033] examines various ways of setting up a stub
344 resolver that either validates DNSSEC locally or trusts the
345 validation provided through a secure channel. For a different class,
346 it is possible to set up a dedicated, caching, DNSSEC-enabled
347 resolver reachable by the mail server through interprocess
348 communication on 127.0.0.1. In such cases, the property dns.sec=yes
349 corresponds to the Authenticated Data (AD) bit in the DNS response
352 When the response contains no DNSSEC data, a security-aware resolver
353 seeks a signed proof of the nonexistence of a DS record at some
354 delegation point. If no error is returned, the zone is unsigned and
355 dns.sec=no can be set. The Security Considerations section of
358 | The absence of DNSSEC data in response to a query with the DO bit
359 | set MUST NOT be taken to mean no security information is available
360 | for that zone as the response may be forged or a non-forged
361 | response of an altered (DO bit cleared) query.
363 If the application verifies the DNSSEC signatures on its own, it
364 effectively behaves like a validating resolver and hence can set
365 dns.sec correspondingly.
367 When the data is downloaded in bulk and made available on a trusted
368 channel without using DNSSEC, the application sets dns.sec=na or not
369 at all. For example, consider DNSWLs that publish bulk versions of
370 their data duly signed using OpenPGP [RFC4880]. It is the
371 responsibility of system administrators to authenticate the data by
372 downloading and validating the signature. The result of such
373 validation is not reported using dns.sec.
3755.3. Inherited Security Considerations
377 For DNSSEC, the considerations of Section 12 of [RFC4033] apply.
379 All of the considerations described in Section 7 of [RFC8601] apply.
380 That includes securing against tampering all the channels after the
381 production of the Authentication-Results header field.
383 In addition, the usual caveats apply about importing text from
384 external online sources. Although queried DNSWLs are well-known,
385 trusted entities, it is suggested that TXT records be reported only
386 if, upon inspection, their content is deemed actionable and their
387 format compatible with the computing environment.
3916.1. Normative References
393 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
394 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
395 <https://www.rfc-editor.org/info/rfc2606>.
397 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
398 DOI 10.17487/RFC5782, February 2010,
399 <https://www.rfc-editor.org/info/rfc5782>.
401 [RFC8601] Kucherawy, M., "Message Header Field for Indicating
402 Message Authentication Status", RFC 8601,
403 DOI 10.17487/RFC8601, May 2019,
404 <https://www.rfc-editor.org/info/rfc8601>.
4066.2. Informative References
408 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
409 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
410 <https://www.rfc-editor.org/info/rfc1034>.
412 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
413 RFC 3225, DOI 10.17487/RFC3225, December 2001,
414 <https://www.rfc-editor.org/info/rfc3225>.
416 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
417 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
418 2003, <https://www.rfc-editor.org/info/rfc3629>.
420 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
421 Rose, "DNS Security Introduction and Requirements",
422 RFC 4033, DOI 10.17487/RFC4033, March 2005,
423 <https://www.rfc-editor.org/info/rfc4033>.
425 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
426 Thayer, "OpenPGP Message Format", RFC 4880,
427 DOI 10.17487/RFC4880, November 2007,
428 <https://www.rfc-editor.org/info/rfc4880>.
430 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
431 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
432 <https://www.rfc-editor.org/info/rfc5198>.
434 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
435 DOI 10.17487/RFC5598, July 2009,
436 <https://www.rfc-editor.org/info/rfc5598>.
438 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
439 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
440 RFC 6376, DOI 10.17487/RFC6376, September 2011,
441 <https://www.rfc-editor.org/info/rfc6376>.
443 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
444 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
445 February 2012, <https://www.rfc-editor.org/info/rfc6530>.
447 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
448 DOI 10.17487/RFC6762, February 2013,
449 <https://www.rfc-editor.org/info/rfc6762>.
451 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
452 Authorizing Use of Domains in Email, Version 1", RFC 7208,
453 DOI 10.17487/RFC7208, April 2014,
454 <https://www.rfc-editor.org/info/rfc7208>.
456 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
457 Message Authentication, Reporting, and Conformance
458 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
459 <https://www.rfc-editor.org/info/rfc7489>.
461 [RFC8460] Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J.,
462 and M. Risher, "SMTP TLS Reporting", RFC 8460,
463 DOI 10.17487/RFC8460, September 2018,
464 <https://www.rfc-editor.org/info/rfc8460>.
466 [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt,
467 "Providing Minimal-Sized Responses to DNS Queries That
468 Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January
469 2019, <https://www.rfc-editor.org/info/rfc8482>.
472 "Courier Mail Server", <https://www.courier-mta.org/>.
474 [DNSWL] "dnswl.org - E-Mail Reputation - Protect against false
475 positives", <https://www.dnswl.org/>.
477 [NFC] Whistler, K., Ed., "Unicode Normalization Forms", Unicode
478 Standard Annex 15, February 2020,
479 <https://www.unicode.org/reports/tr15/tr15-50.html>.
483 Delivered-To: recipient@example.org
484 Return-Path: <sender@example.com>
485 Authentication-Results: mta.example.org;
486 dkim=pass (whitelisted) header.i=@example.com
487 Authentication-Results: mta.example.org;
488 dnswl=pass dns.zone=list.dnswl.example dns.sec=na
490 policy.txt="fwd.example https://dnswl.example/?d=fwd.example"
491 Received-SPF: fail (Address does not pass Sender Policy Framework)
492 client-ip=2001:db8::2:1;
493 envelope-from="sender@example.com";
494 helo=mail.fwd.example;
495 receiver=mta.example.org;
496 Received: from mail.fwd.example (mail.fwd.example [2001:db8::2:1])
497 (TLS: TLSv1/SSLv3,128bits,ECDHE-RSA-AES128-GCM-SHA256)
498 by mta.example.org with ESMTPS; Thu, 03 Oct 2019 19:23:11 +0200
499 id 00000000005DC044.000000005702D87C.000007FC
501 Figure 1: Trace Fields at the Top of the Header
503 The message went through a third party, fwd.example, which forwarded
504 it to the final MTA. The mail path was not arranged beforehand with
505 the involved MTAs; it emerged spontaneously. This message would not
506 have made it to the target without whitelisting, because:
508 * the author domain published a strict SPF policy (-all),
510 * the forwarder did not alter the bounce address, and
512 * the target usually honors reject on fail, according to Section 8.4
515 However, the target also implemented the last paragraph of
516 Appendix D.3 of [RFC7208]. Its behavior hinges on the following DNS
519 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.
522 IN TXT "fwd.example https://dnswl.example/?d=fwd.example"
524 Figure 2: DNS Resource Records for 2001:db8::2:1 (line breaks for
527 If mail.fwd.example had connected from address 192.0.2.1, then the
528 query name would have been "1.2.0.192.list.dnswl.example". See full
529 description in [RFC5782].
531 At connection time, because the remote IP address is whitelisted, the
532 target MTA did not reject the message before DATA. Instead, it
533 recorded the SPF fail result and indicated the local policy mechanism
534 that was applied in order to override that result. Subsequent
535 filtering verified DKIM [RFC6376].
537 At later stages, mail filters can reject or quarantine the message
538 based on its content. A deeper knowledge of the policy values
539 obtained from dnswl.example allows interpreting the values of
540 policy.ip and weighing them against other factors so as to make
543Appendix B. Known Implementation
545 Implementation details mentioned in this section have been stable for
546 several years. Yet, this description is necessarily superficial,
547 version dependent, and subject to change.
549 Courier-MTA [Courier-MTA] can be configured to look up DNSBLs and
550 DNSWLs, with similar command-line switches:
552 -block=zone[=displayzone][,var[/n.n.n.n][,msg]]
553 -allow=zone[=displayzone][,var[/n.n.n.n[,]]]
555 "zone" is the zone to be queried.
557 "displayzone" is only used for -allow; it is the value to be set in
558 the dns.zone property.
560 "var" stands for the environment variable whose existence triggers a
561 special action. The default variable names result in a conventional
562 behavior implemented by Courier-MTA. By setting different
563 environment variables, users can customize the behavior.
564 Conventional behavior differs widely between -block and -allow. The
565 former rejects the message; the latter produces Authentication-
566 Results header fields.
568 The n.n.n.n IP address requires a precise A record response. If not
569 given, any response results in setting the corresponding variable.
570 If given, variables are set only if the response matches exactly.
571 Such syntax provides for a very limited interpretation of the
572 information encoded in A records. However, it is considered to be
573 too complicated already. Even specifying a range, an enumeration of
574 values, or a regular expression would require something beyond what a
575 normal user would be willing to manage.
577 Finally, the trailing message, which overrides the 5xx SMTP reply for
578 -block, is not used for -allow, except that its mere presence
579 requires querying TXT records to be registered in policy.txt.
581 SPF is part of Courier-MTA's core. It is configured separately and
582 provides for an "allowok" keyword to indicate the choice to override
583 rejection in case of SPF failure and -allow whitelisting.
585 A customary whitelist is defined by DNSWL.org [DNSWL]. It serves A
586 records encoded as follows:
592 3rd octet: Category of business, 15 values.
594 4th octet: Trustworthiness/score, 4 values.
596 They also serve TXT records containing the domain name followed by a
597 URL pointing to further information about the relevant organization,
598 such as what other IP addresses of theirs are being whitelisted.
599 They don't use UTF-8.
601 DNSWL.org provides for free registration and free access below
602 100,000 queries per day. They use a special return code, 127.0.0.255
603 as exemplified above, to signal that the quota has been exceeded.
604 Although Courier-MTA itself does not recognize this return code, it
605 has a mail filter (zdkimfilter, named after its main usage) that hard
606 codes recognition of this code and the code for trustworthiness in
609Appendix C. Future Possibilities of the 'dns' ptype
611 The description of the new ptype proposed in Section 4.2 says, "The
612 property being reported belongs to the Domain Name System." That
613 definition can broadly include any tag found in a domain's TXT
614 record. For example, designers of authentication methods can agree
615 that within a resinfo of a given method, any dns ptype refers to tags
616 in the relevant DNS record, unless otherwise specified. So one could
619 Authentication-Results: example.com;
620 spf=pass smtp.mailfrom=example.net dns.sec=y;
621 dkim=pass header.i=@example.org header.b=jIvx30NG dns.s=tlsrpt
623 While dns.sec is defined above, albeit not for the spf method, the
624 use of tlsrpt in the DKIM record is exemplified in Section 3 of
625 [RFC8460]. The tag s= is part of the DKIM TXT record, not to be
626 confused with the selector s=, which is part of a DKIM signature.
627 Just like the latter can be reported as header.s because the DKIM
628 header field is in the message header, it may make sense to report
629 the former as dns.s because the DKIM DNS record is in the DNS.
631 NOTE: This is only a hint at what may become a consistent naming
632 convention around the new ptype. In any case, any new property using
633 this ptype requires its own formal definition. This document does
634 NOT define the property dns.s=, let alone the service tlsrpt.
643 Email: vesely@tana.it