1 ../smtpserver/reputation.go:96
2
3
4
5
6
7Internet Engineering Task Force (IETF) F. Martin, Ed.
8Request for Comments: 7960 LinkedIn
9Category: Informational E. Lear, Ed.
10ISSN: 2070-1721 Cisco Systems GmbH
11 T. Draegen, Ed.
12 dmarcian, inc.
13 E. Zwicky, Ed.
14 Yahoo
15 K. Andersen, Ed.
16 LinkedIn
17 September 2016
18
19
20 Interoperability Issues between Domain-based Message Authentication,
21 Reporting, and Conformance (DMARC) and Indirect Email Flows
22
23Abstract
24
25 Domain-based Message Authentication, Reporting, and Conformance
26 (DMARC) introduces a mechanism for expressing domain-level policies
27 and preferences for email message validation, disposition, and
28 reporting. However, the DMARC mechanism enables potentially
29 disruptive interoperability issues when messages do not flow directly
30 from the author's administrative domain to the final Recipients.
31 Collectively, these email flows are referred to as "indirect email
32 flows". This document describes these interoperability issues and
33 presents possible methods for addressing them.
34
35Status of This Memo
36
37 This document is not an Internet Standards Track specification; it is
38 published for informational purposes.
39
40 This document is a product of the Internet Engineering Task Force
41 (IETF). It represents the consensus of the IETF community. It has
42 received public review and has been approved for publication by the
43 Internet Engineering Steering Group (IESG). Not all documents
44 approved by the IESG are a candidate for any level of Internet
45 Standard; see Section 2 of RFC 7841.
46
47 Information about the current status of this document, any errata,
48 and how to provide feedback on it may be obtained at
49 http://www.rfc-editor.org/info/rfc7960.
50
51
52
53
54
55
56
57
58Martin, et al. Informational [Page 1]
59
60RFC 7960 DMARC Indirect Email Interop Issues September 2016
61
62
63Copyright Notice
64
65 Copyright (c) 2016 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
67
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
77
78Table of Contents
79
80 1. Introduction ....................................................3
81 1.1. Document Conventions .......................................4
82 2. Causes of Interoperability Issues ...............................4
83 2.1. Identifier Alignment .......................................4
84 2.1.1. DKIM Identifier(s) ..................................5
85 2.1.2. SPF Identifier(s) ...................................6
86 2.1.3. Multiple RFC5322.From Addresses .....................6
87 2.2. Message Forwarding .........................................6
88 2.3. Message Modification .......................................7
89 3. Internet Mail Architecture, DMARC, and Indirect Email Flows .....8
90 3.1. Message Handling System ....................................8
91 3.1.1. Message Submission Agents ...........................8
92 3.1.2. Message Transfer Agents .............................9
93 3.1.2.1. Message Encoding ...........................9
94 3.1.2.2. Header Standardization ....................10
95 3.1.2.3. Content Validation ........................10
96 3.1.3. Message Delivery Agents ............................10
97 3.2. Mediators .................................................11
98 3.2.1. Alias ..............................................11
99 3.2.2. ReSenders ..........................................12
100 3.2.3. Mailing Lists ......................................12
101 3.2.3.1. Mailing List Operational Effects ..........13
102 3.2.4. Gateways ...........................................13
103 3.2.5. Boundary Filters ...................................14
104 3.3. Combinations ..............................................15
105 4. Possible Mitigations of Interoperability Issues ................15
106 4.1. Mitigations in Current Use ................................16
107 4.1.1. Mitigations for Senders ............................16
108 4.1.1.1. Identifier Alignment ......................16
109 4.1.1.2. Message Modification ......................17
110 4.1.2. Mitigations for Receivers ..........................17
111
112
113
114Martin, et al. Informational [Page 2]
115
116RFC 7960 DMARC Indirect Email Interop Issues September 2016
117
118
119 4.1.2.1. Identifier Alignment ......................17
120 4.1.2.2. Policy Override ...........................17
121 4.1.3. Mitigations for ReSenders ..........................18
122 4.1.3.1. Changes to the RFC5322.From ...............18
123 4.1.3.2. Avoiding Message Modification .............18
124 4.1.3.3. Mailing Lists .............................18
125 4.2. Proposed and In-Progress Mitigations ......................20
126 4.2.1. Getting More Radical: Requiring New
127 Communication Paths between MUAs ...................21
128 5. Security Considerations ........................................21
129 6. References .....................................................22
130 6.1. Normative References ......................................22
131 6.2. Informative References ....................................23
132 Appendix A. Example SPF Bounce ...................................24
133 A.1. Initial Message ...........................................24
134 A.2. Notification Message ......................................25
135 Acknowledgments ...................................................26
136 Authors' Addresses ................................................27
137
1381. Introduction
139
140 DMARC [RFC7489] introduces a mechanism for expressing domain-level
141 policies and preferences for message validation, disposition, and
142 reporting. The DMARC mechanism, especially when employed with
143 restrictive policies, encounters several different types of
144 interoperability issues due to third-party message sourcing, message
145 transformation, or rerouting. In particular, DMARC with restrictive
146 policies causes problems for many Mailing Lists.
147
148 At the time of writing this document, the DMARC base specification
149 has been published as Informational RFC 7489 [RFC7489] and has seen
150 significant deployment within the email community.
151
152 Cases in which email does not flow directly from the author's
153 administrative domain to the recipient's domain(s) are collectively
154 referred to in this document as "indirect email flows". Due to
155 existing and increasing adoption of DMARC, the impact of DMARC-based
156 email rejection policies on indirect email flows can be significant
157 for a select subset of general email traffic.
158
159 Several known causes of interoperability issues are presented,
160 followed by a description of components within the Internet Mail
161 Architecture [RFC5598] where interoperability issues can arise.
162
163 Finally, known and possible methods for addressing interoperability
164 issues are presented. There are often multiple ways to address any
165 given interoperability issue. While this document strives to be
166 comprehensive in its review, it should not be treated as complete.
167
168
169
170Martin, et al. Informational [Page 3]
171
172RFC 7960 DMARC Indirect Email Interop Issues September 2016
173
174
175 Note that some practices that are in use at the time of this document
176 may or may not be "best practices", especially as future standards
177 evolve.
178
1791.1. Document Conventions
180
181 The notation used in this document for structured fields is taken
182 from [RFC5598], Section 1.3.
183
184 The term "notification message" ([RFC5321], Section 4.5.5) is used to
185 refer to a message with a null RFC5321.MailFrom.
186
187 The terms "Organizational Domain" and "Authenticated Identifiers" are
188 specified in DMARC ([RFC7489], Section 3).
189
190 All words that begin with capital letters take their formal meanings
191 from these references.
192
1932. Causes of Interoperability Issues
194
195 Interoperability issues between DMARC and indirect email flows arise
196 when conformance to the DMARC specification leads a receiving
197 implementation to apply DMARC-based policy restrictions to messages
198 that are both compliant with the architecture as specified in
199 [RFC5598] and viewed as legitimate by the intended Recipient.
200
201 Note that domains that assert a "p=none" policy and email messages
202 that pass standard DMARC validation do not have any interoperability
203 issues.
204
205 Email messages that do not conform to IETF email specifications but
206 are considered legitimate by the intended Recipients are not
207 discussed in this document.
208
209 The rest of this section describes several conceptual causes of
210 interoperability issues.
211
2122.1. Identifier Alignment
213
214 Note to operators and administrators: The identifiers that are used
215 by the Sender Policy Framework (SPF) are technical components of the
216 transport process for SMTP. They may or may not, as described below,
217 bear a meaningful relationship to the content or source of the
218 message itself. This "relationship by proximity" can be a point of
219 confusion for non-technical end users, either recipients or senders.
220
221
222
223
224
225
226Martin, et al. Informational [Page 4]
227
228RFC 7960 DMARC Indirect Email Interop Issues September 2016
229
230
231 DMARC relies on DomainKeys Identified Mail (DKIM) [RFC6376] and SPF
232 [RFC7208] to perform message source validation. The DMARC [RFC7489]
233 specification refers to source domains that are validated by DKIM or
234 SPF as "Authenticated Identifiers". To be used by DMARC, an
235 "Authenticated Identifier" must also be related to the domain found
236 in the message's RFC5322.From header field [RFC5322]. This
237 relationship between an Authenticated Identifier's domain and the
238 domain of the RFC5322.From is referred to as "Identifier Alignment".
239
240 DMARC allows for Identifier Alignment to be determined in two
241 different modes: strict and relaxed. Strict mode requires an exact
242 match between the domain of any of the Authenticated Identifiers and
243 the message's RFC5322.From header field [RFC5322]. Relaxed mode
244 allows for Identifier Alignment if Authenticated Identifiers and the
245 message's RFC5322.From header field [RFC5322] share the same
246 Organizational Domain. In general, DMARC interoperability issues are
247 the same for both strict and relaxed alignment, but strict alignment
248 constrains the possible solutions because of the more rigorous
249 matching requirement. Some of the mitigations described in this
250 document only work with the relaxed mode of Identifier Alignment.
251
2522.1.1. DKIM Identifier(s)
253
254 DKIM provides a cryptographic means for one or more domain
255 identifiers to be associated with a particular message. As a
256 standalone technology, DKIM identifiers are not required to be
257 related to the source of the message's content. However, for a DKIM
258 identifier to align in DMARC, the signing domain of a valid signature
259 must be part of the same Organizational Domain as the domain in the
260 RFC5322.From header field [RFC5322].
261
262 In addition, DKIM allows for the possibility of multiple valid
263 signatures. These multiple signatures may be from the same or
264 different domains; there are no restrictions within the DKIM
265 specification. The DMARC mechanism will process Authenticated
266 Identifiers that are based on DKIM signatures until an aligned
267 Authenticated Identifier is found (if any). However, operational
268 experience has shown that some implementations have difficulty
269 processing multiple signatures. Implementations that cannot process
270 multiple DKIM signatures may incorrectly flag messages as "not
271 passing" (DMARC alignment) and erroneously apply DMARC-based policy
272 to otherwise conforming messages.
273
274
275
276
277
278
279
280
281
282Martin, et al. Informational [Page 5]
283
284RFC 7960 DMARC Indirect Email Interop Issues September 2016
285
286
2872.1.2. SPF Identifier(s)
288
289 The SPF specification [RFC7208] defines two Authenticated Identifiers
290 for each message. These identifiers derive from:
291
292 a. the RFC5321.MailFrom [RFC5321] domain, and
293
294 b. the RFC5321.HELO/.EHLO SMTP domain.
295
296 In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is
297 defined to be based on RFC5321.MailFrom unless that value is absent
298 (as in the case of notification messages), in which case, the second
299 (RFC5321.HELO/.EHLO) identifier value is used. This "fallback"
300 definition has occasionally been misunderstood by operators of MTA
301 systems since notification messages are often an "automatic" feature
302 of MTA software. Some MTA software does not provide the ability to
303 apply a DKIM signature to such notification messages.
304
305 See Appendix A for an example treatment of this scenario.
306
307 For the purposes of DMARC validation/alignment, the hybrid
308 RFC7208.MAILFROM [RFC7208] identifier's domain is used if and only if
309 it is aligned with the RFC5322.From [RFC5322] domain. The alignment
310 of the validated domain is determined based on the DMARC record's
311 "strict" or "relaxed" designation as described above for the DKIM
312 identifiers and in [RFC7489].
313
3142.1.3. Multiple RFC5322.From Addresses
315
316 [RFC5322] permits only one From header field, but it may contain
317 multiple mailboxes. Since this is an extremely rare usage, DMARC
318 specifies that the handling of this situation is implementation
319 dependent.
320
321 Because the presence of multiple domains can be used by an attacker
322 (an attacker could add their domain to the RFC5322.From field,
323 provide arbitrary new content, and sign the message), the DMARC
324 specification recommends that the strictest policy be applied to such
325 messages (Section 6.6.1 of [RFC7489]).
326
3272.2. Message Forwarding
328
329 Section 3 describes forwarding behavior as it relates to the
330 components of the Internet Mail Architecture.
331
332 All forwarding operations involve the retransmission of email. As
333 discussed above, in order for SPF to yield an Authenticated
334 Identifier that is pertinent to DMARC, the domain of the
335
336
337
338Martin, et al. Informational [Page 6]
339
340RFC 7960 DMARC Indirect Email Interop Issues September 2016
341
342
343 RFC7208.MAILFROM must be in alignment with the RFC5322.From header
344 field. Forwarding introduces specific issues to the availability of
345 SPF-based Authenticated Identifiers:
346
347 o If the RFC5321.MailFrom is present and the forwarder maintains the
348 original RFC5321.MailFrom, SPF validation will fail unless the
349 forwarder is an authorized part of the originator's email sending
350 infrastructure. If the forwarder replaces the RFC5321.MailFrom
351 with its own domain, SPF might pass, but Identifier Alignment with
352 the RFC5322.From header field will fail.
353
354 o If the RFC5321.MailFrom is empty (as in the case of Delivery
355 Status Notifications), the RFC5321.HELO/.EHLO domain of the
356 forwarder will likely be in a different Organizational Domain than
357 the original RFC5322.From header field's domain. SPF may pass,
358 but Identifier Alignment with the RFC5322.From header field will
359 fail.
360
361 In both cases, SPF cannot yield relevant Authenticated Identifiers,
362 and DKIM must be relied upon to produce results that are relevant to
363 DMARC.
364
3652.3. Message Modification
366
367 Modification of email content invalidates most DKIM signatures, and
368 many message-forwarding systems modify email content. Mailing List
369 processors are a common example of such systems, but other forwarding
370 systems also make modifications.
371
372 Although DKIM provides a length flag so that content can be appended
373 without invalidating the signature, in practice, particularly with
374 MIME-encoded [RFC2045] messages, a Mailing List processor will do
375 more than simply append content (see Section 5.3 of [RFC5598] for
376 details). Furthermore, the length flag is seldom used due to
377 security issues (see Section 8.2 of [RFC6376] for additional security
378 considerations). Therefore, this method is only mentioned here for
379 completeness.
380
381 DKIM describes two canonicalizations for use when preparing the
382 header and body for DKIM processing: simple and relaxed. The latter
383 is designed to accommodate trivial modifications to whitespace and
384 folding that, at least in the header case, generally have no semantic
385 significance. However, the relaxed canonicalization is more
386 computationally intensive and may not have been preferred in the
387 early deployment of DKIM, leaving some deployments using the less
388 forgiving "simple" canonicalization. While the prevalence is
389 unknown, there are some DKIM verifiers that have problems evaluating
390 relaxed canonicalization correctly.
391
392
393
394Martin, et al. Informational [Page 7]
395
396RFC 7960 DMARC Indirect Email Interop Issues September 2016
397
398
3993. Internet Mail Architecture, DMARC, and Indirect Email Flows
400
401 This section describes components within the Internet Mail
402 Architecture [RFC5598] where interoperability issues between DMARC
403 and indirect email flows can be found.
404
4053.1. Message Handling System
406
407 Section 4 of [RFC5598] describes six basic components that make up
408 the Message Handling System (MHS):
409
410 o Message
411
412 o Message User Agent (MUA)
413
414 o Message Submission Agent (MSA)
415
416 o Message Transfer Agent (MTA)
417
418 o Message Delivery Agent (MDA)
419
420 o Message Store (MS)
421
422 Of these components, MSA, MTA, and MDA are discussed in relation to
423 interoperability with DMARC.
424
425 Section 5 of [RFC5598] also defines a Mediator as a hybrid of several
426 component types. A Mediator is given special consideration in this
427 section due to the unique issues they face when attempting to
428 interoperate with DMARC.
429
4303.1.1. Message Submission Agents
431
432 An MSA accepts messages submitted by a Message User Agent (MUA) and
433 enforces the policies of the hosting ADministrative Management Domain
434 (ADMD) and the requirements of Internet standards.
435
436 MSAs are split into two sub-components:
437
438 o Author-focused MSA functions (aMSA)
439
440 o MHS-focused MSA functions (hMSA)
441
442 MSA interoperability issues with DMARC begin when an aMSA accepts a
443 message where the RFC5322.From header field contains a domain that is
444 outside of the ADMD of the MSA. This situation manifests in one of
445 several ways, such as when someone uses a mail service with their own
446 domain but has failed to properly configure an SPF record or when an
447
448
449
450Martin, et al. Informational [Page 8]
451
452RFC 7960 DMARC Indirect Email Interop Issues September 2016
453
454
455 MUA attempts to transmit mail as someone else. Examples of the
456 latter situation include "forward-to-friend" functionality commonly
457 found on news/article websites or "send-as" functionality present on
458 some MUAs.
459
460 When an hMSA takes responsibility for transit of a message containing
461 a domain in the RFC5322.From header field that is outside of the
462 hMSA's ADMD, the hMSA faces DMARC interoperability issues if the
463 domain publishes a DMARC policy of "quarantine" or "reject". These
464 issues are marked by the inherent difficulty of establishing
465 alignment with the domain present in a message's RFC5322.From header
466 field. Examples of this issue include:
467
468 o Partially open relays - a residential ISP that allows its
469 customers to relay non-local domains through its infrastructure.
470
471 o Embedded devices - cable/DSL modems, firewalls, wireless access
472 points, and printers that send email using hardcoded domains.
473
474 o Devices that send mail on behalf of a user - scanners, security
475 cameras, and alarms that send mail as their owner or a device
476 user.
477
478 o Email service providers - ESPs that service customers who are
479 using domains that publish a DMARC "reject" policy.
480
481 o Calendaring software - an invited member of an event modifies the
482 event, causing the calendaring software to emit an update that
483 claims to come from the creator of the event.
484
4853.1.2. Message Transfer Agents
486
487 MTAs relay a message until the message reaches a destination MDA.
488 Some common message-handling strategies break the integrity of DKIM
489 signatures. A restrictive DMARC policy along with a broken DKIM
490 signature causes latent interoperability problems to become overt
491 problems.
492
4933.1.2.1. Message Encoding
494
495 An MTA may modify the message encoding, for instance, by converting
496 8-bit MIME sections to quoted-printable 7-bit sections. This
497 modification is outside the scope of DKIM canonicalization and will
498 invalidate DKIM signatures that include message content.
499
500
501
502
503
504
505
506Martin, et al. Informational [Page 9]
507
508RFC 7960 DMARC Indirect Email Interop Issues September 2016
509
510
511 An MTA could also re-encode the message without changing the encoding
512 type: receiving a MIME-encoded message and producing a semantically
513 and semiotically equivalent MIME body that is not identical to the
514 original. This is characteristic of systems that use some other
515 message representation internally.
516
5173.1.2.2. Header Standardization
518
519 An MTA may rewrite headers to bring them into compliance with
520 existing RFCs. For example, some common MTAs will correct
521 comprehensible but non-compliant date formats to compliant ones.
522
523 Header rewriting is outside the scope of DKIM canonicalization and
524 will invalidate DKIM signatures. All downstream DMARC processing
525 with be unable to utilize DKIM to yield Authenticated Identifiers due
526 to header rewriting.
527
528 Providing solutions for issues relating to non-RFC-compliant emails
529 is outside the scope of this document.
530
5313.1.2.3. Content Validation
532
533 An MTA may also implement security-motivated changes to the content
534 of email messages, dropping or altering sections of messages, causing
535 breakage of DKIM signatures.
536
5373.1.3. Message Delivery Agents
538
539 The MDA transfers a message from the MHS to a mailbox. Like the MSA,
540 the MDA consists of two sub-components:
541
542 o MHS-focused MDA functions (hMDA)
543
544 o Recipient-focused MDA functions (rMDA)
545
546 Both the hMDA and the rMDA can redirect a message to an alternative
547 address. DMARC interoperability issues related to redirecting of
548 messages are described in Section 3.2.
549
550 Sieve [RFC5228] functionality often lives in the rMDA sub-component
551 and can cause DMARC interoperability issues. The Sieve 'addheader'
552 and 'deleteheader' filtering actions can modify messages and
553 invalidate DKIM signatures, removing DKIM-supplied Authenticated
554 Identifiers as inputs to the DMARC mechanism. There are also Sieve
555 extensions [RFC5703] that modify the body. Sieve alterations may
556 only become an issue when the email is reintroduced into the
557 transport infrastructure.
558
559
560
561
562Martin, et al. Informational [Page 10]
563
564RFC 7960 DMARC Indirect Email Interop Issues September 2016
565
566
5673.2. Mediators
568
569 Mediators [RFC5598] forward messages through a re-posting process.
570 Mediators share some functionality with basic MTA relaying but have
571 greater flexibility in both addressing and content modifications.
572
573 DMARC interoperability issues are common within the context of
574 Mediators, which are often used precisely for their ability to modify
575 messages.
576
577 The DMARC design does not cope with some Mediator functionality such
578 as content modifications that invalidate DKIM signatures and
579 RFC5321.MailFrom rewriting to support SPF authentication of re-sent
580 mail when the new Recipient receives the message from the Mediator
581 rather than the initial organization.
582
5833.2.1. Alias
584
585 An Alias is a simple re-addressing facility that provides one or more
586 new Internet Mail addresses, rather than a single, internal one. A
587 message continues through the transfer service for delivery to one or
588 more alternative addresses.
589
590 Aliases can be implemented by mailbox-level forwarding (e.g., through
591 "dot-forwarding"), Sieve-level forwarding (through the Sieve
592 "redirect" action), or other methods. When an Alias preserves
593 message content and does not make significant header changes, DKIM
594 signatures may remain valid. However, Aliases often extend the
595 delivery path outside of the scope covered by the originating ADMD's
596 SPF record(s).
597
598 Examples of Aliasing include:
599
600 o Forwarding email between free email (freemail) providers to try
601 different interfaces while maintaining an original email address;
602
603 o Consolidating many email addresses into a single account to
604 centralize processing; and
605
606 o Services that provide "activity-based", "role-based", "vanity", or
607 "temporary" email addresses such as universities and professional
608 associations. For instance, professional or alumni institutions
609 may offer their members an Alias for the duration of their
610 membership but may not want to deal with the long-term storage of
611 emails.
612
613
614
615
616
617
618Martin, et al. Informational [Page 11]
619
620RFC 7960 DMARC Indirect Email Interop Issues September 2016
621
622
623 In most cases, the aMSA providing Alias services has no
624 administrative relationship to the ADMD of the originator or the
625 Final Recipient, so solutions to Alias-related DMARC failure should
626 not assume such a relationship.
627
6283.2.2. ReSenders
629
630 ReSenders "splice" a message's addressing information to connect the
631 Author of the original message with the Recipient(s) of the new
632 message. The new Recipient sees the message as being from the
633 original Author, even if the Mediator adds commentary.
634
635 Without Authenticated Identifiers aligned with the Author's
636 RFC5322.From header field domain, the new Recipient has no way to
637 achieve a passing DMARC evaluation.
638
639 Examples of ReSenders include MUA-level forwarding by resending a
640 message to a new Recipient or by forwarding a message "inline" to a
641 new Recipient (this does not include forwarding a message "as an
642 attachment"). An additional example comes in the form of calendaring
643 software that allows a meeting attendee (not the meeting organizer)
644 to modify the content of an invite generating new invitations that
645 claim to be reissued from the meeting organizer.
646
6473.2.3. Mailing Lists
648
649 A Mailing List receives messages as an explicit addressee and then
650 reposts them to a list of subscribed members. The Mailing List
651 performs a task that can be viewed as an elaboration of the ReSender
652 actions.
653
654 Mailing Lists share the same DMARC interoperability issues as
655 ReSenders (Section 3.2.2) and very commonly modify headers or message
656 content in ways that will cause DKIM to fail, including:
657
658 o prepending the RFC5322.Subject header field with a tag, to allow
659 the Recipient to easily identify the Mailing List within a subject
660 line listing;
661
662 o adding a footer to the email body to contain administrative
663 instructions;
664
665 o removing some MIME-parts from the email or converting the message
666 to text only;
667
668 o encrypting the body with the Recipient's key using PGP (Pretty
669 Good Privacy) or S/MIME;
670
671
672
673
674Martin, et al. Informational [Page 12]
675
676RFC 7960 DMARC Indirect Email Interop Issues September 2016
677
678
679 o enforcing community standards by rewriting banned words; and
680
681 o allowing moderators to add arbitrary commentary to messages
682 (discussed in [RFC6377]).
683
684 Any such modifications would invalidate a DKIM signature.
685
686 Header and content modifications are common for many Mailing Lists
687 and are often central to present Mailing List functionality and
688 usage. Furthermore, MUAs have come to rely on Mailing List message
689 modifications to present messages to end users in expected ways.
690
6913.2.3.1. Mailing List Operational Effects
692
693 Mailing Lists may also have the following DMARC interoperability
694 issues:
695
696 o Subscribed members may not receive email from members that post
697 using domains that publish a DMARC "p=reject" policy.
698
699 o Mailing Lists may interpret DMARC-related email rejections as an
700 inability to deliver email to the Recipients that are checking and
701 enforcing DMARC policy. This processing may cause subscribers
702 that are checking and enforcing DMARC policy to be inadvertently
703 suspended or removed from the Mailing List.
704
7053.2.4. Gateways
706
707 A Gateway performs the basic routing and transfer work of message
708 relaying, but it is also permitted to modify content, structure,
709 addressing, and/or other attributes as needed to send the message
710 into a messaging environment that operates under different standards
711 or potentially incompatible policies.
712
713 Gateways share the same DMARC interoperability issues as ReSenders
714 (Section 3.2.2).
715
716 Gateways may also share the same DMARC interoperability issues as
717 MTAs (Section 3.1.2).
718
719 Receiver systems on the non-SMTP side of a protocol Gateway may be
720 unable to evaluate DKIM and SPF. If a message passes through a
721 second protocol Gateway back into the SMTP domain, the
722 transformations commonly break the original DKIM signature(s).
723
724 Gateway-level forwarding can introduce DMARC interoperability issues
725 if the Gateway is configured to rewrite the message into alternate
726 receiving domains. For example, an acquisition may lead an acquiring
727
728
729
730Martin, et al. Informational [Page 13]
731
732RFC 7960 DMARC Indirect Email Interop Issues September 2016
733
734
735 company to decide to decommission the acquired company's domains by
736 rewriting messages to use the domain of the acquiring company. Since
737 the RFC5322.To header field is usually DKIM-signed, this kind of
738 rewriting will invalidate such DKIM signatures.
739
7403.2.5. Boundary Filters
741
742 To enforce security boundaries, organizations can subject messages to
743 analysis for conformance with their safety policies. A filter might
744 alter the content to render it safe, such as by removing or otherwise
745 altering content deemed unacceptable.
746
747 Boundary Filters share the same DMARC interoperability issues as
748 ReSenders.
749
750 Issues may arise with SPF and DKIM evaluation if performed after
751 filter modifications.
752
753 Examples of Boundary Filters include:
754
755 o Malware scanning: To protect readers and its reputation, an MTA
756 that transfers a message may remove content believed to be harmful
757 from messages, reformulate content to canonical formats in order
758 to make them more trustworthy or easier to scan, and/or add text
759 in the body to indicate the message has been scanned. Any such
760 modifications would invalidate a DKIM signature.
761
762 o Spam filtering: To protect its reputation and assist other MTAs,
763 an MTA may modify a message to indicate its decision that the
764 message is likely to be unwanted and/or add text in the body to
765 indicate that such filtering has been done.
766
767 o Other text additions: An MTA may add an organizational disclaimer
768 or advertisement, for instance.
769
770 o URL alteration: Some systems will rewrite or alter embedded URLs
771 as a way to control the potential threat from malware.
772
773 o Secondary MX services: The secondary MX for an organization may be
774 external to the normal mail processing for the organization, and
775 it may queue and forward to the primary when it becomes available.
776 This will not invalidate DKIM but will prevent the primary from
777 validating SPF normally. In this case, however, it is
778 inappropriate for a primary MX server to perform an SPF check
779 against its own secondaries. Rather, the secondary MX should
780 perform this function and employ some trusted mechanism to
781 communicate the results of the SPF, DKIM, and DMARC evaluation(s)
782 to the primary MX server.
783
784
785
786Martin, et al. Informational [Page 14]
787
788RFC 7960 DMARC Indirect Email Interop Issues September 2016
789
790
7913.3. Combinations
792
793 Indirect email flows can be combined. For example, a university
794 student may subscribe to a Mailing List (using his university email
795 address) while this university email address is configured to forward
796 all emails to a freemail or a post-education corporate account
797 provider where a more permanent email address for this student
798 exists.
799
800 Within an organization, the message may pass through various MTAs
801 (Section 3.1.2), each of which performs a different function
802 (authentication, filtering, distribution, etc.).
803
8044. Possible Mitigations of Interoperability Issues
805
806 Solutions to interoperability issues between DMARC and indirect email
807 flows vary widely in their scope and implications. They range from
808 improvements to underlying processing, such as proper handling of
809 multiple DKIM signatures, to more radical changes to the messaging
810 architecture. This section describes possible ways to address
811 interoperability issues. Note that these particular mechanisms may
812 not be considered "best practices" and may, in some cases, violate
813 various conventions or expectations.
814
815 Receivers sometimes need to deliver email messages that do not
816 conform to any standard or protocol, but are otherwise desired by end
817 users. Mitigating the impact of DMARC on indirect email flows is
818 especially important to receivers that operate services where ease of
819 use and compatibility with existing email flows is a priority.
820
821 DMARC provides a mechanism (local policy) for receivers to make
822 decisions about identity alignment acceptability based on information
823 outside DMARC and communicate those decisions as "overrides" to the
824 sender. This facility can be used to ease some interoperability
825 issues, although care is needed to ensure that this does not create
826 loopholes for abuse.
827
828 To further complicate the usage of mitigations, mitigation may not be
829 desired if the email in question is of a certain category of high
830 value or high risk (security-related) transactional messages (dealing
831 with financial transactions or medical records, for example). In
832 these cases, mitigating the impact of DMARC due to indirect email
833 flows may not be desirable (counterproductive or allowing for abuse).
834
835 As a final note, mail systems are diverse and widely deployed.
836 Systems of various ages and capabilities are expected to preserve
837 interoperability with the rest of the SMTP ecosystem. For instance,
838 Qmail is still used, although the base code has not been updated
839
840
841
842Martin, et al. Informational [Page 15]
843
844RFC 7960 DMARC Indirect Email Interop Issues September 2016
845
846
847 since 1998. ezmlm, a once popular MLM, is still deployed but has not
848 been updated since 1997, although a new version (ezmlm-idx) exists.
849 Old versions of other open- and closed-source MTAs are still commonly
850 in operation. When dealing with aging or unsupported systems, some
851 solutions may be time-consuming and/or disruptive to implement.
852
8534.1. Mitigations in Current Use
854
855 Because DMARC is already widely deployed, many operators already have
856 mitigations in use. These mitigations vary in their effectiveness
857 and side effects but have the advantage that they are currently
858 available.
859
8604.1.1. Mitigations for Senders
861
8624.1.1.1. Identifier Alignment
863
864 o MTAs handling multiple domains may choose to change
865 RFC5321.MailFrom to align with RFC5322.From to improve SPF
866 usability for DMARC.
867
868 o MTAs handling multiple domains may also choose to align
869 RFC5321.HELO/.EHLO to RFC5322.From, particularly when sending
870 notification messages. Dynamically adjusting the
871 RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible
872 for some MTA software.
873
874 o MTAs may choose to DKIM-sign notification messages with an aligned
875 domain to allow a DKIM-based DMARC pass.
876
877 o MTAs sending email on behalf of multiple domains may require
878 Domain Owners to provide DKIM keys to use DKIM to avoid SPF
879 validation issues, given the requirement for DMARC alignment with
880 the RFC5322.From header field. Managing DKIM keys with a third
881 party has security risks that should be carefully managed (see
882 also [RFC6376], Section 8). Methods involving CNAMEs and/or
883 subdomains may alleviate some risks.
884
885 o Senders who are sending on behalf of users in other administrative
886 domains may choose to use an RFC5322.From under the sender's
887 control. The new From can be either a forwarding address in a
888 domain controlled by the Sender or a placeholder address, with the
889 original user's address in an RFC5322.Reply-to header field.
890 However, performing this modification may cause the Recipient's
891 MUA to deviate from customary behavior.
892
893
894
895
896
897
898Martin, et al. Informational [Page 16]
899
900RFC 7960 DMARC Indirect Email Interop Issues September 2016
901
902
903 o When implementing "forward-to-friend" functionality, one approach
904 to avoid DMARC failures is to pass a well-formed message to the
905 user's MUA so that it may fill in an appropriate identity and
906 submit through its own MSA.
907
908 o Senders can use domains with distinct DMARC policies for email
909 sent directly and email known to use indirect mail flows.
910 However, for most well-known brands, all active domains are likely
911 to be targeted equally by abusers.
912
9134.1.1.2. Message Modification
914
915 o Senders can maximize survivability of DKIM signatures by limiting
916 the header fields they sign and using relaxed canonicalization.
917 Using the DKIM length tag to allow appended signatures is
918 discouraged due to the security risk created by allowing arbitrary
919 content to be appended to legitimate email.
920
921 o Senders can also maximize survivability by starting with RFC-
922 compliant headers and common body formats.
923
924 o In order to minimize transport-based conversions, Senders can
925 convert messages to a lowest denominator MIME content-transfer
926 encoding such as quoted-printable or base64 before signing
927 ([RFC6376], Section 5.3).
928
9294.1.2. Mitigations for Receivers
930
9314.1.2.1. Identifier Alignment
932
933 o Receivers should update DKIM handling libraries to ensure that
934 they process all valid DKIM signatures and check each signature
935 for alignment.
936
9374.1.2.2. Policy Override
938
939 o Receivers can amalgamate data from their user base to create lists
940 of forwarders and use such lists to inform DMARC local policy
941 overrides. This process may be easier for large receivers where
942 data and resources to create such lists are more readily available
943 than at smaller sites, where there are fewer accounts that receive
944 forwarded mail and other resources may be scarce.
945
946
947
948
949
950
951
952
953
954Martin, et al. Informational [Page 17]
955
956RFC 7960 DMARC Indirect Email Interop Issues September 2016
957
958
9594.1.3. Mitigations for ReSenders
960
9614.1.3.1. Changes to the RFC5322.From
962
963 Many ReSender issues can be avoided by using an RFC5322.From header
964 field under the ReSender's control, instead of the initial
965 RFC5322.From. This will correct Identifier Alignment issues and
966 allow arbitrary message modification as long as the ReSender signs
967 the message with an aligned domain signature. When ReSenders change
968 the RFC5322.From, it is desirable to preserve the information about
969 the original initiator of the message.
970
971 A first option is to use the Original-From [RFC5703] (or X-Original-
972 From) header field for this purpose in various contexts (X- header
973 field names are discouraged by [RFC6648]). However, handling of
974 Original-From (or X-Original-From) is not defined anywhere. It is
975 not currently used consistently or displayed to the user, and in any
976 situation where it is used, it is a new unauthenticated identifier
977 available for exploitation unless included within the scope of the
978 new DKIM signature(s).
979
980 Another option for ReSenders is to rewrite the RFC5322.From header
981 field address to a locally controlled address that will be forwarded
982 back to the original sender (subject to its own ReSender forwarding
983 mitigations).
984
9854.1.3.2. Avoiding Message Modification
986
987 o Forwarders can choose to add email header fields instead of
988 modifying existing headers or bodies, for instance, to indicate a
989 message may be spam.
990
991 o Forwarders can minimize the circumstances in which they choose to
992 fix messages, preferring to preserve non-compliant headers to
993 creating DKIM failures.
994
995 o Forwarders can choose to reject messages with suspect or harmful
996 content instead of modifying them.
997
9984.1.3.3. Mailing Lists
999
1000 [RFC6377] provides some guidance on using DKIM with Mailing lists.
1001 The following mitigation techniques can be used to ease
1002 interoperability issues with DMARC and Mailing lists:
1003
1004 o Configuring the Mailing List Manager (MLM) to alter the
1005 RFC5322.From header field to use the domain of the MLM is a
1006 mitigation policy that is now present in several different Mailing
1007
1008
1009
1010Martin, et al. Informational [Page 18]
1011
1012RFC 7960 DMARC Indirect Email Interop Issues September 2016
1013
1014
1015 List software distributions. Since most list subscribers prefer
1016 to know the identity of the Author of the original message,
1017 typically this information may be provided in the display name
1018 part of the RFC5322.From header field. This display name needs to
1019 be carefully crafted so as to not collide with the original
1020 display name of the Author, nor contain something that looks like
1021 an email address or domain name. These modifications may to some
1022 extent defeat the purpose of DMARC itself. It may make it
1023 difficult to ensure that users of all email clients can easily
1024 reply to the Author, the list, or all using the email client
1025 features provided for that purpose. Use of the RFC5322.Reply-To
1026 header field can alleviate this problem depending on whether the
1027 Mailing List is configured to reply-to-list, reply-to-author, or
1028 reply-to-fixed-address; however, it is important to note that this
1029 header field can take multiple email addresses. When altering the
1030 RFC5322.From, there are three possibilities:
1031
1032 1. change it to put the Mailing List email address,
1033
1034 2. change it to a locally defined address that will be forwarded
1035 back to the original sender, or
1036
1037 3. "break" the address by modifying the domain to a non-existent
1038 domain (such as by adding a suffix like ".invalid").
1039
1040 The latter modification may create issues because it is an invalid
1041 domain name, and some MTAs may pay particular attention to the
1042 validity of email addresses in RFC5322.From and the reputation of
1043 the domains present there.
1044
1045 o Configuring the MLM to "wrap" the message in a MIME message/rfc822
1046 part and to send as the Mailing List email address. Many email
1047 clients (as of the publication of this document), especially
1048 mobile clients, have difficulty reading such messages, and this is
1049 not expected to change soon.
1050
1051 o Configuring the MLM to not modify the message so that the DKIM
1052 signature remains valid. Some Mailing Lists are set up this way
1053 and require few additional changes to ensure the DKIM signature is
1054 preserved. Moving lists that currently modify mail to a policy
1055 like this may be too much of a change for the members of such
1056 lists.
1057
1058 o Rejecting posts or membership requests from domains with a DMARC
1059 policy other than "p=none". However, members or potential members
1060 of such Mailing Lists may complain of unfair exclusion.
1061
1062
1063
1064
1065
1066Martin, et al. Informational [Page 19]
1067
1068RFC 7960 DMARC Indirect Email Interop Issues September 2016
1069
1070
1071 o To alleviate unsubscribes to the Mailing List due to the messages
1072 bouncing because of DMARC, the MLM needs to not act on
1073 notification messages due to message authentication issues.
1074 [RFC3463] specifies Enhanced Mail System Status Codes, which help
1075 differentiate between various failure conditions. Correctly
1076 interpreting Extended SMTP error messages is useful in this case.
1077 In particular, extended status codes for SPF and DKIM causes are
1078 defined in [RFC7372], and DMARC-related failure indications are
1079 discussed in DMARC ([RFC7489], Section 10.3).
1080
1081 All these techniques may provide some specific challenges to MUAs and
1082 different operational usages for end users (like rewriting filters to
1083 sort emails in folders). There will be some time before all
1084 implications are understood and accommodated.
1085
10864.2. Proposed and In-Progress Mitigations
1087
1088 The following mitigations are based on Internet-Drafts (I-Ds) that
1089 are still in process. They are described here to offer an
1090 exploratory path for solutions. These solutions should not be used
1091 in a production environment. Because of the transient nature of
1092 I-Ds, specific citations are not included because a number of them
1093 will inevitably become obsolete, and those that gain consensus in the
1094 community will become RFCs and should be discovered as such.
1095
1096 o Third-party authorization schemes provide ways to extend
1097 Identifier Alignment under control of the Domain Owner.
1098
1099 o Ways to canonicalize messages that transit Mailing Lists so that
1100 their alterations can be isolated from the original signed
1101 content.
1102
1103 o Mechanisms to record message transformations applied at each hop
1104 so they can be reversed and the original signed content recovered.
1105
1106 o "Conditional" DKIM signatures, whereby the Author domain indicates
1107 its signature is only good if accompanied by a signature from an
1108 expected downstream relay.
1109
1110 o Mechanisms to extend Authentication-Results [RFC7601] to multiple
1111 hops, creating a provable chain of custody as well as a view of
1112 message authentication results at each handling step.
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122Martin, et al. Informational [Page 20]
1123
1124RFC 7960 DMARC Indirect Email Interop Issues September 2016
1125
1126
11274.2.1. Getting More Radical: Requiring New Communication Paths between
1128 MUAs
1129
1130 In practice, a number of operators are using strict alignment mode in
1131 DMARC in order to avoid receiving new and innovative forms of
1132 unwanted and unauthentic email through systems purporting to be
1133 Mailing List handlers. The receiving ADMD has no knowledge of which
1134 lists the user has subscribed to and which they have not. One avenue
1135 of exploration would be for the user to authorize Mailing Lists as
1136 proxies for authentication, at which point the receiving ADMD would
1137 be vesting some trust in the Mailing List service. The creators of
1138 DKIM foresaw precisely this possibility at the time by not tightly
1139 binding any semantics to the RFC5322.From header field. Some
1140 experimental work has taken place in this area, as mentioned above.
1141 Additional work might examine a new communication path to the user to
1142 authorize some form of transitive trust.
1143
11445. Security Considerations
1145
1146 This document is an analysis of DMARC's impact on indirect email
1147 flows. It describes the possibility of accidental denial of service
1148 that can be created by rejections of messages by DMARC-aware mail
1149 receivers.
1150
1151 Section 4.1.1.1 discusses the importance of appropriate DKIM key
1152 management vis-a-vis third-party email senders.
1153
1154 Section 4.1.3.3 warns that rewriting the RFC5322.From header field to
1155 create an artificial domain name should not be done with any domain.
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178Martin, et al. Informational [Page 21]
1179
1180RFC 7960 DMARC Indirect Email Interop Issues September 2016
1181
1182
11836. References
1184
11856.1. Normative References
1186
1187 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1188 Extensions (MIME) Part One: Format of Internet Message
1189 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
1190 <http://www.rfc-editor.org/info/rfc2045>.
1191
1192 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
1193 RFC 3463, DOI 10.17487/RFC3463, January 2003,
1194 <http://www.rfc-editor.org/info/rfc3463>.
1195
1196 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
1197 Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
1198 January 2008, <http://www.rfc-editor.org/info/rfc5228>.
1199
1200 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1201 DOI 10.17487/RFC5321, October 2008,
1202 <http://www.rfc-editor.org/info/rfc5321>.
1203
1204 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1205 DOI 10.17487/RFC5322, October 2008,
1206 <http://www.rfc-editor.org/info/rfc5322>.
1207
1208 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1209 DOI 10.17487/RFC5598, July 2009,
1210 <http://www.rfc-editor.org/info/rfc5598>.
1211
1212 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
1213 Tests, Iteration, Extraction, Replacement, and Enclosure",
1214 RFC 5703, DOI 10.17487/RFC5703, October 2009,
1215 <http://www.rfc-editor.org/info/rfc5703>.
1216
1217 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1218 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
1219 RFC 6376, DOI 10.17487/RFC6376, September 2011,
1220 <http://www.rfc-editor.org/info/rfc6376>.
1221
1222 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
1223 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
1224 September 2011, <http://www.rfc-editor.org/info/rfc6377>.
1225
1226 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
1227 "Deprecating the "X-" Prefix and Similar Constructs in
1228 Application Protocols", BCP 178, RFC 6648,
1229 DOI 10.17487/RFC6648, June 2012,
1230 <http://www.rfc-editor.org/info/rfc6648>.
1231
1232
1233
1234Martin, et al. Informational [Page 22]
1235
1236RFC 7960 DMARC Indirect Email Interop Issues September 2016
1237
1238
1239 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
1240 Authorizing Use of Domains in Email, Version 1", RFC 7208,
1241 DOI 10.17487/RFC7208, April 2014,
1242 <http://www.rfc-editor.org/info/rfc7208>.
1243
1244 [RFC7372] Kucherawy, M., "Email Authentication Status Codes",
1245 RFC 7372, DOI 10.17487/RFC7372, September 2014,
1246 <http://www.rfc-editor.org/info/rfc7372>.
1247
12486.2. Informative References
1249
1250 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
1251 Message Authentication, Reporting, and Conformance
1252 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
1253 <http://www.rfc-editor.org/info/rfc7489>.
1254
1255 [RFC7601] Kucherawy, M., "Message Header Field for Indicating
1256 Message Authentication Status", RFC 7601,
1257 DOI 10.17487/RFC7601, August 2015,
1258 <http://www.rfc-editor.org/info/rfc7601>.
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290Martin, et al. Informational [Page 23]
1291
1292RFC 7960 DMARC Indirect Email Interop Issues September 2016
1293
1294
1295Appendix A. Example SPF Bounce
1296
1297 This example illustrates a notification message "bounce".
1298
1299A.1. Initial Message
1300
1301 Here is the message as it exits the Origin MTA (segv.d1.example):
1302
1303 Return-Path: <jqd@d1.example>
1304 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z])
1305 (authenticated bits=0)
1306 by segv.d1.example with ESMTP id t0FN4a8O084569;
1307 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1308 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1309 s=20130426; t=1421363082;
1310 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1311 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1312 Content-Transfer-Encoding;
1313 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1314 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1315 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1316 Message-ID: <54B84785.1060301@d1.example>
1317 Date: Thu, 14 Jan 2015 15:00:01 -0800
1318 From: John Q Doe <jqd@d1.example>
1319 To: no-recipient@dmarc.org
1320 Subject: Example 1
1321
1322 Hey gang,
1323 This is a test message.
1324 --J.
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346Martin, et al. Informational [Page 24]
1347
1348RFC 7960 DMARC Indirect Email Interop Issues September 2016
1349
1350
1351A.2. Notification Message
1352
1353 When dmarc.org rejects the message without a DKIM signature, it
1354 specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local, which has
1355 no SPF record. dmarc.org has a reject policy in place for such non-
1356 passing cases. Since there is no DKIM signature on the notification
1357 message, the failed SPF lookup results in a dmarc=fail, and
1358 d1.example could be expected to discard the notification message
1359 itself:
1360
1361 Return-Path: <>
1362 Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1])
1363 by mx.d1.example with ESMTPS id Lkm25302jJR5
1364 for <jqd@d1.example>
1365 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
1366 Thu, 14 Jan 2015 15:00:24 -0800 (PST)
1367 Authentication-Results: mx.d1.example;
1368 spf=none (d1.example: dmarc.org.local does not designate
1369 permitted sender hosts) smtp.mail=;
1370 dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org
1371 MIME-Version: 1.0
1372 Received: from segv.d1.example (segv.d1.example [198.51.100.1])
1373 by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu,
1374 14 Jan 2015 15:00:24 -0800 (PST)
1375 From: Mail Delivery Subsystem <mailer-daemon@dmarc.org>
1376 To: jqd@d1.example
1377 Subject: Delivery Status Notification (Failure)
1378 Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org>
1379 Date: Thu, 14 Jan 2016 23:00:24 +0000
1380 Content-Type: text/plain; charset=UTF-8
1381
1382 This is an automatically generated Delivery Status Notification
1383
1384 Delivery to the following recipient failed permanently:
1385
1386 no-recipient@dmarc.org
1387
1388 Technical details of permanent failure:
1389 Your message was rejected by the server for the recipient domain
1390 dmarc.org by mail.dmarc.org [192.0.2.1].
1391
1392 The error that the other server returned was:
1393 550 5.1.1 <no-recipient@dmarc.org>... User unknown
1394
1395 ----- Original message -----
1396 Return-Path: <jqd@d1.example>
1397 Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com
1398 [203.252.0.131]) (authenticated bits=0)
1399
1400
1401
1402Martin, et al. Informational [Page 25]
1403
1404RFC 7960 DMARC Indirect Email Interop Issues September 2016
1405
1406
1407 by segv.d1.example with ESMTP id t0FN4a8O084569;
1408 Thu, 14 Jan 2015 15:00:01 -0800 (PST)
1409 (envelope-from jqd@d1.example)
1410 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
1411 s=20130426; t=1421363082;
1412 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
1413 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
1414 Content-Transfer-Encoding;
1415 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
1416 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
1417 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ=
1418 Message-ID: <54B84785.1060301@d1.example>
1419 Date: Thu, 14 Jan 2015 15:00:01 -0800
1420 From: John Q Doe <jqd@d1.example>
1421 To: no-recipient@dmarc.org
1422 Subject: Example 1
1423
1424 Hey gang,
1425 This is a test message.
1426 --J.
1427
1428Acknowledgments
1429
1430 Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Rolf
1431 E. Sonneveld, Tim Draegen, and Franck Martin contributed to the IETF
1432 DMARC Working Group's wiki page listing all known interoperability
1433 issues with DMARC and indirect email flows.
1434
1435 Tim Draegen created the first draft of this document from these
1436 contributions and by ham-fistedly mapping contributions into the
1437 language of [RFC5598].
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458Martin, et al. Informational [Page 26]
1459
1460RFC 7960 DMARC Indirect Email Interop Issues September 2016
1461
1462
1463Authors' Addresses
1464
1465 Franck Martin (editor)
1466 LinkedIn
1467 Mountain View, CA
1468 United States of America
1469
1470 Email: fmartin@linkedin.com
1471
1472
1473 Eliot Lear (editor)
1474 Cisco Systems GmbH
1475 Richtistrasse 7
1476 Wallisellen, ZH CH-8304
1477 Switzerland
1478
1479 Phone: +41 44 878 9200
1480 Email: lear@cisco.com
1481
1482
1483 Tim Draegen (editor)
1484 dmarcian, inc.
1485 PO Box 1007
1486 Brevard, NC 28712
1487 United States of America
1488
1489 Email: tim@dmarcian.com
1490
1491
1492 Elizabeth Zwicky (editor)
1493 Yahoo
1494 Sunnyvale, CA
1495 United States of America
1496
1497 Email: zwicky@yahoo-inc.com
1498
1499
1500 Kurt Andersen (editor)
1501 LinkedIn
1502 2029 Stierlin Court
1503 Mountain View, CA 94043
1504 United States of America
1505
1506 Email: kandersen@linkedin.com
1507
1508
1509
1510
1511
1512
1513
1514Martin, et al. Informational [Page 27]
1515
1516