-
Notifications
You must be signed in to change notification settings - Fork 0
/
dmarc-arc-usage-02.xml
680 lines (564 loc) · 32.7 KB
/
dmarc-arc-usage-02.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
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC5321 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY RFC5322 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY RFC7601 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7601.xml">
<!ENTITY RFC5598 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml">
<!ENTITY RFC7489 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml">
<!ENTITY RFC7960 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7960.xml">
<!ENTITY SELF "[I-D.ARC-USAGE]">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-dmarc-arc-usage-02" category="info">
<front>
<title abbrev="ARC-USAGE">Recommended Usage of the Authenticated Received Chain (ARC)</title>
<author initials="S." surname="Jones" fullname="Steven Jones">
<organization>DMARC.org</organization>
<address>
<email>smj@crash.com</email>
</address>
</author>
<author initials="J." surname="Rae-Grant" fullname="John Rae-Grant">
<organization>Google</organization>
<address>
<email>johnrg@google.com</email>
</address>
</author>
<author initials="T." surname="Adams" fullname="J. Trent Adams">
<organization>Paypal</organization>
<address>
<email>trent.adams@paypal.com</email>
</address>
</author>
<author initials="K." surname="Andersen" fullname="Kurt Andersen" role="editor">
<organization>LinkedIn</organization>
<address>
<postal>
<street>2029 Stierlin Ct.</street>
<city>Mountain View</city>
<region>California</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>kurta@linkedin.com</email>
</address>
</author>
<date year="2017" month="June" day="20"/>
<area>art</area>
<workgroup>DMARC Working Group</workgroup>
<abstract>
<t>The Authentication Received Chain (ARC) provides a means to preserve
email authentication results and verify the identity of email message
handlers, each of which participates by inserting certain header fields
before passing the message on. But the specification does not indicate
how intermediaries and receivers should interpret or utilize ARC. This
document will provide guidance in these areas.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t><xref target="ARC"/> is intended to be used primarily by intermediaries, or message
handlers - those parties who may forward or resend messages, with or
without alterations, such that they will no longer pass the SPF, DKIM,
and/or <xref target="RFC7489"/> authentication mechanisms. In such cases ARC may provide
the final message recipient with useful information about the original
sender.</t>
</section>
<section anchor="how-does-arc-work" title="How does ARC work?">
<t>Consider a mailing list as an example, where the message submitter’s
domain publishes a DMARC policy other than “p=none”. The message is
received, a prefix is added to the RFC5322.Subject header field, some text
is appended to the message body, and the message is sent to list
members with the original RFC5322.From address intact. In this case
SPF may pass because the mailing list operator uses their own domain
in the RFC5321.MailFrom header field, but this domain will not match the
RFC5322.From address, thus the DMARC SPF result cannot be a “pass.”
Any DKIM signature from the message submitter’s domain will be broken
as the message body has been altered (and if included in the
signature, the RFC5322.Subject header field). Again, the DMARC DKIM result
cannot be a “pass.” And if the mailing list operator inserted an
Authentication-Results header field it was most likely stripped and/or
replaced by the next message receiver.</t>
<t>If the mailing list implemented ARC, it would record the contents of
the Authentication-Results header field in the ARC-Authentication-Results
header field. It would then create an an ARC-Message-Signature header field,
which includes a cryptographic signature of the message itself, and
then an ARC-Seal header field, which includes a cryptographic signature of
a few key message header fields - including the other ARC header fields.</t>
<t>Any subsequent system participating in ARC that was not performing
final delivery of the message within its ADMD boundaries would also
generate and insert ARC header fields whose signatures cover all ARC header fields
inserted into the message by previous message handlers. Thus the
information from any previous ARC participants, including the
ARC-Authentication-Results header field from the mailing list operator,
would be signed at each ADMD that handled the message.</t>
<t>When the message reaches the final receiving system, the SPF and DKIM
results will not satisfy the DMARC policy for the message author’s
domain. However if the receiving system implements ARC then it can
check for and validate an ARC chain and verify that the contents of
the ARC-Authentication-Results header field were conveyed intact from the
mailing list operator. At that point the receiving system might choose
to use those authentication results in the decision of whether or not
to deliver the message, even though it failed to pass the usual
authentication checks.</t>
</section>
<section anchor="guidance-for-receiversvalidators" title="Guidance for Receivers/Validators">
<section anchor="what-is-the-significance-of-an-intact-arc-chain" title="What is the significance of an intact ARC chain?">
<t>An intact ARC chain conveys authentication results like SPF and DKIM
as observed by the first ARC participant. In cases where the message
no longer produces passing results for DKIM, SPF, or DMARC but an
intact ARC chain is present, the message receiver may choose to use
the contents of the ARC-Authentication-Results header field in determining
how to handle the message.</t>
</section>
<section anchor="what-exactly-is-an-intact-arc-chain" title="What exactly is an “intact” ARC chain?">
<t>Note that not all ADMDs will implement ARC, and receivers will see
messages where one or more non-participating ADMDs handled a message
before, after, or in between participating ADMDs.</t>
<t>An intact ARC chain is one where the ARC header fields that are present can
be validated, and in particular the ARC-Message-Signature header field from
the last ARC participant can still be validated. This shows that,
whether another ADMD handled the message after the last ARC
participant or not, the portions of the message covered by that
signature were not altered. If any non-participating ADMDs handled the
message between ARC intermediaries but did not alter the message in a
way that invalidated the most recent ARC-Message-Signature present at
that time, the chain would still be considered intact by the next ARC
participant, and recorded as such in the ARC-Seal header field they insert.</t>
<t>Message receivers may make local policy decisions about whether to use
the contents of the ARC-Authentication-Results header field in cases where
a message no longer passes DKIM, DMARC, and/or SPF checks. Whether an
ARC chain is intact can be used to inform that local policy decision.</t>
<t>So for example one message receiver may decide that, for messages with
an intact ARC chain where a DMARC evaluation does not pass, but the
ARC-Authentication-Results header field indicates a DKIM pass was reported
by the first ARC intermediary
that matches the domain in the RFC5322.From header field, it will override a
DMARC “p=reject” policy. Another message receiver may decide to do so
for intact ARC chains where the ARC-Authentication-Results header field
indicates an SPF pass. A third message receiver may use very different
criteria, according to their requirements, while a fourth may choose
not to take ARC information into account at all.</t>
</section>
<section anchor="what-is-the-significance-of-an-invalid-broken-arc-chain" title="What is the significance of an invalid (“broken”) ARC chain?">
<t>An ARC chain is not considered to be valid if the signatures in the
ARC-Seal header fields cannot be verified. For example the remote server
delivering the message to the local ADMD is not reflected in any ARC
header fields, perhaps because they have not implemented ARC, but they
modified the message such that ARC and DKIM signatures already in the
message were invalidated.</t>
<t>In such cases the ARC-Authentication-Results header field should not have
any influence on the disposition of the message. For example, a
message that fails under DMARC and has an invalid ARC chain would be
subject to that DMARC policy, which may cause it to be quarantined or
rejected.</t>
</section>
<section anchor="what-does-the-absence-of-an-arc-chain-in-a-message-mean" title="What does the absence of an ARC chain in a message mean?">
<t>The absence of an ARC chain means nothing. ARC is intended to allow a
participating message handler to preserve certain authentication
results when a message is being forwarded and/or modified such that
the final recipient can evaluate this information. If they are absent, there
is nothing extra that ARC requires the final recipient to do.</t>
</section>
<section anchor="what-reasonable-conclusions-can-you-draw-based-upon-seeing-lots-of-mail-with-arc-chains" title="What reasonable conclusions can you draw based upon seeing lots of mail with ARC chains?">
<t>With sufficient history, ARC can be used to augment DMARC
authentication policy (i.e. a message could fail DMARC, but validated ARC
information and therefore could be considered as validly authenticated as reported
by the first ARC participant).</t>
<t>If the validator does content analysis and reputation tracking, the
ARC participants in a message can be credited or discredited for good
or bad content. By analyzing different ARC chains involved in “bad”
messages, a validator might identify malicious participating
intermediaries.</t>
<t>With a valid chain and good reputations for all ARC participants,
receivers may choose to apply a “local policy override” to the DMARC
policy assertion for the domain authentication evaluation, depending
on the ARC-Authentication-Results header field value. Normal content
analysis should never be skipped.</t>
</section>
<section anchor="what-if-none-of-the-intermediaries-have-been-seen-previously" title="What if none of the intermediaries have been seen previously?">
<t>This has no impact on the operation of ARC, as ARC is not a
reputation system. ARC conveys the results of other authentication
mechanisms such that the participating message handlers can be
positively identified. Final message recipients may or may not choose
to examine these results when messages fail other authentication
checks. They are more likely to override, say, a failing DMARC result
in the presence of an intact ARC chain where the participating ARC
message handlers have been observed to not convey “bad” content in the
past, and the initial ARC participant indicates the message they
received had passed authentication checks.</t>
</section>
<section anchor="what-about-arc-chains-where-some-intermediaries-are-known-and-others-are-not" title="What about ARC chains where some intermediaries are known and others are not?">
<t>Validators may choose to build reputation models for ARC message
handlers they have observed. Generally speaking it is more feasible to
accrue positive reputation to intermediaries when they consistently
send messages that are evaluated positively in terms of content and
ARC chains. When messages are received with ARC chains that are not
intact, it is very difficult identify which intermediaries may have
manipulated the message or injected bad content.</t>
</section>
<section anchor="what-should-message-handlers-do-when-they-detect-malicious-content-in-messages-where-arc-is-present" title="What should message handlers do when they detect malicious content in messages where ARC is present?">
<t>Message handlers should do what they normally do when they detect
malicious content in a message - hopefully that means quarantining or
discarding the message. ARC information should never make malicious
content acceptable.</t>
<t>In such cases it is difficult to determine where the malicious content
may have been injected. What ARC can do in such cases is verify that a
given intermediary or message handler did in fact handle the message
as indicated in the header fields. In such cases a message recipient who
maintains a reputation system about email senders may wish to
incorporate this information as an additional factor in the score for
the intermediaries and sender in question. However reputation systems
are very complex, and usually unique to those organizations operating
them, and therefore beyond the scope of this document.</t>
</section>
<section anchor="what-feedback-does-a-sender-or-domain-owner-get-about-arc-when-it-is-applied-to-their-messages" title="What feedback does a sender or domain owner get about ARC when it is applied to their messages?">
<t>ARC itself does not include any mechanism for feedback or reporting.
It does however recommend that message receiving systems that use ARC
to augment their delivery decisions, who use DMARC and decide to
deliver a message because of ARC information, should include a
notation to that effect in their normal DMARC reports. These notations
would be easily identifiable by report processors, so that senders and
domain owners can see where ARC is being used to augment the
deliverability of their messages.</t>
</section>
<section anchor="what-prevents-a-malicious-actor-from-removing-the-arc-header-fields-altering-the-content-and-creating-a-new-arc-chain" title="What prevents a malicious actor from removing the ARC header fields, altering the content, and creating a new ARC chain?">
<t>ARC does not prevent a malicious actor from doing this. Nor does it
prevent a malicious actor from removing all but the first ADMD’s ARC
header fields and altering the message, eliminating intervening participants
from the ARC chain. Or similar variations.</t>
<t>A valid ARC chain does not provide any automatic benefit. With an
intact ARC chain, the final message recipient may choose to use the
contents of the ARC-Authentication-Results header field in determining how
to handle the message. The decision to use the
ARC-Authentication-Results header field is dependent on evaluation of those
ARC intermediaries.</t>
<t>In the first case, the bad actor has succeeded in manipulating the
message but they have attached a verifiable signature identifying
themselves. While not an ideal situation, it is something they are
already able to do without ARC involved, but now a signature linked to the
domain responsible for the manipulation is present.</t>
<t>Additionally in the second case it is possible some negative
reputational impact might accrue to the first ARC participant left in
place until more messages reveal the pattern of activity by the bad
actor. But again, a bad actor can similarly manipulate a sequence of
RFC5322.Received header fields today without ARC, but with ARC that bad
actor has verifiably identified themselves.</t>
</section>
</section>
<section anchor="guidance-for-intermediaries" title="Guidance for Intermediaries">
<section anchor="what-is-an-intermediary-under-arc" title="What is an Intermediary under ARC?">
<t>In the context of ARC, an Intermediary is typically an Administrative
Management Domain <xref target="RFC5598"/> that is receiving a message,
potentially manipulating or altering it, and then passing it on to
another ADMD for delivery. Common examples of Intermediaries are
mailing lists, alumni or professional email address providers that
forward messages such as universities or professional organizations,
et cetera.</t>
</section>
<section anchor="what-are-the-minimum-requirements-for-an-arc-intermediary" title="What are the minimum requirements for an ARC Intermediary?">
<t>A participating ARC intermediary must validate the ARC chain on a
message it receives, if one is present. It then attaches its own ARC
seal and signature, including an indication if the chain failed to
validate upon receipt.</t>
<section anchor="more-specifically-a-participating-arc-intermediary-must-do-the-following" title="More specifically a participating ARC intermediary must do the following:">
<t><list style="numbers">
<t>Validate that the ARC chain, if one is already present in the message, is intact and well-formed.</t>
<t>Validate that the most recent sender matches the last entry in the ARC chain (if present).</t>
<t>Validate that the most recent sender’s DKIM signature is attached, and matches the reference to it in the ARC chain (if present).</t>
<t>Generate a new ARC Signature and add it to the message according to the ARC specification.</t>
<t>Generate a new ARC Seal and add it to the message according to the ARC specification.</t>
</list></t>
</section>
</section>
<section anchor="should-every-mta-be-an-arc-participant" title="Should every MTA be an ARC participant?">
<t>Generally speaking, ARC is designed to operate at the ADMD level. When
a message is first received by an ADMD, the traditional authentication
results should be captured and preserved - this could be the common
case of creating an Authentication-Results header field. But when it is
determined that the message is being sent on outside of that ADMD,
that is when the ADMD should add itself to the ARC chain - before
sending the message outside of the ADMD.</t>
<t>Some organizations may operate multiple ADMDs, with more or less
independence between them. While they should make a determination
based on their specific circumstances, it may be useful and
appropriate to have one or both ADMDs be ARC participants.</t>
</section>
<section anchor="what-should-an-intermediary-do-in-the-case-of-an-invalid-or-broken-arc-chain" title="What should an intermediary do in the case of an invalid or “broken” ARC chain?">
<t>In general terms, a participating ARC intermediary will note that an
ARC chain was present and invalid, or broken, when it attaches its own
ARC seal and signature. However the fact that the ARC chain was
invalid should have no impact on whether and how the message is
delivered.</t>
</section>
<section anchor="what-should-i-do-in-the-case-where-there-is-no-arc-chain-present-in-a-message" title="What should I do in the case where there is no ARC chain present in a message?">
<t>A participating ARC intermediary receiving a message with no ARC
chain, and which will be delivered outside its ADMD, should start an
ARC chain according to the ARC specification. This will include
capturing the normal email authentication results for the intermediary
(SPF, DKIM, DMARC, etc), which will be conveyed as part of the ARC
chain.</t>
</section>
<section anchor="how-could-arc-affect-my-reputation-as-an-intermediary" title="How could ARC affect my reputation as an intermediary?">
<t>Message receivers often operate reputation systems, which build a
behavioral profile of various message handlers and intermediaries. The
presence or absence of ARC is yet another data point that may be used
as an input to such reputation systems. Messages deemed to have good
content may provide a positive signal for the intermediaries that
handled it, while messages with bad content may provide a negative
signal for the those intermediaries. Intact and valid ARC elements may
amplify or attenuate such signals, depending on the circumstances.</t>
<t>Reputation systems are complex and usually specific to a given message
receiver, and a meaningful discussion of such a broad topic is beyond
the scope of this document.</t>
</section>
<section anchor="what-can-i-do-to-influence-my-reputation-as-an-intermediary" title="What can I do to influence my reputation as an intermediary?">
<t>Today it is extremely simple for a malicious actor to construct a
message that includes your identity as an intermediary, even though
you never handled the message. It is possible that an intermediary
implementing ARC on all traffic it handles might receive some
reputational benefit by making it easier to detect when their
involvement in conveying bad traffic has been “forged.”</t>
<t>As mentioned previously reputation systems are very complex and
usually specific to a given message receiver, and a meaningful
discussion of such a broad topic is beyond the scope of this document.</t>
</section>
</section>
<section anchor="guidance-for-originators" title="Guidance for Originators">
<section anchor="where-can-i-find-out-more-information" title="Where can I find out more information?">
<t>Please join the arc-discuss list at <eref target="mailto:arc-discuss@dmarc.org">arc-discuss@dmarc.org</eref>[mailto:arc-discuss@dmarc.org].</t>
<t>To discuss the IETF spec itself, please join the dmarc working group at [https://datatracker.ietf.org/wg/dmarc].</t>
</section>
<section anchor="howwhere-can-i-test-interoperabililty-for-my-implementation" title="How/where can I test interoperabililty for my implementation?">
<t>The arc-discuss list is the best place to stay in touch with work in progress.</t>
</section>
<section anchor="how-can-arc-impact-my-email" title="How can ARC impact my email?">
<t>Prior to ARC, certain DMARC policies on a domain would cause messages
using those domains in the RFC5322.From field, and which pass through
certain kinds of intermediaries (mailing lists, forwarding services),
to fail authentication checks at the message receiver. As a result
these messages might not be delivered to the intended recipient.</t>
<t>ARC seeks to provide these so-called “indirect mailflows” with a means
to preserve email authentication results as recorded by participating
intermediaries. Message receivers may accept validated ARC information to supplement
the information that DMARC provides, potentially deciding to deliver
the message even though a DMARC check did not pass.</t>
<t>The net result for domain owners and senders is that ARC may allow
messages routed through participating ARC intermediaries to be
delivered, even though those messages would not have been delivered in
the absence of ARC.</t>
</section>
<section anchor="how-can-arc-impact-my-reputation-as-a-message-sender" title="How can ARC impact my reputation as a message sender?">
<t>Message receivers often operate reputation systems, which build a
behavioral profile of various message senders (and perhaps
intermediaries). The presence or absence of ARC is yet another data
point that may be used as an input to such reputation systems.
Messages deemed to have good content may provide a positive signal for
the sending domain and the intermediaries that handled it, while
messages with bad content may provide a negative signal for the
sending domain and the intermediaries that handled it. Intact and
valid ARC elements may amplify or attenuate such signals, depending on
the circumstances.</t>
<t>Reputation systems are complex and usually specific to a given message
receiver, and a meaningful discussion of such a broad topic is beyond
the scope of this document.</t>
</section>
<section anchor="can-i-tell-intermediaries-not-to-use-arc" title="Can I tell intermediaries not to use ARC?">
<t>At present there is no way for a message sender to request that
intermediaries not employ ARC.</t>
</section>
</section>
</middle>
<back>
<references title='Normative References'>
&RFC5321;
&RFC5322;
&RFC7601;
&RFC5598;
</references>
<references title='Informative References'>
&RFC7489;
<reference anchor="OAR" target="https://tools.ietf.org/html/draft-kucherawy-original-authres-00">
<front>
<title>Original-Authentication-Results Header Field</title>
<author initials="M." surname="Chew" fullname="Michael Chew">
<organization></organization>
</author>
<author initials="M." surname="Kucherawy" fullname="Murray Kucherawy">
<organization></organization>
</author>
<date year="2012" month="February" day="20"/>
</front>
</reference>
&RFC7960;
<reference anchor="ENHANCED-STATUS" target="http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml">
<front>
<title>IANA SMTP Enhanced Status Codes</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference anchor="ARC" target="https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-04">
<front>
<title>Authenticated Received Chain (ARC) Protocol</title>
<author initials="K." surname="Andersen" fullname="Kurt Andersen">
<organization></organization>
</author>
<author initials="J." surname="Rae-Grant" fullname="John Rae-Grant">
<organization></organization>
</author>
<author initials="B." surname="Long" fullname="Brandon Long">
<organization></organization>
</author>
<author initials="T." surname="Adams" fullname="Trent Adams">
<organization></organization>
</author>
<author initials="S." surname="Jones" fullname="Steven Jones">
<organization></organization>
</author>
<date year="2017" month="June" day="20"/>
</front>
</reference>
</references>
<section anchor="glossary" title="GLOSSARY">
<t><list style="hanging">
<t hangText='ADMD'>
Administrative Management Domain as used in <xref target="RFC5598"/> and similar
references refers to a single entity operating one or more computers
within one or more domain names under said entity’s control. One
example might be a small company with a single server, handling
email for that company’s domain. Another example might be a large
university, operating many servers that fulfill different roles, all
handling email for several different domains representing parts of
the university.</t>
<t hangText='ARC'>
ARC is an acronym: Authentication Results Chain - see also <xref target="ARC"/></t>
<t hangText='ARC-Seal'>
An <xref target="RFC5322"/> message header field formed in compliance with the ARC
specification. It includes certain content from all prior ARC
participants, if there are any.</t>
<t hangText='ARC-Message-Signature (also abbreviated as “AMS”)'>
An <xref target="RFC5322"/> message header field formed in compliance with the <xref target="ARC"/>
specification. It includes certain content about the message as it
was received and manipulated by the intermediary who inserted it.</t>
<t hangText='ARC-Authentication-Results (also abbreviated as “AAR”)'>
An <xref target="RFC5322"/> message header field formed in compliance with the <xref target="ARC"/>
specification. It includes certain content about the message as it
was received by the intermediary.</t>
<t hangText='Authentication Results Chain (ARC)'>
A system that allows a Message Receiver to identify Intermediaries
or Message Handlers who have conveyed a particular message. For more
information see the Abstract of this document, or refer to <xref target="ARC"/>.</t>
<t hangText='Domain Naming System Block List (DNSBL)'>
This is a system widely used in email filtering services whereby
information about the past activity of a set of hosts or domains
indicates that messages should not be accepted from them, or at
least should be subject to greater scrutiny before being accepted.
Common examples would be SpamCop, Spamhaus.org, SORBS, etc.</t>
<t hangText='Email Service Provider (ESP)'>
An Email Service Provider is typically a vendor or partner firm that
sends mail on behalf of another company. They may use email addresses
in Internet domains belonging to the client or partner firm in
various <xref target="RFC5321"/> fields or <xref target="RFC5322"/> message header fields of the messages
they send on their behalf.</t>
<t hangText='Intermediary'>
In the context of <xref target="ARC"/>, an Intermediary is typically an
Administrative Management Domain (per <xref target="RFC5598"/>) that is receiving
a message, potentially manipulating or altering it, and then passing
it on to another ADMD for delivery. Also see <xref target="RFC7960"/> for
more information and discussion. Common examples of
Intermediaries are mailing lists, alumni or professional email
address providers like universities or professional organizations,
et cetera.</t>
<t hangText='Mail/Message Transfer Agent (MTA)'>
This refers to software that sends and receives email messsages
across a network with other MTAs. Often run on dedicated servers,
common examples are Exim, Microsoft Exchange, Postfix, and Sendmail.</t>
<t hangText='Mailflow'>
A group of messages that share features in common. Typical examples
would be all messages sent by a given Message Sender to a Message
Receiver, related to a particular announcement, a given mailing
list, et cetera.</t>
<t hangText='Malicious Actor'>
A Malicious Actor is a party, often an Intermediary, that will take
actions that seek to exploit or defraud the ultimate recipient of
the message, or subvert the network controls and infrastructure of
the Message Receiver. Typical examples would be a spammer who forges
content or attributes of a message in order to evade anti-spam
measures, or an entity that adds an attachment containing a virus to
a message.</t>
<t hangText='Message Handler'>
A Message Handler is another name for an Intermediary.</t>
<t hangText='Message Receiver'>
In the transmission of an email message from one ADMD to another,
this is the organization receiving the message on behalf of the
intended recipient or end user. The Message Receiver may do this
because the intended recipient is an employee or member of the
organization, or because the end user utilizes email services
provided by the Message Receiver (Comcast, GMail, Yahoo, QQ, et cetera).</t>
<t hangText='Message Sender'>
In the transmission of an email message from one ADMD to another,
this is the organization sending the message on behalf of the
Originator or end user.</t>
<t hangText='Originator'>
This refers to the author of a given email message. In different
contexts it may refer to the end-user writing the message, or the
ADMD providing email services to that end-user.</t>
<t hangText='Reputation'>
In the larger context of email hygiene - blocking spam and malicious
messages - reputation generally refers to a wide variety of
techniques and mechanisms whereby a message receiver uses the past
actions of a sending host or domain to influence the handling of
messages received from them in the future. One of the classic
examples would be a Spamhaus-style DNSBL, where individual IP
addresses will be blocked from sending messages because they’ve been
identified as being bad actors. Very large message receivers may
build and maintain their own reputation systems of this kind,
whereas other organizations might choose to use commercial products
or free services.</t>
<t hangText='Reputation Service Provider'>
A Reputation Service Provider would be a source of reputation
information about a message sender. In this context, the DNSBL
services offered by Spamhaus would allow them to be referred to as
an RPS. Many spam and virus filtering vendors incorporate similar
functionality into their services.</t>
<t hangText='Request For Comment (RFC)'>
RFCs are memoranda that “contain technical and organizational notes
about the Internet.” Created and managed by the Internet Engineering
Task Force (IETF), they are de facto standards for various methods
of communicating or collaborating over the Internet.</t>
<t hangText='RFC5321 - Simple Mail Transfer Protocol'>
This document describes the protocol used to transfer email messages
between Message Transfer Agents (MTA) over a network. Link:
<xref target="RFC5321"/></t>
<t hangText='RFC5322 - Internet Message Format'>
This document describes the format of Internet email messages,
including both the header fields within the message and various types of
content within the message body. Link:
<xref target="RFC5322"/></t>
<t hangText='Validator'>
A Message Receiver that attempts to validate the ARC chain in a
message.</t>
</list></t>
</section>
<section anchor="references" title="References">
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>This draft is the work of OAR-Dev Group.</t>
<t>The authors thanks the entire OAR-Dev group for the ongoing help, innumerable diagrams and
discussions from all the participants, especially: Alex Brotman, Brandon Long, Dave Crocker,
Elizabeth Zwicky, Franck Martin, Greg Colburn, J. Trent Adams, John Rae-Grant, Mike Hammer,
Mike Jones, Steve Jones, Terry Zink, Tim Draegen.</t>
</section>
<section anchor="comments-and-feedback" title="Comments and Feedback">
<t>Please address all comments, discussions, and questions to
the dmarc working group at [https://datatracker.ietf.org/wg/dmarc].</t>
</section>
</back>
</rfc>