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 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 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 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
