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