7Internet Engineering Task Force (IETF) F. Martin, Ed.
8Request for Comments: 7960 LinkedIn
9Category: Informational E. Lear, Ed.
10ISSN: 2070-1721 Cisco Systems GmbH
20 Interoperability Issues between Domain-based Message Authentication,
21 Reporting, and Conformance (DMARC) and Indirect Email Flows
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.
37 This document is not an Internet Standards Track specification; it is
38 published for informational purposes.
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.
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.
58Martin, et al. Informational [Page 1]
60RFC 7960 DMARC Indirect Email Interop Issues September 2016
65 Copyright (c) 2016 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
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.
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
114Martin, et al. Informational [Page 2]
116RFC 7960 DMARC Indirect Email Interop Issues September 2016
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
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.
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.
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.
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.
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.
170Martin, et al. Informational [Page 3]
172RFC 7960 DMARC Indirect Email Interop Issues September 2016
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
1791.1. Document Conventions
181 The notation used in this document for structured fields is taken
182 from [RFC5598], Section 1.3.
184 The term "notification message" ([RFC5321], Section 4.5.5) is used to
185 refer to a message with a null RFC5321.MailFrom.
187 The terms "Organizational Domain" and "Authenticated Identifiers" are
188 specified in DMARC ([RFC7489], Section 3).
190 All words that begin with capital letters take their formal meanings
191 from these references.
1932. Causes of Interoperability Issues
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.
201 Note that domains that assert a "p=none" policy and email messages
202 that pass standard DMARC validation do not have any interoperability
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.
209 The rest of this section describes several conceptual causes of
210 interoperability issues.
2122.1. Identifier Alignment
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.
226Martin, et al. Informational [Page 4]
228RFC 7960 DMARC Indirect Email Interop Issues September 2016
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".
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.
2522.1.1. DKIM Identifier(s)
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].
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.
282Martin, et al. Informational [Page 5]
284RFC 7960 DMARC Indirect Email Interop Issues September 2016
2872.1.2. SPF Identifier(s)
289 The SPF specification [RFC7208] defines two Authenticated Identifiers
290 for each message. These identifiers derive from:
292 a. the RFC5321.MailFrom [RFC5321] domain, and
294 b. the RFC5321.HELO/.EHLO SMTP domain.
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.
305 See Appendix A for an example treatment of this scenario.
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].
3142.1.3. Multiple RFC5322.From Addresses
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
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]).
3272.2. Message Forwarding
329 Section 3 describes forwarding behavior as it relates to the
330 components of the Internet Mail Architecture.
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
338Martin, et al. Informational [Page 6]
340RFC 7960 DMARC Indirect Email Interop Issues September 2016
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:
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.
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
361 In both cases, SPF cannot yield relevant Authenticated Identifiers,
362 and DKIM must be relied upon to produce results that are relevant to
3652.3. Message Modification
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.
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
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.
394Martin, et al. Informational [Page 7]
396RFC 7960 DMARC Indirect Email Interop Issues September 2016
3993. Internet Mail Architecture, DMARC, and Indirect Email Flows
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.
4053.1. Message Handling System
407 Section 4 of [RFC5598] describes six basic components that make up
408 the Message Handling System (MHS):
412 o Message User Agent (MUA)
414 o Message Submission Agent (MSA)
416 o Message Transfer Agent (MTA)
418 o Message Delivery Agent (MDA)
422 Of these components, MSA, MTA, and MDA are discussed in relation to
423 interoperability with DMARC.
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.
4303.1.1. Message Submission Agents
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.
436 MSAs are split into two sub-components:
438 o Author-focused MSA functions (aMSA)
440 o MHS-focused MSA functions (hMSA)
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
450Martin, et al. Informational [Page 8]
452RFC 7960 DMARC Indirect Email Interop Issues September 2016
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
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:
468 o Partially open relays - a residential ISP that allows its
469 customers to relay non-local domains through its infrastructure.
471 o Embedded devices - cable/DSL modems, firewalls, wireless access
472 points, and printers that send email using hardcoded domains.
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
478 o Email service providers - ESPs that service customers who are
479 using domains that publish a DMARC "reject" policy.
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.
4853.1.2. Message Transfer Agents
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
4933.1.2.1. Message Encoding
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.
506Martin, et al. Informational [Page 9]
508RFC 7960 DMARC Indirect Email Interop Issues September 2016
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.
5173.1.2.2. Header Standardization
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.
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
528 Providing solutions for issues relating to non-RFC-compliant emails
529 is outside the scope of this document.
5313.1.2.3. Content Validation
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.
5373.1.3. Message Delivery Agents
539 The MDA transfers a message from the MHS to a mailbox. Like the MSA,
540 the MDA consists of two sub-components:
542 o MHS-focused MDA functions (hMDA)
544 o Recipient-focused MDA functions (rMDA)
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.
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.
562Martin, et al. Informational [Page 10]
564RFC 7960 DMARC Indirect Email Interop Issues September 2016
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.
573 DMARC interoperability issues are common within the context of
574 Mediators, which are often used precisely for their ability to modify
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.
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.
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
598 Examples of Aliasing include:
600 o Forwarding email between free email (freemail) providers to try
601 different interfaces while maintaining an original email address;
603 o Consolidating many email addresses into a single account to
604 centralize processing; and
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
618Martin, et al. Informational [Page 11]
620RFC 7960 DMARC Indirect Email Interop Issues September 2016
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.
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.
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.
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.
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
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:
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
662 o adding a footer to the email body to contain administrative
665 o removing some MIME-parts from the email or converting the message
668 o encrypting the body with the Recipient's key using PGP (Pretty
669 Good Privacy) or S/MIME;
674Martin, et al. Informational [Page 12]
676RFC 7960 DMARC Indirect Email Interop Issues September 2016
679 o enforcing community standards by rewriting banned words; and
681 o allowing moderators to add arbitrary commentary to messages
682 (discussed in [RFC6377]).
684 Any such modifications would invalidate a DKIM signature.
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.
6913.2.3.1. Mailing List Operational Effects
693 Mailing Lists may also have the following DMARC interoperability
696 o Subscribed members may not receive email from members that post
697 using domains that publish a DMARC "p=reject" policy.
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.
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.
713 Gateways share the same DMARC interoperability issues as ReSenders
716 Gateways may also share the same DMARC interoperability issues as
717 MTAs (Section 3.1.2).
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).
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
730Martin, et al. Informational [Page 13]
732RFC 7960 DMARC Indirect Email Interop Issues September 2016
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.
7403.2.5. Boundary Filters
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.
747 Boundary Filters share the same DMARC interoperability issues as
750 Issues may arise with SPF and DKIM evaluation if performed after
751 filter modifications.
753 Examples of Boundary Filters include:
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.
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.
767 o Other text additions: An MTA may add an organizational disclaimer
768 or advertisement, for instance.
770 o URL alteration: Some systems will rewrite or alter embedded URLs
771 as a way to control the potential threat from malware.
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.
786Martin, et al. Informational [Page 14]
788RFC 7960 DMARC Indirect Email Interop Issues September 2016
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
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.).
8044. Possible Mitigations of Interoperability Issues
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.
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.
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
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).
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
842Martin, et al. Informational [Page 15]
844RFC 7960 DMARC Indirect Email Interop Issues September 2016
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.
8534.1. Mitigations in Current Use
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
8604.1.1. Mitigations for Senders
8624.1.1.1. Identifier Alignment
864 o MTAs handling multiple domains may choose to change
865 RFC5321.MailFrom to align with RFC5322.From to improve SPF
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.
874 o MTAs may choose to DKIM-sign notification messages with an aligned
875 domain to allow a DKIM-based DMARC pass.
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.
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.
898Martin, et al. Informational [Page 16]
900RFC 7960 DMARC Indirect Email Interop Issues September 2016
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.
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.
9134.1.1.2. Message Modification
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.
921 o Senders can also maximize survivability by starting with RFC-
922 compliant headers and common body formats.
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).
9294.1.2. Mitigations for Receivers
9314.1.2.1. Identifier Alignment
933 o Receivers should update DKIM handling libraries to ensure that
934 they process all valid DKIM signatures and check each signature
9374.1.2.2. Policy Override
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.
954Martin, et al. Informational [Page 17]
956RFC 7960 DMARC Indirect Email Interop Issues September 2016
9594.1.3. Mitigations for ReSenders
9614.1.3.1. Changes to the RFC5322.From
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.
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).
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
9854.1.3.2. Avoiding Message Modification
987 o Forwarders can choose to add email header fields instead of
988 modifying existing headers or bodies, for instance, to indicate a
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.
995 o Forwarders can choose to reject messages with suspect or harmful
996 content instead of modifying them.
9984.1.3.3. Mailing Lists
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:
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
1010Martin, et al. Informational [Page 18]
1012RFC 7960 DMARC Indirect Email Interop Issues September 2016
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:
1032 1. change it to put the Mailing List email address,
1034 2. change it to a locally defined address that will be forwarded
1035 back to the original sender, or
1037 3. "break" the address by modifying the domain to a non-existent
1038 domain (such as by adding a suffix like ".invalid").
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.
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.
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
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.
1066Martin, et al. Informational [Page 19]
1068RFC 7960 DMARC Indirect Email Interop Issues September 2016
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).
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.
10864.2. Proposed and In-Progress Mitigations
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.
1096 o Third-party authorization schemes provide ways to extend
1097 Identifier Alignment under control of the Domain Owner.
1099 o Ways to canonicalize messages that transit Mailing Lists so that
1100 their alterations can be isolated from the original signed
1103 o Mechanisms to record message transformations applied at each hop
1104 so they can be reversed and the original signed content recovered.
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.
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.
1122Martin, et al. Informational [Page 20]
1124RFC 7960 DMARC Indirect Email Interop Issues September 2016
11274.2.1. Getting More Radical: Requiring New Communication Paths between
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.
11445. Security Considerations
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
1151 Section 4.1.1.1 discusses the importance of appropriate DKIM key
1152 management vis-a-vis third-party email senders.
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.
1178Martin, et al. Informational [Page 21]
1180RFC 7960 DMARC Indirect Email Interop Issues September 2016
11856.1. Normative References
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>.
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>.
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>.
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>.
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>.
1208 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
1209 DOI 10.17487/RFC5598, July 2009,
1210 <http://www.rfc-editor.org/info/rfc5598>.
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>.
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>.
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>.
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>.
1234Martin, et al. Informational [Page 22]
1236RFC 7960 DMARC Indirect Email Interop Issues September 2016
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>.
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>.
12486.2. Informative References
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>.
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>.
1290Martin, et al. Informational [Page 23]
1292RFC 7960 DMARC Indirect Email Interop Issues September 2016
1295Appendix A. Example SPF Bounce
1297 This example illustrates a notification message "bounce".
1301 Here is the message as it exits the Origin MTA (segv.d1.example):
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
1323 This is a test message.
1346Martin, et al. Informational [Page 24]
1348RFC 7960 DMARC Indirect Email Interop Issues September 2016
1351A.2. Notification Message
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
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
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>
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
1382 This is an automatically generated Delivery Status Notification
1384 Delivery to the following recipient failed permanently:
1386 no-recipient@dmarc.org
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].
1392 The error that the other server returned was:
1393 550 5.1.1 <no-recipient@dmarc.org>... User unknown
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)
1402Martin, et al. Informational [Page 25]
1404RFC 7960 DMARC Indirect Email Interop Issues September 2016
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
1425 This is a test message.
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.
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].
1458Martin, et al. Informational [Page 26]
1460RFC 7960 DMARC Indirect Email Interop Issues September 2016
1465 Franck Martin (editor)
1468 United States of America
1470 Email: fmartin@linkedin.com
1476 Wallisellen, ZH CH-8304
1479 Phone: +41 44 878 9200
1480 Email: lear@cisco.com
1483 Tim Draegen (editor)
1487 United States of America
1489 Email: tim@dmarcian.com
1492 Elizabeth Zwicky (editor)
1495 United States of America
1497 Email: zwicky@yahoo-inc.com
1500 Kurt Andersen (editor)
1503 Mountain View, CA 94043
1504 United States of America
1506 Email: kandersen@linkedin.com
1514Martin, et al. Informational [Page 27]