Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)
On Mon, Dec 29, 2014 at 2:29 PM, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: 3.1.3 Flow diagram The box titled 'User Mailbox' could give the impression that there's only one choice for delivery. However, quarantining can be done without delivery to a mailbox. I'd suggest to label this box 'rMDA'. That's already done in -08. OK. Well, it's MDA, but that's OK. One typo in the diagram. When: sMTA is the sending MTA, and rMTA is the receiving MTA. is correct, the box in the diagram should be labelled 'sMTA', not 'oMTA'. Fixed. The part within parentheses of step 6: 6. Recipient transport service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain’s DNS data (when identifiers are aligned; see below). might indicate that SPF and DKIM authentication checks need not be performed when identifiers are not aligned. However, for sake of reporting, SPF and DKIM authentication checks will in general always be done, or am I missing something? I can envision a DMARC implementation that skips SPF or DKIM checks if the corresponding identifiers are not aligned, because they won't be interesting to DMARC in that case. Whether or not to generate reports in the case of non-alignment is not clear from the text, or am I missing something? Par. 3.1.3: 8. If a policy is found, it is combined with the Author's domain and the SPF and DKIM results to produce a DMARC policy result (a pass or fail), and can optionally cause one of two kinds of reports to be generated (not shown). and par. 6.2 goes right into the format of reports, not the conditions under which a report is to be sent. Added an item at the end of the bullet list in 3.1.3. 5.7 Last sentence: Mail Receivers SHOULD also implement reporting instructions of DMARC in place of any extensions to SPF or DKIM that might enable such reporting. Not sure what this means. But it seems to me DMARC cannot claim priority over other options/extensions in other IETF protocols. This is another spot where the SHOULD gives the operator the choice to do both if it wishes. I can't remember off the top of my head what the use case is here, but essentially the absence of a request for DKIM or SPF reporting (as developed by the MARF working group some time ago) should not preclude DMARC reporting, nor should their presence interfere with DMARC reporting. Then, borrowing from your text, may I suggest the following text: Mail Receivers SHOULD implement reporting instructions of DMARC, even in the absence of a request for DKIM or SPF reporting [MARF]. Furthermore, the presence of such requests SHOULD NOT interfere with DMARC reporting. Done, with slight changes. And as a general statement: thanks for all the work, Murray! Anything to get this thing put to bed! -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)
Hi Rolf, getting back to your review (thanks for the nudge): On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: Abstract: This lack of cohesion has several effects: receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology. This focuses on the reporting function of DMARC, leaving out the policy part of it. Suggested text: This lack of cohesion has several effects: senders have difficulty providing information about their use of an authentication policy and receivers have difficulty determining a disposition preferred by senders. Vice versa, mail receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology. The Abstract appears to have been rewritten since you reviewed it, so a straight text swap won't work anymore. The new text focuses on what's being provided, not what was missing. Do you want to take another run at it? Introduction: [...] mail receivers have tried to protect senders [...] Suggested: [...] mail receivers have tried to protect senders and their own users/customers [...] This text no longer appears in the draft. Starting with DMARC allows domain owners and receivers to collaborate by, the terms 'domain owners', 'receivers', 'senders' and 'SMTP receivers', 'Mail Receivers', 'mail receivers' are used throughout the document. I'd suggest to add a definition of the term ' Mail Senders' to the introduction part of chapter 3 and then use only the terms as defined in 3., throughout the document. Suggested text for the term Mail Sender: - Mail Sender: the sender of mail with a domain for which the Domain Owner may have published a DKIM public key and/or an SPF authentication record and/or a DMARC policy; (although we may want to not mention DKIM or SPF here). It looks like that got cleared up; -08 has no reference to Mail Sender. 2.2 Out of Scope Add: ocousin domain attacks Covered in Section 2.4 of -08. 3.1.2 Key Concepts Last sentence: add a reference to this 'other referenced material'. Good idea; added. 3.1.3 Flow diagram The box titled 'User Mailbox' could give the impression that there's only one choice for delivery. However, quarantining can be done without delivery to a mailbox. I'd suggest to label this box 'rMDA'. That's already done in -08. The part within parentheses of step 6: 6. Recipient transport service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain’s DNS data (when identifiers are aligned; see below). might indicate that SPF and DKIM authentication checks need not be performed when identifiers are not aligned. However, for sake of reporting, SPF and DKIM authentication checks will in general always be done, or am I missing something? I can envision a DMARC implementation that skips SPF or DKIM checks if the corresponding identifiers are not aligned, because they won't be interesting to DMARC in that case. 3.1.4.1 DKIM-authenticated Identifiers remove (or change) the 'Cousin Domain' example: it doesn't hold when a bad actor is signing the mail with d=cousindomain and RFC5322.From=localpart@cousindomain It's not there in -08. 4 Use of RFC5322.From Last bullet (The DMARC mechanism ...). It seems the other bullets provide reasons why RFC5322.From is chosen while the last one does not. It looks to me as a circular reasoning. It's not there in -08. 5.2 DMARC URIs It is not clear from the text what the report originator must do when the report payload exceeds the maximum size as indicated by the record. Should it not send anything, should it split up reports, should it notify the requester that there was a report exceeding the maximum size? Section 6.2.2 in both versions explains what to do here. 5.3 General Record Format adkim and aspf do not provide a list of all possible options (like is done for fo and p). Of course it is pretty obvious that for 'strict' the 's' must be used, but it's not clear from the text. They're there in -08. Next, the P: and pct: tags: they show that (in hindsight) the policy part and the reporting part of DMARC might have been better off, when they were defined in different specs. Now we need to complicate the text to say that the policy tag p: is required, but not for third-party reporting records. And for pct, that it MUST NOT be applied to the DMARC-generated reports. Well, I believe this has been discussed before, no need to redo this discussion. I'd suggest to synchronize the short
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Mon, Nov 10, 2014 at 6:50 PM, Brandon Long bl...@google.com wrote: I don't think his changes in 5.6.1 would change anything we do. We currently require a single From header with a single address with a valid domain on all messages (not restricted to DMARC). RFC 6854 as used for EAI downgrades shouldn't apply since we support SMTPUTF8... though, if it became popular enough that we saw a large amount of mail forwarding in that format, we would adjust. I would think that how shipped software handles such things would be more likely to have issues, as its less likely to be upgraded. That said, from my understanding, this is a loosening of restrictions, from only one to may allow more than one, so that doesn't seem particularly problematic. Would we support multiple addresses? Probably not. We've had the current restrictions for 2+ years, and before that had less strict but similar restrictions. I haven't seen any complaints to date about this restriction, but it does apply to a non-trivial amount of mail. Thank you Brandon for replying with your perspective on Trent's proposed changes to 5.6.1. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)
Hi, Murray, On 11/11/2014 02:52 AM, Murray S. Kucherawy wrote: I've posted an update to the base draft, based on recent feedback from Ned and others. Hopefully I've resolved all of the concerns (especially the major ones), as the ISE would like to send the draft to the IESG for conflict review in the next day or two. It also has to begin formal review of its IANA Considerations section as soon as possible. Thanks to all who provided recent comments to lead us to this version. I started earlier this week a review of -05. Please find below my comments, I think most if not all of them also apply to -06. I didn't have time to finish my review, but thought to send my comments 'as is' (before -07 is published ;-)). Most of my comments are of type 'editorial nits', no big changes proposed ;-) Regards, /rolf Abstract: This lack of cohesion has several effects: receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology. This focuses on the reporting function of DMARC, leaving out the policy part of it. Suggested text: This lack of cohesion has several effects: senders have difficulty providing information about their use of an authentication policy and receivers have difficulty determining a disposition preferred by senders. Vice versa, mail receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology. Introduction: [...] mail receivers have tried to protect senders [...] Suggested: [...] mail receivers have tried to protect senders and their own users/customers [...] Starting with DMARC allows domain owners and receivers to collaborate by, the terms 'domain owners', 'receivers', 'senders' and 'SMTP receivers', 'Mail Receivers', 'mail receivers' are used throughout the document. I'd suggest to add a definition of the term ' Mail Senders' to the introduction part of chapter 3 and then use only the terms as defined in 3., throughout the document. Suggested text for the term Mail Sender: * Mail Sender: the sender of mail with a domain for which the Domain Owner may have published a DKIM public key and/or an SPF authentication record and/or a DMARC policy; (although we may want to not mention DKIM or SPF here). 2.2 Out of Scope Add: ocousin domain attacks 3.1.2 Key Concepts Last sentence: add a reference to this 'other referenced material'. 3.1.3 Flow diagram The box titled 'User Mailbox' could give the impression that there's only one choice for delivery. However, quarantining can be done without delivery to a mailbox. I'd suggest to label this box 'rMDA'. The part within parentheses of step 6: 6. Recipient transport service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain’s DNS data (when identifiers are aligned; see below). might indicate that SPF and DKIM authentication checks need not be performed when identifiers are not aligned. However, for sake of reporting, SPF and DKIM authentication checks will in general always be done, or am I missing something? 3.1.4.1 DKIM-authenticated Identifiers remove (or change) the 'Cousin Domain' example: it doesn't hold when a bad actor is signing the mail with d=cousindomain and RFC5322.From=localpart@cousindomain 4 Use of RFC5322.From Last bullet (The DMARC mechanism ...). It seems the other bullets provide reasons why RFC5322.From is chosen while the last one does not. It looks to me as a circular reasoning. 5.2 DMARC URIs It is not clear from the text what the report originator must do when the report payload exceeds the maximum size as indicated by the record. Should it not send anything, should it split up reports, should it notify the requester that there was a report exceeding the maximum size? 5.3 General Record Format adkim and aspf do not provide a list of all possible options (like is done for fo and p). Of course it is pretty obvious that for 'strict' the 's' must be used, but it's not clear from the text. Suggested edit: adkim: (plain-text; OPTIONAL, default is r.) Indicates whether strict or relaxed DKIM identifier alignment mode is required by the Domain Owner. Possible values: r: relaxed DKIM identifier alignment mode required s: strict DKIM identifier alignment mode required See Section 3.1.4.1 for details. and aspf: (plain-text; OPTIONAL, default is r.) Indicates whether strict or relaxed SPF identifier alignment mode is required by the Domain Owner. Possible values: r: relaxed SPF identifier
Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)
On 11/10/2014 5:52 PM, Murray S. Kucherawy wrote: I've posted an update to the base draft, based on recent feedback from Ned and others. Tidbits... Intro: Security terms used in this document are defined in [SEC-TERMS]. There's a Terminology section, so this really belongs there. 2.2: attacks in the RFC5322.From field, also known as display-name attacks; attacks on using the free-form portion of the RFC5322.From field, also known as display-name attacks, after its ABNF rulename; 3.13: The Flow Diagram inneeds to have the DKIM and SPF boxes /also/ connected directly to the Filtering Engine, since they still provide information directly to it. I suggest either: +---+ | Author Domain | . . . . . . . . . . . . . . . . . . . . . . . +---+. . . |. . . VV V . +---+ ++ +--+ +--+ . | MSA || DKIM | | DKIM | |SPF | . | Service | | Signer | | Verifier | | Verifier | . +---+ ++ +--+ +--+ . |**. |*. *. V**. *. +--+() +--+ *. | oMTA |---( other MTAs )| rMTA | *. +--+() +--+ *. | * ... | ** . V V* . +---+V V +-+ |MDA| +--+ | User |--| Filtering |***| DMARC | | Mailbox | | Engine | | Verifier | +-+ +---+ +--+ or +---+ | Author Domain |. . . . . . . . . . . . . . . . . . . . . . . +---+ . .. | . .. V V V. ++ +++--+ +--+ . |MSA || DKIM || DKIM | |SPF | . | Service | | Signer || Verifier | | Verifier | . ++ +++--+ +--+ . |* * V |* * +--+ |*| DMARC | |* | Verifier | |* +--+ |** |* |* * |V V V +---+ +--+()+--+| MDA | | sMTA |---( other MTAs )---| rMTA |---| Filtering | +--+()+--+| Engine | +---+ +-+| | User |---+ | Mailbox | +-+ Since Murray saw a variant of the latter from me earlier, he won't be surprised that I prefer it... 5. Policy: A Domain Owner may choose not to participate in DMARC evaluation by may - can (I'm assume that we don't use normative language to tell people that the have the right to opt out of a specification... Hmmm. Normative language would actually be contradictory, I think...) Mail Receivers. In this case, the Domain Owner simply declines to advertise participation in those schemes. For example, if the results of path authorization checks ought not be considered as part of the overall DMARC result for a given Author Domain, then the Domain Owner does not publish an SPF policy record that can produce an SPF pass result. The way to opt out of DMARC is to not publish a DMARC record. So those schemes doesn't make sense to me, nor does the reference to an SPF record. I think this should say: Mail Receivers. In this case, the Domain Owner
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
Franck Martin writes: I wish the mailbox-list syntax in the From would be deprecated for the mailbox syntax, but it is unlikely to happen, may be when RFC5322 gets revised (under Security, end to end, IPv6 experience), I don't understand why any of those experiences would cause RFC 5322 to be revised in this way. The problem is not in the protocol used to implement the network, but rather in the structure of the network of people involved. Most email networks-of-people don't involve a use case for multiple mailboxes in From, but some do (see below). OTOH, if you really need to pin responsibility for message origination on a particular person, the Sender field is the appropriate field. Even in the case of DMARC, as far as I can tell, for the intended use case of transactional mail there is little problem with throwing From- with-multiple-mailboxes into the unauthenticable pool, and rejecting on that basis if you want to. I see no reason to disallow this useful feature in RFC 5322 when it is better done in DMARC, or perhaps in the lower level protocols. but from an operational point of view (if you want ops to come back to IETF, listen to them :P ) you don't loose any useful email if you reject emails with multiple mailboxes in the From. Please take more care with your pronouns. I am not a member of your you. I know for a fact that if every MTA rejects because of multiple mailboxes in From, mail I consider important will not be delivered. I know and consider it important because I write it on behalf of an anti-harassment committee, and it's important that the members be individually identified[1] and individually reply-able[2]. There are other ways to accomplish these goals simultaneously, but using multiple mailboxes in From is all of most economical, most intuitive, and most beautiful. (I occasionally do it in other cases, but this case is special because it is of true utility to the recipients.) Given that you say this practice is rare and mostly harmless in your own experience, I don't see that the costs of treating such messages as an unauthenticated are high. Also, your experience is probably far less generic than you think, if it's based on LinkedIn. LinkedIn is a social network based not on groups but on individual links (although it provides groups, IME they are not entities in themselves in the way that bureaucratic committees are, but rather aliases for a me-to-many set of bilateral links based on common interest rather than individual identity). It is no surprise to me that the vast majority of messaging at LinkedIn is related to *one*-to-one or *one*-to-many communications. The reverse relationship (many-to-you) is more likely in a bureaucratic context (and certainly is useful for me personally). If you *aren't* speaking of LinkedIn, or that's not a correct analysis of how LinkedIn works, feel free to enlighten us. Footnotes: [1] We have ex oficio personal responsibilities to maintain student privacy that are actually a special exception to the normal faculty- administration relationship. [2] Not a group address -- it's not unheard of for bad actors to end up on such committees, although not in my tenure, thank heaven. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
Printed on recycled paper! On Nov 9, 2014, at 23:22, Stephen J. Turnbull step...@xemacs.org wrote: Franck Martin writes: I wish the mailbox-list syntax in the From would be deprecated for the mailbox syntax, but it is unlikely to happen, may be when RFC5322 gets revised (under Security, end to end, IPv6 experience), I don't understand why any of those experiences would cause RFC 5322 to be revised in this way. The problem is not in the protocol used to implement the network, but rather in the structure of the network of people involved. Most email networks-of-people don't involve a use case for multiple mailboxes in From, but some do (see below). OTOH, if you really need to pin responsibility for message origination on a particular person, the Sender field is the appropriate field. The part missing was end to end encryption where I heard that it could be conceivable that the entire DATA part be encrypted (headers+body). The only info the MTA would have is the envelope. This would require a somehow update/rewrite of RFC5322, but we are not there. Ps: Please don't summarize my experience to Linkedin, I had many other lives before that. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
[Excuse my broken mail system; until the tech staff return on Monday, it looks like I'm stuck with a webmail interface where I can't change my From to the subscribed address or break lines properly etc.] On Fri, Nov 7, 2014 at 8:57 PM, turnb...@sk.tsukuba.ac.jp wrote: Trent Adams writes: - It is important to note that identifier alignment cannot occur, and DMARC determination applied, with a message that is not valid per RFC 5322 [MAIL]. This is particularly true when a message has a malformed or absent RFC5322.From field. - (I think that is a plausible policy choice, since in an invalid message anything can happen. But I don't see that it's a no-brainer.) Do you have another suggestion? Remove the words with a message that is not valid per RFC 5322 [MAIL]. This is particularly true, and add a comment to the effect of other kinds of invalid message should be viewed with extreme suspicion in the DMARC context, because MTAs and MUAs will not necessarily be prepared for them and 'anything can happen' to the Security Considerations. Or just leave that comment for the BCP. Note that there's nothing normative in Trent's suggestion. Understood, I just think it's factually inaccurate. But this seems to be the insecure approach I describe above: 5. Conduct identifier alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks if Authenticated Identifiers fall into alignment as described in Section 3. If one or more of the Authenticated Identifiers align with an identifier extracted from the addr-spec of the RFC5322.From domain, the message is considered to pass the DMARC mechanism check. AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to send spam that passes DMARC on your behalf, as long as my mailbox appears in From, too. Am I misunderstanding your proposed algorithm? No, because in (6) the strictest rule applies. Your throwaway domain might pass, but the other advertised author's would not. I think my interpretation of Trent's words If one or more of the Authenticated Identifiers aligns with an identifier extracted is plausible, though: in that case we don't get to the policy application (6). My understanding is that policy is only applied when the DMARC alignment *fails* for a domain publishing a policy. Right, I think that's what Trent is also saying. Probably, but I don't think my reading is implausible. Regards, ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
Franck Martin writes: Ps: Please don't summarize my experience to Linkedin, I had many other lives before that. I have no choice but to make assumptions about the context in which you collected your data, since you didn't describe it, and the data collection context is required to assess the bias in your results. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue
On Sunday, November 02, 2014 01:44:16 AM Murray S. Kucherawy wrote: Just noticed that I never replied to this: On Fri, Aug 29, 2014 at 8:39 PM, Scott Kitterman skl...@kitterman.com wrote: Since this is the WG list, I'm not sure if this is still the right list for issues with the base spec or not, but here goes ... The definition of fo in Section 5.2, General Record Format, allows both values of 0 and 1 to be specified. It was suggested to me offlist that this might not be appropriate, so I thought it worth a discussion. Does anyone who's implemented fo have a problem with both 0 and 1 being specified? If it is somehow problematic, then the base spec ought to say so. How about this? 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned pass result. I think it's fine. It is a bit of an odd situation where reports for fo=0 are a strict subset of fo=1 reports. As a result, having both 0 and 1 specified is somewhat pointless. OTOH, I don't expect an interoperability problem with it, so meh. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
- Original Message - From: Stephen J. Turnbull step...@xemacs.org To: Franck Martin fra...@peachymango.org Cc: Brett McDowell brettmcdow...@gmail.com, dmarc@ietf.org, Scott Kitterman skl...@kitterman.com Sent: Monday, November 10, 2014 11:05:23 AM Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback Franck Martin writes: Ps: Please don't summarize my experience to Linkedin, I had many other lives before that. I have no choice but to make assumptions about the context in which you collected your data, since you didn't describe it, and the data collection context is required to assess the bias in your results. Fair enough, in the 20 years I do email (starting with uucp), I don't recall any such email where multiple email addresses where in the From: on purpose. So I'm curious to see some real world examples. If you could add them in the wiki may be? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
Franck Martin writes: So I'm curious to see some real world examples. If you could add them in the wiki may be? (a) Of the ones I have ready access to, there are privacy concerns with the email itself in many cases, and employer issues with all of them (Japanese institutions don't like to admit they even *might* have any problems in public). (b) They're in Japanese. So, no, not from my archives there won't be. I'll post the description of the use case and an example, though. I can tell you that in my truly useful case all addresses are work addresses, and therefore all have the same domain and *could* satisfy the DMARC mechanism in the sense that the authenticated domain would be aligned with all addresses in From, like this: DKIM-Signature: ..., d=xemacs.org, ... From: Stephen J. Turnbull step...@xemacs.org, Another Steve st...@xemacs.org I wouldn't be surprised if that handles the majority of such cases. I have sent mail frivolously with multiple domains in From, like this: DKIM-Signature: ..., d=xemacs.org, ... From: Stephen J. Turnbull step...@xemacs.org, My Co-Presenter c...@example.com Subject: Come see our presentation at Tokyo Linux Users Group but I don't seem to have a copy of that immediately available. Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
- Original Message - From: Douglas Otis doug.mtv...@gmail.com To: Franck Martin fra...@peachymango.org Cc: Ned Freed ned.fr...@mrochek.com, dmarc@ietf.org, Murray S. Kucherawy superu...@gmail.com, Douglas Otis doug.mtv...@gmail.com Sent: Saturday, November 8, 2014 11:58:00 PM Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback On Nov 8, 2014, at 5:29 PM, Franck Martin fra...@peachymango.org wrote: No, I think you've got it, but I'm not clear on how the paragraph you cited doesn't say that. You have it exactly right: If From: is missing or so mangled that it's not possible to get a domain out, then there's nothing to which DKIM and SPF can align, and DMARC can't be applied. There might be other mangling though, like multiple From: fields that are properly formed but contain distinct values, in which case we don't know to which one to apply alignment. Dear Franck, Note that an email with no RFC 5322 field is not valid, as well as one with more than 1. This header is mandatory as well as the Date header. These are the only 2 headers mandatory in an email. So rejecting an email with no RFC 5322 or more than one is just following the RFC. Which normative RFC is that? see table under http://tools.ietf.org/html/rfc5322#section-3.6 I'm not talking on how many mailboxes/domain there are in this header It would be wrong to assume SMTP will reject messages based on possible RFC5322 violations. While SMTP implementations have been lenient, they have been lenient in a way which is contrary to this RFC. The Postel statement indicates to be lenient when there is protocol ambiguity, not to allow anything but the kitchen sink when the protocol is clear about what headers must be present. Therefore it is not wrong to assume SMTP will reject messages on protocol violations. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
- Original Message - From: ned+dm...@mrochek.com To: John Levine jo...@taugh.com Cc: dmarc@ietf.org, superu...@gmail.com Sent: Friday, November 7, 2014 10:47:20 AM Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback What sort of remedy would you suggest here? Off the top of my head, here are some suggestions: 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one ... Given the anti-phishing goals of DMARC, I don't see how anything else makes any sense. Or you could skip a step, say that DMARC doesn't permit multi-address From headers, assume that validation failed on all of the domains and proceed directly to the punishment phase. That's fine if any of the domains have an associated DMARC record - of any sort. My concern is the case where none of them do, or when there are no domains present. With IPv6 and openPGP or S/Mime it will become more and more prevalent to block emails based on the domain(s) present in the RFC5322.From. Are the domains, domains that exist? Are they emailable? are they present in blocking lists? When there are none, my eight ball tells me the preferred behavior will be to reject such emails... These are also a set of easy techniques to avoid that DMARC be by-passed. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
- Original Message - From: ned+dm...@mrochek.com To: John Levine jo...@taugh.com Cc: dmarc@ietf.org, superu...@gmail.com Sent: Friday, November 7, 2014 10:47:20 AM Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback For From: headers with address-free groups, recall that the motivation for this was EAI downgrades at delivery time. The un-downgraded message had a normal From: header, so normal DMARC applies. If the address is smashed in the downgrade I don't see any reason that the DMARC result needs to change. Neither do I. Conclusion, a DMARC enabled MTA MUST be SMTPUTF8 enabled (so there is no to little reasons to downgrade). ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On 11/8/2014 8:29 PM, Franck Martin wrote: Note that an email with no RFC 5322 field is not valid, as well as one with more than 1. This header is mandatory as well as the Date header. These are the only 2 headers mandatory in an email. So rejecting an email with no RFC 5322 or more than one is just following the RFC. I'm not talking on how many mailboxes/domain there are in this header. +1 -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On 11/9/2014 4:19 AM, Franck Martin wrote: I'm not talking on how many mailboxes/domain there are in this header It would be wrong to assume SMTP will reject messages based on possible RFC5322 violations. While SMTP implementations have been lenient, they have been lenient in a way which is contrary to this RFC. The Postel statement indicates to be lenient when there is protocol ambiguity, not to allow anything but the kitchen sink when the protocol is clear about what headers must be present. Therefore it is not wrong to assume SMTP will reject messages on protocol violations. +1 -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Nov 8, 2014, at 8:38 PM, Franck Martin fra...@peachymango.org wrote: There are no secret sauces. I thought it was clear this type of language on this list is frown upon as non constructive? Just a point of clarification here. The original author was referring to decisions that receivers make when processing email. Secret sauce is often shorthand for the local conditions that exist at a receiver (eg input from local user behavior, site specific content scanning, etc). No foul here. Play on! ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
Trimming the CC list, as we're getting into spam-trap numbers of mailboxes. Rolf E. Sonneveld writes: The current effort to publish DMARC as informational RFC is mainly, to document the current specification 'as is', to be able to refer from other documents to a published spec. The concerns raised by Ned and the proposal of Trent try to address situations, where the spec does not yet describe what to do (RFC5322.From with multiple addresses), or leaves room for different interpretations/implementations. I don't think that is the case here; the current spec says what to do (reject them). My problem is with the current rationale. I think it is somewhat bogus, and goes beyond DMARC's remit (it says to reject any message with multiple addresses in From, rather than rejecting on the basis of policy corresponding to Authenticated Identifiers). ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On November 9, 2014 4:31:31 AM EST, Franck Martin fra...@peachymango.org wrote: - Original Message - From: ned+dm...@mrochek.com To: John Levine jo...@taugh.com Cc: dmarc@ietf.org, superu...@gmail.com Sent: Friday, November 7, 2014 10:47:20 AM Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback For From: headers with address-free groups, recall that the motivation for this was EAI downgrades at delivery time. The un-downgraded message had a normal From: header, so normal DMARC applies. If the address is smashed in the downgrade I don't see any reason that the DMARC result needs to change. Neither do I. Conclusion, a DMARC enabled MTA MUST be SMTPUTF8 enabled (so there is no to little reasons to downgrade). In that case, DMARC ought to be deferred for several years. I don't think you really mean that. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
Printed on recycled paper! On Nov 9, 2014, at 09:43, Scott Kitterman skl...@kitterman.com wrote: On November 9, 2014 4:31:31 AM EST, Franck Martin fra...@peachymango.org wrote: - Original Message - From: ned+dm...@mrochek.com To: John Levine jo...@taugh.com Cc: dmarc@ietf.org, superu...@gmail.com Sent: Friday, November 7, 2014 10:47:20 AM Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback For From: headers with address-free groups, recall that the motivation for this was EAI downgrades at delivery time. The un-downgraded message had a normal From: header, so normal DMARC applies. If the address is smashed in the downgrade I don't see any reason that the DMARC result needs to change. Neither do I. Conclusion, a DMARC enabled MTA MUST be SMTPUTF8 enabled (so there is no to little reasons to downgrade). In that case, DMARC ought to be deferred for several years. I don't think you really mean that. I'll settle for a SHOULD ;) Seriously, it is important to strengthen your MTA (and be less permissive), if you don't want some forms of unwanted emails to work easily around DMARC. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On 11/09/2014 04:03 PM, Tim Draegen wrote: On Nov 8, 2014, at 8:38 PM, Franck Martin fra...@peachymango.org wrote: There are no secret sauces. I thought it was clear this type of language on this list is frown upon as non constructive? Just a point of clarification here. The original author was referring to decisions that receivers make when processing email. Secret sauce is often shorthand for the local conditions that exist at a receiver (eg input from local user behavior, site specific content scanning, etc). No foul here. Play on! thanks, Tim. Frank, this was exactly the meaning of 'secret sauce' I had in mind, like it has been used in the past, see for example [1] and [2]. From [2]: Obviously, in computing reputations via traffic analysis, some private algorithms may come into play. For some RSPs, such secret sauce comprises their competitive advantage over others in the same space. Although this is said in the context of reputation, a similar meaning can apply to the internal decision making process within MBP's/ESP's when dealing with the results of e.g. SPF verification or DMARC verification. Having said that, it's still interesting to learn (if you want to share that) what LinkedIn does in situations where there are e.g. multiple addresses in a From field. /rolf [1] http://lists.opendkim.org/archive/opendkim/users/2011/06/1143.html [2] https://tools.ietf.org/html/draft-ietf-repute-considerations-03 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On 11/08/2014 01:40 AM, J. Trent Adams wrote: [...] 5.6.2. Determine Handling Policy To arrive at a policy disposition for an individual message, Mail Receivers MUST perform the following actions or their semantic equivalents. Steps 2-4 MAY be done in parallel, whereas steps 5 and 6 require input from previous steps. In the case where multiple identifiers were extracted from the RFC5322.From field, steps 1-4 are performed for each identifier, collecting the results, prior to performing steps 5 and 6. The steps are as follows: 1. Extract the identifier(s) from the addr-spec portion of the RFC5322.From field of from the message (as above). 2. For each identifier, query the DNS for a DMARC policy record published by the Domain Owner(s). Continue if at least one policy record is found, or abort DMARC evaluation otherwise. If there is more than one identifier, the DMARC policy found for each identifier SHOULD be collected as a set to be used in step 5. See Section 5.6.3 for the details of policy discovery. 3. Perform DKIM signature verification checks. A single email may contain multiple DKIM signatures. The results of this step are passed to the remainder of the algorithm and MUST include the value of the d= tag from all checked DKIM signatures. 4. Perform SPF validation checks. The results of this step are passed to the remainder of the algorithm and MUST include the domain name used to complete the SPF check. 5. Conduct identifier alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks if Authenticated Identifiers fall into alignment as described in Section 3. If one or more of the Authenticated Identifiers align with an identifier extracted from the addr-spec of the RFC5322.From domain, the message is considered to pass the DMARC mechanism check. All other conditions (authentication failures, identifier mismatches) are considered to be DMARC mechanism check failures. 6. Apply policy. Within the set of DMARC policies found in Step 2, select the most strict (with p=none being the least strict, next being quarantine, and reject being the most strict) to use in applying policy. See Section 5.3 for details of the discovered DMARC policies. We would like to apply the most strict policy, but doesn't that conflict with the p=none policy, where Domain Owners can start gathering reports without having to bother about impact on the disposition of their mail? Furthermore, doesn't a 'most strict' conflict with the meaning of the pct tag: The purpose of the pct tag is to allow Domain Owners to enact a slow rollout enforcement of the DMARC mechanism. The prospect of all or nothing is recognized as preventing many organizations from experimenting with strong authentication-based mechanisms. Treating the mail with the most strict policy for a From field with two addresses, where one of them has p=reject and the other p=none, may have the result that p=reject is applied for mail from the domain which has policy=none. Or am I missing something? /rolf ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
Printed on recycled paper! On Nov 9, 2014, at 10:27, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: On 11/09/2014 04:03 PM, Tim Draegen wrote: On Nov 8, 2014, at 8:38 PM, Franck Martin fra...@peachymango.org wrote: There are no secret sauces. I thought it was clear this type of language on this list is frown upon as non constructive? Just a point of clarification here. The original author was referring to decisions that receivers make when processing email. Secret sauce is often shorthand for the local conditions that exist at a receiver (eg input from local user behavior, site specific content scanning, etc). No foul here. Play on! thanks, Tim. Frank, this was exactly the meaning of 'secret sauce' I had in mind, like it has been used in the past, see for example [1] and [2]. From [2]: Obviously, in computing reputations via traffic analysis, some private algorithms may come into play. For some RSPs, such secret sauce comprises their competitive advantage over others in the same space. Although this is said in the context of reputation, a similar meaning can apply to the internal decision making process within MBP's/ESP's when dealing with the results of e.g. SPF verification or DMARC verification. Having said that, it's still interesting to learn (if you want to share that) what LinkedIn does in situations where there are e.g. multiple addresses in a From field. No secret sauce here cf https://github.com/linkedin/dmarc-msys/blob/master/dmarc.lua#L815 :P (Resent from a more suitable email address) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitterman skl...@kitterman.com wrote: We would like to apply the most strict policy, but doesn't that conflict with the p=none policy, where Domain Owners can start gathering reports without having to bother about impact on the disposition of their mail? Furthermore, doesn't a 'most strict' conflict with the meaning of the pct tag: The purpose of the pct tag is to allow Domain Owners to enact a slow rollout enforcement of the DMARC mechanism. The prospect of all or nothing is recognized as preventing many organizations from experimenting with strong authentication-based mechanisms. Treating the mail with the most strict policy for a From field with two addresses, where one of them has p=reject and the other p=none, may have the result that p=reject is applied for mail from the domain which has policy=none. Or am I missing something? Sure. OTOH, picking anything other than the strongest policy makes for a trivially implemented bypass of DMARC checks. Given this is a rare corner case, I think it's better to lean towards strictness than leniency. +1 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
- Original Message - From: Brett McDowell brettmcdow...@gmail.com To: Scott Kitterman skl...@kitterman.com Cc: dmarc@ietf.org Sent: Sunday, November 9, 2014 12:30:31 PM Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitterman skl...@kitterman.com wrote: We would like to apply the most strict policy, but doesn't that conflict with the p=none policy, where Domain Owners can start gathering reports without having to bother about impact on the disposition of their mail? Furthermore, doesn't a 'most strict' conflict with the meaning of the pct tag: The purpose of the pct tag is to allow Domain Owners to enact a slow rollout enforcement of the DMARC mechanism. The prospect of all or nothing is recognized as preventing many organizations from experimenting with strong authentication-based mechanisms. Treating the mail with the most strict policy for a From field with two addresses, where one of them has p=reject and the other p=none, may have the result that p=reject is applied for mail from the domain which has policy=none. Or am I missing something? Sure. OTOH, picking anything other than the strongest policy makes for a trivially implemented bypass of DMARC checks. Given this is a rare corner case, I think it's better to lean towards strictness than leniency. +1 From the code I gave, I ran for several weeks my system in logging mode to record the RFC5322.From when it had zero or more than one mailbox. This is what I found: A bug at a major mailbox provider that was not rendering a variable correctly (no domain in From) A bug with a common dot NET version that would do a From like this (If I recall correctly): From: j...@example.com j...@example.com (the first email address is meant to be double quoted) All the rest were bounces (NDM) with stuff like From: postmaster@local or From: mail-dae...@mail6.example.com, postmaster@localhost,... In short non configured machines, some doing backscatter, some not... NDM are getting rarer nowadays by the way. Did not find (probability close to 0 but non null) a single email with 2 email addresses in the From that is meant to an end user. I wish the mailbox-list syntax in the From would be deprecated for the mailbox syntax, but it is unlikely to happen, may be when RFC5322 gets revised (under Security, end to end, IPv6 experience), but from an operational point of view (if you want ops to come back to IETF, listen to them :P ) you don't loose any useful email if you reject emails with multiple mailboxes in the From. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
I support making no change in dmarc-base-05 that might change how current mailbox providers implement dmarc-base. But to the extent this collection of contributors would like to see the recommendations/requirements in section 5.6.1 updated to better harmonize with related RFC's, I support Trent's proposal as it seems to introduce the least amount of increased risk to fraud. That said, we do have people here familiar with large-scale mailbox provider deployments (Google, Yahoo!, Hotmail, etc.). I'd like to ask them if they expect Trent's changes to have any impact on how they implement dmarc-base today. If it will, I think we should consider these changes for a future version of dmarc-base and let this version go through with these requirements unchanged. As you all know, there are now years of experience deploying dmarc-base with these requirements as written. Those deployments have had tremendous success protecting users from domain-spoofing the RFC5322.From field. The importance of the current dmarc-base specification's efficacy at blocking domain-spoofed phishing attacks should not be underestimated. I advise extreme caution when considering any normative changes at the 11th hour. Dear high volume MBP's, will any of these changes in Trent's proposal alter how you implement dmarc-base today? -Brett On Sat, Nov 8, 2014 at 2:26 AM, Murray S. Kucherawy superu...@gmail.com wrote: On Fri, Nov 7, 2014 at 8:57 PM, turnb...@sk.tsukuba.ac.jp wrote: Trent Adams writes: - It is important to note that identifier alignment cannot occur, and DMARC determination applied, with a message that is not valid per RFC 5322 [MAIL]. This is particularly true when a message has a malformed or absent RFC5322.From field. - I occasionally see non-ASCII octets introduced by spam/virus checkers in X-Spam-* fields in the header or in the (non-8-bit) message body, due to copying message content into those contexts. The From field is perfectly valid, however. Does that really mean that identifier alignment cannot occur? (I think that is a plausible policy choice, since in an invalid message anything can happen. But I don't see that it's a no-brainer.) Do you have another suggestion? Note that there's nothing normative in Trent's suggestion. If a receiver thinks it can continue with the X-Spam-* fields malformed as described, then it can continue on that basis. Starting off, we can ignore a null address in the RFC5322.From field as DMARC will have no bearing in that case. Similarly, when there is exactly one address in the RFC5322.From field, application of DMARC is reasonably straight forward. By DMARC, you really mean DMARC policy, right? DMARC the protocol does need to say something about what happens if alignment fails or no policy can be discovered. That's how I understood what he said. That leaves taking some action based on the DMARC policies associated with the set of domains represented in the RFC5322.From field. It seems that the most reasonable approach is to gather the DMARC policies for all addresses, and then apply the most strict. I wouldn't call that reasonable. It's the only plausible option, but here's the problematic use case: Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. For organizational political reasons it is necessary that (a) both names appear on the memo and (b) Stephen has to do the dirty work. Stephen sends the mail From: tr...@example.com, step...@example.org, with proper SPF and DKIM setups. Unfortunately, example.com publishes p=reject, example.com alignment fails because Stephen sent the message, the MTAs reject the message, and nobody except Trent and Stephen shows up to the meeting. I see two ways this message could pass DMARC: Stephen has the keys for example.com, or the Japanese ringi system, where I write and sign the message, send it to Trent, who then signs the message but otherwise forwards it verbatim. Both seem fragile to me. OTOH, only checking policies of aligned SPF source domains and DKIM signers means that Stephen (or any scammer) can add po...@whitehouse.gov to the From field and pass DMARC. It's obvious what the Felons of April would do with that. I guess the most plausible approach to this issue is to say that if you want to use DMARC and have multiple authors, you must contrive to give all the authors mailboxes in the same domain. In the example, I could create the-committee.example.org for committee members, or give trent a forwarding mailbox at example.org itself. Ned, do you concur with this analysis? Is Trent's proposal coupled with this caveat a valid remedy for your point? Given all that, here's my suggested revision to Section 5.6.1.: - 5.6.1. Extract Author Domain In order to be processed by DMARC, the domain(s) must be extracted from the domain of the email address(es) within the addr-spec portion of the
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On 11/08/2014 09:20 PM, Brett McDowell wrote: I support making no change in dmarc-base-05 that might change how current mailbox providers implement dmarc-base. But to the extent this collection of contributors would like to see the recommendations/requirements in section 5.6.1 updated to better harmonize with related RFC's, I support Trent's proposal as it seems to introduce the least amount of increased risk to fraud. That said, we do have people here familiar with large-scale mailbox provider deployments (Google, Yahoo!, Hotmail, etc.). I'd like to ask them if they expect Trent's changes to have any impact on how they implement dmarc-base today. If it will, I think we should consider these changes for a future version of dmarc-base and let this version go through with these requirements unchanged. As you all know, there are now years of experience deploying dmarc-base with these requirements as written. Those deployments have had tremendous success protecting users from domain-spoofing the RFC5322.From field. The importance of the current dmarc-base specification's efficacy at blocking domain-spoofed phishing attacks should not be underestimated. I advise extreme caution when considering any normative changes at the 11th hour. Dear high volume MBP's, will any of these changes in Trent's proposal alter how you implement dmarc-base today? The current effort to publish DMARC as informational RFC is mainly, to document the current specification 'as is', to be able to refer from other documents to a published spec. The concerns raised by Ned and the proposal of Trent try to address situations, where the spec does not yet describe what to do (RFC5322.From with multiple addresses), or leaves room for different interpretations/implementations. As such I welcome the text proposed by Trent. If the big MBP's deviate from what that text describes, then in my opinion: * either this is part of the 'secret sauce' which is being applied by Mail Receivers anyway (no matter what a spec will prescribe) * or (better) the big MBP's will need to come up with text describing what their implementations will do in these specific cases. Not changing the text, because the MBP's might have implemented these cases in a different way than what is being proposed here, but not documenting that way, is not a good idea, IMHO. /rolf ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
I occasionally see non-ASCII octets introduced by spam/virus checkers in X-Spam-* fields in the header or in the (non-8-bit) message body, due to copying message content into those contexts. The From field is perfectly valid, however. Does that really mean that identifier alignment cannot occur? (I think that is a plausible policy choice, since in an invalid message anything can happen. But I don't see that it's a no-brainer.) Do you have another suggestion? I don't see how we can offer useful advice beyond noting that strange things can happen if the message isn't 5322 compliant. On my mail system in the US, random headers with stray high bits are an extremely reliable indicator of botful spamminess, while in Japan, apparently it happens innocently all the time. Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. For organizational political reasons it is necessary that (a) both names appear on the memo and (b) Stephen has to do the dirty work. Stephen sends the mail From: tr...@example.com, step...@example.org, with proper SPF and DKIM setups. Unfortunately, example.com publishes p=reject, example.com alignment fails because Stephen sent the message, the MTAs reject the message, and nobody except Trent and Stephen shows up to the meeting. If I may be direct, our policies don't match what our users do but it's your problem is not exactly a new issue with DMARC. Let's make a deal: if you fix the mailing list problem, I'll fix this problem, and I can probably do it for free since the plausible fixes for mailing lists (e.g., double signing, trusted forwarders) would probably work here, too. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
Printed on recycled paper! On Nov 8, 2014, at 15:00, Rolf E. Sonneveld r.e.sonnev...@sonnection.nl wrote: On 11/08/2014 09:20 PM, Brett McDowell wrote: I support making no change in dmarc-base-05 that might change how current mailbox providers implement dmarc-base. But to the extent this collection of contributors would like to see the recommendations/requirements in section 5.6.1 updated to better harmonize with related RFC's, I support Trent's proposal as it seems to introduce the least amount of increased risk to fraud. That said, we do have people here familiar with large-scale mailbox provider deployments (Google, Yahoo!, Hotmail, etc.). I'd like to ask them if they expect Trent's changes to have any impact on how they implement dmarc-base today. If it will, I think we should consider these changes for a future version of dmarc-base and let this version go through with these requirements unchanged. As you all know, there are now years of experience deploying dmarc-base with these requirements as written. Those deployments have had tremendous success protecting users from domain-spoofing the RFC5322.From field. The importance of the current dmarc-base specification's efficacy at blocking domain-spoofed phishing attacks should not be underestimated. I advise extreme caution when considering any normative changes at the 11th hour. Dear high volume MBP's, will any of these changes in Trent's proposal alter how you implement dmarc-base today? The current effort to publish DMARC as informational RFC is mainly, to document the current specification 'as is', to be able to refer from other documents to a published spec. The concerns raised by Ned and the proposal of Trent try to address situations, where the spec does not yet describe what to do (RFC5322.From with multiple addresses), or leaves room for different interpretations/implementations. As such I welcome the text proposed by Trent. If the big MBP's deviate from what that text describes, then in my opinion: either this is part of the 'secret sauce' which is being applied by Mail Receivers anyway (no matter what a spec will prescribe) or (better) the big MBP's will need to come up with text describing what their implementations will do in these specific cases. There are no secret sauces. I thought it was clear this type of language on this list is frown upon as non constructive? Several MBPs use openDMARC, less use msys-dmarc but both are opensource. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On 11/7/2014 10:47 AM, ned+dm...@mrochek.com wrote: 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one ... ... That's fine if any of the domains have an associated DMARC record - of any sort. My concern is the case where none of them do, or when there are no domains present. Right. I believe the phrasing of 1), above, constrains the scope of applicability carefully and in the way that avoids the possible problems you are (correctly, IMO) concerned about. That is, I believe the if any of them text matches your if any of the text... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Nov 8, 2014, at 5:29 PM, Franck Martin fra...@peachymango.org wrote: No, I think you've got it, but I'm not clear on how the paragraph you cited doesn't say that. You have it exactly right: If From: is missing or so mangled that it's not possible to get a domain out, then there's nothing to which DKIM and SPF can align, and DMARC can't be applied. There might be other mangling though, like multiple From: fields that are properly formed but contain distinct values, in which case we don't know to which one to apply alignment. Dear Franck, Note that an email with no RFC 5322 field is not valid, as well as one with more than 1. This header is mandatory as well as the Date header. These are the only 2 headers mandatory in an email. So rejecting an email with no RFC 5322 or more than one is just following the RFC. Which normative RFC is that? I'm not talking on how many mailboxes/domain there are in this header It would be wrong to assume SMTP will reject messages based on possible RFC5322 violations. Also efforts to change the From header field into alignment with DKIM or SPF violates RFC 5322 as well. In addition, use of DKIM and DMARC alignment to reject phishing attacks can not safely rely on DKIM signatures being considered invalid when multiple From header fields exist. This makes the strategy suggested in RFC6376 Section 8.15 dependent on all domains being checked for DMARC policy. Because of this flaw in DKIM signature validation, it becomes necessary to apply DMARC policy checks against each and every originating domain. It would be incorrect to expect Authentication-Results headers will indicate a failure in the case of invalid originating header fields. The domain being checked for DMARC MUST NOT depend on Authentication-Results headers, OR assume SMTP or DKIM validation rejects such messages since there is no RFC language to impose message rejection or a DMARC policy failu re. DMARC now suggests making this difficult check with an ought. It seems rather dubious to trust DKIM signatures and that DMARC offers a safe and reliable policy enforcement. Also consider that it took several years for Yahoo to notice exploits allowed by multiple From header Fields. Per RFC 5322: Also in Section 3.6.2: In all cases, the From: field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. Per RFC 5321: When the RFC 822 format ([28], [4]) is being used, the mail data include the header fields such as those named Date, Subject, To, Cc, and From. Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message header section or message body. In particular, they MUST NOT reject messages in which the numbers of Resent-header fields do not match or Resent-to appears without Resent-from and/or Resent-date. Even the dmarc-base draft Section 4 and Section 10 removed rejection of invalid From header fields: The absence of a single, properly-formed RFC5322.From field renders the message invalid. This document prescribes no specific action in that case, other than to suggest that the message ought to be disposed of by the Mail Receiver's infrastructure in a safe manner that recognizes and possibly even highlights the malformation. So it is perfectly valid to indicate a DKIM pass with multiple From header fields, and now ignore this situation with DMARC as well. Do you see the problem with the assumption you made? Heck, the DKIM deploy RFC even suggests subsequent checks can be bypassed when a valid DKIM signature is found from a trusted domain. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
What sort of remedy would you suggest here? Off the top of my head, here are some suggestions: 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one ... Given the anti-phishing goals of DMARC, I don't see how anything else makes any sense. Or you could skip a step, say that DMARC doesn't permit multi-address From headers, assume that validation failed on all of the domains and proceed directly to the punishment phase. For From: headers with address-free groups, recall that the motivation for this was EAI downgrades at delivery time. The un-downgraded message had a normal From: header, so normal DMARC applies. If the address is smashed in the downgrade I don't see any reason that the DMARC result needs to change. It also happens to enable an alternative to those do-not-re...@bigbank.com addresses in mail from robots, something I haven't seen yet, but wouldn't be totally silly. I'd say that whatever you do with them is out of scope for DMARC. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Fri, Nov 7, 2014 at 10:06 AM, John Levine jo...@taugh.com wrote: 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one ... Given the anti-phishing goals of DMARC, I don't see how anything else makes any sense. Or you could skip a step, say that DMARC doesn't permit multi-address From headers, assume that validation failed on all of the domains and proceed directly to the punishment phase. Right, that's also an option, and it at least accommodates the no-address From field that RFC6854 permits. Another option I can think of is one where we just admit the conflict with RFC6854 and observe that streams likely to be DMARC-protected don't use this format, so if you see a multi-valued From where any domain has a DMARC policy, it's invalid and the receiver should act accordingly. For From: headers with address-free groups, recall that the motivation for this was EAI downgrades at delivery time. The un-downgraded message had a normal From: header, so normal DMARC applies. If the address is smashed in the downgrade I don't see any reason that the DMARC result needs to change. I don't know much at all about EAI, but if the address is smashed, which DMARC result could you possibly use? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Nov 7, 2014, at 10:32 AM, Murray S. Kucherawy superu...@gmail.com wrote: On Fri, Nov 7, 2014 at 10:06 AM, John Levine jo...@taugh.com wrote: 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one ... Given the anti-phishing goals of DMARC, I don't see how anything else makes any sense. Or you could skip a step, say that DMARC doesn't permit multi-address From headers, assume that validation failed on all of the domains and proceed directly to the punishment phase. Right, that's also an option, and it at least accommodates the no-address From field that RFC6854 permits. Another option I can think of is one where we just admit the conflict with RFC6854 and observe that streams likely to be DMARC-protected don't use this format, so if you see a multi-valued From where any domain has a DMARC policy, it's invalid and the receiver should act accordingly. For From: headers with address-free groups, recall that the motivation for this was EAI downgrades at delivery time. The un-downgraded message had a normal From: header, so normal DMARC applies. If the address is smashed in the downgrade I don't see any reason that the DMARC result needs to change. I don't know much at all about EAI, but if the address is smashed, which DMARC result could you possibly use? Dear Murray, I too agree with John. It also seems a specific Group syntax might allow an obvious (and safe) alternate address strategy. This same approach might also support a scheme to re-write third-party services' From addresses. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
That's fine if any of the domains have an associated DMARC record - of any sort. My concern is the case where none of them do, or when there are no domains present. In that case I agree with you, it's none of DMARC's business what happens. For From: headers with address-free groups, recall that the motivation for this was EAI downgrades at delivery time. The un-downgraded message had a normal From: header, so normal DMARC applies. If the address is smashed in the downgrade I don't see any reason that the DMARC result needs to change. Neither do I. Clarification for Murray: An EAI message might arrive with an address like this: From: stuff a...@. where , , and are UTF-8 strings, and for extra excitement, includes characters not allowed in u-labels. You can easily do a DMARC check on this address by turning ., which have to be U-labels, into A-labels and do a normal DMARC check. Non-EAI mail can't handle the , so one of the ways a message might be smashed for delivery might be this: From: international address a...@. :; (You can use MIME encoding for the comment.) So the address is gone, but the message remains, and the DMARC result might as well remain too. I agree this is pretty deep into nit-land, so my only real concern is that there not be langauge that forbids doing the obvious thing in this situation. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Fri, Nov 7, 2014 at 8:57 PM, turnb...@sk.tsukuba.ac.jp wrote: Trent Adams writes: - It is important to note that identifier alignment cannot occur, and DMARC determination applied, with a message that is not valid per RFC 5322 [MAIL]. This is particularly true when a message has a malformed or absent RFC5322.From field. - I occasionally see non-ASCII octets introduced by spam/virus checkers in X-Spam-* fields in the header or in the (non-8-bit) message body, due to copying message content into those contexts. The From field is perfectly valid, however. Does that really mean that identifier alignment cannot occur? (I think that is a plausible policy choice, since in an invalid message anything can happen. But I don't see that it's a no-brainer.) Do you have another suggestion? Note that there's nothing normative in Trent's suggestion. If a receiver thinks it can continue with the X-Spam-* fields malformed as described, then it can continue on that basis. Starting off, we can ignore a null address in the RFC5322.From field as DMARC will have no bearing in that case. Similarly, when there is exactly one address in the RFC5322.From field, application of DMARC is reasonably straight forward. By DMARC, you really mean DMARC policy, right? DMARC the protocol does need to say something about what happens if alignment fails or no policy can be discovered. That's how I understood what he said. That leaves taking some action based on the DMARC policies associated with the set of domains represented in the RFC5322.From field. It seems that the most reasonable approach is to gather the DMARC policies for all addresses, and then apply the most strict. I wouldn't call that reasonable. It's the only plausible option, but here's the problematic use case: Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. For organizational political reasons it is necessary that (a) both names appear on the memo and (b) Stephen has to do the dirty work. Stephen sends the mail From: tr...@example.com, step...@example.org, with proper SPF and DKIM setups. Unfortunately, example.com publishes p=reject, example.com alignment fails because Stephen sent the message, the MTAs reject the message, and nobody except Trent and Stephen shows up to the meeting. I see two ways this message could pass DMARC: Stephen has the keys for example.com, or the Japanese ringi system, where I write and sign the message, send it to Trent, who then signs the message but otherwise forwards it verbatim. Both seem fragile to me. OTOH, only checking policies of aligned SPF source domains and DKIM signers means that Stephen (or any scammer) can add po...@whitehouse.gov to the From field and pass DMARC. It's obvious what the Felons of April would do with that. I guess the most plausible approach to this issue is to say that if you want to use DMARC and have multiple authors, you must contrive to give all the authors mailboxes in the same domain. In the example, I could create the-committee.example.org for committee members, or give trent a forwarding mailbox at example.org itself. Ned, do you concur with this analysis? Is Trent's proposal coupled with this caveat a valid remedy for your point? Given all that, here's my suggested revision to Section 5.6.1.: - 5.6.1. Extract Author Domain In order to be processed by DMARC, the domain(s) must be extracted from the domain of the email address(es) within the addr-spec portion of the RFC5322.From field. If the domain is encoded with UTF-8, the domain name must be converted to an A-label for further processing. If no domain is found, the message SHOULD be rejected (as it is forbidden under RFC 5322 I still don't think a null From filed is any business of DMARC the protocol. That's really an issue for (a) the security considerations section or (b) the planned BCP. I think we're all in agreement on that point so far. [MAIL]). If more than one domain identifier is found, the full set of domains MAY be collected as a set of identifiers for DMARC processing. But this seems to be the insecure approach I describe above: 5. Conduct identifier alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks if Authenticated Identifiers fall into alignment as described in Section 3. If one or more of the Authenticated Identifiers align with an identifier extracted from the addr-spec of the RFC5322.From domain, the message is considered to pass the DMARC mechanism check. AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to send spam that passes DMARC on your behalf, as long as my mailbox appears in From, too. Am I misunderstanding your proposed algorithm? No, because in (6) the strictest rule applies. Your throwaway domain might pass, but the
Re: [dmarc-ietf] draft-kucherawy-dmarc-base
On Nov 3, 2014, at 9:04 PM, Stephen J. Turnbull step...@xemacs.org wrote: Douglas Otis writes: After all, DMARC permits the weakest authorization as a basis for acceptance, so it would be misleading to describe DMARC results as having been *authenticated*. Well, no, it isn't necessarily misleading. According to RFC 4949, authentication = identification + verification, while authorization is a permission to do something. Dear Stephen, Since SPF authorizes an often _shared_ outbound IP address, it has been accurately described as an authorization method. DMaRC permits a DKIM signature to be spoofed and still allow a message to be accepted solely on the basis of SPF. What magic turns authorization into authentication??? Describing authorization as authentication has been an exaggeration that started with SenderID. Large attack surfaces provided by often overly broad SPF is increasingly being exploited by botnets. Calling DMaRC Authentication threatens victims of malefactors that gain access by way of SPF's fairly insecure authorization scheme which might also employ reverse DNS handily exploited by compromised systems. This misrepresentation injures recipients misled into believing DMaRC authenticated the From email address, as well as senders blocked because an administrator believed DMaRC authenticated the identity in question, the From email address. It has not, nor can it. In addition, incorrectly defining DMARC as an authentication scheme tends to exclude many possible adjustments needed to safely lessen DMARC's disruptive impact on otherwise legitimate and desired third-party services relied upon for decades. Don't let the erroneous term authentication stand in the way of less disruptive authorization extensions. For example, in DKIM d= identifies the Signing Domain and b= + a DNS lookup provides the data needed for verification. At that point you have in fact authenticated the Signing Domain, and with From alignment (and the additional assumptions that the key is available only to the Author/Signing Domain and that the Author Domain authenticates users) you have authenticated the authorization to use that mailbox in From. (You could add a lot more caveats -- there is a lot of attack surface in email. :-( ) Some similar statement is true for SPF (at least under favorable conditions :-). AFAICS authenticating that particular authorization is precisely what DMARC claims to do, although the I-D uses different words to say that. Authenticating an Authorization? Does that then make an Authorization authentication? Anyway, AIUI, the question we're trying to address in Milestone One is how does that affect third parties on the assumptions that (1) mail receivers are satisfied that DMARC does what they think it does and (2) such mail receivers respect p=reject. Removing DMaRC's disruption can be done by enabling the authorization of necessary exceptions. Perhaps by way of authorizing specific domains or or authorizing a specific From header field group syntax. The DMaRC WG should not attempt to define new From header fields as a means to enable policy exceptions. This would be sweeping DMaRC problems under the rug, as any new header field used to replace the From header field will be eventually displayed to users for obvious reasons. Such expected change would provide the effect of re-arranging deck chairs on the Titanic. draft-kucherawy-dmarc-base is not ready, as its definitions remain seriously flawed. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base
Since SPF authorizes an often _shared_ outbound IP address, it has been accurately described as an authorization method. DMaRC permits a DKIM signature to be spoofed and still allow a message to be accepted solely on the basis of SPF. What magic turns authorization into authentication??? This is a good point and I can share some of our own experiences in Microsoft's Office 365. We have a hosted service. Companies/users can either have hosted email accounts wherein they login to the portal and send/receive email, or connect to it via IMAP/POP3. The second option is an on-premise environment wherein their email passes through us and we relay it to their on-premise machines. They can send outbound email through us by connecting to the service by specifying their outbound IP in a Connector. We ask customers to add our service's SPF record to their own SPF records. When they send outbound email through us, it will authenticate at the destination. However, if Customer A ever spoofs Customer B, it will also authenticate via SPF. This is a very real problem. So how are we fixing it? First, hosted email accounts cannot spoof another customer. If you login to the portal, or connect via IMAP/POP3, you can't specify your MAIL FROM domain. You have to set it up in the portal and put a key into your TXT record. That's not changeable. Second, for on-premise machines, they *can* spoof another customer. If they connect over their IP, if the domain they connect with is not provisioned with them, it is attributed to a safe tenant (a misnomer in my opinion). It is here that they could spoof someone else. To get around this, we will check DMARC on outbound mail before we relay it out. If a domain fails DMARC when it connects to us, and it is an outbound email intended for the rest of the Internet, we will reject the message so it cannot be sent out to an unsuspecting third party that might pass SPF since it came from our service's outbound IPs. This is not a perfect solution, but it does close a gap. The existing DMARC specification lets us do this without making any changes to it. -- Terry -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Douglas Otis Sent: Wednesday, November 5, 2014 10:21 AM To: Stephen J. Turnbull Cc: dmarc@ietf.org; Murray S. Kucherawy; Douglas Otis Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base On Nov 3, 2014, at 9:04 PM, Stephen J. Turnbull step...@xemacs.org wrote: Douglas Otis writes: After all, DMARC permits the weakest authorization as a basis for acceptance, so it would be misleading to describe DMARC results as having been *authenticated*. Well, no, it isn't necessarily misleading. According to RFC 4949, authentication = identification + verification, while authorization is a permission to do something. Dear Stephen, Since SPF authorizes an often _shared_ outbound IP address, it has been accurately described as an authorization method. DMaRC permits a DKIM signature to be spoofed and still allow a message to be accepted solely on the basis of SPF. What magic turns authorization into authentication??? Describing authorization as authentication has been an exaggeration that started with SenderID. Large attack surfaces provided by often overly broad SPF is increasingly being exploited by botnets. Calling DMaRC Authentication threatens victims of malefactors that gain access by way of SPF's fairly insecure authorization scheme which might also employ reverse DNS handily exploited by compromised systems. This misrepresentation injures recipients misled into believing DMaRC authenticated the From email address, as well as senders blocked because an administrator believed DMaRC authenticated the identity in question, the From email address. It has not, nor can it. In addition, incorrectly defining DMARC as an authentication scheme tends to exclude many possible adjustments needed to safely lessen DMARC's disruptive impact on otherwise legitimate and desired third-party services relied upon for decades. Don't let the erroneous term authentication stand in the way of less disruptive authorization extensions. For example, in DKIM d= identifies the Signing Domain and b= + a DNS lookup provides the data needed for verification. At that point you have in fact authenticated the Signing Domain, and with From alignment (and the additional assumptions that the key is available only to the Author/Signing Domain and that the Author Domain authenticates users) you have authenticated the authorization to use that mailbox in From. (You could add a lot more caveats -- there is a lot of attack surface in email. :-( ) Some similar statement is true for SPF (at least under favorable conditions :-). AFAICS authenticating that particular authorization is precisely what DMARC claims to do, although the I-D uses different words to say that. Authenticating an Authorization? Does
Re: [dmarc-ietf] draft-kucherawy-dmarc-base
On Wed, Nov 5, 2014 at 10:35 AM, Terry Zink tz...@exchange.microsoft.com wrote: Since SPF authorizes an often _shared_ outbound IP address, it has been accurately described as an authorization method. DMaRC permits a DKIM signature to be spoofed and still allow a message to be accepted solely on the basis of SPF. What magic turns authorization into authentication??? This is a good point and I can share some of our own experiences in Microsoft's Office 365. [...] Terry, In terms of the base draft's content, I think the salient question is: Does the base draft's use of the term authentication mislead you or your customers in any way? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base
On Wednesday, November 05, 2014 06:35:32 PM Terry Zink wrote: Since SPF authorizes an often _shared_ outbound IP address, it has been accurately described as an authorization method. DMaRC permits a DKIM signature to be spoofed and still allow a message to be accepted solely on the basis of SPF. What magic turns authorization into authentication??? This is a good point and I can share some of our own experiences in Microsoft's Office 365. We have a hosted service. Companies/users can either have hosted email accounts wherein they login to the portal and send/receive email, or connect to it via IMAP/POP3. The second option is an on-premise environment wherein their email passes through us and we relay it to their on-premise machines. They can send outbound email through us by connecting to the service by specifying their outbound IP in a Connector. We ask customers to add our service's SPF record to their own SPF records. When they send outbound email through us, it will authenticate at the destination. However, if Customer A ever spoofs Customer B, it will also authenticate via SPF. This is a very real problem. So how are we fixing it? First, hosted email accounts cannot spoof another customer. If you login to the portal, or connect via IMAP/POP3, you can't specify your MAIL FROM domain. You have to set it up in the portal and put a key into your TXT record. That's not changeable. Second, for on-premise machines, they *can* spoof another customer. If they connect over their IP, if the domain they connect with is not provisioned with them, it is attributed to a safe tenant (a misnomer in my opinion). It is here that they could spoof someone else. To get around this, we will check DMARC on outbound mail before we relay it out. If a domain fails DMARC when it connects to us, and it is an outbound email intended for the rest of the Internet, we will reject the message so it cannot be sent out to an unsuspecting third party that might pass SPF since it came from our service's outbound IPs. This is not a perfect solution, but it does close a gap. The existing DMARC specification lets us do this without making any changes to it. If all your customers add your SPF to theirs, then if they forge each other's mail, it'll pass DMARC. BTW, this has long been cited in the security considerations for the SPF RFCs (RFC 4408, 10.4 and RFC 7208 11.1). I don't think you're fixing it at all, at least not as described. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback
On Tue, Nov 4, 2014 at 3:48 PM, Murray S. Kucherawy superu...@gmail.com wrote: So if anyone feels comfortable making comments on whether or not such an -06 would be ready for publication (i.e., -05, which is public, plus the above changes), please say so on this list so the ISE can see them. Any other feedback is of course welcome. I will post what I have for -06 as soon as the embargo lifts on Monday. I'm in favor of a -06 as you propose. --Kurt Andersen ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base
On Sun, Nov 2, 2014 at 6:28 AM, Scott Kitterman skl...@kitterman.com wrote: On Sunday, November 02, 2014 01:42:49 Murray S. Kucherawy wrote: ... As was done with the DKIM deployment RFCs, the same has been done for DMARC. It seems neither DKIM nor DMARC follow the path of least astonishment. Not quite. There was an actual DKIM working group that produced standards track documents that, due to an actual technical issue they found, broke backward compatibility with existing DK key records. DMARC was developed outside the IETF and submitted via the ISE. Not at all the same (nor the least astonishing from my PoV). Not that it's going to change at this point, but let's not overdo the claims of business as usual. Just to get the citation right, it was Doug who said this, not me. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base
Douglas Otis writes: After all, DMARC permits the weakest authorization as a basis for acceptance, so it would be misleading to describe DMARC results as having been *authenticated*. Well, no, it isn't necessarily misleading. According to RFC 4949, authentication = identification + verification, while authorization is a permission to do something. For example, in DKIM d= identifies the Signing Domain and b= + a DNS lookup provides the data needed for verification. At that point you have in fact authenticated the Signing Domain, and with From alignment (and the additional assumptions that the key is available only to the Author/Signing Domain and that the Author Domain authenticates users) you have authenticated the authorization to use that mailbox in From. (You could add a lot more caveats -- there is a lot of attack surface in email. :-( ) Some similar statement is true for SPF (at least under favorable conditions :-). AFAICS authenticating that particular authorization is precisely what DMARC claims to do, although the I-D uses different words to say that. Anyway, AIUI, the question we're trying to address in Milestone One is how does that affect third parties on the assumptions that (1) mail receivers are satisfied that DMARC does what they think it does and (2) such mail receivers respect p=reject. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue
Just noticed that I never replied to this: On Fri, Aug 29, 2014 at 8:39 PM, Scott Kitterman skl...@kitterman.com wrote: Since this is the WG list, I'm not sure if this is still the right list for issues with the base spec or not, but here goes ... The definition of fo in Section 5.2, General Record Format, allows both values of 0 and 1 to be specified. It was suggested to me offlist that this might not be appropriate, so I thought it worth a discussion. Does anyone who's implemented fo have a problem with both 0 and 1 being specified? If it is somehow problematic, then the base spec ought to say so. How about this? 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned pass result. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base
Douglas Otis writes: As such, using the terms authenticates and authentication should not be used when referring to DKIM or SPF results. Nothing is being authenticated. I'm confused. The sending domain is being authenticated, as well as as much content as is signed (none for SPF, at least the From and DKIM-Signature fields for DKIM). Otherwise there's no point to either protocol. Of course, DKIM does NOT ensure that the use of the Author Domain is *authorized* (unless the author domain is the signing domain, it which case it seems reasonable to presume authorization), but it is *authentic* in the sense of being used as the sending domain intended. Or are you referring to the fact that these protocols don't put any requirements on the security of the DNS? The real function is verification of an authorization. I think you are overcomplicating things here, and I don't understand why. We *identify* a terminal of a channel (here by using the IP address for SPF and the DKIM-Signature for DKIM), then *authenticate* that identity, and finally accept its communications as *authorized* when accompanied by an appropriate (secure) token from an authority. In many cases the identity is the token (as when a user is authorized to access a file because she is the owner). In the case of a domain publishing an SPF policy, the nature of the protocol is essentially that anything from these hosts is authentic and authorized (the identity == sending IP is the authorization token). If you don't want to say that, don't publish any hosts with your restrictive SPF policy. Analogously for DKIM, as far as I can see. The signed part of a message is similarly self-authorizing if the signature is valid, and if you don't like that, don't sign anything and use some other protocol. I suppose here you also need DMARC or other policy protocol to actually announce that you aren't sending any authentic mail with DKIM signatures. Agreed, there are good reasons to demand From alignment. This can be is authenticated by DKIM (assuming the DNS and MTA have not been subverted), and I suppose SPF (but in a world of virtualization and shared resources I'm not so sure about SPF). Again agreed, these don't identify users. But nobody in the mailbox provider game seems to care about that anyway. Section 2, Was: However, there has been no single widely accepted or publicly available mechanism to communicate domain-specific message authentication policies, or to request reporting of authentication and disposition of received mail. Should be: However, there has been no single widely accepted or publicly available mechanism to communicate domain-specific message verification policies, or to request reporting of verification and disposition of received mail. This is also inaccurate, however. Nothing about the message is verified by any of these protocols, except the sending domain (and in the case of DKIM, the integrity of the signed portion of message can be verified). If you want to be more specific, you could write authentication of the sending domain and the signed portion of the message, if any. (Again, unless you want to question the use of the DNS as a source of authentication information. But I think that is outside of the scope of these protocol documents, let alone of the WG.) Was: As a result, senders who have implemented email authentication have had difficulty determining how effective their authentication is, and use of authentication failures to filter mail has not been a success Should be: As a result, senders implementing email authorization schemes have had difficulty determining how effective their authorization is, and use of authorization failures to filter mail has not been a success. I think this is exactly correct as was. I think that in the case where *authentic* communications are *authorized* implicitly, we should use the weaker term. Section 2.2 Was: o authentication of entities other than domains, since DMARC is built upon SPF and DKIM which authenticate domains; and Should be: o authorizations of entities other than domains, since DMARC is built upon SPF and DKIM which authorizes domains; and These and following changes are clearly incorrect, because authorization of domains is done by domain registrars, not by the domains. Do you mean authentication - verification as above? (I still think this is better as was, but I'm trying to understand your intent here.) Regards, Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ Dear Murray, Nice work as this is a great improvement. The introduction properly states the function of DKIM or SPF is to detect and block unauthorized email. Neither DKIM nor SPF determines: 1) valid RFC5322 structure 2) intended message recipient 3) sending domain 4) From header field content 5) Subject header field content As such, using the terms authenticates and authentication should not be used when referring to DKIM or SPF results. Nothing is being authenticated. The real function is verification of an authorization. It is dangerously misleading to overstate DMARC/SPF/DKIM mechanisms, especially since DMARC permits the weakest mechanism to be a basis for acceptance. Leave the name of the document as is, in the hopes future mechanisms will enable an ability to actually authenticate domains. Perhaps by using tokens similar to ApplePay or LoopPay. Section 2, Was: However, there has been no single widely accepted or publicly available mechanism to communicate domain-specific message authentication policies, or to request reporting of authentication and disposition of received mail. Should be: However, there has been no single widely accepted or publicly available mechanism to communicate domain-specific message verification policies, or to request reporting of verification and disposition of received mail. Was: As a result, senders who have implemented email authentication have had difficulty determining how effective their authentication is, and use of authentication failures to filter mail has not been a success Should be: As a result, senders implementing email authorization schemes have had difficulty determining how effective their authorization is, and use of authorization failures to filter mail has not been a success. Section 2.2 Was: o authentication of entities other than domains, since DMARC is built upon SPF and DKIM which authenticate domains; and Should be: o authorizations of entities other than domains, since DMARC is built upon SPF and DKIM which authorizes domains; and Section 3: Was: Authenticated Identifiers: Domain-level identifiers that are established using authentication technologies are referred to as Authenticated Identifiers. See Section 3.1.1 for details about the supported mechanisms. Should be: Authorized Identifiers: Domain-level identifiers that are established using authorization technologies are referred to as Authorized Identifiers. See Section 3.1.1 for details about the supported mechanisms. Was: 3.1.1. Authentication Mechanisms Should be: 3.1.1. Authorization Mechanisms Was: o [SPF], which authenticates the domain found in an [SMTP] MAIL command when it is the authorized domain. Should be: o [SPF], which authorizes the domain found in an [SMTP] MAIL command. Section 3.1.4 Was: Each of the underlying authentication technologies Should be: Each of the underlying authorization technologies Was: 3.1.4.2. SPF-authenticated Identifiers Should be: 3.1.4.2. SPF-authorized Identifiers Section 5 Was: A Domain Owner may find that although its messages pass a particular authentication scheme's checks, it wishes not to have Mail Receivers Should be; A Domain Owner may find that although its messages pass a particular authorization scheme's checks, it wishes not to have Mail Receivers Although DMARC requires subsequent format checks of the From header field, it does not do this with the Subject line which often permits injectable clickable URLs. As was done with the DKIM deployment RFCs, the same has been done for DMARC. It seems neither DKIM nor DMARC follow the path of least astonishment. If history is any sort of predictor, DMARC will be gamed whenever receivers follow the path of least resistance and trust the Authentication results contained within messages. It seems unfortunate that Internet Identified Mail was not adopted because it passed the public key within the message which was seen as causing too much message overhead. Now, rather than correcting the DKIM validation process, domains are now expected to list all the headers used twice in each and every message. As such, it seems IIM would now have been the better choice. It is very dangerous to over sell the function of SPF and DKIM. Both of these mechanisms are experiencing increased exploitation in highly critical areas. It is unfortunate it took until May of 2014 for a major provider to finally acknowledge the nature of these exploits, although they had been explained much earlier in appeals and magazine articles. Unless DKIM is repaired, both the DKIM Deployment and DMARC BCPs drafts are sorely lacking much needed guidance. Guidance many are likely to find astonishing. Regards, Douglas Otis ___ dmarc mailing list
Re: [dmarc-ietf] draft-kucherawy-dmarc-base revision submitted
Murray, You've clearly put a lot of work into updating this document, and there are a substantial number of changes. That means it deserves this group's serious attention. You've given me my homework assignment, I can say... Eliot On 10/29/14, 9:37 PM, Murray S. Kucherawy wrote: On Tue, Oct 28, 2014 at 3:44 PM, Murray S. Kucherawy superu...@gmail.com mailto:superu...@gmail.com wrote: Since we're past the I-D deadline, the ISE or Pete will have to approve its addition to the datatracker, so it will magically appear at some point soon, and then move forward in the publication process. It's now available in the datatracker: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc signature.asc Description: OpenPGP digital signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base revision submitted
Thanks Murray. That was a really important step. You continue to carry the bulk of the email security standardization load on your shoulders, and it is greatly appreciated! Cheers, -Brett On Tue, Oct 28, 2014 at 6:44 PM, Murray S. Kucherawy superu...@gmail.com wrote: Colleagues, With apologies once again that it's taken so long, I have submitted the base draft again to the datatracker. It underwent what Eliot Lear calls a haircut, which is to say I spent a good chunk of time rearranging the material, consolidating redundant sections, removing unnecessarily verbose or unimportant text. His sketch of a roadmap to doing so was very helpful indeed. There was only one technical change, and that was to remove all references to IODEF since that's an aspect of the reporting component that is completely unimplemented. In the hopes of keeping the spec simple, it's now gone. Since we're past the I-D deadline, the ISE or Pete will have to approve its addition to the datatracker, so it will magically appear at some point soon, and then move forward in the publication process. My thanks to all of you that took time to make haircut suggestions. Onward, -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue
Dave Crocker writes: That is, perhaps start by asking the question on: http://www.dmarc.org/mailman/listinfo/dmarc-discuss Last I heard that list was deprecated in favor of this one. It certainly has been mostly inactive for quite a long time. Murray? Franck? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue
On Aug 29, 2014, at 11:39 PM, Scott Kitterman skl...@kitterman.com wrote: Since this is the WG list, I'm not sure if this is still the right list for issues with the base spec or not, but here goes ... Right list. Just to set precedent, any thoughts on this issue will be captured in the WG's issue tracker. Once the WG shifts to considering specification changes (next year), we'll bring it up again and fold necessary changes into spec. =- Tim The definition of fo in Section 5.2, General Record Format, allows both values of 0 and 1 to be specified. It was suggested to me offlist that this might not be appropriate, so I thought it worth a discussion. Does anyone who's implemented fo have a problem with both 0 and 1 being specified? If it is somehow problematic, then the base spec ought to say so. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue
On 8/30/2014 7:12 AM, Tim Draegen wrote: On Aug 29, 2014, at 11:39 PM, Scott Kitterman skl...@kitterman.com wrote: Since this is the WG list, I'm not sure if this is still the right list for issues with the base spec or not, but here goes ... Right list. ... While this might be a reasonable list for the question, it might be more useful to /start/ with a broader and more operations-oriented dmarc list, and then bring the topic here when there is some convergence from the discussion elsewhere. That is, perhaps start by asking the question on: http://www.dmarc.org/mailman/listinfo/dmarc-discuss d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue
On Aug 30, 2014, at 7:12 AM, Tim Draegen t...@eudaemon.net wrote: On Aug 29, 2014, at 11:39 PM, Scott Kitterman skl...@kitterman.com wrote: Since this is the WG list, I'm not sure if this is still the right list for issues with the base spec or not, but here goes ... Right list. Just to set precedent, any thoughts on this issue will be captured in the WG's issue tracker. Once the WG shifts to considering specification changes (next year), we'll bring it up again and fold necessary changes into spec. I would suggest we just convert draft-kucherawy-dmarc-base-04 into draft-dmarcwg-dmarc-base-01 to reflect the current spec has been accept by this WG for further work. Is this the way it is done, usually? Then all issues can be directed, tracked, and emailed to this wg using the IETF tools (and others) as the spec will have this WG email address attached to it. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
