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
|
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 7410 December 2014
Updates: 7001
Category: Standards Track
ISSN: 2070-1721
A Property Types Registry for the Authentication-Results Header Field
Abstract
This document updates RFC 7001 by creating a registry for property
types in the Authentication-Results header field, used in email
authentication work, rather than limiting participants to using the
original, small set of fixed values.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7410.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Kucherawy Standards Track [Page 1]
^L
RFC 7410 Authentication-Results Property Types December 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Updated "ptype" Definition . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
[RFC7001] defines the email Authentication-Results header field that
presents the results of an authentication effort in a machine-
readable format. The header field creates a place to collect the
output from authentication processes that are disjoint from later
processes that might use the output, such as analysis, filtering, or
sorting mechanisms.
The specification in that document enumerated a small set of types of
properties that can be reported using this mechanism. There has
emerged a desire to report types of properties about a message
through this mechanism. Accordingly, this document updates the
specification to allow for additional property types ("ptypes")
beyond the original set and creates a registry where new ones can be
listed and their defining documents referenced.
2. Updated "ptype" Definition
Advanced Backus Naur Form (ABNF) is defined in [RFC5234].
The ABNF in Section 2.2 of [RFC7001] is updated as follows:
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 Message Transfer Agent (MTA)
The ABNF token "Keyword" is defined in Section 4.1.2 of [RFC5321].
Kucherawy Standards Track [Page 2]
^L
RFC 7410 Authentication-Results Property Types December 2014
Legal values of "ptype" are as defined in the IANA "Email
Authentication Property Types" registry (see Section 3). The initial
values are as follows, matching those defined in [RFC7001]:
body: Indicates 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.
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.
policy: A local policy mechanism was applied that augments or
overrides the result returned by the authentication mechanism.
See Section 2.3 of [RFC7001].
smtp: Indicates information that was extracted from an SMTP command
that was used to relay the message.
When a consumer of this header field encounters a "ptype" that it
does not understand, it ignores the result reported with that
"ptype".
3. IANA Considerations
IANA has created the "Email Authentication Property Types" sub-
registry within the existing "Email Authentication Parameters"
registry. Entries in this registry are subject to the Expert Review
rules as described in [RFC5226]. Each entry in the registry requires
the following values:
o The "ptype" token to be registered, which must fit within the ABNF
described in Section 2.
o A brief description of what sort of information this "ptype" is
meant to cover.
o An optional reference to the defining document. This is
recommended, but not required.
Kucherawy Standards Track [Page 3]
^L
RFC 7410 Authentication-Results Property Types December 2014
The initial entries in this table are as follows, taken from
[RFC7001]:
+--------+-------------+----------------------------------------+
| ptype | Definition | Description |
+--------+-------------+----------------------------------------+
| body | RFC 7001 | The property being reported was found |
| | Section 2.2 | in the body of the message. |
+--------+-------------+----------------------------------------+
| header | RFC 7001 | The property being reported was found |
| | Section 2.2 | in a header field of the message. |
+--------+-------------+----------------------------------------+
| policy | RFC 7001 | The property being reported relates to |
| | Section 2.3 | a locally defined policy. |
+--------+-------------+----------------------------------------+
| smtp | RFC 7001 | The property being reported is a |
| | Section 2.2 | parameter to an SMTP command used to |
| | | relay the message. |
+--------+-------------+----------------------------------------+
For new entries, the Designated Expert needs to assure that the
description provided for the new entry adequately describes the
intended use. An example would be helpful to include in the entry's
defining document, if any, although entries in the "Email
Authentication Methods" registry or the "Email Authentication Result
Names" registry might also serve as examples of intended use.
4. Security Considerations
It is unknown how legacy code, which expects one of a fixed set of
"ptype" tokens, will handle new tokens as they begin to appear.
There are typically two options: prevent delivery of the message, or
ignore those portions of the field that use unknown "ptype" tokens
and allow processing of the message to continue.
The choice comes down to whether the consumer considers it a threat
when there are unknown "ptypes" present. The semantics of the report
are unknown; the report might be indicating the message is authentic,
fraudulent, or that a test failed to complete. The report itself is
not actionable because it cannot be understood, and only its presence
is certain.
Generally, the advice in this situation is to ignore unknown
"ptypes". It is anticipated that a new property type evaluated by
earlier handling agents would also result in the filtering of
messages by those agents until consumers can be updated to interpret
them.
Kucherawy Standards Track [Page 4]
^L
RFC 7410 Authentication-Results Property Types December 2014
5. Normative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC7001] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7001, September 2013,
<http://www.rfc-editor.org/info/rfc7001>.
Acknowledgements
The author wishes to acknowledge the following for their review and
constructive criticism of this update: Dave Crocker, Tim Draegen,
Scott Kitterman, and Franck Martin.
Author's Address
Murray S. Kucherawy
270 Upland Drive
San Francisco, CA 94127
United States
EMail: superuser@gmail.com
Kucherawy Standards Track [Page 5]
^L
|
