idnits 2.17.1 draft-ietf-dmarc-interoperability-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 18, 2016) is 2832 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7601 (Obsoleted by RFC 8601) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC F. Martin, Ed. 3 Internet-Draft LinkedIn 4 Intended status: Informational E. Lear, Ed. 5 Expires: January 19, 2017 Cisco Systems GmbH 6 T. Draegen, Ed. 7 dmarcian, inc. 8 E. Zwicky, Ed. 9 Yahoo 10 K. Andersen, Ed. 11 LinkedIn 12 July 18, 2016 14 Interoperability Issues Between DMARC and Indirect Email Flows 15 draft-ietf-dmarc-interoperability-18 17 Abstract 19 DMARC (Domain-based Message Authentication, Reporting, and 20 Conformance) introduces a mechanism for expressing domain-level 21 policies and preferences for email message validation, disposition, 22 and reporting. However, the DMARC mechanism enables potentially 23 disruptive interoperability issues when messages do not flow directly 24 from the author's administrative domain to the final recipients. 25 Collectively these email flows are referred to as indirect email 26 flows. This document describes these interoperability issues, and 27 presents possible methods for addressing them. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 19, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 4 65 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4 66 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 67 2.1.1. DKIM Identifier(s) . . . . . . . . . . . . . . . . . 5 68 2.1.2. SPF Identifier(s) . . . . . . . . . . . . . . . . . . 5 69 2.1.3. Multiple RFC5322.From Addresses . . . . . . . . . . . 6 70 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 6 71 2.3. Message Modification . . . . . . . . . . . . . . . . . . 7 72 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 7 73 3.1. Message Handling System . . . . . . . . . . . . . . . . . 8 74 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 8 75 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 9 76 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 9 77 3.1.2.2. Header Standardization . . . . . . . . . . . . . 10 78 3.1.2.3. Content Validation . . . . . . . . . . . . . . . 10 79 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 10 80 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10 81 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 11 82 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 12 83 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 12 84 3.2.3.1. Mailing List Operational Effects . . . . . . . . 13 85 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 13 86 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 14 87 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 15 88 4. Possible Mitigations of Interoperability Issues . . . . . . . 15 89 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 16 90 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 16 91 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 16 92 4.1.1.2. Message Modification . . . . . . . . . . . . . . 17 93 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 17 94 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 17 95 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 17 96 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 17 97 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 18 98 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 18 99 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 18 100 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 20 101 4.2.1. Getting More Radical: Requiring New Communication 102 Paths Between MUAs . . . . . . . . . . . . . . . . . 20 103 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 104 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 105 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 108 8.2. Informative References . . . . . . . . . . . . . . . . . 23 109 Appendix A. Appendix A - Example SPF Bounce . . . . . . . . . . 23 110 A.1. Initial Message . . . . . . . . . . . . . . . . . . . . . 23 111 A.2. Notification message . . . . . . . . . . . . . . . . . . 23 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 114 1. Introduction 116 DMARC [RFC7489] introduces a mechanism for expressing domain-level 117 policies and preferences for message validation, disposition, and 118 reporting. The DMARC mechanism, especially when employed with 119 restrictive policies, encounters several different types of 120 interoperability issues due to third-party message sourcing, message 121 transformation, or rerouting. In particular, DMARC with restrictive 122 policies causes problems for many mailing lists. 124 At the time of the writing of this document, the DMARC base 125 specification is published as Informational RFC 7489 [RFC7489] and 126 has seen significant deployment within the email community. 128 Cases in which email does not flow directly from the author's 129 administrative domain to the recipient's domain(s) are collectively 130 referred to in this document as indirect email flows. Due to 131 existing and increasing adoption of DMARC, the impact of DMARC-based 132 email rejection policies on indirect email flows can be significant 133 for a select subset of general email traffic. 135 Several known causes of interoperability issues are presented, 136 followed by a description of components within the Internet Mail 137 Architecture [RFC5598] where interoperability issues can arise. 139 Finally, known and possible methods for addressing interoperability 140 issues are presented. There are often multiple ways to address any 141 given interoperability issue. While this document strives to be 142 comprehensive in its review, it should not be treated as complete. 143 Note that some practices which are in use at the time of this 144 document may or may not be "best practices", especially as future 145 standards evolve. 147 1.1. Document Conventions 149 The notation used in this document for structured fields is taken 150 from [RFC5598] section 1.3. 152 The term "notification message" [RFC5321] section 4.5.5 is used to 153 refer to a message with a null RFC5321.MailFrom. 155 The terms "Organizational Domain" and "Authenticated Identifiers" are 156 specified in DMARC [RFC7489] section 3. 158 2. Causes of Interoperability Issues 160 Interoperability issues between DMARC and indirect email flows arise 161 when conformance to the DMARC specification leads a receiving 162 implementation to apply DMARC-based policy restrictions to messages 163 that are both compliant with the architecture as specified in 164 [RFC5598] and viewed as legitimate by the intended recipient. 166 Note that domains which assert a "p=none" policy and email which 167 passes standard DMARC validation do not have any interoperability 168 issues. 170 Email messages that do not conform to IETF email specifications but 171 are considered legitimate by the intended recipients are not 172 discussed in this document. 174 The rest of this section describes several conceptual causes of 175 interoperability issues. 177 2.1. Identifier Alignment 179 Note to operators and administrators: The identifiers which are used 180 by SPF are technical components of the transport process for SMTP. 181 They may or may not, as described below, bear a meaningful 182 relationship to the content or source of the message itself. This 183 "relationship by proximity" can be a point of confusion for non- 184 technical end users, either recipients or senders. 186 DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message 187 source validation. The DMARC [RFC7489] specification refers to 188 source domains that are validated by DKIM or SPF as "Authenticated 189 Identifiers". To be used by DMARC an "Authenticated Identifier" must 190 also be related to the domain found in the message's RFC5322.From 191 header field [RFC5322]. This relationship between an Authenticated 192 Identifier's domain and the domain of the RFC5322.From is referred to 193 as "Identifier Alignment". 195 DMARC allows for Identifier Alignment to be determined in two 196 different modes: strict and relaxed. Strict mode requires an exact 197 match between the domain of any of the Authenticated Identifiers and 198 the message's RFC5322.From header field [RFC5322]. Relaxed mode 199 allows for Identifier Alignment if Authenticated Identifiers and the 200 message's RFC5322.From header field [RFC5322] share the same 201 Organizational Domain. In general, DMARC interoperability issues are 202 the same for both strict and relaxed alignment, but strict alignment 203 constrains the possible solutions because of the more rigorous 204 matching requirement. Some of mitigations described in this document 205 only work with the relaxed mode of Identifier Alignment. 207 2.1.1. DKIM Identifier(s) 209 DKIM provides a cryptographic means for one or more domain identifier 210 to be associated with a particular message. As a standalone 211 technology DKIM identifiers are not required to be related to the 212 source of the message's content. However, for a DKIM identifier to 213 align in DMARC, the signing domain of a valid signature must be part 214 of the same Organizational Domain as the domain in the RFC5322.From 215 header field [RFC5322]. 217 In addition, DKIM allows for the possibility of multiple valid 218 signatures. These multiple signatures may be from the same or 219 different domains, there are no restrictions within the DKIM 220 specification. The DMARC mechanism will process Authenticated 221 Identifiers that are based on DKIM signatures until an aligned 222 Authenticated Identifier is found (if any). However, operational 223 experience has shown that some implementations have difficulty 224 processing multiple signatures. Implementations that cannot process 225 multiple DKIM signatures may incorrectly flag messages as "not 226 passing" (DMARC alignment) and erroneously apply DMARC-based policy 227 to otherwise conforming messages. 229 2.1.2. SPF Identifier(s) 231 The SPF specification [RFC7208] defines two Authenticated Identifiers 232 for each message. These identifiers derive from: 234 a. the RFC5321.MailFrom [RFC5321] domain, and 236 b. the RFC5321.HELO/.EHLO SMTP domain. 238 In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is 239 defined to be based on RFC5321.MailFrom unless that value is absent 240 (as in the case of notification messages) in which case, the second 241 (RFC5321.HELO/.EHLO) identifier value is used. This "fallback" 242 definition has occasionally been misunderstood by operators of MTA 243 systems since notification messages are often an "automatic" feature 244 of MTA software. Some MTA software does not provide the ability to 245 apply a DKIM signature to such notification messages. 247 See Appendix A for an example treatment of this scenario. 249 For the purposes of DMARC validation/alignment, the hybrid 250 RFC7208.MAILFROM [RFC7208] identifier's domain is used if and only if 251 it is aligned with the RFC5322.From [RFC5322] domain. The alignment 252 of the validated domain is determined based on the DMARC record's 253 "strict" or "relaxed" designation as described above for the DKIM 254 identifiers and in [RFC7489]. 256 2.1.3. Multiple RFC5322.From Addresses 258 [RFC5322] permits only one From header field, but it may contain 259 multiple mailboxes. Since this is an extremely rare usage, DMARC 260 specifies that the handling of this situation is implementation 261 dependent. 263 Because the presence of multiple domains can be used by an attacker 264 (an attacker could add their domain to the RFC5322.From field, 265 provide arbitrary new content, and sign the message) the DMARC 266 specification recommends that the strictest policy be applied to such 267 messages (section 6.6.1 [RFC7489]). 269 2.2. Message Forwarding 271 Section 3 describes forwarding behavior as it relates to the 272 components of the Internet Mail Architecture. 274 All forwarding operations involve the retransmission of email. As 275 discussed above, in order for SPF to yield an Authenticated 276 Identifier that is pertinent to DMARC, the domain of the 277 RFC7208.MAILFROM must be in alignment with the RFC5322.From header 278 field. Forwarding introduces specific issues to the availability of 279 SPF-based Authenticated Identifiers: 281 o If the RFC5321.MailFrom is present and the forwarder maintains the 282 original RFC5321.MailFrom, SPF validation will fail unless the 283 forwarder is an authorized part of the originator's email sending 284 infrastructure. If the forwarder replaces the RFC5321.MailFrom 285 with its own domain, SPF might pass but Identifier Alignment with 286 the RFC5322.From header field will fail. 288 o If the RFC5321.MailFrom is empty (as in the case of Delivery 289 Status Notifications), the RFC5321.HELO/.EHLO domain of the 290 forwarder will likely be in a different organizational domain than 291 the original RFC5322.From header field's domain. SPF may pass but 292 Identifier Alignment with the RFC5322.From header field will fail. 294 In both cases, SPF cannot yield relevant Authenticated Identifiers, 295 and DKIM must be relied upon to produce results that are relevant to 296 DMARC. 298 2.3. Message Modification 300 Modification of email content invalidates most DKIM signatures, and 301 many message forwarding systems modify email content. Mailing list 302 processors are a common example of such systems, but other forwarding 303 systems also make modifications. 305 Although DKIM provides a length flag so that content can be appended 306 without invalidating the signature, in practice, particularly with 307 MIME-encoded [RFC2045] messages, a mailing list processor will do 308 more than simply append content (see Section 5.3 of [RFC5598] for 309 details). Furthermore, the length flag is seldom used due to 310 security issues (see Section 8.2 of [RFC6376] for additional security 311 considerations), therefore, this method is only here mentioned for 312 completeness. 314 DKIM describes two canonicalizations for use when preparing header 315 and body for DKIM processing: simple and relaxed. The latter is 316 designed to accommodate trivial modifications to whitespace and 317 folding which, at least in the header case, generally have no 318 semantic significance. However, the relaxed canonicalization is more 319 computationally intensive and may not have been preferred in the 320 early deployment of DKIM, leaving some deployments using the less 321 forgiving "simple" canonicalization. While the prevalence is 322 unknown, there are some DKIM verifiers which have problems evaluating 323 relaxed canonicalization correctly. 325 3. Internet Mail Architecture, DMARC, and Indirect Email Flows 327 This section describes components within the Internet Mail 328 Architecture [RFC5598] where interoperability issues between DMARC 329 and indirect email flows can be found. 331 3.1. Message Handling System 333 Section 4 of [RFC5598] describes six basic components that make up 334 the Message Handling System (MHS): 336 o Message 338 o Message User Agent (MUA) 340 o Message Submission Agent (MSA) 342 o Message Transfer Agent (MTA) 344 o Message Delivery Agent (MDA) 346 o Message Store (MS) 348 Of these components MSA, MTA, and MDA are discussed in relation to 349 interoperability with DMARC. 351 [RFC5598] Section 5 also defines a Mediator as a hybrid of several 352 component types. A Mediator is given special consideration in this 353 section due to the unique issues they face when attempting to 354 interoperate with DMARC. 356 3.1.1. Message Submission Agents 358 An MSA accepts messages submitted by a Message User Agent (MUA) and 359 enforces the policies of the hosting ADministrative Management Domain 360 (ADMD) and the requirements of Internet standards. 362 MSAs are split into two sub-components: 364 o Author-focused MSA functions (aMSA) 366 o MHS-focused MSA functions (hMSA) 368 MSA interoperability issues with DMARC begin when an aMSA accepts a 369 message where the RFC5322.From header field contains a domain that is 370 outside of the ADMD of the MSA. This situation manifests in one of 371 several ways, such as when someone uses a mail service with their own 372 domain but has failed to properly configure an SPF record; or when an 373 MUA attempts to transmit mail as someone else. Examples of the 374 latter situation include "forward-to-friend" functionality commonly 375 found on news/article websites or "send-as" functionality present on 376 some MUAs. 378 When an hMSA takes responsibility for transit of a message containing 379 a domain in the RFC5322.From header field that is outside of the 380 hMSA's ADMD, the hMSA faces DMARC interoperability issues if the 381 domain publishes a DMARC policy of "quarantine" or "reject". These 382 issues are marked by the inherent difficulty of establishing 383 alignment with the domain present in a message's RFC5322.From header 384 field. Examples of this issue include: 386 o Partially-open relays - a residential ISP that allows its 387 customers to relay non-local domains through its infrastructure. 389 o Embedded devices - cable/DSL modems, firewalls, wireless access 390 points, printers that send email using hardcoded domains. 392 o Devices that send mail on behalf of a user - scanners, security 393 cameras, alarms that send mail as their owner or a device user. 395 o Email service providers - ESPs that service customers who are 396 using domains that publish a DMARC "reject" policy. 398 o Calendaring software - an invited member of an event modifies the 399 event causing calendaring software to emit an update that claims 400 to come from the creator of the event. 402 3.1.2. Message Transfer Agents 404 MTAs relay a message until the message reaches a destination MDA. 405 Some common message handling strategies break the integrity of DKIM 406 signatures. A restrictive DMARC policy along with a broken DKIM 407 signature causes latent interoperability problems to become overt 408 problems. 410 3.1.2.1. Message Encoding 412 An MTA may modify the message encoding, for instance by converting 413 8-bit MIME sections to quoted-printable 7-bit sections. This 414 modification is outside the scope of DKIM canonicalization and will 415 invalidate DKIM signatures that include message content. 417 An MTA could also re-encode the message without changing the encoding 418 type, receiving a MIME-encoded message and producing a semantically 419 and semiotically-equivalent MIME body that is not identical to the 420 original. This is characteristic of systems that use some other 421 message representation internally. 423 3.1.2.2. Header Standardization 425 An MTA may rewrite headers to bring them into compliance with 426 existing RFCs. For example, some common MTAs will correct 427 comprehensible but non-compliant date formats to compliant ones. 429 Header rewriting is outside the scope of DKIM canonicalization and 430 will invalidate DKIM signatures. All downstream DMARC processing 431 with be unable to utilize DKIM to yield Authenticated Identifiers due 432 to header rewriting. 434 Providing solutions for issues relating to non RFC-compliant emails 435 is outside the scope of this document. 437 3.1.2.3. Content Validation 439 An MTA may also implement security-motivated changes to the content 440 of email messages, dropping or altering sections of messages, causing 441 breakage of DKIM signatures 443 3.1.3. Message Delivery Agents 445 The MDA transfers a message from the MHS to a mailbox. Like the MSA, 446 the MDA consists of two sub-components: 448 o MHS-focused MDA functions (hMDA) 450 o Recipient-focused MDA functions (rMDA) 452 Both the hMDA and the rMDA can redirect a message to an alternative 453 address. DMARC interoperability issues related to redirecting of 454 messages are described in Section 3.2. 456 SIEVE [RFC5228] functionality often lives in the rMDA sub-component 457 and can cause DMARC interoperability issues. The SIEVE 'addheader' 458 and 'deleteheader' filtering actions can modify messages and 459 invalidate DKIM signatures, removing DKIM-supplied Authenticated 460 Identifiers as inputs to the DMARC mechanism. There are also SIEVE 461 extensions [RFC5703] that modify the body. SIEVE alterations may 462 only become an issue when the email is reintroduced into the 463 transport infrastructure. 465 3.2. Mediators 467 Mediators [RFC5598] forward messages through a re-posting process. 468 Mediators share some functionality with basic MTA relaying, but have 469 greater flexibility in both addressing and content modifications. 471 DMARC interoperability issues are common within the context of 472 Mediators, which are often used precisely for their ability to modify 473 messages. 475 The DMARC design does not cope with some Mediator functionality such 476 as content modifications that invalidate DKIM signatures and 477 RFC5321.MailFrom rewriting to support SPF authentication of resent 478 mail when the new Recipient receives the message from the Mediator 479 rather than the initial organization. 481 3.2.1. Alias 483 An Alias is a simple re-addressing facility that provides one or more 484 new Internet Mail addresses, rather than a single, internal one. A 485 message continues through the transfer service for delivery to one or 486 more alternative addresses. 488 Aliases can be implemented by mailbox-level forwarding (e.g., through 489 "dot-forwarding") or SIEVE-level forwarding (through the SIEVE 490 'redirect' action) or other methods. When an Alias preserves message 491 content and does not make significant header changes, DKIM signatures 492 may remain valid. However, Aliases often extend the delivery path 493 outside of the scope covered by the originating ADMD's SPF record(s). 495 Examples of Aliasing include: 497 o Forwarding email between free email (freemail) providers to try 498 different interfaces while maintaining an original email address; 500 o Consolidating many email addresses into a single account to 501 centralize processing; 503 o Services that provide "activity-based", "role-based" , "vanity" or 504 "temporary" email addresses such as universities and professional 505 associations. For instance professional or alumni institutions 506 may offer their members an alias for the duration of their 507 membership but may not want to deal with the long term storage of 508 emails. 510 In most cases, the aMSA providing Alias services has no 511 administrative relationship to the ADMD of the originator or the 512 final recipient, so solutions to Alias-related DMARC failure should 513 not assume such a relationship. 515 3.2.2. ReSenders 517 ReSenders "splice" a message's addressing information to connect the 518 Author of the original message with the Recipient(s) of the new 519 message. The new Recipient sees the message as being from the 520 original Author, even if the Mediator adds commentary. 522 Without Authenticated Identifiers aligned with the Author's 523 RFC5322.From header field domain, the new Recipient has no way to 524 achieve a passing DMARC evaluation. 526 Examples of ReSenders include MUA-level forwarding by resending a 527 message to a new recipient or by forwarding a message "inline" to a 528 new recipient (this does not include forwarding a message "as an 529 attachment"). An additional example comes in the form of calendaring 530 software that allows a meeting attendee (not the meeting organizer) 531 to modify the content of an invite generating new invitations that 532 claim to be reissued from the meeting organizer. 534 3.2.3. Mailing Lists 536 A Mailing List receives messages as an explicit addressee and then 537 reposts them to a list of subscribed members. The Mailing List 538 performs a task that can be viewed as an elaboration of the ReSender 539 actions. 541 Mailing Lists share the same DMARC interoperability issues as 542 ReSenders (Section 3.2.2), and very commonly modify headers or 543 message content in ways that will cause DKIM to fail, including: 545 o prepending the RFC5322.Subject header field with a tag, to allow 546 the recipient to easily identify the mailing list within a subject 547 line listing; 549 o adding a footer to the email body to contain administrative 550 instructions; 552 o removing some MIME-parts from the email or converting the message 553 to text only; 555 o PGP-encrypting or S/MIME encrypting the body with the receiver's 556 key; 558 o enforcing community standards by rewriting banned words; 560 o allowing moderators to add arbitrary commentary to messages 561 (discussed in [RFC6377]). 563 Any such modifications would invalidate a DKIM signature. 565 Header and content modifications are common for many mailing lists 566 and are often central to present mailing list functionality and 567 usage. Furthermore, MUAs have come to rely on mailing list message 568 modifications to present messages to end users in expected ways. 570 3.2.3.1. Mailing List Operational Effects 572 Mailing Lists may also have the following DMARC interoperability 573 issues: 575 o Subscribed members may not receive email from members that post 576 using domains that publish a DMARC "p=reject" policy. 578 o Mailing Lists may interpret DMARC-related email rejections as an 579 inability to deliver email to the recipients that are checking and 580 enforcing DMARC policy. This processing may cause subscribers 581 that are checking and enforcing DMARC policy to be inadvertently 582 suspended or removed from the Mailing List. 584 3.2.4. Gateways 586 A Gateway performs the basic routing and transfer work of message 587 relaying, but it also is permitted to modify content, structure, 588 addressing, and/or other attributes as needed to send the message 589 into a messaging environment that operates under different standards 590 or potentially incompatible policies. 592 Gateways share the same DMARC interoperability issues as ReSenders 593 (Section 3.2.2). 595 Gateways may also share the same DMARC interoperability issues as 596 MTAs (Section 3.1.2). 598 Receiver systems on the non-SMTP side of a protocol gateway may be 599 unable to evaluate DKIM and SPF. If a message passes through a 600 second protocol gateway back into the SMTP domain, the 601 transformations commonly break the original DKIM signature(s). 603 Gateway-level forwarding can introduce DMARC interoperability issues 604 if the Gateway is configured to rewrite the message into alternate 605 recipient domains. For example, an acquisition may lead an acquiring 606 company to decide to decommission the acquired company's domains by 607 rewriting messages to use the domain of the acquiring company. Since 608 the RFC5322.To header field is usually DKIM-signed, this kind of 609 rewriting will invalidate such DKIM signatures. 611 3.2.5. Boundary Filters 613 To enforce security boundaries, organizations can subject messages to 614 analysis for conformance with their safety policies. A filter might 615 alter the content to render it safe, such as by removing or otherwise 616 altering content deemed unacceptable. 618 Boundary Filters share the same DMARC interoperability issues as 619 ReSenders. 621 Issues may arise with SPF and DKIM evaluation if performed after 622 filter modifications. 624 Examples of Boundary Filters include: 626 o Malware scanning: To protect readers and its reputation, an MTA 627 that transfers a message may remove content believed to be harmful 628 from messages, reformulate content to canonical formats in order 629 to make them more trustworthy or easier to scan, and/or add text 630 in the body to indicate the message has been scanned. Any such 631 modifications would invalidate a DKIM signature. 633 o Spam filtering: To protect reputation and assist other MTAs, an 634 MTA may modify a message to indicate its decision that the message 635 is likely to be unwanted, and/or add text in the body to indicate 636 that such filtering has been done. 638 o Other text additions: An MTA may add an organizational disclaimer 639 or advertisement, for instance. 641 o URL alteration: Some systems will rewrite or alter embedded URLs 642 as a way to control the potential threat from malware. 644 o Secondary MX services: The secondary MX for an organization may be 645 external to the normal mail processing for the organization, and 646 queue and forward to the primary when it becomes available. This 647 will not invalidate DKIM but will prevent the primary from 648 validating SPF normally. In this case, however, it is 649 inappropriate for a primary MX server to perform an SPF check 650 against its own secondaries. Rather, the secondary MX should 651 perform this function and employ some trusted mechanism to 652 communicate the results of the SPF, DKIM, and DMARC evaluation(s) 653 to the primary MX server. 655 3.3. Combinations 657 Indirect email flows can be combined. For example, a university 658 student may subscribe to a mailing list (using his university email 659 address) while this university email address is configured to forward 660 all emails to a freemail or a post-education corporate account 661 provider where a more permanent email address for this student 662 exists. 664 Within an organization the message may pass through various MTAs 665 (Section 3.1.2), each of which performs a different function 666 (authentication, filtering, distribution, etc.) 668 4. Possible Mitigations of Interoperability Issues 670 Solutions to interoperability issues between DMARC and indirect email 671 flows vary widely in their scope and implications. They range from 672 improvements to underlying processing, such as proper handling of 673 multiple DKIM signatures, to more radical changes to the messaging 674 architecture. This section describes possible ways to address 675 interoperability issues. Note that these particular mechanisms may 676 not be considered "best practices" and may, in some cases, violate 677 various conventions or expectations. 679 Receivers sometimes need to deliver email messages that do not 680 conform to any standard or protocol, but are otherwise desired by end 681 users. Mitigating the impact of DMARC on indirect email flows is 682 especially important to receivers that operate services where ease of 683 use and compatibility with existing email flows is a priority. 685 DMARC provides a mechanism (local policy) for receivers to make 686 decisions about identity alignment acceptability based on information 687 outside DMARC and communicate those decisions as "overrides" to the 688 sender. This facility can be used to ease some interoperability 689 issues, although care is needed to ensure that this does not create 690 loopholes for abuse. 692 To further complicate the usage of mitigations, mitigation may not be 693 desired if the email in question is of a certain category of high 694 value or high risk (security-related) transactional messages (dealing 695 with financial transactions or medical records, for example). In 696 these cases, mitigating the impact of DMARC due to indirect email 697 flows may not be desirable (counterproductive or allowing for abuse). 699 As a final note, mail systems are diverse and widely deployed. 700 Systems of various ages and capabilities are expected to preserve 701 interoperability with the rest of the SMTP ecosystem. For instance, 702 Qmail is still used, although the base code has not been updated 703 since 1998. ezmlm, a once popular mailing list manager, is still 704 deployed but has not been updated since 1997, although a new version, 705 ezmlm-idx exists. Old versions of other open and closed source MTAs 706 are still commonly in operation. When dealing with aging or 707 unsupported systems, some solutions may be time-consuming and/or 708 disruptive to implement. 710 4.1. Mitigations in Current Use 712 Because DMARC is already widely deployed, many operators already have 713 mitigations in use. These mitigations vary in their effectiveness 714 and side effects, but have the advantage that they are currently 715 available. 717 4.1.1. Mitigations for Senders 719 4.1.1.1. Identifier Alignment 721 o MTAs handling multiple domains may choose to change 722 RFC5321.MailFrom to align with RFC5322.From to improve SPF 723 usability for DMARC. 725 o MTAs handling multiple domains may also choose to align 726 RFC5321.HELO/.EHLO to RFC5322.From, particularly when sending 727 notification messages. Dynamically adjusting the 728 RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible 729 for some MTA software. 731 o MTAs may choose to DKIM-sign notification messages with an aligned 732 domain to allow a DKIM-based DMARC pass. 734 o MTAs sending email on behalf of multiple domains may require 735 Domain Owners to provide DKIM keys to use DKIM to avoid SPF 736 validation issues, given the requirement for DMARC alignment with 737 the RFC5322.From header field. Managing DKIM keys with a third 738 party has security risks that should be carefully managed (see 739 also [RFC6376] section 8). Methods involving CNAMEs and/or 740 subdomains may alleviate some risks. 742 o Senders who are sending on behalf of users in other Administrative 743 Domains may choose to use an RFC5322.From under the sender's 744 control. The new From can be either a forwarding address in a 745 domain controlled by the Sender, or a placeholder address, with 746 the original user's address in an RFC5322.Reply-to header field. 747 However, performing this modification may cause the recipient's 748 MUA to deviate from customary behavior. 750 o When implementing "forward-to-friend" functionality, one approach 751 to avoid DMARC failures is to pass a well-formed message to the 752 user's MUA so that it may fill in an appropriate identity and 753 submit through its own MSA. 755 o Senders can use domains with distinct DMARC policies for email 756 sent directly and email known to use indirect mail flows. 757 However, for most well-known brands, all active domains are likely 758 to be targeted equally by abusers. 760 4.1.1.2. Message Modification 762 o Senders can maximize survivability of DKIM signatures by limiting 763 the header fields they sign and using relaxed canonicalization. 764 Using the DKIM length tag to allow appended signatures is 765 discouraged due to the security risk created by allowing arbitrary 766 content to be appended to legitimate email. 768 o Senders can also maximize survivability by starting with RFC- 769 compliant headers and common body formats. 771 o In order to minimize transport-based conversions, Senders can 772 convert messages to a lowest denominator MIME content-transfer 773 encoding such as quoted-printable or base64 before signing 774 ([RFC6376] Section 5.3). 776 4.1.2. Mitigations for Receivers 778 4.1.2.1. Identifier Alignment 780 o Receivers should update DKIM handling libraries to ensure that 781 they process all valid DKIM signatures and check each signature 782 for alignment. 784 4.1.2.2. Policy Override 786 o Receivers can amalgamate data from their user base to create lists 787 of forwarders and use such lists to inform DMARC local policy 788 overrides. This process may be easier for large receivers where 789 data and resources to create such lists are more readily available 790 than at smaller sites where the recipient footprint and other 791 resources may be scarce. 793 4.1.3. Mitigations for ReSenders 794 4.1.3.1. Changes to the RFC5322.From 796 Many ReSender issues can be avoided by using an RFC5322.From header 797 field under the ReSender's control, instead of the initial 798 RFC5322.From. This will correct identifier alignment issues and 799 allow arbitrary message modification as long as the ReSender signs 800 the message with an aligned domain signature. When ReSenders change 801 the RFC5322.From, it is desirable to preserve the information about 802 the original initiator of the message. 804 A first option is to use the Original-From [RFC5703] (or X-Original- 805 From) header field for this purpose in various contexts (X- header 806 field names are discouraged by [RFC6648]). However, handling of 807 Original-From (or X-Original-From) is not defined anywhere. It is 808 not currently used consistently or displayed to the user, and in any 809 situation where it is used, it is a new unauthenticated identifier 810 available for exploitation unless included within the scope of the 811 new DKIM signature(s). 813 Another option for ReSenders is to rewrite the RFC5322.From header 814 field address to a locally controlled address which will be forwarded 815 back to the original sender (subject to its own ReSender forwarding 816 mitigations!). 818 4.1.3.2. Avoiding Message Modification 820 o Forwarders can choose to add email header fields instead of 821 modifying existing headers or bodies, for instance to indicate a 822 message may be spam. 824 o Forwarders can minimize the circumstances in which they choose to 825 fix messages, preferring to preserve non-compliant headers to 826 creating DKIM failures. 828 o Forwarders can choose to reject messages with suspect or harmful 829 content instead of modifying them. 831 4.1.3.3. Mailing Lists 833 [RFC6377] provides some guidance on using DKIM with Mailing lists. 834 The following mitigation techniques can be used to ease 835 interoperability issues with DMARC and Mailing lists: 837 o Configuring the Mailing List Manager (MLM) to alter the 838 RFC5322.From header field to use the domain of the MLM is a 839 mitigation policy that is now present in several different Mailing 840 List software distributions. Since most list subscribers prefer 841 to know the identity of the author of the original message, 842 typically this information may be provided in the display name 843 part of the RFC5322.From header field. This display name needs to 844 be carefully crafted so as to not collide with the original 845 display name of the author, nor contain something that looks like 846 an email address or domain name. These modifications may to some 847 extent defeat the purpose of DMARC itself. It may make it 848 difficult to ensure that users of all email clients can easily 849 reply to the author, the list, or all using the email client 850 features provided for that purpose. Use of RFC5322.Reply-To 851 header field can alleviate this problem depending on whether the 852 mailing list is configured to reply-to-list, reply-to-author or 853 reply-to-fixed-address, however it is important to note that this 854 header field can take multiple email addresses. When altering the 855 RFC5322.From there are three possibilities: 857 1. change it to put the mailing list email address, 859 2. change it to a locally-defined address which will be forwarded 860 back to the original sender, or 862 3. "break" the address by modifying the domain to a non-existent 863 domain (such as by adding a suffix like ".invalid".) 865 The latter modification may create issues because it is an invalid 866 domain name, and some MTAs may pay particular attention to the 867 validity of email addresses in RFC5322.From and the reputation of 868 the domains present there. 870 o Configuring the MLM to "wrap" the message in a MIME message/rfc822 871 part and to send as the Mailing List email address. Many email 872 clients (as of the publication of this document), especially 873 mobile clients, have difficulty reading such messages and this is 874 not expected to change soon. 876 o Configuring the MLM to not modify the message so that the DKIM 877 signature remains valid. Some Mailing Lists are set up this way 878 and require few additional changes to ensure the DKIM signature is 879 preserved. Moving lists that currently modify mail to a policy 880 like this may be too much of a change for the members of such 881 lists. 883 o Rejecting posts or membership requests from domains with a DMARC 884 policy other than "p=none". However members or potential members 885 of such Mailing Lists may complain of unfair exclusion. 887 o To alleviate unsubscribes to the Mailing List due to the messages 888 bouncing because of DMARC, the MLM needs to not act on 889 notification messages due to Message Authentication issues. 891 [RFC3463] specifies Enhanced Mail System Status Codes which help 892 differentiate between various failure conditions. Correctly 893 interpreting Extended SMTP error messages is useful in this case. 894 In particular, extended status codes for SPF and DKIM causes are 895 defined in [RFC7372] and DMARC-related failure indications are 896 discussed in DMARC [RFC7489] section 10.3. 898 All these techniques may provide some specific challenges to MUAs and 899 different operational usages for end users (like rewriting filters to 900 sort emails in folders). There will be some time before all 901 implications are understood and accommodated. 903 4.2. Proposed and In-Progress Mitigations 905 The following mitigations are based on Internet Drafts (I-Ds) which 906 are still in process. They are described here to offer exploratory 907 path for solutions. These solutions should not be used in a 908 production environment. Because of the transient nature of I-Ds, 909 specific citations are not included because a number of them will 910 inevitably become obsolete and those which gain consensus in the 911 community will become RFCs and should be discovered as such. 913 o Third-party authorization schemes provide ways to extend 914 identifier alignment under control of the domain owner. 916 o Ways to canonicalize messages that transit mailing lists so that 917 their alterations can be isolated from the original signed 918 content. 920 o Mechanisms to record message transformations applied at each hop 921 so they can be reversed and the original signed content recovered. 923 o "Conditional" DKIM signatures, whereby the author domain indicates 924 its signature is only good if accompanied by a signature from an 925 expected downstream relay. 927 o Mechanisms to extend Authentication-Results [RFC7601] to multiple 928 hops, creating a provable chain of custody as well as a view of 929 message authentication results at each handling step. 931 4.2.1. Getting More Radical: Requiring New Communication Paths Between 932 MUAs 934 In practice a number of operators are using strict alignment mode in 935 DMARC in order to avoid receiving new and innovative forms of 936 unwanted and unauthentic email through systems purporting to be 937 mailing list handlers. The receiving ADMD has no knowledge of which 938 lists the user has subscribed to and which they have not. One avenue 939 of exploration would be for the user to authorize mailing lists as 940 proxies for authentication, at which point the receiving ADMD would 941 be vesting some trust in the mailing list service. The creators of 942 DKIM foresaw precisely this possibility at the time by not tightly 943 binding any semantics to the RFC5322.From header field. Some 944 experimental work has taken place in this area, as mentioned above. 945 Additional work might examine a new communication path to the user to 946 authorize some form of transitive trust. 948 5. IANA Considerations 950 This document contains no actions for IANA. [RFC Editor: Please 951 delete this section prior to publication.] 953 6. Security Considerations 955 This document is an analysis of DMARC's impact on indirect email 956 flows. It describes the possibility of accidental denial-of-service 957 that can be created by rejections of messages by DMARC-aware Mail 958 Receivers. 960 Section 4.1.1.1 discusses the importance of appropriate DKIM key 961 management vis-a-vis third-party email senders. 963 Section 4.1.3.3 warns that rewriting the RFC5322.From header field to 964 create an artificial domain name should not be done with any domain. 966 7. Acknowledgments 968 Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, 969 Rolf E. Sonneveld, Tim Draegen, and Franck Martin contributed to the 970 IETF DMARC Working Group's wiki page listing all known 971 interoperability issues with DMARC and indirect email flows. 973 Tim Draegen created the first draft of this document from these 974 contributions and by hamfistedly mapping contributions into the 975 language of [RFC5598]. 977 8. References 979 8.1. Normative References 981 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 982 Extensions (MIME) Part One: Format of Internet Message 983 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 984 . 986 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 987 RFC 3463, DOI 10.17487/RFC3463, January 2003, 988 . 990 [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email 991 Filtering Language", RFC 5228, DOI 10.17487/RFC5228, 992 January 2008, . 994 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 995 DOI 10.17487/RFC5321, October 2008, 996 . 998 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 999 DOI 10.17487/RFC5322, October 2008, 1000 . 1002 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1003 DOI 10.17487/RFC5598, July 2009, 1004 . 1006 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 1007 Tests, Iteration, Extraction, Replacement, and Enclosure", 1008 RFC 5703, DOI 10.17487/RFC5703, October 2009, 1009 . 1011 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1012 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1013 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1014 . 1016 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 1017 Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, 1018 September 2011, . 1020 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 1021 "Deprecating the "X-" Prefix and Similar Constructs in 1022 Application Protocols", BCP 178, RFC 6648, 1023 DOI 10.17487/RFC6648, June 2012, 1024 . 1026 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1027 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1028 DOI 10.17487/RFC7208, April 2014, 1029 . 1031 [RFC7372] Kucherawy, M., "Email Authentication Status Codes", 1032 RFC 7372, DOI 10.17487/RFC7372, September 2014, 1033 . 1035 8.2. Informative References 1037 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1038 Message Authentication, Reporting, and Conformance 1039 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1040 . 1042 [RFC7601] Kucherawy, M., "Message Header Field for Indicating 1043 Message Authentication Status", RFC 7601, 1044 DOI 10.17487/RFC7601, August 2015, 1045 . 1047 Appendix A. Appendix A - Example SPF Bounce 1049 This example illustrates a notification message "bounce". 1051 A.1. Initial Message 1053 Here is the message as it exits the Origin MTA (segv.d1.example): 1055 Return-Path: 1056 Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) 1057 (authenticated bits=0) 1058 by segv.d1.example with ESMTP id t0FN4a8O084569; 1059 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1060 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1061 s=20130426; t=1421363082; 1062 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1063 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1064 Content-Transfer-Encoding; 1065 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1066 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1067 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1068 Message-ID: <54B84785.1060301@d1.example> 1069 Date: Thu, 14 Jan 2015 15:00:01 -0800 1070 From: John Q Doe 1071 To: no-recipient@dmarc.org 1072 Subject: Example 1 1074 Hey gang, 1075 This is a test message. 1076 --J. 1078 A.2. Notification message 1080 When dmarc.org rejects the message without a DKIM signature, it 1081 specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local which has 1082 no SPF record. dmarc.org has a reject policy in place for such non- 1083 passing cases. Since there is no DKIM signature on the notification 1084 message, the failed SPF lookup results in a dmarc=fail and d1.example 1085 could be expected to discard the notification message itself: 1087 Return-Path: <> 1088 Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1]) 1089 by mx.d1.example with ESMTPS id Lkm25302jJR5 1090 for 1091 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); 1092 Thu, 14 Jan 2015 15:00:24 -0800 (PST) 1093 Authentication-Results: mx.d1.example; 1094 spf=none (d1.example: dmarc.org.local does not designate 1095 permitted sender hosts) smtp.mail=; 1096 dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org 1097 MIME-Version: 1.0 1098 Received: from segv.d1.example (segv.d1.example [198.51.100.1]) 1099 by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu, 1100 14 Jan 2015 15:00:24 -0800 (PST) 1101 From: Mail Delivery Subsystem 1102 To: jqd@d1.example 1103 Subject: Delivery Status Notification (Failure) 1104 Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org> 1105 Date: Thu, 14 Jan 2016 23:00:24 +0000 1106 Content-Type: text/plain; charset=UTF-8 1108 This is an automatically generated Delivery Status Notification 1110 Delivery to the following recipient failed permanently: 1112 no-recipient@dmarc.org 1114 Technical details of permanent failure: 1115 Your message was rejected by the server for the recipient domain 1116 dmarc.org by mail.dmarc.org [192.0.2.1]. 1118 The error that the other server returned was: 1119 550 5.1.1 ... User unknown 1121 ----- Original message ----- 1122 Return-Path: 1123 Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com 1124 [203.252.0.131]) (authenticated bits=0) 1125 by segv.d1.example with ESMTP id t0FN4a8O084569; 1126 Thu, 14 Jan 2015 15:00:01 -0800 (PST) 1127 (envelope-from jqd@d1.example) 1128 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; 1129 s=20130426; t=1421363082; 1130 bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; 1131 h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: 1132 Content-Transfer-Encoding; 1133 b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw 1134 bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl 1135 gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= 1136 Message-ID: <54B84785.1060301@d1.example> 1137 Date: Thu, 14 Jan 2015 15:00:01 -0800 1138 From: John Q Doe 1139 To: no-recipient@dmarc.org 1140 Subject: Example 1 1142 Hey gang, 1143 This is a test message. 1144 --J. 1146 Authors' Addresses 1148 Franck Martin (editor) 1149 LinkedIn 1150 Mountain View, CA 1151 USA 1153 Email: fmartin@linkedin.com 1155 Eliot Lear (editor) 1156 Cisco Systems GmbH 1157 Richtistrasse 7 1158 Wallisellen, ZH CH-8304 1159 Switzerland 1161 Phone: +41 44 878 9200 1162 Email: lear@cisco.com 1164 Tim Draegen (editor) 1165 dmarcian, inc. 1166 PO Box 1007 1167 Brevard, NC 28712 1168 USA 1170 Email: tim@dmarcian.com 1171 Elizabeth Zwicky (editor) 1172 Yahoo 1173 Sunnyvale, CA 1174 USA 1176 Email: zwicky@yahoo-inc.com 1178 Kurt Andersen (editor) 1179 LinkedIn 1180 2029 Stierlin Court 1181 Mt. View, CA 94043 1182 USA 1184 Email: kandersen@linkedin.com