idnits 2.17.00 (12 Aug 2021) /tmp/idnits32384/draft-ietf-dkim-mailinglists-06.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 seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 505: '... MLM, the author SHOULD be cautious wh...' RFC 2119 keyword, line 519: '... site SHOULD use a separate message ...' RFC 2119 keyword, line 536: '...as "discardable" SHOULD NOT send mail ...' RFC 2119 keyword, line 544: '...rticipating MLMs SHOULD be prepared fo...' RFC 2119 keyword, line 567: '...refore, participants SHOULD honour the...' (35 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2011) is 4071 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 5617 (ref. 'ADSP') ** Obsolete normative reference: RFC 5451 (ref. 'AUTH-RESULTS') (Obsoleted by RFC 7001) ** Obsolete normative reference: RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) ** Downref: Normative reference to an Informational RFC: RFC 5598 (ref. 'EMAIL-ARCH') -- Obsolete informational reference (is this intentional?): RFC 5672 (ref. 'DKIM-UPDATE') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5070 (ref. 'IODEF') (Obsoleted by RFC 7970) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DKIM Working Group M. Kucherawy 3 Internet-Draft Cloudmark 4 Intended status: BCP March 28, 2011 5 Expires: September 29, 2011 7 DKIM And Mailing Lists 8 draft-ietf-dkim-mailinglists-06 10 Abstract 12 DomainKeys Identified Mail (DKIM) allows an administrative mail 13 domain (ADMD) to assume some responsibility for a message. As the 14 industry has now gained some deployment experience, the goal for this 15 document is to explore the use of DKIM for scenarios that include 16 intermediaries, such as Mailing List Managers (MLMs) and describe the 17 Best Current Practices. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 29, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. MLMs In Infrastructure . . . . . . . . . . . . . . . . . . 4 56 1.3. Feedback Loops And Other Bi-Lateral Agreements . . . . . . 5 57 1.4. Document Scope and Goals . . . . . . . . . . . . . . . . . 6 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 2.1. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.2. DKIM-Specific References . . . . . . . . . . . . . . . . . 7 61 2.3. 'DKIM-Friendly' . . . . . . . . . . . . . . . . . . . . . 7 62 2.4. Message Streams . . . . . . . . . . . . . . . . . . . . . 7 63 3. Mailing Lists and DKIM . . . . . . . . . . . . . . . . . . . . 8 64 3.1. Roles and Realities . . . . . . . . . . . . . . . . . . . 8 65 3.2. Types Of Mailing Lists . . . . . . . . . . . . . . . . . . 9 66 3.3. Current MLM Effects On Signatures . . . . . . . . . . . . 10 67 4. Non-Participating MLMs . . . . . . . . . . . . . . . . . . . . 12 68 4.1. Author-Related Signing . . . . . . . . . . . . . . . . . . 12 69 4.2. Verification Outcomes at Receivers . . . . . . . . . . . . 13 70 4.3. Handling Choices at Receivers . . . . . . . . . . . . . . 13 71 4.4. Wrapping A Non-Participating MLM . . . . . . . . . . . . . 13 72 5. Participating MLMs . . . . . . . . . . . . . . . . . . . . . . 14 73 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 5.2. DKIM Author Domain Signing Practices . . . . . . . . . . . 15 75 5.3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . 15 76 5.4. Author-Related Signing . . . . . . . . . . . . . . . . . . 15 77 5.5. Verification Outcomes at MLMs . . . . . . . . . . . . . . 16 78 5.6. Signature Removal Issues . . . . . . . . . . . . . . . . . 17 79 5.7. MLM Signatures . . . . . . . . . . . . . . . . . . . . . . 18 80 5.8. Verification Outcomes at Final Receiving Sites . . . . . . 19 81 5.9. Use With FBLs . . . . . . . . . . . . . . . . . . . . . . 20 82 5.10. Handling Choices at Receivers . . . . . . . . . . . . . . 20 83 6. DKIM Reporting . . . . . . . . . . . . . . . . . . . . . . . . 22 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 86 8.1. Authentication Results When Relaying . . . . . . . . . . . 24 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 90 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 91 Appendix B. Example Scenarios . . . . . . . . . . . . . . . . . . 28 92 B.1. MLMs and ADSP . . . . . . . . . . . . . . . . . . . . . . 28 93 B.2. MLMs and FBLs . . . . . . . . . . . . . . . . . . . . . . 28 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 96 1. Introduction 98 DomainKeys Identified Mail ([DKIM]) allows an Administrative Mail 99 Domain to take some responsibility for a [MAIL] message. This can be 100 an author's organization, an operational relay (Mail Transfer Agent, 101 or MTA) or one of their agents. Assertion of responsibility is made 102 through a cryptographic signature. Message transit from author to 103 recipient is through relays that typically make no substantive change 104 to the message content and thus preserve the validity of the DKIM 105 signature. 107 In contrast to relays, there are intermediaries, such as mailing list 108 managers (MLMs), that actively take delivery of messages, re-format 109 them, and re-post them, often invalidating DKIM signatures. The goal 110 for this document is to explore the use of DKIM for scenarios that 111 include intermediaries, and recommend Best Current Practices based on 112 acquired experience. Questions that will be discussed include: 114 o Under what circumstances is it advisable for an author, or its 115 organization, to apply DKIM to mail sent to mailing lists? 117 o What are the tradeoffs regarding having an MLM verify and use DKIM 118 identifiers? 120 o What are the tradeoffs regarding having an MLM remove existing 121 DKIM signatures prior to re-posting the message? 123 o What are the tradeoffs regarding having an MLM add its own DKIM 124 signature? 126 These and others are open questions for which there may be no 127 definitive answers. However, based on experience since the 128 publication of [DKIM] and its gradual deployment, there are some 129 views that are useful to consider and some recommended procedures. 131 In general there are, in relation to DKIM, two categories of MLMs: 132 participating and non-participating. As each types has its own 133 issues regarding DKIM-signed messages that are either handled or 134 produced by them (or both), the types are discussed in separate 135 sections. 137 1.1. Background 139 DKIM signatures permit an agent of the email architecture (see 140 [EMAIL-ARCH]) to make a claim of responsibility for a message by 141 affixing a validated domain-level identifier to the message as it 142 passes through a gateway. Although not the only possibility, this is 143 most commonly done as a message passes through a Mail Transport Agent 144 (MTA) as it departs an Administrative Mail Domain (ADMD) toward the 145 general Internet. 147 A DKIM signature will fail to verify if a portion of the message 148 covered by one of its hashes is altered. An MLM commonly alters 149 messages to provide information specific to the mailing list for 150 which it is providing service. Common modifications are enumerated 151 and described in Section 3.3. However, note that MLMs vary widely in 152 behaviour as well as often allowing subscribers to select individual 153 behaviours. Further, this does not consider changes the MTA might 154 make independent of what changes the MLM chooses to apply. 156 The DKIM specification document deliberately refrains from the notion 157 of tying the signing domain (the "d=" tag in a DKIM signature) to any 158 identifier within a message; any ADMD that handles a message could 159 sign it, regardless of its origin or author domain. In particular, 160 DKIM does not define any meaning to the occurrence of a match between 161 the content of a "d=" tag and the value of, for example, a domain 162 name in the RFC5322.From field, nor is there any obvious degraded 163 value to a signature where they do not match. Since any DKIM 164 signature is merely an assertion of "some" responsibility by an ADMD, 165 a DKIM signature added by an MLM has no more, nor less, meaning than 166 a signature with any other "d=" value. 168 1.2. MLMs In Infrastructure 170 Section 3.3 describes some of the things MLMs commonly do that 171 produce broken signatures, thus reducing the perceived value of DKIM. 173 Further, while there are published standards that are specific to MLM 174 behaviour (e.g. [MAIL], [LIST-ID] and [LIST-URLS]), their adoption 175 has been spotty at best. Hence, efforts to specify the use of DKIM 176 in the context of MLMs needs to be incremental and value-based. 178 Other MLM behaviours are well-established. Although it can be argued 179 that they frustrate widespread DKIM adoption, it cannot be said that 180 such behaviours are not standards compliant. Thus, the best approach 181 is to provide these best practices to all parties involved, imposing 182 the minimum requirements possible to MLMs themselves. 184 An MLM is an autonomous agent that takes delivery of a message and 185 can re-post it as a new message, or construct a digest of it along 186 with other messages to the members of the list (see [EMAIL-ARCH], 187 Section 5.3). However, the fact that the RFC5322.From field of such 188 a message (in the non-digest case) is typically the same as that of 189 the original message, and that recipients perceive the message as 190 "from" the original author rather than the MLM, creates confusion 191 about responsibility and autonomy for the re-posted message. This 192 has important implications for use of DKIM. 194 A DKIM signature on a message is an expression of some responsibility 195 for the message taken by the signing domain. An open issue, and one 196 this document intends to address, is some idea of how such a 197 signature might be used by a recipient's evaluation module after the 198 message has gone through a mailing list and may or may not have been 199 invalidated, and if it has, where and how the invalidation may have 200 happened. 202 Note that where in this document there is discussion of an MLM 203 conducting validation of DKIM signatures or ADSP policies, the actual 204 implementation could be one where the validation is done by the MTA 205 or an agent attached to it, and the results of that work are relayed 206 by a trusted channel not specified here. See [AUTH-RESULTS] for a 207 discussion of this. This document does not favour any particular 208 arrangement of these agents over another, but merely talks about the 209 MLM itself doing the work as a matter of simplicity. 211 1.3. Feedback Loops And Other Bi-Lateral Agreements 213 A Feedback Loop (FBL) is a bi-lateral agreement between two parties 214 to exchange reports of abuse. Typically, a sender registers with a 215 receiving site to receive abuse reports from that site for mail 216 coming from the sender. 218 An FBL reporting address (i.e., an address to which FBL reports are 219 sent) is part of this bi-lateral registration. Some FBLs require 220 DKIM use by the registrant. 222 A DKIM-signed message sent to an MLM, and then distributed to all of 223 a list's recipients, could result in a complaint from one of the 224 recipients for some reason. This could be an actual complaint from 225 some subscriber that finds the message abusive or otherwise 226 undesirable, or it could be an automated complaint such as receiver 227 detection of an invalidated DKIM signature or some other condition. 228 It could also be a complaint that results from antagonistic 229 behaviour, such as is common when a subscriber to a list is having 230 trouble unsubscribing, and then begins issuing complaints about all 231 submissions to the list. This would result in a complaint being 232 generated in the context of an FBL report back to the message author. 233 However, the original author has no involvement in operation of the 234 MLM itself, meaning the FBL report is not actionable and thus 235 undesirable. 237 See Section 6 for additional discussion. 239 FBLs tend to use the ARF ([MARF]) or the IODEF ([IODEF]) format. 241 1.4. Document Scope and Goals 243 This document provides discussion on the above issues, to improve the 244 handling of possible interactions between DKIM and MLMs. In general, 245 consensus shows a preference toward imposing changes to behaviour at 246 the signer and verifier rather than at the MLM. 248 Wherever possible, MLMs will be conceptually decoupled from MTAs 249 despite the very tight integration that is sometimes observed in 250 implementation. This is done to emphasize the functional 251 independence of MLM services and responsibilities from those of an 252 MTA. 254 Parts of this document explore possible changes to common practice by 255 signers, verifiers and MLMs. The suggested enhancements are largely 256 theoretical in nature, taking into account the current email 257 infrastructure, the facilities DKIM can provide as it gains wider 258 deployment, and working group consensus. There is no substantial 259 implementation history upon which these suggestions are based, and 260 the efficacy, performance and security characteristics of them have 261 not yet been fully explored. 263 2. Definitions 265 2.1. Other Terms 267 See [EMAIL-ARCH] for a general description of the current messaging 268 architecture, and for definitions of various terms used in this 269 document. 271 2.2. DKIM-Specific References 273 Readers are encouraged to become familiar with [DKIM] and [ADSP], 274 which are core specification documents, as well as [DKIM-OVERVIEW] 275 and [DKIM-DEPLOYMENT], which are DKIM's primary tutorial documents. 277 2.3. 'DKIM-Friendly' 279 The term "DKIM-Friendly" is used to describe an email intermediary 280 that, when handling a message, makes no changes to that message which 281 cause valid [DKIM] signatures present on the message on input to fail 282 to verify on output. 284 Various features of MTAs and MLMs seen as helpful to users often have 285 side effects that do render DKIM signatures unverifiable. These 286 would not qualify for this label. 288 2.4. Message Streams 290 This document makes reference to the concept of "message streams". 291 The idea is to identify groups of messages originating from within an 292 ADMD that are distinct in intent, origin and/or use, and partition 293 them somehow (i.e., via changing the value in the "d=" tag value in 294 the context of DKIM) so as to keep them associated to users yet 295 distinct in terms of their evaluation and handling by verifiers or 296 receivers. 298 A good example might be user mail generated by a company's employees, 299 versus operational or transactional mail that comes from automated 300 sources, versus marketing or sales campaigns. Each of these could 301 have different security policies imposed against them, or there might 302 be a desire to insulate one from the other (e.g., a marketing 303 campaign that gets reported by many spam filters could cause the 304 marketing stream's reputation to degrade without automatically 305 punishing the transactional or user streams). 307 3. Mailing Lists and DKIM 309 It is important to make some distinctions among different MLM-like 310 agents, their typical implementations, and the impacts they have in a 311 DKIM-aware environment. 313 3.1. Roles and Realities 315 In DKIM parlance, there are several key roles in the transit of a 316 message. Most of these are defined in [EMAIL-ARCH]. 318 author: The agent that provided the content of the message being 319 sent through the system, and performed the initial submission. 320 This can be a human using an MUA or a common system utility such 321 as "cron", etc. 323 originator: The agent that accepts a message from the author, 324 ensures it conforms to the relevant standards such as [MAIL], and 325 then relays it toward its destination(s). This is often referred 326 to as the Mail Submission Agent (MSA). 328 signer: Any agent that affixes one or more DKIM signature(s) to a 329 message on its way toward its ultimate destination. There is 330 typically a signer running at the MTA that sits between the 331 author's ADMD and the general Internet. The originator and/or 332 author might also be a signer. 334 verifier: Any agent that conducts DKIM signature analysis. One is 335 typically running at the MTA that sits between the general 336 Internet and the receiver's ADMD. Note that any agent that 337 handles a signed message could conduct verification; this document 338 only considers that action and its outcomes either at an MLM or at 339 the receiver. Filtering decisions could be made by this agent 340 based on verification results. 342 receiver: The agent that is the final transit relay for the message 343 prior to being delivered to the recipient(s) of the message. 344 Filtering decisions based on results made by the verifier could be 345 applied by the receiver. The verifier and the receiver could be 346 the same agent. 348 In the case of simple user-to-user mail, these roles are fairly 349 straightforward. However, when one is sending mail to a list, which 350 then gets relayed to all of that list's subscribers, the roles are 351 often less clear to the general user as particular agents may hold 352 multiple important but separable roles. The above definitions are 353 intended to enable more precise discussion of the mechanisms 354 involved. 356 3.2. Types Of Mailing Lists 358 There are four common MLM implementation modes: 360 aliasing: An aliasing MLM (see Section 5.1 of [EMAIL-ARCH]) is one 361 that makes no changes to a message as it redistributes; any 362 modifications are constrained to changes to the [SMTP] envelope 363 recipient list (RCPT commands) only. There are no changes to the 364 message body at all and only [MAIL] trace header fields are added. 365 The output of such an MLM is considered to be a continuation of 366 the author's original message. An example of such an MLM is an 367 address that expands directly in the MTA, such as a list of local 368 system administrators used for relaying operational or other 369 internal-only messages. See also Section 3.9.2 of [SMTP]. 371 resending: A resending MLM (see Sections 5.2 and 5.3 of 372 [EMAIL-ARCH]) is one that may make changes to a message. The 373 output of such an MLM is considered to be a new message; delivery 374 of the original has been completed prior to distribution of the 375 re-posted message. Such messages are often re-formatted, such as 376 with list-specific header fields or other properties, to 377 facilitate discussion among list subscribers. 379 authoring: An authoring MLM is one that creates the content being 380 sent as well as initiating its transport, rather than basing it on 381 one or more messages received earlier. This is a special case of 382 the MLM paradigm, one that generates its own content and does not 383 act as an intermediary. Typically replies are not generated, or 384 if they are, they go to a specific recipient and not back to the 385 list's full set of recipients. Examples include newsletters and 386 bulk marketing mail. 388 digesting: A special case of the resending MLM is one that sends a 389 single message comprising an aggregation of recent MLM 390 submissions, which might be a message of [MIME] type "multipart/ 391 digest" (see [MIME-TYPES]). This is obviously a new message but 392 it may contain a sequence of original messages that may themselves 393 have been DKIM-signed. 395 In the remainder of this document we distinguish two relevant steps, 396 corresponding to the following SMTP transactions: 398 MLM Input: Originating user is author; originating ADMD is 399 originator and signer; MLM's ADMD is verifier; MLM's input 400 function is receiver. 402 MLM Output: MLM (sending its reconstructed copy of the originating 403 user's message) is author; MLM's ADMD is originator and signer; 404 the ADMD of each subscriber of the list is a verifier; each 405 subscriber is a receiver. 407 Much of this document focuses on the resending class of MLM as it has 408 the most direct conflict operationally with DKIM. 410 The dissection of the overall MLM operation into these two distinct 411 steps allows the DKIM-specific issues with respect to MLMs to be 412 isolated and handled in a logical way. The main issue is that the 413 repackaging and reposting of a message by an MLM is actually the 414 construction of a completely new message, and as such the MLM is 415 introducing new content into the email ecosystem, consuming the 416 author's copy of the message and creating its own. When considered 417 in this way, the dual role of the MLM and its ADMD becomes clear. 419 Some issues about these activities are discussed in Section 3.6.4 of 420 [MAIL] and in Section 3.4.1 of [EMAIL-ARCH]. 422 3.3. Current MLM Effects On Signatures 424 As described above, an aliasing MLM does not affect any existing 425 signature, and an authoring MLM is always creating new content and 426 thus there is never an existing signature. However, the changes a 427 resending MLM can make typically affect the RFC5322.Subject header 428 field, addition of some list-specific header fields, and/or 429 modification of the message body. The impacts of each of these on 430 DKIM verification are discussed below. 432 Subject tags: A popular feature of MLMs is the "tagging" of an 433 RFC5322.Subject field by prefixing the field's contents with the 434 name of the list, such as "[example]" for a list called "example". 435 Altering the RFC5322.Subject field on new submissions by adding a 436 list-specific prefix or suffix will invalidate the signer's 437 signature if that header field was included when creating that 438 signature. [DKIM] lists RFC5322.Subject as one that should be 439 covered, so this is expected to be an issue for any list that 440 makes such changes. 442 List-specific header fields: Some lists will add header fields 443 specific to list administrative functions such as those defined in 444 [LIST-ID] and [LIST-URLS], or the "Resent-" fields defined in 445 [MAIL]. It is unlikely that a typical MUA would include such 446 fields in an original message, and DKIM is resilient to the 447 addition of header fields in general (see notes about the "h=" tag 448 in Section 3.5 of [DKIM]). Therefore this is seen as less of a 449 concern. 451 Other header fields: Some lists will add or replace header fields 452 such as "Reply-To" or "Sender" in order to establish that the 453 message is being sent in the context of the mailing list, so that 454 the list is identified ("Sender") and any user replies go to the 455 list ("Reply-To"). If these fields were included in the original 456 message, it is possible that one or more of them may have been 457 signed, and those signatures will thus be broken. 459 Minor body changes: Some lists prepend or append a few lines to each 460 message to remind subscribers of an administrative URL for 461 subscription issues, or of list policy, etc. Changes to the body 462 will alter the body hash computed at the DKIM verifier, so these 463 will render any existing signatures that cover those portions of 464 the message body unverifiable. 466 Major body changes: There are some MLMs that make more substantial 467 changes to message bodies when preparing them for re-distribution, 468 such as adding, deleting, reordering, or reformatting [MIME] 469 parts, "flattening" HTML messages into plain text, or insert 470 headers or footers within HTML messages. Most or all of these 471 changes will invalidate a DKIM signature. 473 MIME part removal: Some MLMs that are MIME-aware will remove large 474 MIME parts from submissions and replace them with URLs to reduce 475 the size of the distributed form of the message and to prevent 476 inadvertent automated malware delivery. Except in cases where a 477 body length limit is applied in generation of the DKIM signature, 478 the signature will be broken. 480 There reportedly still exist a few scattered mailing lists in 481 operation that are actually run manually by a human list manager, 482 whose workings in preparing a message for distribution could include 483 the above or even some other changes. 485 In general, absent a general movement by MLM developers and operators 486 toward more DKIM-friendly practices, an MLM subscriber cannot expect 487 signatures applied before the message was processed by the MLM to be 488 valid on delivery to a receiver. Such an evolution is not expected 489 in the short term due to general development and deployment inertia. 490 Moreover, even if an MLM currently passes messages unmodified such 491 that author signatures validate, it is possible that a configuration 492 change or software upgrade to that MLM will cause that no longer to 493 be true. 495 4. Non-Participating MLMs 497 This section contains a discussion of issues regarding sending DKIM- 498 signed mail to or through an MLM that is not DKIM-aware. 499 Specifically, the header fields introduced by [DKIM] and 500 [AUTH-RESULTS] carry no special meaning to such an MLM. 502 4.1. Author-Related Signing 504 If an author knows that the MLM to which a message is being sent is a 505 non-participating resending MLM, the author SHOULD be cautious when 506 deciding whether or not to send to the list when that mail would be 507 signed. The MLM could make a change that would invalidate the 508 author's signature but not remove it prior to re-distribution. 509 Hence, list recipients would receive a message purportedly from the 510 author but bearing a DKIM signature that would not verify. There 511 exist DKIM modules that incorrectly penalize messages with signatures 512 that do not validate, so this may have detrimental effects outside of 513 the author's control. (Additional discussion of this is below.) 514 This problem could be compounded if there were receivers that applied 515 signing policies (e.g., [ADSP]) and the author published any kind of 516 strict policy. 518 For domains that do publish strict ADSP policies, the originating 519 site SHOULD use a separate message stream (see Section 2.4), such as 520 a sub-domain, for the "personal" mail -- a subdomain that is 521 different from domain(s) used for other mail streams. This allows 522 each to develop an independent reputation, and more stringent 523 policies (including ADSP) can be applied to the mail stream(s) that 524 do not go through mailing lists or perhaps do not get signed at all. 526 However, all of this presupposes a level of infrastructure 527 understanding that is not expected to be common. Thus, it will be 528 incumbent upon site administrators to consider how support of users 529 wishing to participate in mailing lists might be accomplished as DKIM 530 achieves wider adoption. 532 In general, the more strict practices and policies are likely to be 533 successful only for the mail streams subject to the most end-to-end 534 control by the originating organization. That typically excludes 535 mail going through MLMs. Therefore, authors whose ADSP is published 536 as "discardable" SHOULD NOT send mail to MLMs, as it is likely to be 537 rejected by ADSP-aware verifiers or recipients. (This is discussed 538 further in Section 5.6 below.) 540 4.2. Verification Outcomes at Receivers 542 There does not appear to be a reliable way to determine that a piece 543 of mail arrived via a non-participating MLM. Sites whose users 544 subscribe to non-participating MLMs SHOULD be prepared for legitimate 545 mail to arrive with no valid signature, just as it always has in the 546 absence of DKIM. 548 4.3. Handling Choices at Receivers 550 A receiver's ADMD would have to have some way to register such non- 551 participating lists to exempt them from the expectation of signed 552 mail as discussed in Section 4.1. This is, however, probably not a 553 scalable solution as it imposes a burden on the receiver that is 554 predicated on sender behaviour. 556 Note that the [DKIM] specification explicitly directs verifiers and 557 receivers to treat a verification failure as though the message was 558 not signed in the first place. In the absence of specific ADSP 559 direction, any treatment of a verification failure as having special 560 meaning is either outside the scope of DKIM or is in violation of it. 562 Use of restrictive domain policies such as [ADSP] "discardable" 563 presents an additional challenge. In that case, when a message is 564 unsigned or the signature can no longer be verified, discarding of 565 the message is requested. There is no exception in the policy for a 566 message that may have been altered by an MLM, nor is there a reliable 567 way to identify such mail. Therefore, participants SHOULD honour the 568 policy and disallow the message. 570 4.4. Wrapping A Non-Participating MLM 572 One approach to adding DKIM support to an otherwise non-participating 573 MLM is to "wrap" it, or in essence place it between other DKIM-aware 574 components (such as MTAs) that provide some DKIM services. For 575 example, the ADMD operating a non-participating MLM could have a DKIM 576 verifier act on submissions, enforcing some of the features and 577 recommendations of Section 5 on behalf of the MLM, and the MTA or MSA 578 receiving the MLM Output could also add a DKIM signature for the 579 MLM's domain. 581 5. Participating MLMs 583 This section contains a discussion of issues regarding sending DKIM- 584 signed mail to or through an MLM that is DKIM-aware, and may also be 585 ADSP-aware. 587 5.1. General 589 As DKIM becomes more widely deployed, it is highly desirable that MLM 590 software adopt more DKIM-friendly processing. 592 Changes that merely add new header fields, such as those specified by 593 [LIST-ID], [LIST-URLS] and [MAIL], are generally the most friendly to 594 a DKIM-participating email infrastructure in that their addition by 595 an MLM will not affect any existing DKIM signatures unless those 596 fields were already present and covered by a signature's hash or a 597 signature was created specifically to disallow their addition (see 598 the note about "h=" in Section 3.5 of [DKIM]). 600 However, the practice of applying headers and footers to message 601 bodies is common and not expected to fade regardless of what 602 documents this or any standards body might produce. This sort of 603 change will invalidate the signature on a message where the body hash 604 covers the entire message. Thus, the following sections also discuss 605 and suggest other processing alternatives. 607 A possible mitigation to this incompatibility is use of the "l=" tag 608 to bound the portion of the body covered by the DKIM body hash, but 609 this is not workable for [MIME] messages; moreover, it has security 610 considerations (see Section 3.5 of [DKIM]). Its use is therefore 611 discouraged. 613 MLM operators often arrange to affix to outgoing messages expressions 614 of list-specific policy and related information (e.g., rules for 615 participation, small advertisements, etc.). There is currently no 616 header field proposed for relaying such general operational MLM 617 details apart from what [LIST-URLS] already supports. This sort of 618 information is what is commonly included in appended footer text or 619 prepended header text. The working group RECOMMENDS periodic, 620 automatic mailings to the list to remind subscribers of list policy, 621 and otherwise RECOMMENDS use of standard header fields to express 622 list operation parameters rather than body changes. These periodic 623 mailings will be repetitive, of course, but by being generally the 624 same each time they can be easily filtered if desired. 626 5.2. DKIM Author Domain Signing Practices 628 [ADSP] presents a particular challenge. An author domain posting a 629 policy of "discardable" imposes a very tight restriction on the use 630 of mailing lists, essentially constraining that domain's users to 631 lists operated by aliasing MLMs only; any MLM that alters a message 632 from such a domain or removes its signature subjects the message to 633 severe action by verifiers or receivers. It is the consensus of the 634 working group that a resending MLM SHOULD reject outright any mail 635 from an author whose domain posts such a policy as it is likely to be 636 rejected by any ADSP-aware recipients, and SHOULD also discourage 637 such subscribers when they first sign up to the list. Further 638 discussion of this appears in Section 5.3. 640 Where the above practice is not observed and "discardable" mail 641 arrives via a list to a verifier that applies ADSP checks which fail, 642 the message SHOULD either be discarded (i.e. accept the message at 643 the [SMTP] level but discard it without delivery) or rejected by 644 returning a 5xx error code. In the latter case, some advice for how 645 to conduct the rejection in a potentially meaningful way can be found 646 in Section 5.10. 648 See also Appendix B.5 of [ADSP] for further discussion. 650 5.3. Subscriptions 652 At subscription time, an ADSP-aware MLM SHOULD check for a published 653 ADSP record for the new subscriber's domain. If the policy specifies 654 "discardable", the MLM SHOULD disallow the subscription or present a 655 warning that the subscriber's submissions to the mailing list might 656 not be deliverable to some recipients because of the subscriber's 657 ADMD's published policy. 659 Of course, such a policy record could be applied after subscription, 660 so this is not a universal solution. An MLM implementation MAY do 661 periodic checks of its subscribers and issue warnings where such a 662 policy is detected, or simply check upon each submission. 664 5.4. Author-Related Signing 666 An important consideration is that authors rarely have any direct 667 influence over the management of an MLM. As such, a signed message 668 from an author will in essence go to a set of unexpected places, 669 sometimes coupled with other messages from other sources. In the 670 future, as DKIM signature outputs (e.g. the AUID or SDID of 671 [DKIM-UPDATE]) are used as inputs to reputation modules, there may be 672 a desire to insulate one's reputation from influence by the unknown 673 results of sending mail through an MLM. In that case, authors SHOULD 674 create a mail stream specifically used for generating signatures when 675 sending traffic to MLMs. 677 This suggestion can be made more general. Mail that is of a 678 transactional or generally end-to-end nature, and not likely to be 679 forwarded around either by MLMs or users, SHOULD come from a 680 different mail stream than a stream that serves more varied uses. 682 5.5. Verification Outcomes at MLMs 684 MLMs typically attempt to authenticate messages posted through them. 685 They usually do this through the trivial (and insecure) means of 686 verifying the RFC5322.From field email address (or, less frequently, 687 the RFC5321.MailFrom parameter) against a list registry. DKIM 688 enables a stronger form of authentication, although this is not yet 689 formally documented: It can require that messages using a given 690 RFC5322.From address also have a DKIM signature with a corresponding 691 "d=" domain. This feature would be somewhat similar to using ADSP, 692 except that the requirement for it would be imposed by the MLM and 693 not the author's organization. 695 As described, the MLM MAY conduct DKIM verification of a signed 696 message to attempt to confirm the identity of the author. Although 697 it is a common and intuitive conclusion, not all signed mail will 698 include an author signature (see [ADSP]). MLM implementers SHOULD 699 accommodate such in their configurations. For example, an MLM might 700 be designed to accommodate a list of possible signing domains (the 701 "d=" portion of a DKIM signature) for a given author, and determine 702 at verification time if any of those are present. 704 A message that cannot be thus authenticated MAY be held for 705 moderation or rejected outright. 707 This logic could apply to any list operation, not just list 708 submission. In particular, this improved authentication MAY apply to 709 subscription, unsubscription, and/or changes to subscriber options 710 that are sent via email rather than through an authenticated, 711 interactive channel such as the web. 713 In the case of verification of signatures on submissions, MLMs SHOULD 714 add an [AUTH-RESULTS] header field to indicate the signature(s) 715 observed on the submission as it arrived at the MLM and what the 716 outcome of the evaluation was. Downstream agents may or may not 717 trust the content of that header field depending on their own a 718 priori knowledge of the operation of the ADMD generating (and, 719 preferably, signing) that header field. See [AUTH-RESULTS] for 720 further discussion. 722 5.6. Signature Removal Issues 724 A message that arrives signed with DKIM means some domain prior to 725 MLM Input has made a claim of some responsibility for the message. 726 An obvious benefit to leaving the input-side signatures intact, then, 727 is to preserve that chain of responsibility of the message so that 728 the receivers of the final message have an opportunity to evaluate 729 the message with that information available to them. 731 However, if the MLM is configured to make changes to the message 732 prior to re-posting that would invalidate the original signature(s), 733 further action is RECOMMENDED to prevent invalidated signatures from 734 arriving at final recipients, possibly triggering unwarranted filter 735 actions. (Note, however, that such filtering actions are plainly 736 wrong; [DKIM] stipulates that an invalid signature is to be treated 737 as no signature at all.) 739 A possible solution would be to: 741 1. Attempt verification of all DKIM signatures present on the input 742 message; 744 2. Apply local policy to authenticate the identity of the author; 746 3. Remove all existing [AUTH-RESULTS] fields (optional); 748 4. Add an [AUTH-RESULTS] header field to the message to indicate the 749 results of the above; 751 5. Remove all previously-evaluated DKIM signatures; 753 6. Affix a new signature that covers the entire message on the 754 output side, including the Authentication-Results header field 755 just added (see Section 5.7). 757 Removing the original signature(s) seems particularly appropriate 758 when the MLM knows it is likely to invalidate any or all of them due 759 to the nature of the reformatting it will do. This avoids false 760 negatives at the list's subscribers in their roles as receivers of 761 the message; although [DKIM] stipulates that an invalid signature is 762 the same as no signature, it is anticipated that there will be some 763 implementations that ignore this advice. 765 The MLM could re-evaluate existing signatures after making its 766 message changes to determine whether or not any of them have been 767 invalidated. The cost of this is reduced by the fact that, 768 presumably, the necessary public keys have already been downloaded 769 and one or both of the message hashes could be reused. 771 Per the discussion in [AUTH-RESULTS], there is no a priori reason for 772 the final receivers to put any faith in the veracity of that header 773 field when added by the MLM. Thus, the final recipients of the 774 message have no way to verify on their own the authenticity of the 775 author's identity on that message. However, if that field is the 776 only one on the message when the verifier gets it, and the verifier 777 explicitly trusts the signer (in this case, the MLM), the verifier is 778 in a position to believe that a valid author signature was present on 779 the message. 781 This can be generalized as follows: A receiver SHOULD consider only 782 [AUTH-RESULTS] fields bearing an authserv-id that appears in a list 783 of sites the receiver trusts and which is also included in the header 784 hash of a [DKIM] signature added by a domain in the same trusted 785 list. 787 Since an aliasing MLM makes no substantive changes to a message, it 788 need not consider the issue of signature removal as the original 789 signatures should arrive at least to the next MTA unmodified. It is 790 possible that future domain-based reputations would prefer a more 791 rich data set on receipt of a message, and in that case signature 792 removal would be undesirable. 794 An authoring MLM is closed to outside submitters, thus much of this 795 discussion does not apply in that case. 797 5.7. MLM Signatures 799 DKIM-aware resending MLMs and authoring MLMs SHOULD affix their own 800 signatures when distributing messages. The MLM is responsible for 801 the alterations it makes to the original messages it is re-sending, 802 and should express this via a signature. This is also helpful for 803 getting feedback from any FBLs that might be set up so that undesired 804 list mail can generate appropriate action. 806 MLM signatures will likely be used by recipient systems to recognize 807 list mail, and they give the MLM's ADMD an opportunity to develop a 808 good reputation for the list itself. 810 A signing MLM is, as any other MLM, free to omit redistribution of a 811 message if that message was not signed in accordance with its own 812 local configuration or policy. It could also redistribute but not 813 sign such mail. However, selective signing is NOT RECOMMENDED; 814 essentially that would create two message streams from the MLM, one 815 signed and one not, which can confuse DKIM-aware verifiers and 816 receivers. 818 A signing MLM SHOULD add a List-Post: header field (see [LIST-URLS]) 819 using a DNS domain matching what will be used in the "d=" tag of the 820 DKIM signature it will add to the new message. This could be used by 821 verifiers or receivers to identify the DKIM signature that was added 822 by the MLM. This is not required, however; it is believed the 823 reputation of the signer will be a more critical data point rather 824 than this suggested binding. Furthermore, this is not a binding 825 recognized by any current specification document. 827 Such MLMs SHOULD ensure the signature's header hash will cover at 828 least: 830 o Any [AUTH-RESULTS] fields added by the MLM; 832 o Any [LIST-ID] or [LIST-URLS] fields added by the MLM; 834 o Any [MAIL] fields, especially Sender and Reply-To, added or 835 replaced by the MLM. 837 A DKIM-aware resending MLM SHOULD sign the entire message after being 838 prepared for distribution (i.e. the "MLM Output" from Section 3.2). 839 Any other configuration might generate signatures that cannot be 840 expected to validate. As with any other DKIM signing operation, the 841 choice of what portions of the header and body of the output message 842 should include those parts of the header and body for which the MLM 843 wishes to assert responsibility. 845 DKIM-aware authoring MLMs MUST sign the mail they send according to 846 the regular signing guidelines given in [DKIM]. 848 One concern is that having an MLM apply its signature to unsigned 849 mail might cause some verifiers or receivers to interpret the 850 signature as conferring more authority or authenticity to the message 851 content than is defined by [DKIM]. This is an issue beyond MLMs and 852 primarily entails receive-side processing outside of the scope of 853 [DKIM]. It is nevertheless worth noting here. In the case of MLMs, 854 the presence of an MLM signature is best treated as similar to MLM 855 handling that affixes an RFC5322.Subject tag or similar information. 856 It therefore does not introduce any new concerns. 858 5.8. Verification Outcomes at Final Receiving Sites 860 In general, verifiers and receivers SHOULD treat a signed message 861 from an MLM like any other signed message; indeed, it would be 862 difficult to discern any difference since specifications such as 863 [LIST-URLS] and [LIST-ID] are not universally deployed and can be 864 trivially spoofed. 866 However, because the author domain will commonly be different from 867 the MLM's signing domain, there may be a conflict with [ADSP] as 868 discussed in Section 4.3 and Section 5.6, especially where an ADMD 869 has misused ADSP. 871 5.9. Use With FBLs 873 An FBL operator might wish to act on a complaint from a user about a 874 posting to a list. Some FBLs could choose to generate feedback 875 reports based on DKIM verifications in the subject message. Such 876 operators SHOULD send a report to each domain with a valid signature 877 that has an FBL agreement established, as DKIM signatures are claims 878 of some responsibility for that message. Because authors generally 879 have limited control over the operation of a list, this point makes 880 MLM signing all the more important. 882 Where the FBL wishes to be more specific, it MAY act solely on a DKIM 883 signature where the signing domain matches the DNS domain found in a 884 List-Post: header field (or similar). 886 Use of FBLs in this way SHOULD be made explicit to list subscribers. 887 For example, if it is the policy of the MLM's ADMD to handle an FBL 888 item by unsubscribing the user that was the apparent sender of the 889 offending message, advising subscribers of this in advance would help 890 to avoid surprises later. 892 5.10. Handling Choices at Receivers 894 A recipient that explicitly trusts signatures from a particular MLM 895 MAY wish to extend that trust to an [AUTH-RESULTS] header field 896 signed by that MLM. The recipient MAY then do additional processing 897 of the message, using the results recorded in the Authentication- 898 Results header field instead of the original author's DKIM signature. 899 This includes possibly processing the message as per ADSP 900 requirements. 902 Receivers SHOULD ignore or remove all unsigned externally-applied 903 Authentication-Results header fields, and those not signed by an ADMD 904 that can be trusted by the receiver. See Section 5 and Section 7 of 905 [AUTH-RESULTS] for further discussion. 907 Upon DKIM and ADSP evaluation during an SMTP session (a common 908 implementation), an agent MAY decide to reject a message during an 909 SMTP session. If this is done, use of an [SMTP] failure code not 910 normally used for "user unknown" (550) is suggested; 554 seems an 911 appropriate candidate and thus SHOULD be used. If the rejecting SMTP 912 server supports [ENHANCED] status codes, it SHOULD make a distinction 913 between messages rejected deliberately due to policy decisions rather 914 than those rejected because of other deliverability issues. In 915 particular, a policy rejection SHOULD be relayed using a 5.7.1 916 enhanced status code and some appropriate wording in the text part of 917 the reply, in contrast to a code of 5.1.1 indicating the user does 918 not exist. Those MLMs that automatically attempt to remove users 919 with prolonged delivery problems (such as account deletion) SHOULD 920 thus detect the difference between policy rejection and other 921 delivery failures, and act accordingly. SMTP servers doing so SHOULD 922 also use appropriate wording in the text portion of the reply, 923 perhaps explicitly using the string "ADSP" to facilitate searching of 924 relevant data in logs. 926 The preceding paragraph does not apply to an [ADSP] policy of 927 "discardable". In such cases where the submission fails that test, 928 the receiver or verifier SHOULD discard the message but return an 929 SMTP success code, i.e. accept the message but drop it without 930 delivery. An SMTP rejection of such mail instead of the requested 931 discard action causes more harm than good. 933 6. DKIM Reporting 935 The MARF working group is developing mechanisms for reporting 936 forensic details about DKIM verification failures. At the time of 937 this writing, this is still a work in progress. 939 MLMs SHOULD apply these or other DKIM failure reporting mechanisms as 940 a method for providing feedback to signers about issues with DKIM 941 infrastructure. This is especially important for MLMs that implement 942 DKIM verification as a mechanism for authentication of list 943 configuration commands and submissions from subscribers. 945 7. IANA Considerations 947 This document includes no IANA actions. 949 8. Security Considerations 951 This document provides suggested or best current practices for use 952 with DKIM, and as such does not introduce any new technologies for 953 consideration. However, the following security issues should be 954 considered when implementing the above practices. 956 8.1. Authentication Results When Relaying 958 Section 5 advocates addition of an [AUTH-RESULTS] header field to 959 indicate authentication status of a message received as MLM Input. 960 Per Section 7.2 of [AUTH-RESULTS], receivers generally should not 961 trust such data without a good reason to do so, such as an a priori 962 agreement with the MLM's ADMD. 964 Such agreements are strongly advised to include a requirement that 965 those header fields be covered by a [DKIM] signature added by the 966 MLM's ADMD. 968 9. References 970 9.1. Normative References 972 [ADSP] Allman, E., Delany, M., Fenton, J., and J. Levine, "DKIM 973 Sender Signing Practises", RFC 5617, August 2009. 975 [AUTH-RESULTS] 976 Kucherawy, M., "Message Header Field for Indicating 977 Message Authentication Status", RFC 5451, April 2009. 979 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 980 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 981 Signatures", RFC 4871, May 2007. 983 [EMAIL-ARCH] 984 Crocker, D., "Internet Mail Architecture", RFC 5598, 985 July 2009. 987 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 988 October 2008. 990 9.2. Informative References 992 [DKIM-DEPLOYMENT] 993 Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 994 "DomainKeys Identified Mail (DKIM) Development, Deployment 995 and Operations", I-D DRAFT-IETF-DKIM-DEPLOYMENT, 996 January 2010. 998 [DKIM-OVERVIEW] 999 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 1000 Identified Mail (DKIM) Service Overview", RFC 5585, 1001 July 2009. 1003 [DKIM-UPDATE] 1004 Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) 1005 Signatures -- Update", RFC 5672, August 2009. 1007 [ENHANCED] 1008 Vaudreuil, G., "Enhanced Mail System Status Codes", 1009 RFC 3463, January 2003. 1011 [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident 1012 Object Description Exchange Format", RFC 5070, 1013 December 2007. 1015 [LIST-ID] Chandhok, R. and G. Wenger, "List-Id: A Structured Field 1016 and Namespace for the Identification of Mailing Lists", 1017 RFC 2919, March 2001. 1019 [LIST-URLS] 1020 Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 1021 for Core Mail List Commands and their Transport through 1022 Message Header Fields", RFC 2369, July 1998. 1024 [MARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 1025 Extensible Format for Email Feedback Reports", RFC 5965, 1026 August 2010. 1028 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1029 Extensions (MIME) Part One: Format of Internet Message 1030 Bodies", RFC 2045, November 1996. 1032 [MIME-TYPES] 1033 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1034 Extensions (MIME) Part Two: Media Types", RFC 2046, 1035 November 1996. 1037 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1038 October 2008. 1040 Appendix A. Acknowledgements 1042 The author wishes to acknowledge the following for their review and 1043 constructive criticism of this document: Serge Aumont, Daniel Black, 1044 Dave Crocker, JD Falk, Tony Hansen, Eliot Lear, Charles Lindsey, John 1045 Levine, Jeff Macdonald, S. Moonesamy, Rolf E. Sonneveld, and 1046 Alessandro Vesely. 1048 Appendix B. Example Scenarios 1050 This section describes a few MLM-related DKIM scenarios that were 1051 part of the impetus for this work, and the recommended resolutions 1052 for each. 1054 B.1. MLMs and ADSP 1056 Problem: 1058 o author ADMD advertises an ADSP policy of "dkim=discardable" 1060 o author sends DKIM-signed mail to a non-participating MLM, which 1061 invalidates the signature 1063 o receiver MTA checks DKIM and ADSP at SMTP time, and is configured 1064 to reject ADSP failures, so rejects this message 1066 o process repeats a few times, after which the MLM unsubscribes the 1067 receiver 1069 Solution: MLMs should refuse mail from domains advertising ADSP 1070 policies of "discardable" unless the MLMs are certain they make no 1071 changes that invalidate DKIM signatures. 1073 B.2. MLMs and FBLs 1075 Problem: 1077 o subscriber sends signed mail to a non-participating MLM that does 1078 not invalidate the signature 1080 o a recipient reports the message as spam 1082 o FBL at recipient ADMD sends report to contributor rather than list 1083 manager 1085 Solution: MLMs should sign mail they send and might also strip 1086 existing signatures; FBLs should report to list operators instead of 1087 subscribers where such can be distinguished, otherwise to all parties 1088 with valid signatures. 1090 Author's Address 1092 Murray S. Kucherawy 1093 Cloudmark 1094 128 King St., 2nd Floor 1095 San Francisco, CA 94107 1096 US 1098 Phone: +1 415 946 3800 1099 Email: msk@cloudmark.com