Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
In article you write: >-=-=-=-=-=- >But are your really arguing that no one in the Mailing List business paid >attention to > the concerns about the fraud and spoofing problems with email? I am unaware of any mailing lists causing fraud and spoofing problems in email, so no more than anyone else. (Sending along real mail in ways that DMARC cannot describe is neither fraud nor spoofing, of course.) >This morning I had a conversation with the CEO of a company that was hit by >ransomware which arrived with the help of a >single email. He is slowly getting his company back after paying a lot of >money to people who want to destroy us. I think you would be dismayed how little of that would be stopped by more stringent DMARC policies. They use lookalike addresses, or they depend on MUAs that show the From header comments rather than the addresses. I once saw a very slick spear phish where the crook registered the victim's domain name subsituting "rn" for "m". R's, John PS: >My comments about From validation were based on the wording of the RFCs, so I >stand by what I said. I hope you will forgive me if I do not accept your interpretation of RFCs that I wrote. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On 8/15/2020 3:33 PM, Douglas E. Foster wrote: Consequently, the real problem before us becomes the existence of users who are unhappy because the From address on some mail does not meet their preferences. I have to ask why that is a problem worthy of a standards body? Who, exactly, do you think these services are /for/? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
My comments about From validation were based on the wording of the RFCs, so I stand by what I said. But are your really arguing that no one in the Mailing List business paid attention to the concerns about the fraud and spoofing problems with email? This morning I had a conversation with the CEO of a company that was hit by ransomware which arrived with the help of a single email. He is slowly getting his company back after paying a lot of money to people who want to destroy us. That is the problem we should be worried about. And that is why I am letting my emotions show. This WG is playing the fiddle while Rome burns. Doug From: "John Levine" Sent: 8/15/20 6:53 PM To: dmarc@ietf.org Cc: fost...@bayviewphysicians.com Subject: Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field In article <6755d0cef49e465bbf2bd170dbdc6...@bayviewphysicians.com> you write: >Based on the discussions here, it appears that the notion of From address >validation was envisioned from the >beginning Sender Authentication discussions. We have written evidence that >Form address validation was >anticipated in the DKIM and ATPS RFCs prior to DMARC. Not really. DKIM was deliberately designed not to be tied to any visible part of the message. ADSP was a poorly designed hack that was never implemented other than small experiments, and that I don't think many people understood. I got a lot of grief for making the most strict policy "discardable" even though that's obviously what it was. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On 8/15/2020 3:59 PM, John R Levine wrote: On Sat, 15 Aug 2020, Dave Crocker wrote: My comment was not about your opinion of either of the drafts but of your impatience with considering one you don't like. Um, if one thinks something is a bad idea, why should we spend more time on it? Out of respect for others who might disagree with you and others who might not have formed their opinion yet. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On Sat, 15 Aug 2020, Dave Crocker wrote: On 8/15/2020 12:48 PM, John Levine wrote: Also, I'm sorry to hear that the wg isn't capable of discussing two drafts at the same time. I'm pretty sure that my opinions about -author and -sender would be the same even if they'd been published a year apart. John -- your response is oddly orthongonal to my comment. My comment was not about your opinion of either of the drafts but of your impatience with considering one you don't like. Um, if one thinks something is a bad idea, why should we spend more time on it? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
In article <6755d0cef49e465bbf2bd170dbdc6...@bayviewphysicians.com> you write: >Based on the discussions here, it appears that the notion of From address >validation was envisioned from the >beginning Sender Authentication discussions.We have written evidence that >Form address validation was >anticipated in the DKIM and ATPS RFCs prior to DMARC. Not really. DKIM was deliberately designed not to be tied to any visible part of the message. ADSP was a poorly designed hack that was never implemented other than small experiments, and that I don't think many people understood. I got a lot of grief for making the most strict policy "discardable" even though that's obviously what it was. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
Based on the discussions here, it appears that the notion of From address validation was envisioned from the beginning Sender Authentication discussions. We have written evidence that Form address validation was anticipated in the DKIM and ATPS RFCs prior to DMARC.So we have more than a decade of warnings that From address validation was coming. While not everybody has time to read every RFC, the Mailing List trade press must have should have been reporting on it as something to watch. Even after DMARC was in use, it appears that nobody in the mailing list community felt inconvenienced until the AOL/Yahoo hack and their decision to implement DMARC with p=reject. This was the moment of Unhappy Surprise. Bad guys had obtained many valid email addresses, so one of the concerns was how to prevent them from spoofing those users to send spam. They could not use those address in the SMTP address because of SPF, but only DMARC could prevent those addresses from being misused in the Message From address. It was the obvious thing to do and it would have been reckless for them to do otherwise. Can you at least admit that the mailing list community was surprised because they failed to prepare for this contingency? But that moment is now in the rear view mirror.Mailing lists can get delivery to all subscribers by confirming to the requirements of the DMARC-participating domains, by using their own domain in the From address, at least for those domains.I assume that there are still mailing list operation that are not unable to comply with DMARC-participant expectations, because they have failed to upgrade. But an individual organization’s failure to adapt is not a problem worthy of a standards body. I liked XP just fine and hated Vista, like Windows7 OK but hated Windows 8. But Microsoft killed support for XP and Windows 7 and my organization is adapting.Life is unfair. COVID-19 is unfair and has caused a lot of problems. Every organization has problems, and we all have jobs so that we can help solve them. The time to cry in your beer is over. Mailing lists have a interoperability solution, and they should use it whether they like it or not, because that is what is necessary to get their mail delivered according to the requirements of the recipient organization.As a result, mailing list operators really have no standing in this discussion, although they can certainly speak as unhappy individual users and on behalf of their unhappy users. Consequently, the real problem before us becomes the existence of users who are unhappy because the From address on some mail does not meet their preferences. I have to ask why that is a problem worthy of a standards body? I have about 8 different scenarios in my head where a user might be have unmet expectations with the format of the From address, or might experience mailing list deliverability problems because of the email filtering policy of its domain relative to the addressing practices of his mailing list. If our requirement is to make every user happy, shall we head down the path of all 8 problems, not just this one? This project was supposed to discuss moving DMARC from informational to standards track. It has been hijacked by those who, to paraphrase Shakespeare, “have not come to praise DMARC, but to bury it.” This has been abetted by the chair’s assertion that we must square a circle – meet the MLs requirement for them to impersonate without authorization while continuing to advance the DMARC requirement to prohibit impersonation without authorization. As part of that hijacking, we have been inundated by Mr. Crocker’s assertions that the message From Address does not matter. All the years of theoretical analysis that preceded DMARC and all of the operational success from implementations of DMARC are just wrong, simply because he says so. Worse yet, he asserts without justification that the message From address should be unimportant to everybody except mailing list subscribers, for the simple reason that the Message From is so very important to his Mailing List subscribers. It is comparable to asserting that the earth is flat, for everyone except astronauts.This is sheer nonsense. More importantly, this discussion has failed to address the actual objective, which is to solve the asserted Mailing List problem as it relates to AOL/Yahoo/Verizon. That enterprise does not seem to be involved in this process, and no one has offered reason why they will be swayed by anything said here.The strategy seems to be that if we tell these people how stupid they are, that they will do whatever we tell them they must do, even if the solution is to weaken security for everyone on the Internet.That is not a winning strategy. DMARC has been mandated by at least three national governments,, by a variety of businesses, and by this one
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
If DMARC wasn't experimental, maybe I could see adding it separately, but this seems like a fairly fundamental change and shouldn't just be a bolt-on Without suggesting a preference, it's worth considering nature/implication: 1. Separate DMARCbis is likely to be small changes on the existing spec and incorporation of something like my draft's changes could a) destablilize the effort, and b) make the bis effort take significantly longer. Also, my proposal is a lot more fragile than the base DMARC spec, both in terms of possible technical issue and possible operational issues. 2. Integrated Merging them makes it more likely that the result really is integrated and seamless. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On 8/15/2020 12:48 PM, John Levine wrote: Also, I'm sorry to hear that the wg isn't capable of discussing two drafts at the same time. I'm pretty sure that my opinions about -author and -sender would be the same even if they'd been published a year apart. John -- your response is oddly orthongonal to my comment. My comment was not about your opinion of either of the drafts but of your impatience with considering one you don't like. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
Completely agree. Please consider the environment before reading this message. John Levine, jo...@taugh.com > On Aug 15, 2020, at 14:12, Dave Crocker wrote: > > On 8/15/2020 3:32 AM, Alessandro Vesely wrote: >> If X pretends to be Y, > > > If I put my gmail address into the from field, there is no pretending, no > matter what platform I am using. > > This continuing practice of characterizing valid use as if it were spoofing > or pretending has been a major impediment to constructive discussion in the > industry. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
In article <603b1699-6a99-0fc3-3fc8-a037126a7...@dcrocker.net> you write: >Also, I'm sorry to hear that the wg isn't capable of discussing two >drafts at the same time. I'm pretty sure that my opinions about -author and -sender would be the same even if they'd been published a year apart. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
In article you write: >The premise that MLMs have actually been long-tolerated abusers is a flawed >one, in my opinion. I actually used to think the same thing back in the >RFC 4871 era, but I no longer agree. The same thing happens over and over. Someone invents a mail authentication scheme which works for a lot of mail, but not all mail. Then they roll it out, and its enthusiasts blame the victim as they try to redefine the mail that it doesn't handle as "spoofed" or otherwise illegimate. This happened with SPF, and it's sure happening again with DMARC. Can't wait to see what the next magic bullet aimed at our foot is. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On 8/15/2020 3:32 AM, Alessandro Vesely wrote: If X pretends to be Y, If I put my gmail address into the from field, there is no pretending, no matter what platform I am using. This continuing practice of characterizing valid use as if it were spoofing or pretending has been a major impediment to constructive discussion in the industry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On 8/12/2020 1:09 PM, John Levine wrote: Let's work on your Sender draft which doesn't try to change what MUAs display. and which won't fully fix the user-level problems, because... legacy DMARC. Also, I'm sorry to hear that the wg isn't capable of discussing two drafts at the same time. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On 8/13/2020 2:38 PM, Kurt Andersen (b) wrote: Passing DMARC is not a be-all-end-all. That's what local policy is for. I fail to see why local policy would not solve your problem (as described). We tend to use the term 'local policy' to refer to exceptional behavior. (I'm not suggesting you were, but am using your reference to it as an excuse to make this small rant.) Receiving filtering engines do whatever they want. Always. Always have. No outside agency or actor or standard affects that fact at all. Rather, outside agencies, actors, and standards merely provide input to that filtering engine. "Local policy" is always and entirely in charge of what happens locally. Everything else is subservient. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
Steve, et al, On 8/12/2020 8:16 AM, Steve Atkins wrote: On 12/08/2020 04:32, Dave Crocker wrote: Here's why I think it won't: They already have From:. The real value in DMARC is not what is displayed to the end-user but in having a required field that cites the originating domain name. That doesn't change if there are additional fields that might or might not mention the originating domain. I think we disagree on the goal of DMARC. The entire point of DMARC is brand protection. Yes, but... High-level goals are fine. But then they meet lower-level technical and operational pragmatics. For its originally-intended use, DMARC linked high and low pretty well. The expanded use doesn't and essentially was adopted more to do with stemming a denial of service attack. Control over what is displayed to the user, I'm confused. I thought this was a technical forum, not a marketing forum. User's typically don't see the email address and typically it won't matter if they do. And this has been pointed out repeatedly. So while, yes, these have driven many people's thinking, that thinking isn't based on empirical realities. In this forum, we should not have to constantly be reminded that, in actual practice, none of these activities involve direct user behavior. Operationally, they are only relevant to the receiving filtering engine. To the extent someone wants to claim otherwise, they should produce empirical evidence, not summaries of marketing views. (And this request also should not need this constant repetition.) not what's in any particular header. You could use it for other things, but that's what informed publishers of DMARC say they're using it for (sometimes phrased as "protection against phishing" but that too is all about what's displayed to the recipient). No doubt. But, really, there is no closed-loop mechanism to validate that it is achieving what they think it is for, namely getting users to make fewer bad decisions about their mail content. Certainly unauthorized use of a domain name in the From: field /correlates/ positively and perfectly with an assessment of spam, but it correlates negatively and perfectly with authorized uses, such as mailing lists. So in statistical terms, folk using DMARC see utility, but that's as a detector of some spam, and not other spam. And they are dismissive of the negatives, because it doesn't affect /them/. The tone that seems to permeate here is that we need to prevent any new identity -- addressing -- fields because bad actors will abuse them. What this misses is whether that abuse matters. I realize that it bothers us to see such abuse, but whether the abuse matters ought to be relevant. If you display the contents of Author to the user, then DMARC publishers will want to control that. So we need to cater to folk who want to do things that have no empirical validity? Seems a poor basis for technical work. The reason the Author: field is being proposed is to regain author-to-recipient MUA-level utility. Also there's the small matter of anticipating strategic behavior of operators without actually knowing that the anticipation is correct and having no history of such behavior other than a single, problematic data point. As I recall, DMARC uptake is a small percentage of the industry. That makes invocation of a predicted industry behavior also problematic. If MUAs will display the contents of the Author: header where the From: header is now then draft-crocker-dmarc-author-00 effectively moves what used to be Sender: header to the From: header and what used to be the From: header to the Author: header. As I keep noting, that is what DMARC has already done. It breaks basic, author-related utility of the From: field for MUA use. That should matter. And the -sender- proposal can't fix that. (see below) You could achieve exactly the same result, with much less deployment effort, by updating DMARC to enforce the Sender header and leaving MUAs displaying the From: header. That wouldn't be acceptable to anyone who wants to publish DMARC, so the Author: proposal won't be either. It would be nice for that to be as effective as folk want to believe, but it can't. 1. Sender is an optional field. DMARC needs something that is always present. That's really why there was no choice other than From:, for its original design. 2. DMARC has an installed base and the 'legacy' receiving engines need to be able to operate with DMARC without having to convert ot use of the Sender: field. I tried to find a way to make this work and failed, which is why the current -sender- draft works in parallel to the From: field, rather than taking precedence over it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Sat, Aug 15, 2020 at 3:32 AM Alessandro Vesely wrote: > The workarounds we have on the table, to standardize From: rewriting > possibly copying the original From: value to some other field > (Author:, To:, Reply-To:), to verify DKIM modulo transformations, and > to accept a tunable set of Sender:'s do have the potential to smooth > enough harshness and thereby avoid that cans which invalidate > themselves mess up the store and ruin nearby products, don't they? > They are all worthy of consideration, to be sure. But that's not the thing to which I was objecting. The premise that MLMs have actually been long-tolerated abusers is a flawed one, in my opinion. I actually used to think the same thing back in the RFC 4871 era, but I no longer agree. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Sat 15/Aug/2020 11:02:06 +0200 Murray S. Kucherawy wrote: On Sat, Aug 15, 2020 at 12:47 AM Alessandro Vesely wrote: [...] Syllogism goes like so: Mailing list must not accept strict DMARC policies, humans may happen to use mailing lists, therefore email domains which hosts mailboxes used by humans must not publish strict DMARC policies. Is that really what we seek? I hope not. It is our current reality, and in my humble opinion, we've nobody to blame but ourselves. The workarounds we have on the table, to standardize From: rewriting possibly copying the original From: value to some other field (Author:, To:, Reply-To:), to verify DKIM modulo transformations, and to accept a tunable set of Sender:'s do have the potential to smooth enough harshness and thereby avoid that cans which invalidate themselves mess up the store and ruin nearby products, don't they? The first one of them has already proved its effectiveness. If X pretends to be Y, it must do so in a verifiable, uncloakable way. How processes which rely on the cloak can still believe it has to be worked out case by case. The more alternatives we provide, the more likely one of them can suit a given case. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
Emphatically hatless: On Sat, Aug 15, 2020 at 12:47 AM Alessandro Vesely wrote: > >> Lists have been around a lot longer than DMARC has. > > That doesn't grant lists any extra right. Others consider current > global usage as a priority gauge. > This line of thinking has bothered me for a long time. Imagine you're a large soft drink manufacturer. Your delicious, popular product is sold in grocery stores the world over, sometimes directly from your production line, sometimes via a local reseller. Your sales team does one or the other depending on the use case. Business has been good for a generation or two. One day you decide you don't like resellers anymore because some of them mis-promote your product, so you somehow arrange that the cans in the stores that passed through resellers suddenly and randomly begin invalidating themselves by bursting, making a mess of the store and soaking customers. Other products nearby are also ruined. This reflects poorly on the resellers, some of whom are forced to stop doing business with you. Stores get angry and are forced to reconsider doing business with you as well, but you're big and popular and so many of them have to deal with your mess on an ongoing basis. Many customers take their business elsewhere; the stores suffer. The argument here appears to be that is that this is justified, because the ecosystem of manufacturers, grocery stores, resellers, and customers that has existed for as long as you can remember has no right to operate that way if you suddenly decide you don't want it to; it's your brand, and your word about your brand is final irrespective of how you choose to enforce it. You're suddenly, for reasons you feel are legitimate, asserting that the ecosystem was broken to begin with despite the fact that you've been a willing participant for decades, and therefore you are at liberty to disrupt it (though, admittedly, you may have been unaware of the blast radius of doing so). Now, you may be right that the ecosystem was built on the incorrect premise that domain names don't need to be treated as sacrosanct. (Let's ignore for the moment the stuff about hindsight.) But that assertion clearly differs from the well-established foundation upon which a great deal rests today. It is far from trivial to change that now. It's possible to do, to be sure, but dropping it into the world overnight has a hugely disruptive impact. Such a change needs to be an evolution, with the cooperation and collaboration of a preponderance of the participants, not a philosophical light switch you get to throw and expect everyone else to conform. I don't want any more soda on me. Why people's mailboxes must be spoofable? > I don't know about "must", but changing the fundamental assumption that it's acceptable in some cases for X to pretend to be Y (which is what MLMs do), at X's discretion, is a tectonic change that should have been rolled out with more community collaboration and grace than it was. I think we need to be more considerate of that fact if there is to be progress. Syllogism goes like so: Mailing list must not accept strict DMARC > policies, humans may happen to use mailing lists, therefore email > domains which hosts mailboxes used by humans must not publish strict > DMARC policies. Is that really what we seek? I hope not. > It is our current reality, and in my humble opinion, we've nobody to blame but ourselves. -MSK, participating. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On Fri 14/Aug/2020 21:08:56 +0200 Jim Fenton wrote: If the Sender header field is to be used by DMARC in the manner described in this draft, it should be an integral part of the DMARCbis specification rather than a separate extension to it. In other words, this should be an issue on the DMARC WG issue tracker rather than a working group draft (and presumably eventual RFC). There are enough different combinations of originators and receivers that might use Sender (which the chart in Section 2 begins to describe) that we don't need the ongoing ambiguity of whether the receiver does or does not implement this as an extension. 100% agreed. However, since I haven't yet understood how exactly the spec is going to be split among various I-Ds, I voted for adoption in order to boost discussion. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field
On 2020-08-14 7:04 p.m., Dotzero wrote: On Fri, Aug 14, 2020 at 12:42 PM John Levine wrote: In article you write: [...] This is why I made the point above that lists should respect DMARC policy and not accept submissions from domains with DMARC p=reject policies. Lists have been around a lot longer than DMARC has. That doesn't grant lists any extra right. Others consider current global usage as a priority gauge. Perhaps you meant to say that domains whose users participate in mailing lists should not publish restrictive DMARC policies. If they don't want their users to send mail to lists, they should tell their users not to send mail to lists. Should they file lawsuits against online infringers? I meant what I wrote. Domains who actively want their users to participate in mailing lists or even passively accept that their users participate in mailing lists shouldn't publish p=reject for the domain their users are sending from or should take steps to migrate the users to another domain/subdomain, etc. Why people's mailboxes must be spoofable? Syllogism goes like so: Mailing list must not accept strict DMARC policies, humans may happen to use mailing lists, therefore email domains which hosts mailboxes used by humans must not publish strict DMARC policies. Is that really what we seek? I hope not. This is not the mailcore WG where they have to bring to full standard a time-honored paper. We're talking about a protocol that is gaining adoption slowly as it has some troubles. It's going to be Proposed Standard anyway. Fixes may go as far as introducing Sender:. In such a scenario, why should we stick to the restricted p=none except transactional? Conversely, if a domain IS publishing p=reject then yes, they should be taking steps internally but I also believe others should consider that domain's published policy as intentional and act accordingly. I've never heard of a DMARC policy getting published due to inaction. Someone with administrative rights actively published that policy. Possibly, that policy was pushed for security reasons. We may say they don't know what they're doing. They may say the same of us. If DMARC cannot secure people's mailboxes, perhaps we should invent a different protocol. It may still be based on SPF and DKIM authentication. And still be called DMARC, no? There are lots of organizations that actively want their employees to participate in the IETF, to the extent that they give them paid time for IETF activities, yet publish p=reject policies to cripple that participation. I wish they would make up their minds. Me too. We could make up our minds as well... Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
