Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?
On 8/5/2023 5:06 PM, Tim Wicinski wrote: The former resonates with harried admins, while the later is useful to implementers. Providing a definition that is at odds with established meaning for a word is something that can work tech geeks but is counter-productive when applied for others. d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?
On 8/5/2023 4:23 PM, Neil wrote: > The language used for DMARC has always been problematic. "Policy" > implies control, but the domain owner has no control over the receiving > platform. Quarantine and Reject declare control that also does not exist. Suppose you set a policy of p=reject that’s still your policy even if receivers aren’t obligated to honor your policy. But it’s a policy nonetheless. It’s not required that a policy be followed for it to be policy. That aside, there’s unlikely to be another word that works better than’s worth any confusion or disruption that could be caused by changing the jargon. www.dictionary.com Policy Definition & Meaning | Dictionary.com <#> Policy definition, a definite course of action adopted for the sake of expediency, facility, etc.: We have a new company policy. See more. https://www.dictionary.com/browse/policy <https://www.dictionary.com/browse/policy> Also, we understand who our audiences are in reality. Sometimes it’ll be a harried admin skimming the RFC, and others will take the time to do a deep dive. Even the harried admin scanning today might want to dive deep when he has more time. So out of respect for those who want to get things done and solve problems quickly and those who wish to grok the new DMARC spec, I think the optimal solution would be to follow E.B. White, making every word count, having empathy for the reader, and avoiding distractions that could bog the stressed reader down. When writing specifications, yes, it is good to consider the casual or harried reader. To that end, vocabulary should not mislead. 'Policy' misleads about the effect of choosing a particular value. d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?
On 8/5/2023 9:30 AM, Jesse Thompson wrote: Conformance has a synonym Compliance, which may be a reason why people in the ranks of Security and Compliance in "general purpose" Author Domains fixate on p=quarantine|reject as a rubric to assess their perceived security posture without any serious knowledge/consideration of the email interoperability issues, and then inevitably there's some kind of unsolvable security incident that convinces the CISO to say "damn the torpedoes". The language used for DMARC has always been problematic. "Policy" implies control, but the domain owner has no control over the receiving platform. Quarantine and Reject declare control that also does not exist. Governance seems like the best word to me, since Governance is what Reporting has provided to ADs in Monitoring Mode, but I do not want to say DMARG out loud either :-) Here, too, the domain owner does not govern the platform receiver. d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?
On 6/30/2023 11:22 AM, Todd Herr wrote: Why is the mechanism called "Domain-based Message Authentication, Reporting, and Conformance" and not "Domain-based Message Authentication, Reporting, and Disposition"? Say DMARC out loud. Now say DMARD out loud. d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Info for SitRep
If anyone in the DMARC wg has status information for us to include in the Silicon Valley Red Cross chapter monthly report, I'll be glad to include it. For the rest of you, apologies for the misaddressed message... d/ On 2/23/2023 2:58 PM, Dave Crocker wrote: On 2/23/2023 2:23 PM, Meyerson, Julie wrote: As I discussed last volunteer meeting, I'm not able to access the doc for editing the SitRep. Here's what I'd like to include for community disaster education. Julie, I'll add your text, but would like to do a session with you to try to figure out the problem. Any chance you have some time tomorrow (Friday) afternoon? d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Info for SitRep
On 2/23/2023 2:23 PM, Meyerson, Julie wrote: As I discussed last volunteer meeting, I'm not able to access the doc for editing the SitRep. Here's what I'd like to include for community disaster education. Julie, I'll add your text, but would like to do a session with you to try to figure out the problem. Any chance you have some time tomorrow (Friday) afternoon? d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Pros & cons with keeping v=1 when replacing pct with t
On 2/23/2023 11:20 AM, Trent Adams wrote: I agree... given that changes are being made, it makes total sense to rev the version number. a natural assessment. unfortunately it has problems. version numbers mostly don't work. if the changes produce a spec that is a superset of the previous version, the new stuff is self-declaring and version number isn't needed. if the changes produce an incompatible spec, it's a new protocol, rather than a 'version'. cf, MIME history that landed on this realization. d/ -- Dave Crocker dcroc...@gmail.com mast:@dcrocker@mastodon.social 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational Domain
empts to distinguish the role of the term in DMARC, from the algorithmic details (that they are in the process of changing.) That is, the what from the how. As you have also done. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational Domain
On 1/30/2022 10:39 AM, Scott Kitterman wrote: On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote: On 1/29/2022 7:53 PM, Scott Kitterman wrote: 1. Using 7489 or 9091 as fixed, controlling documents is problematic, as I've noted. So, 'consistency' with them is frankly irrelevant. The WG charter doesn't say that they are irrelevant. I don't think we should be redefining terms for the sake of redefining terms. You've given no rationale for there being a problem with the current definition, so I don't think it's up to me to make the case for why things shouldn't change. 1. For this topic, they are irrelevant. There is nothing in the charter that says terminology must be preserved. Interoperability is not endangered by changes in terminology. I disagree. OK. Then point to the text in the charter that supports your view. Having the same term mean two different things in different DMARC RFCs is a recipe for confusion. 1. This ignores the concept of "Experimental" and, therefore, learning from experience. 2. Your certitude about consequences means that you have clear and compelling evidence from the field that the negative outcome will happen. Please cite it. Otherwise, what you are saying is merely that you are concerned there might be confusion. To this I'll counter that having two different terms that cover exactly the same semantic is inherently... semantically confusing. Confusion leads to programming and configuration errors, which definitely impact interoperability. I think the current definition of Organizational Domain is fine. If you think there is a problem with it, I would encourage you to come up with a different term to use in DMARCbis (and whatever other documents it's relevant to) and make your case. OD is not a programming construct. And the way to ensure consistent, accurate programming -- or, at least, to make it more likely -- is with clear, precise, accurate specification of algorithms, rather than by treating unifying labels as problematic. 2. Your 'for the sake of' is uncalled for and dismissive. Please stop doing that. Attempts to be dismissive are a popular debating technique in the IETF, but they are counter-productive, as well as unprofessional. (And no, this comment is not just meant for you. You're just lucky, tonight.) I agree they are unfortunately common, but you've made no case for the change beyond that fact that you proposed it. Then I suggest you read my proposal and followup texts a lot more carefully and even engage with their details, such the details I reiterated that you included below... You may, in fact, have a good reason for it, but I have no idea what it is. That's my opinion based on what I know. If I missed something about why you think this is worth spending time on, please point me at the reference or explain it. Clearly. 3. As for giving no rationale, 'tree walk' posting set the stage. a) Today's posting specifically noted: "the move towards supporting (at least) two very different methods of finding it." \ b) Again: for DMARC, the semantics of the different mechanisms is the same. Hence a single term. There is quite a bit of benefit in having a single term to cover different means of achieving the same goal. So now I'll again ask: what are the semantic differences that are relevant to DMARC, and what is the benefit of having DMARC use different terms, given that DMARC does not care about which mechanism is used? Since relaxed mode alignment in RFC 7489 Section 3.1 is referenced to the organizational domain, changing the definition of organizational domain to include PSDs would have a huge impact on DMARC. You are depending on a restriction for relaxed that is not documented and, frankly, doesn't make obvious sense. So reliance on that isn't helpful to this topic. DMARC may not care about the mechanism (I agree with that), but it certainly cares about the result. With your proposed change maryland.gov could send mail with a DMARC pass from virignia.gov. While that's not particularly catastrophic, as soon as a non- governmental PSD publishes a record, it would be. Please explain 1) how that can happen under .gov, and 2) why it is credible to claim that it could happen. Because neither is obvious to me. 2. To the extent that the text I've proposed does not accurately reflect the semantics of what DMARC needs, please explain what, specifically, are the issues. I'm not aware of any related to a need for this new text. I think that's up to you. Sorry no. It's not my job to guess at your objections. I'm pretty sure it's your job to explain them. I've made my objections pretty clear, I think. 1. You have not engaged with the specific points I've made, explaining the basis and benefit of what I've proposed. 2. You've relied on points that aren't documented and, IMO, don't make sense. So, no, you have
Re: [dmarc-ietf] Organizational Domain
On 1/30/2022 4:34 AM, Alessandro Vesely wrote: ANK admins decide to setup a DKIM signing service for .bank domains. They register dkim.bank, and accept and relay messages originating from their customers, signing them with d=dkim.bank. (Compare to onmicrosoft.com?) They may consider that a tangible way to protect .bank domains. Will that work to validate, say, mail From: acco...@havenbank.bank? Consider .bank.com, setting up dkim.bank.com, signing with dkim.bank.com. Will that work to validate, say, mail from acco...@havenbank.bank? Please explain why these two different cases should be treated differently. In other words, the issue is with problematic operational policies, rather than with needing to place special technical restrictions on TLDs. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational Domain
On 1/29/2022 7:53 PM, Scott Kitterman wrote: 1. Using 7489 or 9091 as fixed, controlling documents is problematic, as I've noted. So, 'consistency' with them is frankly irrelevant. The WG charter doesn't say that they are irrelevant. I don't think we should be redefining terms for the sake of redefining terms. You've given no rationale for there being a problem with the current definition, so I don't think it's up to me to make the case for why things shouldn't change. 1. For this topic, they are irrelevant. There is nothing in the charter that says terminology must be preserved. Interoperability is not endangered by changes in terminology. 2. Your 'for the sake of' is uncalled for and dismissive. Please stop doing that. Attempts to be dismissive are a popular debating technique in the IETF, but they are counter-productive, as well as unprofessional. (And no, this comment is not just meant for you. You're just lucky, tonight.) 3. As for giving no rationale, 'tree walk' posting set the stage. a) Today's posting specifically noted: "the move towards supporting (at least) two very different methods of finding it." \ b) Again: for DMARC, the semantics of the different mechanisms is the same. Hence a single term. There is quite a bit of benefit in having a single term to cover different means of achieving the same goal. So now I'll again ask: what are the semantic differences that are relevant to DMARC, and what is the benefit of having DMARC use different terms, given that DMARC does not care about which mechanism is used? 2. To the extent that the text I've proposed does not accurately reflect the semantics of what DMARC needs, please explain what, specifically, are the issues. I'm not aware of any related to a need for this new text. I think that's up to you. Sorry no. It's not my job to guess at your objections. I'm pretty sure it's your job to explain them. 3. The role of the function that uses the PSD and the role of the function that does a tree walk are identical. Since you apparently feel otherwise, please explain. A PSD is potentially useful for DMARC policy determination if no policy exists for the exact domain or the organizational domain. It is not useful for evaluating relaxed alignment. Only the organizational domain can be used for that. So I do not think you are correct. The RFC 9091 does not contain the word 'relaxed', so I'm curious about the basis for your assertion of the limitation. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational Domain
On 1/29/2022 1:58 PM, Scott Kitterman wrote: So going back to Dave's proposed text that started the thread: On Saturday, January 29, 2022 1:11:29 PM EST Dave Crocker wrote: Here is some alternative phrasing: For DMARC, an Organizational Domain can contain a DMARC record, to be used as the default DMARC record for subordinate domains that do not have a DMARC record of their own, and for subordinate domains that do not exist. I don't think that is consistent with either RFC 7489 or RFC 9091. I don't think what is in the current draft is great either. RFC 7489 distinguished between the definition of organizational domain and how you find the organizational domain. I think that distinction is useful. 1. Using 7489 or 9091 as fixed, controlling documents is problematic, as I've noted. So, 'consistency' with them is frankly irrelevant. 2. To the extent that the text I've proposed does not accurately reflect the semantics of what DMARC needs, please explain what, specifically, are the issues. 3. The role of the function that uses the PSD and the role of the function that does a tree walk are identical. Since you apparently feel otherwise, please explain. d/ -- Dave Crocker ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational Domain
On 1/29/2022 12:48 PM, John R Levine wrote: Since a PSD can't be an organizational domain, I don't think that's going to work. Please provide the foundation to this assertion, because I believe the text I've offered makes your premise wrong. Then it's lucky we caught this mistake now, isn't it? See RFC 9091, section 1. John, You might be surprised to find out that your saying something is a mistake does not make it one. Especially when, you know, it isn't one. You might also be surprised to find out that making a generic reference to an entire document does not further detailed discussion about a specific point. And you might even be surprised to find out that citing an Experimental RFC does not do much in establishing much, as is constantly being pointed out in Emailcore, no matter how much group effort, and even IETF approval, was developed to get the document published. And best of all is that the RFC you cited refers back to RFC 7489 for the definition of Organizational Domain. And, gosh, that's also Experimental, not to mention, well, it's the document we are revising here. So, perhaps you will consider the challenge of engaging in substantive discussion and respond to my proposed language... substantially? d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational Domain
On 1/29/2022 10:52 AM, John Levine wrote: Since a PSD can't be an organizational domain, I don't think that's going to work. Please provide the foundation to this assertion, because I believe the text I've offered makes your premise wrong. That is, I think you are taking as a given, something that is not a given. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Organizational Domain
Folks, The current draft has this text concerning Organizational Domain: 3.2.7. <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#section-3.2.7>Organizational Domain <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#name-organizational-domain> The Organizational Domain is typically a domain that was registered with a domain name registrar. More formally, it is any Public Suffix Domain plus one label. The Organizational Domain for the domain in the RFC5322.From domain is determined by applying the algorithm found in Section 4.6 <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#determining-the-organizational-domain>. I believe the text is not adequately helpful, in terms of DMARC's history, and especially not helpful in the move towards supporting (at least) two very different methods of finding it. I understand the desire to declare The One True mechanism, but I will claim it is too late for that. Also, I think the term continues to be useful... Here is some alternative phrasing: For DMARC, an Organizational Domain can contain a DMARC record, to be used as the default DMARC record for subordinate domains that do not have a DMARC record of their own, and for subordinate domains that do not exist. This is text about the what, rather than the how. It defines DMARC-relevant semantics, without saying anything about the mechanics of finding it. In that light, I'll renew my strong suggestion, from back in the days of PSD development, that this core DMARC document NOT contain details or sections devoted to PSD, in the style now shown in the current sections 3.2.8 - 3.2.10 Rather, I suggest adding an additional sentence to the alternative phrasing, above: The method of finding an Organizational Domain is outside the scope of this specification. Examples of such methods include the Public Suffice Domain (PSD) [RFC9091] and Public Suffix List [http://publicsuffix.org]. I think this gives an adequate nod to established and new practice, without emphasizing either or the excluding the possibility of other methods. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 11:11 AM, John R Levine wrote: Hm, we're addressing the same problem that DBOND did, but it's not DBOUND. Well, OK. You seem to be, but I'm not. I'm addressing a documentation issue. I'm sorry you are having so much trouble understanding that. I've no idea how you came up with a larger and more abstract scope. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 10:49 AM, Scott Kitterman wrote: Or, not to put too fine a point on it, if you two want to discuss DBOUND, I thinkdbo...@ietf.org is still active. there's nothing in what I posted that has anything to do with dbound or possible derivatives. The introduction of the reference came from a creative misreading of my posting. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 10:54 AM, John R Levine wrote: Ahh, You are claiming I said something about a 'general method'. I didn't. Since you think otherwise, could you explain in simple language that even I could understand how you reached that interpretation of my note? Now we're both confused. When you said "The method of finding the organizational domain should be specified outside of the base DMARC specification" did that mean it's still unique to DMARC, but we put it in a different document? 1. I said it should be specified outside of the base DMARC document. That's different from saying what the internals of the separate document should contain. I didn't comment on that. 2. But since you are asking, I think it is pretty easy to specify the details of the mechanism in a way that does not require DMARC specific text. Not because it is will or might have more general use -- that that's often a collateral benefit -- but because specs should not overspecify detail they don't need to. If so, what's the point of making it separate? If not, what am I missing? It removes fate-sharing of the core mechanism from the messier component mechanism that will have (at least) two very different operational designs with the new one being... new and lacking solid field experience that gives assurance for uptake. (Thought I said all that in the original note. Should I have used caps?) d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 10:38 AM, John R Levine wrote: It appears that Dave Crocker said: The method of finding the organizational domain should be specified outside of the base DMARC specification. I suggested this back during the PSD discussion. That assumes that the org domain is useful on its own, rather than just as a tool to help find policy records or to check for relaxed alignment. It does? I don't understand how it assumes that. If the org domain isn't useful, why would we care how it's defined? Well, now you've completely lost me. I have no idea what you are talking about, nevermind how it it supposed to relate to the rather simple point of distinction I suggested, separating what from how. We tried and failed to find a general method to find an organizaional domain in DBOUND, and I don't think we want to go there again. So it's a good thing I didn't suggest anything of the sort. Could you explain in simple language that even I could understand how a generic definition of a way to find an org domain is not what DBOUND tried to do? Ahh, You are claiming I said something about a 'general method'. I didn't. Since you think otherwise, could you explain in simple language that even I could understand how you reached that interpretation of my note? d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 10:04 AM, John Levine wrote: It appears that Dave Crocker said: The method of finding the organizational domain should be specified outside of the base DMARC specification. I suggested this back during the PSD discussion. That assumes that the org domain is useful on its own, rather than just as a tool to help find policy records or to check for relaxed alignment. It does? I don't understand how it assumes that. We tried and failed to find a general method to find an organizaional domain in DBOUND, and I don't think we want to go there again. So it's a good thing I didn't suggest anything of the sort. This just leaves the question of why you are introducing it here? 1. There is already an installed base using the PSL. While I understand the desire to move away from it, the change might or might not happen and if it does, it will take a potentially long time. ... I think we have all agreed that whatever we come up with has to produce similar results to the current scheme. I say similar rather than identical, since the PSL is a moving target. My concern has nothing to do with equivalent semantics but rather is about the pragmatics of transition with parallel field operation, duration for gaining traction, and the risk of inadequate uptake. Sorry I wasn't adequately clear about that. 2. In spite of the current fashion that encourages use of tree walk, it does not have prior field experience and in fact runs contrary to long-standing, established practices. ... RFC 8659 suggests otherwise. Because, yeah, the mere fact that an RFC was issued 2 years ago completely reverses established concerns and practice of 35 years... And I'm sure there is plenty of data about operational uptake and comfort with the mechanism, though I didn't see it when searching for references to the RFC. Please provide a point to the field experience that cover the concern I raised. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 9:30 AM, Seth Blank wrote: Yes, this is a core ticket that needs to be addressed: https://trac.ietf.org/trac/dmarc/ticket/46 21 months ago? as if I'd remember something from 21 minutes ago. sheesh. I believe right now the group is just dialing in the definition/text, but there has been broad agreement (I don't remember hearing any disagreement, but I wouldn't go so far as to call it consensus yet) that everything related to organizational domain discovery should be moved into a separate document. great. hadn't gotten that vibe from the list discussion but as long as the separation is an open point, that's fine. thanks! d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] tree walk is experimental
G'day. The method of finding the organizational domain should be specified outside of the base DMARC specification. I suggested this back during the PSD discussion. There are a number of reasons: 1. There is already an installed base using the PSL. While I understand the desire to move away from it, the change might or might not happen and if it does, it will take a potentially long time. During all of that time, field operations will be non-compliant with the DMARC specification. Note that success for tree walk requires a) receivers to attempt it, and b) operational experience to be satisfying. Good ideas often turn out not to succeed... Again, at the very least, it will take an unknown amount of time for there to be enough uptake of this replacement mechanism. And the incentives for that uptake are frankly not all that clear; do we have solid documentation of widespread dissatisfaction with the use of PSL in DMARC? (I'm not asking about the logic, but about the basis for claiming widesprea market dissatisfaction.) 2. In spite of the current fashion that encourages use of tree walk, it does not have prior field experience and in fact runs contrary to long-standing, established practices. While it might prove good to do and even better than PSL, it is, by its nature, an experimental mechanism. Including it inside the base DMARC specification encourages treating that base specification as an experiment. 3. The base DMARC specification needs to define the construct of an organizational domain and it needs to specify how one is used in DMARC operation. It does /not/ need to specify how to obtain one. Given that we will have (at least) two different methods, it is cleaner and safer to partition the 'how' out of the core, leaving only the 'what'. 4. To the extent that there is a view that having tree walk inside the base spec somehow encourages or forces adoption, experience tends to show that, instead, it makes the transition confusing. Also, see points 1 & 2, above. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Evaluator reference model
On 1/18/2022 9:11 AM, Barry Leiba wrote: I think what's*also* outside the intent is for the receiver to infer anything in absence of any statement by the domain owner. Do you disagree with that? Heck no. Since there is nothing in DMARC that mandates that it be used, and nothing normative that specifications the 'conditions' 'intent' about when it /is/ used, then inferring anything by its absence is quite literally outside the scope of DMARC specification. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Evaluator reference model
On 1/18/2022 9:04 AM, Barry Leiba wrote: If a receiving domain wants to use DMARC in its decision process, outside what the purported sending domain says, that's, as Todd says, its choice, but is outside of the intent, and therefor the specification, of DMARC. Ahem. A mechanism that includes a domain owner's being able to suggest disposition handling by a receiver makes the implication of benefit to the receiver explicit, rather than outside of the intent. What is outside the intent is any 'requirement' of compliance by the receiver. (But to riff on this a bit: One can imagine some tortured logic where the tossing or marginalizing of some mail by the receiver is only beneficial to the domain owner, but I'll claim it fails on the pragmatics.) d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Evaluator reference model
On 1/18/2022 7:33 AM, Todd Herr wrote: On Tue, Jan 18, 2022 at 9:36 AM Douglas Foster wrote: I entirely agree that the DMARC result is different from the wanted/unwanted result. If my opening failed to convey that, it was not intentional. My real point was that DMARC is, or should be, for the benefit of the evaluator. Specifically, I have trouble with the language about "Domain owners enable verification...", because it implies that DMARC is controlled by, and consequently for the benefit of, the domain owner. RFC 7489 and DMARCbis both say that if a policy record is not discovered, then "Mail Receivers SHOULD NOT apply the DMARC mechanism to the message." Forgive me, but there is a simpler point here. 1. "enables" does not "imply" control; it asserts it quite plainly. 2. The claim of implying to benefit only to the domain owner is simply incorrect. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Evaluator reference model
On 1/18/2022 5:51 AM, Todd Herr wrote: I don't agree with the goal statement here, because it implies to me that all messages that pass DMARC validation are safe and wanted, while all messages that do not pass DMARC validation are malicious, and neither statement is true. Let me provide, in quotes from the Abstract and Introduction sections of the current rev of DMARCbis, an alternate viewpoint: +1 d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy
On 1/6/2022 3:32 AM, Douglas Foster wrote: Consequently, the best way for senders to avoid delayed or blocked messages is to avoid getting close examination. This is facilitated by ensuring messages are both DKIM-verifiable and SPF-PASS, regardless of DMARC policy. P=NONE or T=Y or no policy are not valid substitutes. That's doubly and impressively wrong. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 5 - DKIM-only authentication
On 1/5/2022 5:59 AM, Tobias Herkula wrote: I have one bigger example back from the days when I was working for an ESP. You've described a company making a set of operational decisions that are known to create problems when using DMARC. They also choose an ESP that imposes an operational requirement known to cause deliverability problems. And you somehow want to modify DMARC to 'fix' this? This is reminiscent of the explanation I got from a CEO, about the complaints sales folk were making about an excellent product, claiming that it needed this or that change: It saves them from doing their job of actually selling the existing product. The company needs to use the technology that exists, in a way that works, and to choose vendors that do the same. If they can find a serious constituency of other companies wanting similar changes, then maybe there is a task for DMARC to embrace. But only maybe. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Section 5 - DKIM-only authentication
On 1/4/2022 6:42 AM, Tobias Herkula wrote: One big thing missing in the Discussion are Receiver obligations, I encountered a lof of Mailbox Providers that demand a valid and concise SPF record, and in this case the Sender has no way to state that he requires DKIM signatures for DMARC, the often stated argument of simply not publishing SPF records if a Sender wants DKIM-only DMARC is not a viable solution in the real world. The specification is very clear about the interpretation and limitations of DMARC. I believe what you are describing are things that some receivers do that are outside of the DMARC specification. Operational variations are important, of course, but they really are outside the scope of the protocol specification. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence
On 12/18/2021 10:17 AM, Phillip Hallam-Baker wrote: Mailing lists are not well supported by SMTP and never will be. Any discussion of how to make mailing lists work better has to begin with the acceptance that they will never work very well which is what most people have been arguing in this thread. SMTP is a transfer protocol. It does not know about mailing lists and doesn't need to. (There is text in the SMTP spec about mailing lists, but really the text has nothing to do with SMTP, per se, and not a lot to do with the operation of mailing lists. Mailing lists are user-level processes that sit at a layer above SMTP. Rather than seeing mailing lists as they work today as the pinnacle of evolution, we should see them for what they are, a rather disgusting hack that we never got round to fixing. Can't say I've ever noticed anyone suggesting that mailing lists are the pinnacle of anything. On the other hand, efforts to produce more interesting capabilities that aren't centralized have not gotten much traction. One keeps hoping, but field experience is not encouraging. Why is it assumed that the input to a mailing list is an SMTP email? That seems to me to be a rather narrow assumption. Not everyone makes that assumption. That said, where is the spec for the alternative and who supports that spec? Once we recognize that the inputs and outputs from 'mailing lists' can be through other transports than SMTP, all arguments about preserving 'original' headers collapse. This is not an interaction between an SMTP sender and receiver, the mailing list itself is a principal. When playing in the sandbox of a particular set of specifications, then it's fine -- actually it's essential -- to specify requirements such as information preservation. If the point is that mail can transit heterogeneous environments, with different semantics, then the fact of that difference ensures information loss. Absent that assurance, why shouldn't the information be preserved, no matter how it is transported? That is, after all, one of the benefits of distinguish the message object specification from the message transport specification. Apologies. I've probably entirely missed your point. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Best Guess SPF is a dead hack from 18 years ago
On 12/6/2021 1:18 PM, John Levine wrote: Please can we all pretend it never existed, we never heard of it, and we certainly are not going to say anything about it. My best guess is that you are referencing something that has no business even being referenced in an IETF specification. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Best Guess SPF should not be deprecated.
On 12/6/2021 11:56 AM, Scott Kitterman wrote: Somewhere we need to explain about how ARC related to DMARC. If it's going to be in the protocol specification, this is the place. Otherwise it would go in the appendix I keep mentioning that we need which explains options senders, intermediaries, and receivers can do to mitigate DMARC interoperability challenges. I think it's slightly better to do it in an appendix , as long as we remember to write it. You want to comment on ARC in the DMARC specification? Don't do that. ARC currently has nothing to do with DMARC. And DMARC currently has nothing to do with ARC. To change this will require writing a specification, presumably as an enhancement to DMARC, to include consideration of ARC. In technical terms, the ARC specification must not know about or care about DMARC, since ARC is attempting to augment DKIM, rather than an upper-level function that uses DKIM, which is what DMARC is. If it helps, draw boxes with labels for different functions, like SPF, DKIM, and DMARC. Draw arrows between them,to establish which provides functionality and which uses it. A providing specification must not know or document anything about a consumer. Otherwise it is, effectively, a layer violation. It also invites messy complexity and out-of-date references, as specifications change. To the extent that there is a strong benefit in having a document that discussion an aggregation of components, then it's a separate operations or architecture document. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Best Guess SPF should not be deprecated.
On 12/6/2021 5:29 AM, Scott Kitterman wrote: I think what better goes in this spot is a more general comment about local policy (it doesn't seem to be discussed elsewhere). "Local policy" is just another way of saying "doing something outside of the specification". People are always 'allowed' to do whatever they want. It has nothing to do with interoperability through the specification. Telling people that they can do things outside of the specification is not helpful. In fact, it often is counter-productive, because having such language in a specification makes it seem to carry extra weight. Which it doesn't. For example, it often seems to be granting permission or constraint, but it is doing that for something about which the specification has no power or authority. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions
On 12/6/2021 10:48 AM, Scott Kitterman wrote: I understand you don't like what's there, but not how you think it should be changed. The proposed revision addresses the concern I had raised. If a sentence or a paragraph is not providing necessary specification and is not providing necessary clarification and is not providing useful guidance, then drop that text. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions
On 12/6/2021 10:06 AM, Scott Kitterman wrote: OK. What's your recommendation then? Scott, I think my note contained a series of very basic recommendations. I'm not sure what else you are looking for. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions
On 12/6/2021 9:38 AM, Scott Kitterman wrote: In the interests of future-proofing, should there ever be additional underlying authentication protocols, I propose this: Should any authentication failures for systems under the Domain Owner's control be found in the reports, in cases where the failures are caused by local misconfiguration or omission the Domain Owner can take steps to address such failures. I think that's good. Sorry, but I think it's not. 1. A specification should specify. It should specify things that are concrete, precise, reliably actionable, and generally produce the same understanding across widely differing readers. Specification language that does not satisfy the list in the preceding sentence is not a specification. Rather it is commentary. 2. When a specifications says that something vague and operational is allowed or not allowed, consider whether it would be meaningful to switch the bit. The above text is saying that local problems are allowed to be fixed by taking local action. Could it make sense here to prohibit taking that action? I sure hope not. So this text is, really, entirely gratuitous. It purports to be saying something useful, but it isn't. 3. IETF specification culture is quite nice in also allowing commentary about background or use or 'issues' with the specification. The downside is that this often produces text that is, really, none of the things listed in the preceding sentence. Rather, it is language that might feel comfortable to the authors but has no practical utility. On 12/6/2021 5:35 AM, Todd Herr wrote: SPF normally fails on forwarding. Should we mention that? I don't know if it's necessary. SPF breaking due to forwarding is a well-known condition, and I don't think it has to be documented in every text that mentions SPF. Kudos for that point. 4. Duplication of specification details or commentary text invites divergence and/or misunderstanding. Sometimes a caution is helpful, not not when it is long-standing issue with another specification and is already well-understood. To the extent that there is a continuing concern about the reader's understanding the fact of the caution, there should be a basic pointer, early in the specification, to material that discusses this (other) specification. The problems here come from good intentions, but from the problematic view that adding bits of vague or redundant text will provide meaningful protection against the points of concern. They won't. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Best Guess SPF should not be deprecated.
On 12/4/2021 4:23 PM, Murray S. Kucherawy wrote: DKIM, for example, allows verifiers to decide what an acceptable signature is (a favorite I remember from the early days was "I don't want to accept a DKIM signature that didn't cover the Subject field"), which again means one site's "pass" is another site's "fail". I'm going to suggest that that analysis is not formally correct. The DKIM specification precisely defines validation for the signature and it precisely defines what coverage is 'required'. A receiver can indeed choose to apply stricter requirements, but a failure to satisfy these is NOT a DKIM fail. The extra requirements are outside the scope of the DKIM specification and therefore the failure has nothing to do with the standard. This is not a minor point, but it does seem to be a common point of confusion. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Reversing modifications from mailing lists
On 11/28/2021 3:31 PM, Wei Chuang wrote: What type of concern do you have? Is it algorithmic complexity? Or runtime or header size overhead? Biggest concern, for changing anything that has a significant installed base of use and users, is their willingness to make the changes. They have to see a compelling case for the time, effort and expense. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On 10/29/2021 7:56 PM, John Levine wrote: I asked for some examples of bad things that the PSL would prevent or fix. Don’t think we’ve seen any. 1. I've reviewed what I believe are all of your relevant postings on this thread and managed to miss where you asked that. Please point to the message. 2. Though I admit it's a bit difficult to discern exactly what your concern is, I read the motivating text as encouraging the development of a thoughtful privacy and security considerations section. Oddly, you appear to have objected to that point. Can't guess as to why. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On 10/29/2021 6:40 PM, John Levine wrote: It appears that Dave Crocker said: Except that Alessandro's original reference was in the service of explaining why a mechanism DMARC relies on, for establishing organization authority, should not necessarily rely on everyone's being a good actor. I take it you are agreeing that we should stop using the PSL. Since I never said or implied anything of the sort, it's odd you would choose to again introduce such a distraction, given the exercise we've just gone through. Please stop. It's just a bunch of thinly funded volunteers and a github repo. Who knows what they might decide to do tomorrow? You mean, like the DNS root operators? But, again, this is, at best, only tenuously relevant to the original point. I will bet that, with some effort, you could find a way to make a relevant response to Alessandro's original point. Please feel encouraged to try. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On 10/29/2021 6:06 PM, John R Levine wrote: an you explain what this line of argument has to do with DMARC? I'm drawing a blank. If it's that any TLD operator might at any time do something horrible, even though they never have before, it seems to me that the only reasonable option is to abandon the DNS. Sorry you lost the thread. To review: Alessandro expressed concern about a particular company's demonstrated predilection for what was classed as abuse. You attempted to dismiss his concern with an irrelevant point about the particulars of the specific abuse he cited. I pointed out that you'd missed the point that he cited as issue with corporate culture. You again attempted to dismiss the point by claiming it was a single event, long ago. I point out that there was a pattern of behavior and concern about them. You are now claiming that all this is irrelevant to the current topic. Except that Alessandro's original reference was in the service of explaining why a mechanism DMARC relies on, for establishing organization authority, should not necessarily rely on everyone's being a good actor. A point that is entirely relevant and would have been easier to focus on, had you not chosen to distract from it. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On 10/29/2021 5:02 PM, John R Levine wrote: Oh, please. That was the sitefinder fiasco which led to lawsuits and convulsions at ICANN, and considerable contract revision. Nothing like that will happen again for reasons I can explain privately for anyone who cares. Except that repetition of the same action is not what was being suggested. Rather, a matter of corporate culture was. That was one event eighteen years ago. Since they haven't done anything else like that since then, perhaps they learned a lesson. When Jon Postel had half the root servers change where they took the master data from, it was not as a demonstration of his power, independent of the US government, as is often claimed. The same folk in question here ran that master DNS root and were threatening to go rogue and Jon wanted to make sure it would be possible to marginalize the damage if they did. cf, my above reference to corporate culture. A variant of trust-but-verify is trust-but-prevent. Every gTLD operator has a web of contracts with ICANN, and Verisign also with the US government, which severely constrain what they can do with their TLDs. Yes, yes. All of them are well-behaved, following all the rules, and the rules perfectly protect against misbehaviors, which they'd never think of finding a way around. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery
On 10/29/2021 10:31 AM, John Levine wrote: Oh, please. That was the sitefinder fiasco which led to lawsuits and convulsions at ICANN, and considerable contract revision. Nothing like that will happen again for reasons I can explain privately for anyone who cares. Except that repetition of the same action is not what was being suggested. Rather, a matter of corporate culture was. I'm not commenting on the company, but do suggest that it helps more to respond to a point being made than to a point not being made. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
But it is nice to know who a message is from. ... That, and the ability to reply to author. And for the recipient's MUA to organize messages from the same author as if they were from the same author, rather than from a variety of different authors. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/12/2021 3:52 AM, Laura Atkins wrote: It strikes me that these fields (Original From, Reply To, Original Author) may be used rather than unmunging as well. And the purpose of the Author: specification is to suggest there be a single, common place for this. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/9/2021 3:08 PM, Scott Kitterman wrote: Technically it's pretty easy to set up a mailing list which doesn't modify the message in ways likely to make DKIM fail. Almost no one bothers to do so despite pressures resulting from widespread use of DMARC p=reject. This highlights the difference between technical details, versus group operational culture. As we all keep noting, the humans using these lists have lived with a certain kind of operational style, for decades. Entirely legal and -- more important -- deemed useful. So while one can describe various, feasible changes that circumvent the intrusive, destructive effects of DMARC, they requires changes to a long history of use. The word that you might be looking for, here, is Procrustean. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Oh, the mail, it is a-changin', was DMARC-Compliant Mailing Lists
On 10/8/2021 1:51 PM, John R Levine wrote: Language like 'wrap messages' typically means making the content inaccessible except to a recipient that supports the wrapping mechanism. I meant message/rfc822 MIME parts. I agree that some MUAs support them better than others, despite them having been standardized 25 years ago. Saying 'message digest' typically means a hash No, I mean like a mailing list digest, you know, the one daily message with all of the day's messages as message/rfc822 MIME parts. Same 25 years, same so-so support. I guess I'm not the only one who thinks "message digest" has a different, long-standing meaning. https://www.techopedia.com/definition/4024/message-digest There was a long list of additional entries, provided by a simple search, that produced the same interpretation. I am pretty sure I heard the term, with this meaning, going back 40 years, but maybe it was before that. This is the problem with excessively casual references and no explanation, when trying to have a technical discussion. Changing DKIM is an infrastructure change, since it involves components in the handling stream, rather than just the MUA. That too, but if you want to recover the original unmunged message so you know who to reply to, that involves the MUA. Recover from what? You didn't explain what was distorting/hiding the address. In any event, the Author approach is rather substantially simpler than any distorting/hiding process. The Author field is a pure, incremental value-add. It only requires MUA support, ... Well, yeah, just like the other two. I don't understand the point here. Since I pointed out how and why they are in fact fundamentally different than the Author field, your comment, here is both wrong and confusing. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Oh, the mail, it is a-changin', was DMARC-Compliant Mailing Lists
On 10/8/2021 12:12 PM, John Levine wrote: It appears that Dave Crocker said: The purpose of the Author field is to retain some information that presumably won't get modified. ... The problem for me is that this is just another entry in the list of things that are supposed to help peek back and see what the original message said. Other things that immediately come to mind: - wrap messages, like a single message digest - DKIM unmunging hints like Ale has proposed All of these share the characteristic that to be useful, they require MUAs to do things they do not do now, so I don't see much reason to put a lot of effort into any of them unless we see interest from Language like 'wrap messages' typically means making the content inaccessible except to a recipient that supports the wrapping mechanism. Saying 'message digest' typically means a hash, which is in addition to clear content. So I'm not sure what you mean. Assuming you just mean a hash, I don't see its relevance here. Changing DKIM is an infrastructure change, since it involves components in the handling stream, rather than just the MUA. The Author field is a pure, incremental value-add. It only requires MUA support, and it imposes no burden to a recipient MUA that does not support it. These are very, very different barriers to adoption. So while, of course, Author requires new code, the nature and amount is quite different from any requiring infrastructure change, and especially different from anything hiding content unless the recipient supports it. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/8/2021 10:44 AM, Alessandro Vesely wrote: On Fri 08/Oct/2021 18:18:45 +0200 Dave Crocker wrote: Whether signed fields are validated depends on the signing domain's policy. That statement is both true and misleading. DKIM has a semantic that is not dependent on the choices of folk who use DKIM. DKIM's semantic for what it signs does NOT include validation of the content. That some signers might do some sorts of validation does not affect DKIM's semantics. Within the context of the DKIM specification there is no way to tell that a signer has these added constraints or meanings. Therefore, if you are interpreting a signature as meaning that some aspect of the data are valid, you have gone beyond DKIM. DMARC is an example of going beyond DKIM semantics, with incremental specification, but only for the domain name in the From field. Some do check that From: is valid. If they add Author:, I'd expect they faithfully copy it from From:. Unfortunately, there is no automated way to learn a domain's policy. Exactly. DMARC adds to the semantics with its definition of alignment. It's part of DMARC, not DKIM. So it's certainly reasonable to include the Author: field in the set that produce the DKIM signature, but that inclusions does not have any semantic other than it didn't get changed since the signing. Data integrity is nice but is quite different from validation. If the author's domain signed Author:, then a receiver knows that they are aware of the mailing list problem and presumably interested in validation results. I think understand this thinking but I also think it imparts far too much thought and diligence that is going to validly apply. -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/8/2021 10:34 AM, Scott Kitterman wrote: I think it's fair to consider that Sender is at least implicitly always present. In the abstract, according to the spec, yes it is. In practice, arguably it often is not. To the extent that Sender should indicate the 'operator' of the mechanics, distinct from the 'author' of the content, the Sender information often is not present. From a DMARC perspective, what one would have wished for is for all mail to always have the Sender field included explicitly, and DMARC work off of that, independent of the From field. Having a MLM add Sender and not munge From is a far better UX than the munged From. Lots of software already supports it too. That requires trying to change DMARC. That's not going to happen. Would it make sense, perhaps, to key DMARCbis off Sender (i.e. Sender if present or From if no explicit Sender)? If that makes overall sense, it would substantially simplify the MLM's problem. Do the transition matrix for that, showing interactions between changed and unchanged DMARC participants. (I did that during this round of effort that lead to the Author proposal.) The result isn't viable. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
Sorry. Hit send too soon On 10/8/2021 9:45 AM, Scott Kitterman wrote: Are MUAs that don't display Sender still a concern? Do we care? No we don't. Display is irrelevant to any of this, sincesecurity-related user behavior is not affected by these kind of display choices. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/8/2021 9:45 AM, Scott Kitterman wrote: My vague recollection is that the reason not to use Sender (implicit or explicit) as the key for ADSP and later DMARC was concern that some MUAs didn't display the explicit Sender (mostly Outlook Express, IIRC). The original Yahoo! DomainKeys had some sort of a policy component that keyed off Sender. I haven't gone back and looked anything up to be sure, so no promises. Maybe that was the right answer all along. Are MUAs that don't display Sender still a concern? Do we care? Maybe keying off Sender instead of From gets us to a similar place without requiring upgrades to every MUA in existence? Marc Delaney's original DomainKeys uses Sender. The problem with that is that it often isn't in the message, given that its semantic is folded into the From field, when they (start with) the same string. Since From is the only identification field that is always present, that's what DMARC latched on to. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/8/2021 9:28 AM, Scott Kitterman wrote: Agreed. I was confused because it appeared to me that you were directing me there for an answer about DKIM signing and I couldn't find it. From your note I thought you didn't know about the spec. (No, that doesn't seem like a reasonable believe on my part, but I'm still working on my second cup of coffee.) In shorthand terms, Author is the opposite of Sender. In the existing Sender paradigm From is constant, the mediator would add Sender, which would result in sent by Sender on behalf of From. Under this proposal the originator includes both From and Author, the mediator mangles From and the result could be sent by From on behalf of Author. Is that right? One of the reasons I pointed to the draft is that it discusses the history and semantics of Sender vs. From and makes the case the DMARC forces From to be Sender, but not really From any more. Author seeks to recover a purely From semantic. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/8/2021 9:09 AM, Scott Kitterman wrote: So originator includes From and Author and signs both. Then the mediator (e.g. MLM) minges From and signs again. Receiver checks DMARC and it passes. Then receiver sends feedback to both Author and From domains? The purpose of the Author field is to retain some information that presumably won't get modified. Whether to actually 'believe' that information is a different matter, just as it is for all other header fields. And let's be clear that including a field in a DKIM signature does NOT validate its contents. DMARC adds to the semantics with its definition of alignment. It's part of DMARC, not DKIM. So it's certainly reasonable to include the Author: field in the set that produce the DKIM signature, but that inclusions does not have any semantic other than it didn't get changed since the signing. Data integrity is nice but is quite different from validation. Since you are pressing the concern, perhaps you could characterize what danger/threat and what meaningful protection against it you are looking for? d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/8/2021 9:04 AM, Scott Kitterman wrote: I did read that before I replied. I just read it again. I don't see where it specifies which fields should be DKIM signed. Did I miss it? No, that is outside its scope. Its scope is defining a field. Something like specifying what should be DKIM signed is a very different task and needs to be done within the scope of a specification that worries about message 'protections' or the like. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/8/2021 8:41 AM, Scott Kitterman wrote: It's not clear to me which you mean by author's domain? Are you suggesting that the email originator include both Author and From and DKIM sign Author instead of From? Yes he is. Please see: Email Author Header Field https://datatracker.ietf.org/doc/rfc9057/ Abstract Internet mail defines the From: header field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message on the author's behalf. The Sender: field is optional if it has the same information as the From: field. This was not a problem until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field to circumvent mail rejection caused by those protections. In effect, the From: field has become dominated by its role as a handling identifier. The current specification augments the altered use of the From: field by specifying the Author: field, which ensures identification of the original author of the message and is not subject to modification by Mediators. This document is published as an Experimental RFC to assess community interest, functional efficacy, and technical adequacy. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/7/2021 8:21 AM, Barry Leiba wrote: and I don't think I've exhibited symptoms of bizarritude (though I suppose if I had I might not know...). no more than usual, no. but to be fair -- or, perhaps bizarrely fair -- my comment wasn't just a concern about your own preferences... d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/7/2021 8:11 AM, Murray S. Kucherawy wrote: He didn't specify, but I took the suggestion to mean a new document, not any of the current ones. The use of DMARC, and its collateral effects, are atypically complex. So a separate discussion piece would certainly make sense. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
On 10/7/2021 6:57 AM, Barry Leiba wrote: But here: I think it is reasonable, perhaps advisable, to informationally document From-rewriting as a mechanism that is in use, and to include in that documentation a clear exposition of the problems that it causes. Why not get those horrible UX issues down on paper so that when someone decides to deploy it they are better informed? Perhaps we can lead people to take steps to reduce the UX challenges (for example, rewriting the way the IETF is doing it at least addresses the issue of knowing who sent the message, and how to reply to the actual sender, as compared to a rewrite directly to the mailing list address). Sorry, but I've lost track of which document would informationally document this issue. The re-writing hack is an operational one that might or might not prove the be transient. Having a spec note the effect of what it does, in terms of rendering mailing use problematic, is reasonable. Having a spec go into details about the hack of the moment isn't. On the other hand, it's reasonable to put such discussion into a companion 'usage' doc, IMO. d/ ps. As soon as there is text talking about From rewriting, there should be associated text discussing related mechansisms. The Author spec has already been mentioned, but the discussion should try to be exhaustive. ARC and whatever else makes sense, too. -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99
On 7/21/2021 1:28 AM, Laura Atkins wrote: This is going to cause difficulties in deployment for a lot of companies and domains. Experience tells us that p=quarantine pct=0 detects forwarders and other types systems that modify and break DMARC authentication. These systems are undetectable when p=none is in place. How is this 'detection' actually used? That is, what is then done differently? On 7/21/2021 10:19 AM, John Levine wrote: I suppose we could leave pct=0 as a hint to forwarders to turn on their DMARC evasion hacks. Why doesn't seeing DMARC as seeing that it isn't p=none outght to suffice for that? d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99
On 7/20/2021 7:04 PM, John Levine wrote: I suppose we should have a Former DMARC Tags registry to prevent them from being recycled with a different meaning. Or keep the current entry, changing the specification citation to NONE, or even just keep the existing one. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99
On 7/20/2021 1:13 PM, Barry Leiba wrote: One of the points of "deprecation" is that we don't eliminate it entirely, but say that it's no longer used. New implementations no longer generate it, but implementations that are interested in backward compatibility will still include support for it on receipt. Eventually, when we see that its use is rare enough, the community might move to no longer include suppor This is a natural, and considerate, model. In the Internet, I believe it also has been shown not to work. Really. If something is to be removed from a protocol, it needs to be removed. So, remove it. If there is a concern about noting the removal, add an appendix that references the removed feature, explaining why it was removed, and citing the previous specification. Do NOT make it 'deprecated'. Don't continue it's specification. Do NOT make its use optional. Make its use a matter of private choice, beyond the four walls of the public protocol specification. "Deprecated" makes things complicated and conditional. Neither of those are protocol attributes to aspire to. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99
On 7/20/2021 7:54 AM, Barry Leiba wrote: I would like to see us deprecate PCT entirely, +1 d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: Priming the Pump for Discussion - Ratchets
On 7/20/2021 7:50 AM, Barry Leiba wrote: I don't agree with the characterization of the second group. I would say that we are partitioning messages into these two groups: - Those for which we can confirm that they originated in the domain they say they did. - Those for which we can not confirm that. Note that the second of those is subtly different to your Not sure it's that subtle, but am sure the difference is profoundly important. A constant misunderstanding of efforts in this realm of effort is a belief that perfection is attainable. It isn't. Therefore any characterization needs to use language of approximations, estimations, heuristics and trade-offs. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ABNF update to dmarc-psd
On 6/7/2021 3:10 PM, Tim Wicinski wrote: dmarc-nprequest = "np" *WSP "=" *WSP ( "none" / "quarantine" / "reject" ) I suggest adding a comment that makes the linkage of 'nprequest' to the prose text explicit. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket 7, 47, and 52_
On 6/7/2021 2:30 PM, Todd Herr wrote: I have plans to remove the comments when version -02 is released soon. dandy. tnx. /d -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Ticket 7, 47, and 52_
Sorry, not sure which ticket this is tied to. *_Ticket 7, 47, and 52_* dmarc-record= dmarc-version dmarc-sep [dmarc-request] [dmarc-sep dmarc-srequest] [dmarc-sep dmarc-auri] [dmarc-sep dmarc-furi] [dmarc-sep dmarc-adkim] [dmarc-sep dmarc-aspf] [dmarc-sep dmarc-ainterval] [dmarc-sep dmarc-fo] [dmarc-sep dmarc-rfmt] [dmarc-sep dmarc-percent] [dmarc-sep] **(dmarc-tag dmarc-sep) dmarc-tag = dmarc-request / dmarc-srequest / dmarc-auri / dmarc-furi / dmarc-ainterval / dmarc-fo / dmarc-rfmt* ; components other than dmarc-version and ; dmarc-request may appear in any order 1. I just had cause to review the previous ABNF and thought that something like this change would be quite nice. Then saw that you'd done it. So, good job! Reviewing the above text, I realized that the comment text is no longer needed and might even be confusing. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section
On 6/3/2021 7:50 PM, Dave Crocker wrote: (this time without an attachment...) Interesting. My own MUA is not showing a received copy of any of my postings of the message through the IETF list. Hence the re-sends, guessing at why not. Finally looked at the IETF's IMAP archive and there they all are. Curious. Anyhow, another round of apologies. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section
(this time without an attachment...) On 5/5/2021 11:48 AM, Todd Herr wrote: We would like to achieve rough consensus on this section of text by Friday, May 21. Apologies. I've only just been able to review this text. Here's a link to suggested changes, done as a Word document with revision tracking turned on: https://www.dropbox.com/s/qmp2t5n1g99l9wj/DMARCbis-Intro-dcrocker.docx?dl=0 (I suggest looking at the document without the revision tracks being displayed.) It might appear that the edits effect major substance changes to the Introduction, but I believe they do not; the intent was to retain the same goals for the Introduction. Changes were driven by: * Providing better lead-in for readers with less background on the document's topic * Eliminating detail that is not need in an introduction * Minimizing PSO text, since I belive the covered domains have Domain Owners whether they are PSOs or not; hence the fact of being a PSO has minimal import in the Introduction * General wordsmithing, to tighten things up d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section
On 5/5/2021 11:48 AM, Todd Herr wrote: We would like to achieve rough consensus on this section of text by Friday, May 21. Apologies. I've only just been able to review this text. Here's a link to suggested changes, done as a Word document with revision tracking turned on: https://www.dropbox.com/s/qmp2t5n1g99l9wj/DMARCbis-Intro-dcrocker.docx?dl=0 It might appear that the edits effect major substance changes to the Introduction, but I believe they do not; the intent was to retain the same goals for the Introduction. Changes were driven by: * Providing better lead-in for readers with less background on the document's topic * Eliminating detail that is not need in an introduction * Minimizing PSO text, since I belive the covered domains have Domain Owners whether they are PSOs or not; hence the fact of being a PSO has minimal import in the Introduction * General wordsmithing, to tighten things up d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org DMARCbis-Intro-dcrocker.docx Description: MS-Word 2007 document ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section
On 5/5/2021 11:48 AM, Todd Herr wrote: We would like to achieve rough consensus on this section of text by Friday, May 21. Apologies. I've only just been able to review this text. Attached are suggested changes, done as a Word document with revision tracking turned on. It might appear that the edits effect major substance changes to the Introduction, but I believe they do not; the intent was to retain the same goals for the Introduction. Changes were driven by: * Providing better lead-in for readers with less background on the document's topic * Eliminating detail that is not need in an introduction * Minimizing PSO text, since I belive the covered domains have Domain Owners whether they are PSOs or not; hence the fact of being a PSO has minimal import in the Introduction * General wordsmithing, to tighten things up d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org DMARCbis-Intro-dcrocker.docx Description: MS-Word 2007 document ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Question on ABNF
On 5/28/2021 12:10 PM, Tim Wicinski wrote: So in looking at removing the "ri" tag from the document, I realized that the ABNF reference needed to be removed also. Thinking about that, I realized that when one adds a new tag to the registry there should be a formalized way that it is represented in the ABNF. Perhaps the IANA Consideration section should also spell out that for new tags, the specification should also include the incorporating ABNF. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
On 5/10/2021 7:10 AM, Matthäus Wander wrote: I support the use of the namespace declaration. A report with namespace declaration allows for automatic syntax checks with XML Schema Validation. Version numbers, and the like, tend to be a lot less useful than intuition leads one to expect. The distinction to make is 'increments' versus 'incompatibilities'.l If an new spec merely /adds/ to a previous spec, then the presence of the new constructs is self-declaring. The only requirement is to have the base specification declare that unrecognized constructs are to be ignored. So, versioning adds the illusion of utility, but really only adds unnecessary complexity. Incompatibilities, where new constructs conflict with previous ones, mean that the new specification is not a new version. It is an independent specification. It needs to be labeled accordingly. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt
On 5/7/2021 2:45 PM, Murray S. Kucherawy wrote: Yeah, but it also means the tools team should probably arrange that announcements of new I-Ds don't use the dead URLs. where's the fun in that? d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation
On 5/5/2021 9:26 PM, Seth Blank wrote: The Chairs ask group participants to explicitly speak up if: 1) they intend to participate in the interim yes. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Sender vs From Addresses
On 3/24/2021 4:54 AM, Ken O'Driscoll wrote: There is actually an existing working group draft discussing extending DMARC to incorporate the 5322.Sender header, see https://datatracker.ietf.org/doc/draft-ietf-dmarc-sender/ <https://datatracker.ietf.org/doc/draft-ietf-dmarc-sender/>. That document goes into considerable detail on how 5322.Sender could be incorporated in the future. To be possibly overly frank, I think the draft is stalled. Given existing practice, there are challenges to fielding this, for incremental adoption, in a way that is reasonable and useful. (The Internet does not support 'flag' days.) I am still, sometimes, mulling over the choices for this, but so far haven't come up with (or seen) ways to resolve the challenge. An option the working group declined to pursue is to define an Author: field and leave the From: field to the 'handling' role DMARC has relegated it to. The draft for this is being pursued outside of the working group. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & PLanning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Sender vs From Addresses
On 3/24/2021 4:54 AM, Ken O'Driscoll wrote: DMARC is intended to prevent unauthorised use a domain name in the 5322.From header. This header was chosen because it is displayed in MUAs and is the target of spoofing attempts in phishing campaigns. It was also chosen because it is the only identification field that is always present. As for display to user, there is no evidence that validating the field has any effect on end-user susceptibility to phishing. It seems natural that it would; however in fact there is evidence that it doesn't. Still, the belief that it does persists. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & PLanning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-11.txt
NEW Defensively registering all variants of "tax" is obviously not a scalable strategy. The intent of this specification, therefore, is to enhance the DMARC discovery method by enabling an agent receiving such a message to be able to determine that a relevant policy is present at "gov.example", which is precluded by the current DMARC specification. Tim, I still think that including the term "obviously" in the first sentence of this snippet is a pejorative judgemental statement which is out of place in a specification. Especially given that there are alternatives to "registering" any such domains at all via the use of "trick" DNS servers at the PSD level. Even worse is the demonstrable fact that it is far from obvious to many people and businesses. Buying up cousin domains remains an active line of effort for (some) companies. Consequently, the requirement here is to explain why it isn't scalable, rather than to simple assert the fact. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & PLanning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
On 2/25/2021 8:41 AM, Kurt Andersen (b) wrote: Especially in the case of the PSD policies, one should not expect that the controlling organization would necessarily be "a mail-originating organization". Generally the idea is to *disavow* being such :-) Suggested alternate text: Domain-based Message Authentication, Reporting, and Conformance (DMARC) permits a domain-controlling organization to express domain-level policies and preferences for message validation, disposition, and reporting, which a mail-receiving organization can use to improve mail handling. +1 d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
ins, thereby indicating that they are PSDs, below which organizational domains can be registered. Suppose further that there exists a legitimate domain called "tax.gov.example", registered within ".gov.example". NEW This DMARC record provides policy and a reporting destination for mail sent from @gov.example. Similarly, "tax.gov.example" will have a DMARC record that specifies policy for mail sent from addresses @tax.gov.example. However, due to DMARC's current method of discovering and applying policy at the organizational domain level, the non-existent organizational domain of @t4x.gov.example does not and cannot fall under a DMARC policy. darn. couldn't find anything to suggest changing for this one... d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
On 2/22/2021 7:49 AM, Douglas Foster wrote: So what is the best nomenclature for referring to the "ICANN-authorized registries"? Dave's phrase or something else? Strictly speaking co.uk is not ICAN-authorized. It's authorized by mechanisms internal to the UK. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
Actually that's a community that I would expect to know exactly what all those terms mean and how they are all related. yes. But it's worse than that. The current language is not automatically clear even for folk with good knowledge about DNS administration. As is being noted, I too think a great deal of the problem is over-reliance on the word register. It is being used as if it explains a basic difference in administrative roles. It doesn't. Not even close. To work with the example you gave here, I agree that "facebook.com" is registered (under "com"), but disagree that "www.facebook.com" is registered at all; Right, of course it's not. I disagree. Strongly. The fact that one registration is internal and another is through a third-party, semi-regulated service does not make a difference, for the use of that word. I work with an organization that has an IT department that is just as formal typical ICANN-authorized registries. To get a sub-domain is a Very Big Deal. Don't think for a moment that it is fundamentally different than interacting with the TLD registeries. I didn't say that it is: I said that people who don't fully understand this stuff *think* it is, and that's the part that the text isn't making clear. To my mind, "register" involves a specific transaction, sometimes involving money, with whoever gates access to make those delegations. How much do you pay to register to vote? However the rest of the above statement is correct. A transaction to record gain access to a resource or to reserve access to it. Registration is a process of signing up. That's all. And it says nothing about the role or relationship of the entity the registration is with. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
On 2/18/2021 9:10 AM, Murray S. Kucherawy wrote: Circling back to this: On Fri, Jan 29, 2021 at 12:56 PM Dave Crocker <mailto:dcroc...@gmail.com>> wrote: On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote: On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker mailto:dcroc...@gmail.com>> wrote: organization can use to improve mail handling. The design of DMARC presumes that domain names represent either nodes in the tree below which registrations occur, or nodes where registrations have DMARC does not have 'registrations'. ... I'm struggling to understand the concern here. I think we all know what it means to register a domain, and that the namespace is arranged as a tree, With the intent of building upon Barry's note: Specification writing requires clarity of who the reader is and empathy with the experience they will have reading the document. In that context "we all know" is automatically a red flag for requiring overly insider expertise. However in this case, I think the problem is worse. Simply put, I believe the text does not say what it means to distinguish, even for an expert reader. So, yes, we all know what you say we know. But in fact that's not the point of the text. It's trying to make some other point, I assume it's about a type of boundary status, but it doesn't say that, nevermind saying it clearly and with enough technical and semantic detail to distinguish it. The text you offer: Maybe this is better, just for the sake of having something else to look at? DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. The design of DMARC presumes that domain names represent nodes in the DNS tree that are either reserved as points below which new domain name registrations are made, or are the results of those registrations; it does not permit a node to have both of these properties simultaneously. Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy for these domains as well. moves closer to the mark, I think, but still doesn't get there. EVERY node can have sub-nodes registered. So it isn't clear what 'reserved' means. Worse is that: reserved as points below which new domain name registrations are made, or are the results of those registrations; it does not permit a node to have both of these properties simultaneously. doesn't make sense to me. I suspect an average technical reader will be at least as confused as I am. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #1 - SPF alignment
On 2/10/2021 3:24 PM, Douglas Foster wrote: Huh? Are you asserting that SPF MAILFROM and SPF HELO are interchangeable? They are not, but they can work together. Perhaps I misread, but I thought I saw that this really is out of scope for this working group. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #1 - SPF alignment
On 2/6/2021 3:57 PM, Kurt Andersen (b) wrote: +1 - now, if only we had a real voting system :-P Yeah, 'cause this one is really close, and it's hard to tell what the decision is... d/ ps. +1 -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem
On 2/2/2021 9:19 AM, Alessandro Vesely wrote: On Tue 02/Feb/2021 02:42:25 +0100 Dave Crocker wrote: On 2/1/2021 5:38 PM, John R Levine wrote: If we want to document existing practice, I guess we would say that reports should be authenticated and aligned if practical, but it's OK to send them if not. exactly. I changed it again, for failure reports, like so: 3.3. Transport Email streams carrying DMARC failure reports SHOULD conform to the DMARC mechanism, thereby resulting in an aligned "pass". This "conform to" seems odd wording; it's not immediately obvious what it means here. Perhaps: SHOULD provide DMARC-based authentication, to produce their own aligned "pass" requirement is a MUST in case the sending host has a DMARC record 'sending host' is ambiguous in this context. featuring a ruf= tag. Indeed, special care must be taken of authentication in that case, as failure to authenticate failure reports may result in mail loops. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem
On 2/1/2021 6:33 PM, Michael Thomas wrote: On 2/1/21 6:24 PM, Dave Crocker wrote: DMARC has been deployed for 6 or 7 years. Where is this onerous abuse on reporting that you feel is inevitable? Email was around for 20 years until spam became a problem. Perhaps you missed the difference in scale between all of the last 5-7 years versus pretty much all of that 20 years? In other words, just to keep this simple: They not in the least comparable. Also, cf, my previous reference to incentives. We know how this plays out: bad guys do the least amount of work possible until they have to react. When it becomes a barrier as p=reject does, they take action to protect their turf. Plugging an obvious security hole with a well known and trivial set of authentication mechanisms to prevent forgery should be the default posture. Anybody who is against that needs to explain in depth why it should not be the case. Especially since it's part of DMARC now. Mike, security related specs thumbing their nose at security is a very peculiar stance. Mechanical application of a high-level script, without attending to the details that make the script actually work in a specific case, tends to lead to counter-productive decisions. cf my earlier reference to barriers to entry and lack of damaging effect. And flamboyant, aggressively hostile language like 'thumbing their nose' is not merely wrong, it is another attempt at gaslighting. cf my earlier reference to hostile work environment. sigh. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem
On 2/1/2021 6:13 PM, Michael Thomas wrote: Because we all know how well unauthenticated data worked out for email. I fail to see why anybody would be in favor of digesting unauthenticated data when the method of authenticating it is trivial and well known. It's an extraordinary claim that needs to be backed up. But you don't need to convince me; you need to convince the security AD's and cross area reviewers. DMARC has been deployed for 6 or 7 years. Where is this onerous abuse on reporting that you feel is inevitable? I suspect you've assumed the incentives for sending problematic reports are the same as the incentives for abuse of generic mail, while they are likely quite different. And no, it isn't trivial at all. Setting this stuff up properly takes skill and effort, which means it's expensive. And often is fragile. Hence the need to attend thoughtfully to pragmatics. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem
On 2/1/2021 5:58 PM, Michael Thomas wrote: This, on the other hand, should be measurable. Saying that we should ignore authentication requirements should require extraordinary proof that it is needed for practical as well as security reasons. The burden of proof is on the nay-sayers, especially since it is so trivial to implement these days. Or perhaps: 1. Barrier to adoption, for something that supposedly needs a lot more adoption 2. Doesn't seem to make much difference. I'd class those as suggesting rather strongly that the burden is on those that want to impose the barrier, rather than those who don't. The problem with arbitrarily claiming a requirement, without justify it carefully and in a balanced matter is that it is, well, arbitrary. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem
On 2/1/2021 5:38 PM, John R Levine wrote: So I would say that from my small sample, a lot of people have figured out how to send aligned reports, and, to be thorough, some/alot have not. either by using their regular signing engines or with an SPF record for the host that sends the reports. On the other hand, for reasons we've discussed that are evident to anyone familiar with DMARC, there's little reason to worry about fake reports, and authentication doesn't help even if there were. exactly. If we want to document existing practice, I guess we would say that reports should be authenticated and aligned if practical, but it's OK to send them if not. exactly. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On 2/1/2021 4:41 PM, Michael Thomas wrote: we're supposed to balance purported security considerations with pragmatic, real-world operational limits. cost/benefit. not an unusual concept. We have no means of evaluating what you're complaining about. It's a Chimera, and a long tailed one at that. You're probably right. Far better to offer requirements as absolutes, unanchored by practical concerns. Except that cost/benefit isn't an illusion or fabrication, but is a common practice, so attempting to claim it is otherwise is gaslighting. And gaslighting is a method that creates a hostile work environment. It's a shame the working group management hasn't put serious effort into curbing such behavior. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On 2/1/2021 4:12 PM, Michael Thomas wrote: So we're supposed to ignore security considerations because... some companies are a mess? we're supposed to balance purported security considerations with pragmatic, real-world operational limits. cost/benefit. not an unusual concept. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On 2/1/2021 3:49 PM, Michael Thomas wrote: It strains credulity that one part of a company would want to send out reports when some other can't even sign their email. Both need access to the email stream for starters. No it doesn't. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On 2/1/2021 3:21 PM, John Levine wrote: I find it hard to believe that if you are going to enough effort to maintain the data to create and send reports, you can't figure out how to install an SPF record for your reporting domain. Except that the tracking/reporting functions are completely separate from the 'signing' side of DMARC and could easily be different parts of a company. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On 2/1/2021 10:25 AM, Michael Thomas wrote: On 2/1/21 10:13 AM, Dave Crocker wrote: The model that a receiving site is not allowed to report DMARC traffic unless that site is also generating DMARC authentication is Procrustean. And as I noted, is likely counter-productive. There is no such thing as "DMARC authentication". Actually, there is. DMARC's requirement for alignment with the author's From: field domain name asserts a specific bit of authenticated semantics that does not exist elsewhere. The paragraph quoted is poorly written and should be rewritten to say that the report should pass either SPF or DKIM authentication as I wrote in issue #98. It might be written better, but its requirement is for support of applying DMARC to generated reports. That's more than just requiring SPF or DKIM. This is separate from not asserting the requirement at all, of course. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On 2/1/2021 10:15 AM, Michael Thomas wrote: On 2/1/21 9:25 AM, Dave Crocker wrote: So, it's probably a good thing I emphasized: "It should take a very, very substantial record of reporting problems to justify such a barrier." Meanwhile in 2021, the internet is a dangerous place where the default posture is to assume that if something can be gamed it will be gamed. Perhaps you'd put that comment into both a cost/benefit tradeoff consideration and in technical and operational terms that reflects practical limits? d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On 2/1/2021 10:08 AM, Alessandro Vesely wrote: On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote: Consider the challenges to ensuring a DMARC pass. That's a pretty high barrier to entry against generating reports. Well, if a mail site is unable to get a DMARC pass, they have more urgent problems to solve than setting up aggregate report generation. No, they probably don't have more urgent problems. Sites choose not to adopt DMARC for a variety of reasons. It's probably a good idea to respect that variety. The model that a receiving site is not allowed to report DMARC traffic unless that site is also generating DMARC authentication is Procrustean. And as I noted, is likely counter-productive. I understand the zeal that drives a lot of the effort to promote DMARC, but the danger with aggressive proselytizing is that it changes from serious technical and operational evaluation into purely religious fervor. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On 2/1/2021 9:12 AM, Michael Thomas wrote: On 2/1/21 8:38 AM, Dave Crocker wrote: Mostly this will discourage reporting. Legitimate reporting. Versus illegitimate ones you'd assumedly want to ignore. So, it's probably a good thing I emphasized: "It should take a very, very substantial record of reporting problems to justify such a barrier." d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On 1/27/2021 7:17 PM, Steven M Jones wrote: 3.3. Transport Email streams carrying DMARC failure reports MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass". 1. I haven't been tracking discussion closely. So if this is something already sufficiently well-discussed and understood and still landed on the above normative text, I'll apologize for re-raising. 2. But not really, because it strikes me as a serious operational mistake, though a well-motivated one. Mostly this will discourage reporting. Legitimate reporting. Consider the challenges to ensuring a DMARC pass. That's a pretty high barrier to entry against generating reports. It should take a very, very substantial record of reporting problems to justify such a barrier. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: I-D Action: draft-ietf-dmarc-psd-10.txt
On 1/29/2021 12:15 PM, Murray S. Kucherawy wrote: On Fri, Jan 29, 2021 at 7:51 AM Dave Crocker <mailto:dcroc...@gmail.com>> wrote: Abstract DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. The design of DMARC presumes that domain names represent either nodes in the tree below which registrations occur, or nodes where registrations have DMARC does not have 'registrations'. It's referring to domain name registrations, not DMARC registrations. Also the occur/occured contrast has no obvious meaning to me. Really, I have no idea what's intended by it. "exist"? "take place"? "are made"? "are done"? The issue wasn't synonyms but semantics. 'registrations occurred' has no obvious DMARC meaning. unless, perhaps, the meaning is 'domain names exist', but that still doesn't explain the contrast being drawn. occurred; it does not permit a domain name to have both of these "both" of what? registration? It's describing properties of nodes in the domain name tree. DMARC's current design stipulates that every node is either (a) a node below which registrations can occur, or (b) a node at which a registration has occurred. An example of the former is "org", and an example of the latter is "ietf.org <http://ietf.org>" and its entire subtree. DMARC does not have 'registrations'. The word in used in the spec as: " 3 <https://tools.ietf.org/html/rfc7489#section-3>. Terminology and Definitions Domain Owner: An entity or organization that owns a DNS domain. The term "owns" here indicates that the entity or organization being referenced holds the registration of that DNS domain." and: " 3.2 <https://tools.ietf.org/html/rfc7489#section-3.2>. Organizational Domain The Organizational Domain is determined using the following algorithm: 1. Acquire a "public suffix" list, i.e., a list of DNS domain names reserved for registrations. " (The later reference to the Tag Registry is presumably irrelevant here.) properties simultaneously. Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy for these domains as well. Which domains? The intent is to augment DMARC's ability to describe the domain name tree such that a node can be both (a) and (b) at the same time, for the purposes of policy expression. So those are the nodes (domains) of interest. My frustration is that a document that reaches wg Last Call should not have language that is this confusing, especially about its fundamentals and especially given how much revision it has already gotten. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
