-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-kucherawy-dmarc-rfc7601bis.xml
3244 lines (2884 loc) · 178 KB
/
draft-kucherawy-dmarc-rfc7601bis.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5451 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5451.xml">
<!ENTITY RFC6008 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6008.xml">
<!ENTITY RFC6530 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6530.xml">
<!ENTITY RFC6531 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6531.xml">
<!ENTITY RFC6532 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6532.xml">
<!ENTITY RFC6577 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6577.xml">
<!ENTITY RFC7001 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7001.xml">
<!ENTITY RFC7601 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7601.xml">
<!ENTITY RFC8174 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8301 PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8301.xml">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="trust200902" category="std"
obsoletes="7601"
docName="draft-ietf-dmarc-rfc7601bis-06">
<front>
<title abbrev="Authentication-Results Header Field">
Message Header Field for Indicating Message Authentication
Status
</title>
<author initials="M. S." surname="Kucherawy"
fullname="Murray S. Kucherawy">
<address>
<postal>
<street>270 Upland Drive</street>
<city>San Francisco</city>
<region>CA</region>
<code>94127</code>
<country>United States</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2019"/>
<area>Applications</area>
<workgroup>Individual submission</workgroup>
<keyword>DKIM</keyword>
<keyword>SPF</keyword>
<keyword>ATPS</keyword>
<keyword>VBR</keyword>
<keyword>Authentication</keyword>
<keyword>Reputation</keyword>
<abstract>
<t> This document specifies a message header field called
Authentication-Results for use with
electronic mail messages to indicate the results of
message authentication efforts. Any receiver-side
software, such as mail filters or Mail User Agents
(MUAs), can use this header field to relay that
information in a convenient and meaningful way to users
or to make sorting and filtering decisions. </t>
<t> This document obsoletes <xref target="RFC7601"/>. </t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> This document describes a header field called
Authentication-Results for electronic mail messages that
presents the results of a message authentication effort
in a machine-readable format. The intent of the header
field is to create a place to collect such data when
message authentication mechanisms are in use so that a
Mail User Agent (MUA) and downstream filters can make
filtering decisions and/or provide a recommendation to the
user as to the validity of the message's origin and
possibly the safety and integrity of its content. </t>
<t> End users are not expected to be direct consumers of this
header field. This header field is intended for
consumption by programs that will then use such data or
render it in a human-usable form. </t>
<t> This document specifies the format of this header
field and discusses the implications of its presence or
absence. However, it does not discuss how the data
contained in the header field ought to be used, such as
what filtering decisions are appropriate or how an MUA
might render those results, as these are local policy
and/or user interface design questions that are not
appropriate for this document. </t>
<t> At the time of publication of this document, the following
are published email authentication methods:
<list style="symbols">
<t> SMTP Service Extension for Authentication
(<xref target="AUTH"/>) </t>
<t> DomainKeys Identified Mail Signatures
(<xref target="DKIM"/>) </t>
<t> Domain-based Message Authentication, Reporting and
Conformance (<xref target="DMARC"/>) </t>
<t> Sender Policy Framework (<xref target="SPF"/>) </t>
<t> reverse IP address name validation
("iprev", defined in <xref target="iprev"/>) </t>
<t> Require-Recipient-Valid-Since Header Field and SMTP
Service Extension (<xref target="RRVS"/>) </t>
<t> S/MIME Signature Verification
(<xref target="SMIME-REG"/>) </t>
<t> Vouch By Reference (<xref target="VBR"/>) </t>
</list> </t>
<t> The following historic specifications were previously
supported by this framework, but have since become
obsolete:
<list style="symbols">
<t> Author Domain Signing Practices
(<xref target="ADSP"/>) (Historic) </t>
<t> DomainKeys (<xref target="DOMAINKEYS"/>)
(Historic) </t>
<t> Sender ID (<xref target="SENDERID"/>)
(Historic) </t>
</list> </t>
<t> There exist registries for tokens used within this header
field that refer to the specifications listed above.
<xref target="iana"/> describes the registries and their
contents and specifies the process by which entries are
added or updated. It also updates the existing contents
to match the current states of these specifications. </t>
<t> The goal of this work is to give current
and future authentication schemes a common framework within
which to deliver their results to downstream agents and
discourage the creation of unique header fields for
each. </t>
<t> Although SPF defined a header field called "Received-SPF"
and the historic DomainKeys defined one called
"DomainKey-Status" for this purpose, those header fields
are specific to the conveyance of their respective results
only and thus are insufficient to satisfy the requirements
enumerated below. In addition, many SPF implementations
have adopted the header field specified here at least as
an option, and DomainKeys has been obsoleted by DKIM. </t>
<section anchor="purpose" title="Purpose">
<t> The header field defined in this document is
expected to serve several purposes:
<list style="numbers">
<t> Convey the results of various message
authentication checks, which are applied by
upstream filters and Mail Transfer
Agents (MTAs) and then passed to MUAs and
downstream filters within the same "trust
domain". Such agents might wish to render
those results to end users or to use those
data to apply more or less stringent
content checks based on authentication
results; </t>
<t> Provide a common location within a message
for this data;</t>
<t> Create an extensible framework for
reporting new authentication methods as
they emerge. </t>
</list> </t>
<t> In particular, the mere presence of this header
field does not mean its contents are valid.
Rather, the header field is reporting assertions
made by one or more authentication schemes
applied somewhere upstream.
For an MUA or downstream filter to treat the
assertions as actually valid, there must be an
assessment of the trust relationship among such
agents, the validating MTA, the paths between them,
and the mechanism for conveying the
information. </t>
</section>
<section anchor="trust" title="Trust Boundary">
<t> This document makes several references to the
"trust boundary" of an administrative management
domain (ADMD). Given the diversity among existing
mail environments, a precise definition of this
term isn't possible. </t>
<t> Simply put, a transfer from the producer of the
header field to the consumer must occur within a
context that permits the consumer to treat
assertions by the producer as being reliable and
accurate (trustworthy). How this trust is obtained
is outside the scope of this document. It is
entirely a local matter. </t>
<t> Thus, this document defines a "trust boundary" as
the delineation between "external" and "internal"
entities. Services that are internal -- within the
trust boundary -- are provided by the ADMD's
infrastructure for its users. Those that are
external are outside of the authority of the
ADMD. By this definition, hosts that are within
a trust boundary are subject to the ADMD's
authority and policies, independent of their
physical placement or their physical operation.
For example, a host within a trust boundary might
actually be operated by a remote service provider
and reside physically within its data center. </t>
<t> It is possible for a message to be evaluated inside
a trust boundary but then depart and re-enter the
trust boundary. An example might be a forwarded
message such as a message/rfc822 attachment
(see Multipurpose Internet Mail Extensions
<xref target="MIME"/>) or one that is part of a
multipart/digest. The details reported by this
field cannot be trusted in that case. Thus, this
field found within one of those media types is
typically ignored. </t>
<t> Note that an MUA could be configured to retrieve
messages from a Receiver yet not be within the
Receiver's ADMD. In this case, for the purposes
of this work, that MUA is considered to be within
the Receiver's ADMD if is configured to identify
and ascribe value to authentication results
recorded by that ADMD. </t>
</section>
<section anchor="scope" title="Processing Scope">
<t> The content of this header field is meant to convey
to message consumers that authentication work on
the message was already done within its trust
boundary, and those results are being presented.
It is not intended to provide message parameters
to consumers so that they can perform
authentication protocols on their own. </t>
</section>
<section anchor="requirements" title="Requirements">
<t> This document establishes no new requirements on
existing protocols, insofar as a non-participating
service will continue to interoperate with the
deployed messaging infrastructure. </t>
<t> In particular, this document establishes no
requirement on MTAs to reject or filter arriving
messages that do not pass authentication checks.
The data conveyed by the specified header field's
contents are for the information of MUAs and
filters and are to be used at their
discretion. </t>
<t> A participating ADMD does undertake some filtering
and message modification obligations described
in <xref target="removing"/>. </t>
</section>
<section anchor="definitions" title="Definitions">
<t> This section defines various terms used throughout
this document. </t>
<section anchor="defs_keywords" title="Key Words">
<t> The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document
are to be interpreted as described in
BCP 14
<xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only
when, they appear in all capitals, as
shown here. </t>
</section>
<section anchor="defs_eai"
title="Internationalized Email">
<t> In this document, there are references to
messages formatted to support Email Address
Internationalization (EAI). Reference
material for this can be found in
<xref target="RFC6530"/>,
<xref target="RFC6531"/>, and
<xref target="RFC6532"/>.
Generally speaking, these documents allow
UTF-8 in most places that free-form text
can be found and U-labels where domain
names can be used, and this document
extends Authentication-Results
accordingly. </t>
</section>
<section anchor="defs_security" title="Security">
<t> "Guidelines for Writing RFC Text on
Security Considerations"
(<xref target="SECURITY"/>) discusses
authentication and authorization and the
conflation of the two concepts. The use
of those terms within the context of
recent message security work has given rise
to slightly different definitions, and
this document reflects those current
usages, as follows:
<list style="symbols">
<t> "Authorization" is the
establishment of permission to use
a resource or represent an
identity. In this context,
authorization indicates that a
message from a particular ADMD
arrived via a route the ADMD
has explicitly approved. </t>
<t> "Authentication" is the assertion
of validity of a piece of data
about a message (such as the
sender's identity) or the message
in its entirety. </t>
</list> </t>
<t> As examples: SPF is an
authorization mechanism in that it
expresses a result that shows whether
the ADMD that apparently sent the message
has explicitly authorized the connecting
Simple Mail Transfer Protocol
(<xref target="SMTP"/>) client to relay
messages on its behalf, but they do not
actually validate any other property of
the message itself. By contrast, DKIM
is agnostic as to the routing of a message
but uses cryptographic signatures to
authenticate agents, assign (some)
responsibility for the message (which
implies authorization), and ensure that
the listed portions of the message were not
modified in transit. Since the signatures
are not tied to SMTP connections, they can
be added by either the ADMD of origin,
intermediate ADMDs (such as a mailing list
server), other handling agents, or any
combination. </t>
<t> Rather than create a separate header field
for each class of solution, this
specification groups them both into a
single header field. </t>
</section>
<section anchor="defs_email" title="Email Architecture">
<t> <list style="symbols">
<t> A "border MTA" is an MTA that
acts as a gateway between the
general Internet and the users
within an organizational
boundary. (See also
<xref target="trust"/>.) </t>
<t> A "delivery MTA" (or Mail Delivery
Agent or MDA) is an MTA that
actually enacts delivery of a
message to a user's inbox or other
final delivery. </t>
<t> An "intermediate MTA" is any MTA
that is not a delivery MTA and is
also not the first MTA to handle
the message. </t>
</list> </t>
<t> The following diagram illustrates the flow
of mail among these defined components.
See Internet Mail Architecture
<xref target="EMAIL-ARCH"/> for further
discussion on general email system
architecture, which includes detailed
descriptions of these components, and
<xref target="op_considerations"/> of this
document for discussion about the common
aspects of email authentication in current
environments.
<figure><artwork>
+-----+ +-----+ +------------+
| MUA |-->| MSA |-->| Border MTA |
+-----+ +-----+ +------------+
|
|
V
+----------+
| Internet |
+----------+
|
|
V
+-----+ +-----+ +------------------+ +------------+
| MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA |
+-----+ +-----+ +------------------+ +------------+
</artwork></figure>
</t>
<t> Generally, it is assumed that the work of
applying message authentication schemes
takes place at a border MTA or a delivery
MTA. This specification is written with
that assumption in mind. However, there
are some sites at which the entire mail
infrastructure consists of a single host.
In such cases, such terms as "border MTA"
and "delivery MTA" might well apply to the
same machine or even the very same agent.
It is also possible that some message
authentication tests could take place on
an intermediate MTA. Although this
document doesn't specifically describe
such cases, they are not meant to be
excluded. </t>
</section>
<section anchor="defs_other" title="Other Terms">
<t> In this document, the term "producer"
refers to any component that adds this
header field to messages it is handling,
and "consumer" refers to any component
that identifies, extracts, and parses the
header field to use as part of a handling
decision. </t>
</section>
</section>
<section anchor="environment" title="Trust Environment">
<t> This header field permits one or more message
validation mechanisms to communicate output to
one or more separate assessment mechanisms. These
mechanisms operate within a unified trust boundary
that defines an Administrative Management Domain
(ADMD). An ADMD contains one or more entities
that perform validation and generate the header
field and one or more that consume it for some
type of assessment. The field often contains no
integrity or validation mechanism of its own, so
its presence must be trusted implicitly. Hence,
valid use of the header field requires removing
any occurrences of it that claim to be associated
with the ADMD when the
message enters the ADMD. This ensures that later
occurrences have been added within the trust
boundary of the ADMD. </t>
<t> The authserv-id token defined in
<xref target="format_formal"/> can be used to
reference an entire ADMD or a specific validation
engine within an ADMD. Although the labeling
scheme is left as an operational choice, some
guidance for selecting a token is provided
in later sections of this document. </t>
</section>
</section>
<section anchor="format"
title="Definition and Format of the Header Field">
<t> This section gives a general overview of the format
of the header field being defined and then provides a
formal specification. </t>
<section anchor="format_general" title="General Description">
<t> The header field specified here is called
Authentication-Results. It is a Structured
Header Field as defined in Internet Message
Format (<xref target="MAIL"/>), and thus all of
the related definitions in that document
apply. </t>
<t> This header field is added at the top of the
message as it transits MTAs that do authentication
checks, so some idea of how far away the checks
were done can be inferred. It is therefore
considered to be a trace field as defined in
<xref target="MAIL"/>, and thus all of the related
definitions in that document apply. </t>
<t> The value of the header field (after removing
comments) consists of an authentication
identifier, an optional version, and then a series
of statements and supporting data. The statements
are of the form "method=result" and indicate which
authentication method(s) were applied and their
respective results. For each such statement, the
supporting data can include a "reason" string and
one or more "property=value" statements indicating
which message properties were evaluated to reach
that conclusion. </t>
<t> The header field can appear more than once in a
single message, more than one result can be
represented in a single header field, or a
combination of these can be applied. </t>
</section>
<section anchor="format_formal" title="Formal Definition">
<t> Formally, the header field is specified as
shown below using Augmented Backus-Naur Form
(<xref target="ABNF"/>). Examples of valid
header fields with explanations of their
semantics can be found in
<xref target="examples"/>. </t>
<figure><artwork>
authres-header-field = "Authentication-Results:" authres-payload
authres-payload = [CFWS] authserv-id
[ CFWS authres-version ]
( no-result / 1*resinfo ) [CFWS] CRLF
authserv-id = value
; see below for a description of this element
authres-version = 1*DIGIT [CFWS]
; indicates which version of this specification is in use;
; this specification is version "1", and the absence of a
; version implies this version of the specification
no-result = [CFWS] ";" [CFWS] "none"
; the special case of "none" is used to indicate that no
; message authentication was performed
resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
*( CFWS propspec )
methodspec = [CFWS] method [CFWS] "=" [CFWS] result
; indicates which authentication method was evaluated
; and what its output was
reasonspec = "reason" [CFWS] "=" [CFWS] value
; a free-form comment on the reason the given result
; was returned
propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue
; an indication of which properties of the message
; were evaluated by the authentication scheme being
; applied to yield the reported result
method = Keyword [ [CFWS] "/" [CFWS] method-version ]
; a method indicates which method's result is
; represented by "result", and is one of the methods
; explicitly defined as valid in this document
; or is an extension method as defined below
method-version = 1*DIGIT [CFWS]
; indicates which version of the method specification is
; in use, corresponding to the matching entry in the IANA
; "Email Authentication Methods" registry; a value of "1"
; is assumed if this version string is absent
result = Keyword
; indicates the results of the attempt to authenticate
; the message; see below for details
ptype = Keyword
; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, was a value taken
; from a message header field, was some property of
; the message body, or was some other property evaluated by
; the receiving MTA; expected to be one of the "property
; types" explicitly defined as valid, or an extension
; ptype, as defined below
property = special-smtp-verb / Keyword
; indicates more specifically than "ptype" what the
; source of the evaluated property is; the exact meaning
; is specific to the method whose result is being reported
; and is defined more clearly below
special-smtp-verb = "mailfrom" / "rcptto"
; special cases of [SMTP] commands that are made up
; of multiple words
pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name )
[CFWS]
; the value extracted from the message property defined
; by the "ptype.property" construction
</artwork></figure>
<t> "local-part" is defined in Section 3.4.1 of
<xref target="MAIL"/>, as modified by
<xref target="RFC6531"/>. </t>
<t> "CFWS" is defined in
Section 3.2.2 of <xref target="MAIL"/>. </t>
<t> "Keyword" is defined in Section 4.1.2 of
<xref target="SMTP"/>. It is further constrained
by the necesity of being registered in the IANA
registry relevant to the context in which it
it is used. See
<xref target="m_and_r"/>, and
<xref target="ptypes"/>, and
<xref target="iana"/>. </t>
<t> The "value" is as defined in Section 5.1 of
<xref target="MIME"/>, with "quoted-string"
updated as specified in
<xref target="RFC6532"/>. </t>
<t> The "domain-name" is as defined in Section 3.5 of
<xref target="DKIM"/>. </t>
<t> The "Keyword" used in "result" above is further
constrained by the necessity of being enumerated
in <xref target="m_and_r"/>. </t>
<t> See <xref target="identifier"/> for a description
of the authserv-id element. </t>
<t> If the value portion of a "pvalue" construction
identifies something intended to be an email
identity, then it MUST use the right hand portion
of that ABNF definition. </t>
<t> The list of commands eligible for use with the
"smtp" ptype can be found in Section 4.1 of
<xref target="SMTP"/>. </t>
<t> The "propspec" may be omitted if, for example,
the method was unable to extract any properties
to do its evaluation yet still has a result to
report. It may also be omitted if the agent
generating this result wishes not to reveal
such properties to downstream agents. </t>
<t> Where an SMTP command name is being reported as a
"property", the agent generating the header field
represents that command by converting it to
lowercase and dropping any spaces (e.g., "MAIL
FROM" becomes "mailfrom", "RCPT TO" becomes
"rcptto", etc.). </t>
<t> A "ptype" value of "policy" indicates a policy
decision about the message not specific to a
property of the message that could be extracted.
See <xref target="policyptype"/> for details. </t>
<t> Examples of complete messages using this
header field can be found in
<xref target="examples"/>. </t>
</section>
<section anchor="ptypes"
title="Property Types (ptypes) and Properties">
<t> The "ptype" in the ABNF above indicates the
general type of property being described by the
result being reported, upon which the reported
result was based. Coupled with the "property",
which is more specific, they indicate from where
the reported data were extracted. This can
include a particular part of the
message header or body, some part of the SMTP
session, a secondary output of an authentication
method (apart from its pure result), or some other
aspect of the message's handling. </t>
<t> Combinations of ptypes and properties are
registered and described in the "Email
Authentication Methods" registry, coupled with
the authentication methods with which they are
used. This is further described in
<xref target="iana"/>. </t>
<t> Legal values of "ptype" are as defined in the
IANA "Email Authentication Property Types"
registry, created by <xref target="RFC7410"/>.
The initial values and what they typically
indicate are as follows, based on
<xref target="RFC7001"/>:
<list style="hanging">
<t hangText="body:"> Information
that was extracted from the body of the
message. This might be an arbitrary
string of bytes, a hash of a string of
bytes, a Uniform Resource Identifier,
or some other content of interest. The
"property" is an indication of where
within the message body the extracted
content was found, and can indicate an
offset, identify a MIME part, etc.
(At the time of this revision, no
properties matching this ptype have
been registered. Accordingly, this
ptype may be deprecated in the
future.) </t>
<t hangText="header:"> Indicates information
that was extracted from the header of
the message. This might be the value
of a header field or some portion of a
header field. The "property" gives
a more precise indication of the place
in the header from which the extraction
took place. </t>
<t hangText="policy:"> A local policy mechanism
was applied that augments or overrides
the result returned by the
authentication mechanism. (See
<xref target="policyptype"/>.) </t>
<t hangText="smtp:"> Indicates information that
was extracted from an SMTP command
that was used to relay the
message. The "property" indicates
which SMTP command included the
extracted content as a parameter. </t>
</list> </t>
<t> Results reported using unknown ptypes MUST NOT be
used in making handling decisions. They can be
safely ignored by consumers. </t>
<t> Entries in the "Email Authentication Methods"
registry can define properties that deviate from
these definitions when appropriate. Such
deviations need to be clear in the registry and/or
in the defining document. See
<xref target="dkim_results"/> for an
example. </t>
</section>
<section anchor="policyptype"
title="The "policy" ptype">
<t> A special ptype value of "policy" is also defined.
This ptype is provided to indicate that some
local policy mechanism was applied that augments
or even replaces (i.e., overrides) the result
returned by the authentication mechanism. The
property and value in this case identify the
local policy that was applied and the result it
returned.</t>
<t> For example, a DKIM signature is not required to
include the Subject header field in the set of
fields that are signed. An ADMD receiving such
a message might decide that such a signature is
unacceptable, even if it passes, because the
content of the Subject header field could be
altered post-signing without invalidating the
signature. Such an ADMD could replace the DKIM
"pass" result with a "policy" result and then
also include the following in the corresponding
Authentication-Result field: </t>
<figure><artwork>
... dkim=policy policy.dkim-rules=unsigned-subject ...
</artwork></figure>
<t> In this case, the property is "dkim-rules",
indicating some local check by that name took
place and that check returned a result of
"unsigned-subject". These are arbitrary names
selected by (and presumably used within) the
ADMD making use of them, so they are not normally
registered with IANA or otherwise specified apart
from setting syntax restrictions that allow for
easy parsing within the rest of the header
field. </t>
<t> This ptype existed in the original specification
for this header field (<xref target="RFC5451"/>),
but without a complete description or example of
intended use. As a result, it has not seen any
practical use to date that matches its intended
purpose. These added details are provided to
guide implementers toward proper use. </t>
</section>
<section anchor="identifier"
title="Authentication Identifier Field">
<t> Every Authentication-Results header field
has an authentication service identifier field
(authserv-id above). Specifically, this is any
string intended to identify the authentication
service within the ADMD that conducted
authentication checks on the message. This
identifier is intended to be machine-readable and
not necessarily meaningful to users. </t>
<t> Note that in an EAI-formatted message, this
identifier may be expressed in UTF-8. </t>
<t> Since agents consuming this field will use this
identifier to determine whether its contents
are of interest (and are safe to use), the
uniqueness of the identifier MUST be guaranteed by
the ADMD that generates it and MUST pertain to
that ADMD. MUAs or downstream filters SHOULD use
this identifier to determine whether or not the
data contained in an Authentication-Results header
field ought to be used or ignored. </t>
<t> For simplicity and scalability, the authentication
service identifier SHOULD be a common token used
throughout the ADMD. Common practice is to use
the DNS domain name used by or within that ADMD,
sometimes called the "organizational domain",
but this is not strictly necessary. </t>
<t> For tracing and debugging purposes, the
authentication identifier can instead be the
specific hostname of the MTA performing the
authentication check whose result is being
reported. Moreover, some implementations define
a substructure to the identifier; such structures
are outside of the scope of this specification. </t>
<t> Note, however, that using a local, relative
identifier like a flat hostname, rather
than a hierarchical and globally unique ADMD
identifier like a DNS domain name, makes
configuration more difficult for large sites. The
hierarchical identifier permits aggregating
related, trusted systems together under a single,
parent identifier, which in turn permits assessing
the trust relationship with a single reference.
The alternative is a flat namespace requiring
individually listing each trusted system. Since
consumers will use the identifier to determine
whether to use the contents of the header field:
<list style="symbols">
<t> Changes to the identifier impose a large,
centralized administrative burden. </t>
<t> Ongoing administrative changes require
constantly updating this centralized
table, making it difficult to ensure
that an MUA or downstream filter will have
access to accurate information for
assessing the usability of the header
field's content. In particular, consumers
of the header field will need to know not
only the current identifier(s) in use
but previous ones as well to account
for delivery latency or later
re-assessment of the header field's
contents. </t>
</list> </t>
<t> Examples of valid authentication identifiers are
"example.com", "mail.example.org",
"ms1.newyork.example.com", and "example-auth". </t>
</section>
<section anchor="versions" title="Version Tokens">
<t> The grammar above provides for the optional
inclusion of versions on both the header field
itself (attached to the authserv-id token)
and on each of the methods being reported.
The method version refers to the method itself,
which is specified in the documents describing
those methods, while the authserv-id version
refers to this document and thus the syntax of
this header field. </t>
<t> The purpose of including these is to avoid
misinterpretation of the results. That is,
if a parser finds a version after an
authserv-id that it does not explicitly
know, it can immediately discontinue trying to
parse since what follows might not be in an
expected format. For a method version, the
parser SHOULD ignore a method result if the
version is not supported in case the semantics
of the result have a different meaning than what
is expected. For example, if a hypothetical
DKIM version 2 yielded a "pass" result for
different reasons than version 1 does, a consumer
of this field might not want to use the altered
semantics. Allowing versions in the syntax
is a way to indicate this and let the consumer
of the header field decide. </t>
</section>
<section anchor="m_and_r"
title="Defined Methods and Result Values">
<t> Each individual authentication method returns
one of a set of specific result values. The
subsections below provide references to the
documents defining the authentication methods
specifically supported by this document, and
their corresponding result values. Verifiers
SHOULD use these values as described below. New
methods not specified in this document, but
intended to be supported by the header field
defined here, MUST include a similar result table
either in their defining documents or in
supplementary ones. </t>
<section anchor="dkim_results" title="DKIM">
<t> DKIM is represented by the "dkim"
method and is defined in
<xref target="DKIM"/>. </t>
<t> A signature is "acceptable to the
ADMD" if it passes local policy
checks (or there are no specific local
policy checks). For example, an ADMD
policy might require that the signature(s)
on the message be added using the DNS
domain present in the From header field of
the message, thus making third-party
signatures unacceptable even if they
verify. </t>
<t> The DKIM result set is as follows:
<list style="hanging">
<t hangText="none:"> The message was
not signed. </t>
<t hangText="pass:"> The message was
signed, the signature or signatures
were acceptable to the ADMD,
and the signature(s) passed
verification tests. </t>
<t hangText="fail:"> The message
was signed and the signature or
signatures were acceptable to the
ADMD, but they failed the
verification test(s). </t>
<t hangText="policy:"> The message
was signed, but some aspect of the
signature or signatures was not
acceptable to the ADMD. </t>
<t hangText="neutral:"> The message
was signed, but the signature or
signatures contained syntax errors
or were not otherwise able to be
processed. This result is
also used for other failures
not covered elsewhere in this
list. </t>
<t hangText="temperror:"> The message
could not be verified due to some
error that is likely transient
in nature, such as a temporary
inability to retrieve a public
key. A later attempt may produce
a final result. </t>
<t hangText="permerror:"> The message
could not be verified due to some
error that is unrecoverable, such
as a required header field being
absent. A later attempt is
unlikely to produce a final
result. </t>
</list> </t>
<t> DKIM results are reported using a ptype
of "header". The property, however,
represents one of the tags found in the
DKIM-Signature header field rather than
a distinct header field. For example,
the ptype-property combination "header.d"
refers to the content of the "d"
(signing domain) tag from within the
signature header field, and not a distinct
header field called "d". </t>
<t> Note that in an EAI-formatted message,
the values of the "d" and "i" properties
can be expressed in UTF-8. </t>
<t> In addition to previous registrations,
this document registers the DKIM tags "a"
(cryptographic algorithm used to sign the
message) and "s" (selector) as reportable
properties. This can be used to aid
receivers during post-verification
processing. In particular,
<xref target="RFC8301"/>
obsoleted use of the "rsa-sha1" algorithm
in DKIM, so it is important to be able to