forked from dmarc-ietf/id
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-ietf-dmarc-interoperability.txt
1456 lines (980 loc) · 57 KB
/
draft-ietf-dmarc-interoperability.txt
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
DMARC F. Martin, Ed.
Internet-Draft LinkedIn
Intended status: Informational E. Lear, Ed.
Expires: January 19, 2017 Cisco Systems GmbH
T. Draegen, Ed.
dmarcian, inc.
E. Zwicky, Ed.
Yahoo
K. Andersen, Ed.
LinkedIn
July 18, 2016
Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-18
Abstract
DMARC (Domain-based Message Authentication, Reporting, and
Conformance) introduces a mechanism for expressing domain-level
policies and preferences for email message validation, disposition,
and reporting. However, the DMARC mechanism enables potentially
disruptive interoperability issues when messages do not flow directly
from the author's administrative domain to the final recipients.
Collectively these email flows are referred to as indirect email
flows. This document describes these interoperability issues, and
presents possible methods for addressing them.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 19, 2017.
Martin, et al. Expires January 19, 2017 [Page 1]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
Copyright Notice
Copyright (c) 2016 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document Conventions . . . . . . . . . . . . . . . . . . 4
2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4
2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4
2.1.1. DKIM Identifier(s) . . . . . . . . . . . . . . . . . 5
2.1.2. SPF Identifier(s) . . . . . . . . . . . . . . . . . . 5
2.1.3. Multiple RFC5322.From Addresses . . . . . . . . . . . 6
2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 6
2.3. Message Modification . . . . . . . . . . . . . . . . . . 7
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 7
3.1. Message Handling System . . . . . . . . . . . . . . . . . 8
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 8
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 9
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 9
3.1.2.2. Header Standardization . . . . . . . . . . . . . 10
3.1.2.3. Content Validation . . . . . . . . . . . . . . . 10
3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 10
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 12
3.2.3.1. Mailing List Operational Effects . . . . . . . . 13
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 13
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 14
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 15
4. Possible Mitigations of Interoperability Issues . . . . . . . 15
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 16
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 16
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 16
4.1.1.2. Message Modification . . . . . . . . . . . . . . 17
4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 17
Martin, et al. Expires January 19, 2017 [Page 2]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 17
4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 17
4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 17
4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 18
4.1.3.2. Avoiding Message Modification . . . . . . . . . . 18
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 18
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 20
4.2.1. Getting More Radical: Requiring New Communication
Paths Between MUAs . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Appendix A - Example SPF Bounce . . . . . . . . . . 23
A.1. Initial Message . . . . . . . . . . . . . . . . . . . . . 23
A.2. Notification message . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
DMARC [RFC7489] introduces a mechanism for expressing domain-level
policies and preferences for message validation, disposition, and
reporting. The DMARC mechanism, especially when employed with
restrictive policies, encounters several different types of
interoperability issues due to third-party message sourcing, message
transformation, or rerouting. In particular, DMARC with restrictive
policies causes problems for many mailing lists.
At the time of the writing of this document, the DMARC base
specification is published as Informational RFC 7489 [RFC7489] and
has seen significant deployment within the email community.
Cases in which email does not flow directly from the author's
administrative domain to the recipient's domain(s) are collectively
referred to in this document as indirect email flows. Due to
existing and increasing adoption of DMARC, the impact of DMARC-based
email rejection policies on indirect email flows can be significant
for a select subset of general email traffic.
Several known causes of interoperability issues are presented,
followed by a description of components within the Internet Mail
Architecture [RFC5598] where interoperability issues can arise.
Finally, known and possible methods for addressing interoperability
issues are presented. There are often multiple ways to address any
given interoperability issue. While this document strives to be
Martin, et al. Expires January 19, 2017 [Page 3]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
comprehensive in its review, it should not be treated as complete.
Note that some practices which are in use at the time of this
document may or may not be "best practices", especially as future
standards evolve.
1.1. Document Conventions
The notation used in this document for structured fields is taken
from [RFC5598] section 1.3.
The term "notification message" [RFC5321] section 4.5.5 is used to
refer to a message with a null RFC5321.MailFrom.
The terms "Organizational Domain" and "Authenticated Identifiers" are
specified in DMARC [RFC7489] section 3.
2. Causes of Interoperability Issues
Interoperability issues between DMARC and indirect email flows arise
when conformance to the DMARC specification leads a receiving
implementation to apply DMARC-based policy restrictions to messages
that are both compliant with the architecture as specified in
[RFC5598] and viewed as legitimate by the intended recipient.
Note that domains which assert a "p=none" policy and email which
passes standard DMARC validation do not have any interoperability
issues.
Email messages that do not conform to IETF email specifications but
are considered legitimate by the intended recipients are not
discussed in this document.
The rest of this section describes several conceptual causes of
interoperability issues.
2.1. Identifier Alignment
Note to operators and administrators: The identifiers which are used
by SPF are technical components of the transport process for SMTP.
They may or may not, as described below, bear a meaningful
relationship to the content or source of the message itself. This
"relationship by proximity" can be a point of confusion for non-
technical end users, either recipients or senders.
DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message
source validation. The DMARC [RFC7489] specification refers to
source domains that are validated by DKIM or SPF as "Authenticated
Identifiers". To be used by DMARC an "Authenticated Identifier" must
Martin, et al. Expires January 19, 2017 [Page 4]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
also be related to the domain found in the message's RFC5322.From
header field [RFC5322]. This relationship between an Authenticated
Identifier's domain and the domain of the RFC5322.From is referred to
as "Identifier Alignment".
DMARC allows for Identifier Alignment to be determined in two
different modes: strict and relaxed. Strict mode requires an exact
match between the domain of any of the Authenticated Identifiers and
the message's RFC5322.From header field [RFC5322]. Relaxed mode
allows for Identifier Alignment if Authenticated Identifiers and the
message's RFC5322.From header field [RFC5322] share the same
Organizational Domain. In general, DMARC interoperability issues are
the same for both strict and relaxed alignment, but strict alignment
constrains the possible solutions because of the more rigorous
matching requirement. Some of mitigations described in this document
only work with the relaxed mode of Identifier Alignment.
2.1.1. DKIM Identifier(s)
DKIM provides a cryptographic means for one or more domain identifier
to be associated with a particular message. As a standalone
technology DKIM identifiers are not required to be related to the
source of the message's content. However, for a DKIM identifier to
align in DMARC, the signing domain of a valid signature must be part
of the same Organizational Domain as the domain in the RFC5322.From
header field [RFC5322].
In addition, DKIM allows for the possibility of multiple valid
signatures. These multiple signatures may be from the same or
different domains, there are no restrictions within the DKIM
specification. The DMARC mechanism will process Authenticated
Identifiers that are based on DKIM signatures until an aligned
Authenticated Identifier is found (if any). However, operational
experience has shown that some implementations have difficulty
processing multiple signatures. Implementations that cannot process
multiple DKIM signatures may incorrectly flag messages as "not
passing" (DMARC alignment) and erroneously apply DMARC-based policy
to otherwise conforming messages.
2.1.2. SPF Identifier(s)
The SPF specification [RFC7208] defines two Authenticated Identifiers
for each message. These identifiers derive from:
a. the RFC5321.MailFrom [RFC5321] domain, and
b. the RFC5321.HELO/.EHLO SMTP domain.
Martin, et al. Expires January 19, 2017 [Page 5]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is
defined to be based on RFC5321.MailFrom unless that value is absent
(as in the case of notification messages) in which case, the second
(RFC5321.HELO/.EHLO) identifier value is used. This "fallback"
definition has occasionally been misunderstood by operators of MTA
systems since notification messages are often an "automatic" feature
of MTA software. Some MTA software does not provide the ability to
apply a DKIM signature to such notification messages.
See Appendix A for an example treatment of this scenario.
For the purposes of DMARC validation/alignment, the hybrid
RFC7208.MAILFROM [RFC7208] identifier's domain is used if and only if
it is aligned with the RFC5322.From [RFC5322] domain. The alignment
of the validated domain is determined based on the DMARC record's
"strict" or "relaxed" designation as described above for the DKIM
identifiers and in [RFC7489].
2.1.3. Multiple RFC5322.From Addresses
[RFC5322] permits only one From header field, but it may contain
multiple mailboxes. Since this is an extremely rare usage, DMARC
specifies that the handling of this situation is implementation
dependent.
Because the presence of multiple domains can be used by an attacker
(an attacker could add their domain to the RFC5322.From field,
provide arbitrary new content, and sign the message) the DMARC
specification recommends that the strictest policy be applied to such
messages (section 6.6.1 [RFC7489]).
2.2. Message Forwarding
Section 3 describes forwarding behavior as it relates to the
components of the Internet Mail Architecture.
All forwarding operations involve the retransmission of email. As
discussed above, in order for SPF to yield an Authenticated
Identifier that is pertinent to DMARC, the domain of the
RFC7208.MAILFROM must be in alignment with the RFC5322.From header
field. Forwarding introduces specific issues to the availability of
SPF-based Authenticated Identifiers:
o If the RFC5321.MailFrom is present and the forwarder maintains the
original RFC5321.MailFrom, SPF validation will fail unless the
forwarder is an authorized part of the originator's email sending
infrastructure. If the forwarder replaces the RFC5321.MailFrom
Martin, et al. Expires January 19, 2017 [Page 6]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
with its own domain, SPF might pass but Identifier Alignment with
the RFC5322.From header field will fail.
o If the RFC5321.MailFrom is empty (as in the case of Delivery
Status Notifications), the RFC5321.HELO/.EHLO domain of the
forwarder will likely be in a different organizational domain than
the original RFC5322.From header field's domain. SPF may pass but
Identifier Alignment with the RFC5322.From header field will fail.
In both cases, SPF cannot yield relevant Authenticated Identifiers,
and DKIM must be relied upon to produce results that are relevant to
DMARC.
2.3. Message Modification
Modification of email content invalidates most DKIM signatures, and
many message forwarding systems modify email content. Mailing list
processors are a common example of such systems, but other forwarding
systems also make modifications.
Although DKIM provides a length flag so that content can be appended
without invalidating the signature, in practice, particularly with
MIME-encoded [RFC2045] messages, a mailing list processor will do
more than simply append content (see Section 5.3 of [RFC5598] for
details). Furthermore, the length flag is seldom used due to
security issues (see Section 8.2 of [RFC6376] for additional security
considerations), therefore, this method is only here mentioned for
completeness.
DKIM describes two canonicalizations for use when preparing header
and body for DKIM processing: simple and relaxed. The latter is
designed to accommodate trivial modifications to whitespace and
folding which, at least in the header case, generally have no
semantic significance. However, the relaxed canonicalization is more
computationally intensive and may not have been preferred in the
early deployment of DKIM, leaving some deployments using the less
forgiving "simple" canonicalization. While the prevalence is
unknown, there are some DKIM verifiers which have problems evaluating
relaxed canonicalization correctly.
3. Internet Mail Architecture, DMARC, and Indirect Email Flows
This section describes components within the Internet Mail
Architecture [RFC5598] where interoperability issues between DMARC
and indirect email flows can be found.
Martin, et al. Expires January 19, 2017 [Page 7]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
3.1. Message Handling System
Section 4 of [RFC5598] describes six basic components that make up
the Message Handling System (MHS):
o Message
o Message User Agent (MUA)
o Message Submission Agent (MSA)
o Message Transfer Agent (MTA)
o Message Delivery Agent (MDA)
o Message Store (MS)
Of these components MSA, MTA, and MDA are discussed in relation to
interoperability with DMARC.
[RFC5598] Section 5 also defines a Mediator as a hybrid of several
component types. A Mediator is given special consideration in this
section due to the unique issues they face when attempting to
interoperate with DMARC.
3.1.1. Message Submission Agents
An MSA accepts messages submitted by a Message User Agent (MUA) and
enforces the policies of the hosting ADministrative Management Domain
(ADMD) and the requirements of Internet standards.
MSAs are split into two sub-components:
o Author-focused MSA functions (aMSA)
o MHS-focused MSA functions (hMSA)
MSA interoperability issues with DMARC begin when an aMSA accepts a
message where the RFC5322.From header field contains a domain that is
outside of the ADMD of the MSA. This situation manifests in one of
several ways, such as when someone uses a mail service with their own
domain but has failed to properly configure an SPF record; or when an
MUA attempts to transmit mail as someone else. Examples of the
latter situation include "forward-to-friend" functionality commonly
found on news/article websites or "send-as" functionality present on
some MUAs.
Martin, et al. Expires January 19, 2017 [Page 8]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
When an hMSA takes responsibility for transit of a message containing
a domain in the RFC5322.From header field that is outside of the
hMSA's ADMD, the hMSA faces DMARC interoperability issues if the
domain publishes a DMARC policy of "quarantine" or "reject". These
issues are marked by the inherent difficulty of establishing
alignment with the domain present in a message's RFC5322.From header
field. Examples of this issue include:
o Partially-open relays - a residential ISP that allows its
customers to relay non-local domains through its infrastructure.
o Embedded devices - cable/DSL modems, firewalls, wireless access
points, printers that send email using hardcoded domains.
o Devices that send mail on behalf of a user - scanners, security
cameras, alarms that send mail as their owner or a device user.
o Email service providers - ESPs that service customers who are
using domains that publish a DMARC "reject" policy.
o Calendaring software - an invited member of an event modifies the
event causing calendaring software to emit an update that claims
to come from the creator of the event.
3.1.2. Message Transfer Agents
MTAs relay a message until the message reaches a destination MDA.
Some common message handling strategies break the integrity of DKIM
signatures. A restrictive DMARC policy along with a broken DKIM
signature causes latent interoperability problems to become overt
problems.
3.1.2.1. Message Encoding
An MTA may modify the message encoding, for instance by converting
8-bit MIME sections to quoted-printable 7-bit sections. This
modification is outside the scope of DKIM canonicalization and will
invalidate DKIM signatures that include message content.
An MTA could also re-encode the message without changing the encoding
type, receiving a MIME-encoded message and producing a semantically
and semiotically-equivalent MIME body that is not identical to the
original. This is characteristic of systems that use some other
message representation internally.
Martin, et al. Expires January 19, 2017 [Page 9]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
3.1.2.2. Header Standardization
An MTA may rewrite headers to bring them into compliance with
existing RFCs. For example, some common MTAs will correct
comprehensible but non-compliant date formats to compliant ones.
Header rewriting is outside the scope of DKIM canonicalization and
will invalidate DKIM signatures. All downstream DMARC processing
with be unable to utilize DKIM to yield Authenticated Identifiers due
to header rewriting.
Providing solutions for issues relating to non RFC-compliant emails
is outside the scope of this document.
3.1.2.3. Content Validation
An MTA may also implement security-motivated changes to the content
of email messages, dropping or altering sections of messages, causing
breakage of DKIM signatures
3.1.3. Message Delivery Agents
The MDA transfers a message from the MHS to a mailbox. Like the MSA,
the MDA consists of two sub-components:
o MHS-focused MDA functions (hMDA)
o Recipient-focused MDA functions (rMDA)
Both the hMDA and the rMDA can redirect a message to an alternative
address. DMARC interoperability issues related to redirecting of
messages are described in Section 3.2.
SIEVE [RFC5228] functionality often lives in the rMDA sub-component
and can cause DMARC interoperability issues. The SIEVE 'addheader'
and 'deleteheader' filtering actions can modify messages and
invalidate DKIM signatures, removing DKIM-supplied Authenticated
Identifiers as inputs to the DMARC mechanism. There are also SIEVE
extensions [RFC5703] that modify the body. SIEVE alterations may
only become an issue when the email is reintroduced into the
transport infrastructure.
3.2. Mediators
Mediators [RFC5598] forward messages through a re-posting process.
Mediators share some functionality with basic MTA relaying, but have
greater flexibility in both addressing and content modifications.
Martin, et al. Expires January 19, 2017 [Page 10]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
DMARC interoperability issues are common within the context of
Mediators, which are often used precisely for their ability to modify
messages.
The DMARC design does not cope with some Mediator functionality such
as content modifications that invalidate DKIM signatures and
RFC5321.MailFrom rewriting to support SPF authentication of resent
mail when the new Recipient receives the message from the Mediator
rather than the initial organization.
3.2.1. Alias
An Alias is a simple re-addressing facility that provides one or more
new Internet Mail addresses, rather than a single, internal one. A
message continues through the transfer service for delivery to one or
more alternative addresses.
Aliases can be implemented by mailbox-level forwarding (e.g., through
"dot-forwarding") or SIEVE-level forwarding (through the SIEVE
'redirect' action) or other methods. When an Alias preserves message
content and does not make significant header changes, DKIM signatures
may remain valid. However, Aliases often extend the delivery path
outside of the scope covered by the originating ADMD's SPF record(s).
Examples of Aliasing include:
o Forwarding email between free email (freemail) providers to try
different interfaces while maintaining an original email address;
o Consolidating many email addresses into a single account to
centralize processing;
o Services that provide "activity-based", "role-based" , "vanity" or
"temporary" email addresses such as universities and professional
associations. For instance professional or alumni institutions
may offer their members an alias for the duration of their
membership but may not want to deal with the long term storage of
emails.
In most cases, the aMSA providing Alias services has no
administrative relationship to the ADMD of the originator or the
final recipient, so solutions to Alias-related DMARC failure should
not assume such a relationship.
Martin, et al. Expires January 19, 2017 [Page 11]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
3.2.2. ReSenders
ReSenders "splice" a message's addressing information to connect the
Author of the original message with the Recipient(s) of the new
message. The new Recipient sees the message as being from the
original Author, even if the Mediator adds commentary.
Without Authenticated Identifiers aligned with the Author's
RFC5322.From header field domain, the new Recipient has no way to
achieve a passing DMARC evaluation.
Examples of ReSenders include MUA-level forwarding by resending a
message to a new recipient or by forwarding a message "inline" to a
new recipient (this does not include forwarding a message "as an
attachment"). An additional example comes in the form of calendaring
software that allows a meeting attendee (not the meeting organizer)
to modify the content of an invite generating new invitations that
claim to be reissued from the meeting organizer.
3.2.3. Mailing Lists
A Mailing List receives messages as an explicit addressee and then
reposts them to a list of subscribed members. The Mailing List
performs a task that can be viewed as an elaboration of the ReSender
actions.
Mailing Lists share the same DMARC interoperability issues as
ReSenders (Section 3.2.2), and very commonly modify headers or
message content in ways that will cause DKIM to fail, including:
o prepending the RFC5322.Subject header field with a tag, to allow
the recipient to easily identify the mailing list within a subject
line listing;
o adding a footer to the email body to contain administrative
instructions;
o removing some MIME-parts from the email or converting the message
to text only;
o PGP-encrypting or S/MIME encrypting the body with the receiver's
key;
o enforcing community standards by rewriting banned words;
o allowing moderators to add arbitrary commentary to messages
(discussed in [RFC6377]).
Martin, et al. Expires January 19, 2017 [Page 12]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
Any such modifications would invalidate a DKIM signature.
Header and content modifications are common for many mailing lists
and are often central to present mailing list functionality and
usage. Furthermore, MUAs have come to rely on mailing list message
modifications to present messages to end users in expected ways.
3.2.3.1. Mailing List Operational Effects
Mailing Lists may also have the following DMARC interoperability
issues:
o Subscribed members may not receive email from members that post
using domains that publish a DMARC "p=reject" policy.
o Mailing Lists may interpret DMARC-related email rejections as an
inability to deliver email to the recipients that are checking and
enforcing DMARC policy. This processing may cause subscribers
that are checking and enforcing DMARC policy to be inadvertently
suspended or removed from the Mailing List.
3.2.4. Gateways
A Gateway performs the basic routing and transfer work of message
relaying, but it also is permitted to modify content, structure,
addressing, and/or other attributes as needed to send the message
into a messaging environment that operates under different standards
or potentially incompatible policies.
Gateways share the same DMARC interoperability issues as ReSenders
(Section 3.2.2).
Gateways may also share the same DMARC interoperability issues as
MTAs (Section 3.1.2).
Receiver systems on the non-SMTP side of a protocol gateway may be
unable to evaluate DKIM and SPF. If a message passes through a
second protocol gateway back into the SMTP domain, the
transformations commonly break the original DKIM signature(s).
Gateway-level forwarding can introduce DMARC interoperability issues
if the Gateway is configured to rewrite the message into alternate
recipient domains. For example, an acquisition may lead an acquiring
company to decide to decommission the acquired company's domains by
rewriting messages to use the domain of the acquiring company. Since
the RFC5322.To header field is usually DKIM-signed, this kind of
rewriting will invalidate such DKIM signatures.
Martin, et al. Expires January 19, 2017 [Page 13]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
3.2.5. Boundary Filters
To enforce security boundaries, organizations can subject messages to
analysis for conformance with their safety policies. A filter might
alter the content to render it safe, such as by removing or otherwise
altering content deemed unacceptable.
Boundary Filters share the same DMARC interoperability issues as
ReSenders.
Issues may arise with SPF and DKIM evaluation if performed after
filter modifications.
Examples of Boundary Filters include:
o Malware scanning: To protect readers and its reputation, an MTA
that transfers a message may remove content believed to be harmful
from messages, reformulate content to canonical formats in order
to make them more trustworthy or easier to scan, and/or add text
in the body to indicate the message has been scanned. Any such
modifications would invalidate a DKIM signature.
o Spam filtering: To protect reputation and assist other MTAs, an
MTA may modify a message to indicate its decision that the message
is likely to be unwanted, and/or add text in the body to indicate
that such filtering has been done.
o Other text additions: An MTA may add an organizational disclaimer
or advertisement, for instance.
o URL alteration: Some systems will rewrite or alter embedded URLs
as a way to control the potential threat from malware.
o Secondary MX services: The secondary MX for an organization may be
external to the normal mail processing for the organization, and
queue and forward to the primary when it becomes available. This
will not invalidate DKIM but will prevent the primary from
validating SPF normally. In this case, however, it is
inappropriate for a primary MX server to perform an SPF check
against its own secondaries. Rather, the secondary MX should
perform this function and employ some trusted mechanism to
communicate the results of the SPF, DKIM, and DMARC evaluation(s)
to the primary MX server.
Martin, et al. Expires January 19, 2017 [Page 14]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
3.3. Combinations
Indirect email flows can be combined. For example, a university
student may subscribe to a mailing list (using his university email
address) while this university email address is configured to forward
all emails to a freemail or a post-education corporate account
provider where a more permanent email address for this student
exists.
Within an organization the message may pass through various MTAs
(Section 3.1.2), each of which performs a different function
(authentication, filtering, distribution, etc.)
4. Possible Mitigations of Interoperability Issues
Solutions to interoperability issues between DMARC and indirect email
flows vary widely in their scope and implications. They range from
improvements to underlying processing, such as proper handling of
multiple DKIM signatures, to more radical changes to the messaging
architecture. This section describes possible ways to address
interoperability issues. Note that these particular mechanisms may
not be considered "best practices" and may, in some cases, violate
various conventions or expectations.
Receivers sometimes need to deliver email messages that do not
conform to any standard or protocol, but are otherwise desired by end
users. Mitigating the impact of DMARC on indirect email flows is
especially important to receivers that operate services where ease of
use and compatibility with existing email flows is a priority.
DMARC provides a mechanism (local policy) for receivers to make
decisions about identity alignment acceptability based on information
outside DMARC and communicate those decisions as "overrides" to the
sender. This facility can be used to ease some interoperability
issues, although care is needed to ensure that this does not create
loopholes for abuse.
To further complicate the usage of mitigations, mitigation may not be
desired if the email in question is of a certain category of high
value or high risk (security-related) transactional messages (dealing
with financial transactions or medical records, for example). In
these cases, mitigating the impact of DMARC due to indirect email
flows may not be desirable (counterproductive or allowing for abuse).
As a final note, mail systems are diverse and widely deployed.
Systems of various ages and capabilities are expected to preserve
interoperability with the rest of the SMTP ecosystem. For instance,
Qmail is still used, although the base code has not been updated
Martin, et al. Expires January 19, 2017 [Page 15]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
since 1998. ezmlm, a once popular mailing list manager, is still
deployed but has not been updated since 1997, although a new version,
ezmlm-idx exists. Old versions of other open and closed source MTAs
are still commonly in operation. When dealing with aging or
unsupported systems, some solutions may be time-consuming and/or
disruptive to implement.
4.1. Mitigations in Current Use
Because DMARC is already widely deployed, many operators already have
mitigations in use. These mitigations vary in their effectiveness
and side effects, but have the advantage that they are currently
available.
4.1.1. Mitigations for Senders
4.1.1.1. Identifier Alignment
o MTAs handling multiple domains may choose to change
RFC5321.MailFrom to align with RFC5322.From to improve SPF
usability for DMARC.
o MTAs handling multiple domains may also choose to align
RFC5321.HELO/.EHLO to RFC5322.From, particularly when sending
notification messages. Dynamically adjusting the
RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible
for some MTA software.
o MTAs may choose to DKIM-sign notification messages with an aligned
domain to allow a DKIM-based DMARC pass.
o MTAs sending email on behalf of multiple domains may require
Domain Owners to provide DKIM keys to use DKIM to avoid SPF
validation issues, given the requirement for DMARC alignment with
the RFC5322.From header field. Managing DKIM keys with a third
party has security risks that should be carefully managed (see
also [RFC6376] section 8). Methods involving CNAMEs and/or
subdomains may alleviate some risks.
o Senders who are sending on behalf of users in other Administrative
Domains may choose to use an RFC5322.From under the sender's
control. The new From can be either a forwarding address in a
domain controlled by the Sender, or a placeholder address, with
the original user's address in an RFC5322.Reply-to header field.
However, performing this modification may cause the recipient's
MUA to deviate from customary behavior.
Martin, et al. Expires January 19, 2017 [Page 16]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
o When implementing "forward-to-friend" functionality, one approach
to avoid DMARC failures is to pass a well-formed message to the
user's MUA so that it may fill in an appropriate identity and
submit through its own MSA.
o Senders can use domains with distinct DMARC policies for email
sent directly and email known to use indirect mail flows.
However, for most well-known brands, all active domains are likely
to be targeted equally by abusers.
4.1.1.2. Message Modification
o Senders can maximize survivability of DKIM signatures by limiting
the header fields they sign and using relaxed canonicalization.
Using the DKIM length tag to allow appended signatures is
discouraged due to the security risk created by allowing arbitrary
content to be appended to legitimate email.
o Senders can also maximize survivability by starting with RFC-
compliant headers and common body formats.
o In order to minimize transport-based conversions, Senders can
convert messages to a lowest denominator MIME content-transfer
encoding such as quoted-printable or base64 before signing
([RFC6376] Section 5.3).
4.1.2. Mitigations for Receivers
4.1.2.1. Identifier Alignment
o Receivers should update DKIM handling libraries to ensure that
they process all valid DKIM signatures and check each signature
for alignment.
4.1.2.2. Policy Override
o Receivers can amalgamate data from their user base to create lists
of forwarders and use such lists to inform DMARC local policy
overrides. This process may be easier for large receivers where
data and resources to create such lists are more readily available
than at smaller sites where the recipient footprint and other
resources may be scarce.
4.1.3. Mitigations for ReSenders
Martin, et al. Expires January 19, 2017 [Page 17]
Internet-Draft DMARC Indirect Email Interop Issues July 2016
4.1.3.1. Changes to the RFC5322.From
Many ReSender issues can be avoided by using an RFC5322.From header
field under the ReSender's control, instead of the initial
RFC5322.From. This will correct identifier alignment issues and
allow arbitrary message modification as long as the ReSender signs
the message with an aligned domain signature. When ReSenders change
the RFC5322.From, it is desirable to preserve the information about
the original initiator of the message.
A first option is to use the Original-From [RFC5703] (or X-Original-
From) header field for this purpose in various contexts (X- header
field names are discouraged by [RFC6648]). However, handling of
Original-From (or X-Original-From) is not defined anywhere. It is
not currently used consistently or displayed to the user, and in any
situation where it is used, it is a new unauthenticated identifier
available for exploitation unless included within the scope of the
new DKIM signature(s).
Another option for ReSenders is to rewrite the RFC5322.From header
field address to a locally controlled address which will be forwarded
back to the original sender (subject to its own ReSender forwarding
mitigations!).
4.1.3.2. Avoiding Message Modification
o Forwarders can choose to add email header fields instead of
modifying existing headers or bodies, for instance to indicate a
message may be spam.
o Forwarders can minimize the circumstances in which they choose to
fix messages, preferring to preserve non-compliant headers to
creating DKIM failures.
o Forwarders can choose to reject messages with suspect or harmful
content instead of modifying them.
4.1.3.3. Mailing Lists
[RFC6377] provides some guidance on using DKIM with Mailing lists.
The following mitigation techniques can be used to ease
interoperability issues with DMARC and Mailing lists:
o Configuring the Mailing List Manager (MLM) to alter the