Re: [dmarc-ietf] DMARC marketing on NPR
On Thu, Nov 23, 2023 at 9:19 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The gap between what is being attempted and what is needed is a huge > personal disappointment. > You have made your disappointment plain more times than I can remember. It's on the record each of those times that the working group has noted and considered that position. There's no need to continue repeating yourself. In fact, I would submit that this repetition is beginning to look a lot like a denial of service attack on the working group. Please desist. I would prefer that the chairs not be forced into the position of having to invoke BCP 94 just to complete its chartered work. At this point, I'd have to say that I would support such an action without them even asking. The DMARC goal should be to block malicious impersonation without blocking > wanted messages, where "wanted" is in the eyes of the evaluator and his end > user.That puts the onus on the evaluator. RFC 7960 said that > evaluators need to be aware of problems, but gave no solutions. DMARCbis > replaces the evaluator with a mindless automaton, repeating all the worst > mistakes of RFC 7489. > DMARC aims to solve a problem at least one layer lower than where you seem to be fixed in your thinking. I don't know how to resolve such a stalemate. DMARC is not going to up-level itself (it was specifically chartered to deal with the layer where it lives only, and nothing more, for very good reasons) and you appear steadfast about the layer where you want solutions to appear. You and the WG are talking past each other, consuming precious resources. I would like to see this corrected. There is at least one other person monitoring this WG that would like to see a broader email authentication effort started. You might try finding that person and adding your energy to his to see if something comes of it. > This is from a real-world conversation with a product support tech: >Me: I cannot use your DMARC implementation because it does not have an > exception mechanism. >Him: Why would you need exceptions? > I blame his ignorance, and his product's inadequacies, on RFC 7489, which > defined no exceptions. > How likely do you believe it is that the support tech you spoke to has an understanding of the protocol intricacies involved here? Or has read RFC 7489 in its entirety? Or is aware of its status? Or knows what an RFC is? I suspect that person's source (if there is one) is elsewhere. We need a document that is targeted at evaluators, to help them make > correct disposition decisions for their organizations. The current > document blames the charter as the reason that it does not even try. > ...which is the right thing for it to do. If this working group were to put forward a DMARCbis that either exceeds or falls short of its charter, it is unlikely to get approval for publication. You have already made it abundantly clear that you feel the charter cripples the working group from producing what you think the community needs. You have generated two drafts that appear to advance practices or information you feel are more appropriate. It does not appear that the working group concurs with these positions. Adding continued sound and fury seems to me to be unlikely to change this result and has the semblance of being non-constructive. -MSK, ART Area Director ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC marketing on NPR
Please move on from this thread, it’s done now. Seth, as Chair -mobile On Fri, Nov 24, 2023 at 09:53 Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The real evidence of failure is the assumption, built into this document, > that allowing mailing list paticipation is as easy as changing your policy > to None. > > We expect evaluators to treat Fail with None the same as Pass. This says > that a lot of malice is also being treated the same as Pass. > > If our assignment is to inhibit malice, then we have built a solution on > the assumption of widespread failure to accomplish that purpose. We > should not be so negligent. > > If AOL and related brands were the only ones rejecting list messages, we > would have an AOL grievance, although they would be in their rights to do > as they pleased. But we have a mailing list (and ESP) problem because > other organizations honor the AOL reject policy unconditionally, against > the wishes of their users when list messages are affected. This is > defective evaluators behavior. > > Doug > > > On Fri, Nov 24, 2023, 9:35 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> If this implied solution was working, we would not have a mailing list >> problem 10 years running. >> >> >> >> On Thu, Nov 23, 2023, 10:41 AM Dotzero wrote: >> >>> >>> >>> On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster < >>> dougfoster.emailstanda...@gmail.com> wrote: >>> The gap between what is being attempted and what is needed is a huge personal disappointment. The DMARC goal should be to block malicious impersonation without blocking wanted messages, where "wanted" is in the eyes of the evaluator and his end user.That puts the onus on the evaluator. RFC 7960 said that evaluators need to be aware of problems, but gave no solutions. DMARCbis replaces the evaluator with a mindless automaton, repeating all the worst mistakes of RFC 7489. This is from a real-world conversation with a product support tech: Me: I cannot use your DMARC implementation because it does not have an exception mechanism. Him: Why would you need exceptions? I blame his ignorance, and his product's inadequacies, on RFC 7489, which defined no exceptions. RFC 7489 falsely divides the mail stream into four groups: - Authenticated / Pass, - Unauthenticated without Prejudice (None), - Unauthenticated with Prejudice (Quarantine/Reject), and - No Result. In reality, there are only two possible states: Authenticated and Not Authenticated. - The Mailing List problem proves that the distinction between None and Reject is a fiction. At best, Fail with Reject justifies a slightly higher risk weight for environments that depend on weighting. - "No Result" is an error in RFC 7489.The PSL and default alignment rules allowed a result to be calculated on any domain. An evaluator cannot excuse a decision to allow malware infestation by saying, "the domain owner did not give me permission to check for malicious impersonation." "No Result" is another way of saying, "I did not do my job." - Any unauthenticated message is a potential impersonation. It is the evaluator's job to figure out whether malicious impersonation actually occurred or not. Authentication failure provides a starting point, not an end point. The risk of malicious impersonation applies to every unauthenticated message. Correct evaluation fixes the mailing list problem and fixes a lot of other false blocks, while blocking the malicious traffic that RFC 7489 leaves unmolested. We need a document that is targeted at evaluators, to help them make correct disposition decisions for their organizations. The current document blames the charter as the reason that it does not even try. Doug Foster >>> >>> You are absolutely incorrect when you state that there are no exceptions >>> provided. "Local policy" enables an evaluator to implement any >>> exception(s) they wish. >>> >>> Michael Hammer >>> >> ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC marketing on NPR
The real evidence of failure is the assumption, built into this document, that allowing mailing list paticipation is as easy as changing your policy to None. We expect evaluators to treat Fail with None the same as Pass. This says that a lot of malice is also being treated the same as Pass. If our assignment is to inhibit malice, then we have built a solution on the assumption of widespread failure to accomplish that purpose. We should not be so negligent. If AOL and related brands were the only ones rejecting list messages, we would have an AOL grievance, although they would be in their rights to do as they pleased. But we have a mailing list (and ESP) problem because other organizations honor the AOL reject policy unconditionally, against the wishes of their users when list messages are affected. This is defective evaluators behavior. Doug On Fri, Nov 24, 2023, 9:35 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > If this implied solution was working, we would not have a mailing list > problem 10 years running. > > > > On Thu, Nov 23, 2023, 10:41 AM Dotzero wrote: > >> >> >> On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster < >> dougfoster.emailstanda...@gmail.com> wrote: >> >>> The gap between what is being attempted and what is needed is a huge >>> personal disappointment. >>> >>> The DMARC goal should be to block malicious impersonation without >>> blocking wanted messages, where "wanted" is in the eyes of the evaluator >>> and his end user.That puts the onus on the evaluator. RFC 7960 said >>> that evaluators need to be aware of problems, but gave no solutions. >>> DMARCbis replaces the evaluator with a mindless automaton, repeating all >>> the worst mistakes of RFC 7489. >>> >>> This is from a real-world conversation with a product support tech: >>>Me: I cannot use your DMARC implementation because it does not have >>> an exception mechanism. >>>Him: Why would you need exceptions? >>> I blame his ignorance, and his product's inadequacies, on RFC 7489, >>> which defined no exceptions. >>> >>> RFC 7489 falsely divides the mail stream into four groups: >>> >>>- Authenticated / Pass, >>>- Unauthenticated without Prejudice (None), >>>- Unauthenticated with Prejudice (Quarantine/Reject), and >>>- No Result. >>> >>> In reality, there are only two possible states: Authenticated and Not >>> Authenticated. >>> >>>- The Mailing List problem proves that the distinction between None >>>and Reject is a fiction. At best, Fail with Reject justifies a slightly >>>higher risk weight for environments that depend on weighting. >>>- "No Result" is an error in RFC 7489.The PSL and default >>>alignment rules allowed a result to be calculated on any domain. An >>>evaluator cannot excuse a decision to allow malware infestation by >>> saying, >>>"the domain owner did not give me permission to check for malicious >>>impersonation." "No Result" is another way of saying, "I did not do my >>>job." >>>- Any unauthenticated message is a potential impersonation. It is >>>the evaluator's job to figure out whether malicious impersonation >>> actually >>>occurred or not. >>> >>> Authentication failure provides a starting point, not an end point. The >>> risk of malicious impersonation applies to every unauthenticated message. >>> >>> Correct evaluation fixes the mailing list problem and fixes a lot of >>> other false blocks, while blocking the malicious traffic that RFC 7489 >>> leaves unmolested. >>> >>> We need a document that is targeted at evaluators, to help them make >>> correct disposition decisions for their organizations. The current >>> document blames the charter as the reason that it does not even try. >>> >>> Doug Foster >>> >> >> You are absolutely incorrect when you state that there are no exceptions >> provided. "Local policy" enables an evaluator to implement any >> exception(s) they wish. >> >> Michael Hammer >> > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC marketing on NPR
If this implied solution was working, we would not have a mailing list problem 10 years running. On Thu, Nov 23, 2023, 10:41 AM Dotzero wrote: > > > On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> The gap between what is being attempted and what is needed is a huge >> personal disappointment. >> >> The DMARC goal should be to block malicious impersonation without >> blocking wanted messages, where "wanted" is in the eyes of the evaluator >> and his end user.That puts the onus on the evaluator. RFC 7960 said >> that evaluators need to be aware of problems, but gave no solutions. >> DMARCbis replaces the evaluator with a mindless automaton, repeating all >> the worst mistakes of RFC 7489. >> >> This is from a real-world conversation with a product support tech: >>Me: I cannot use your DMARC implementation because it does not have >> an exception mechanism. >>Him: Why would you need exceptions? >> I blame his ignorance, and his product's inadequacies, on RFC 7489, which >> defined no exceptions. >> >> RFC 7489 falsely divides the mail stream into four groups: >> >>- Authenticated / Pass, >>- Unauthenticated without Prejudice (None), >>- Unauthenticated with Prejudice (Quarantine/Reject), and >>- No Result. >> >> In reality, there are only two possible states: Authenticated and Not >> Authenticated. >> >>- The Mailing List problem proves that the distinction between None >>and Reject is a fiction. At best, Fail with Reject justifies a slightly >>higher risk weight for environments that depend on weighting. >>- "No Result" is an error in RFC 7489.The PSL and default >>alignment rules allowed a result to be calculated on any domain. An >>evaluator cannot excuse a decision to allow malware infestation by saying, >>"the domain owner did not give me permission to check for malicious >>impersonation." "No Result" is another way of saying, "I did not do my >>job." >>- Any unauthenticated message is a potential impersonation. It is >>the evaluator's job to figure out whether malicious impersonation actually >>occurred or not. >> >> Authentication failure provides a starting point, not an end point. The >> risk of malicious impersonation applies to every unauthenticated message. >> >> Correct evaluation fixes the mailing list problem and fixes a lot of >> other false blocks, while blocking the malicious traffic that RFC 7489 >> leaves unmolested. >> >> We need a document that is targeted at evaluators, to help them make >> correct disposition decisions for their organizations. The current >> document blames the charter as the reason that it does not even try. >> >> Doug Foster >> > > You are absolutely incorrect when you state that there are no exceptions > provided. "Local policy" enables an evaluator to implement any > exception(s) they wish. > > Michael Hammer > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC marketing on NPR
On Thu 23/Nov/2023 16:41:11 +0100 Dotzero wrote: On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster wrote: The gap between what is being attempted and what is needed is a huge personal disappointment. [...] This is from a real-world conversation with a product support tech: Me: I cannot use your DMARC implementation because it does not have an exception mechanism. Him: Why would you need exceptions? I blame his ignorance, and his product's inadequacies, on RFC 7489, which defined no exceptions. [...] You are absolutely incorrect when you state that there are no exceptions provided. "Local policy" enables an evaluator to implement any exception(s) they wish. I only quoted that snippet of Doug's post, because it's what triggered my understanding. The gap is between the spec and the implementation. It is true that local policy allows much leeway. Any implementation should have an option to just report results, leaving actions to downstream filters. Yet, it's easier to configure a filter to reject when appropriate. Of course, whitelisting is the key. (I think that's a better term than exceptions. And please let's accept it along with whitespace, black friday , and etcetera...) I wouldn't blame RFC 7489, nor DMARCbis. However, if there is a way to clarify the role of a DMARC implementation, it may be worth discussing it. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC marketing on NPR
On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The gap between what is being attempted and what is needed is a huge > personal disappointment. > > The DMARC goal should be to block malicious impersonation without blocking > wanted messages, where "wanted" is in the eyes of the evaluator and his end > user.That puts the onus on the evaluator. RFC 7960 said that > evaluators need to be aware of problems, but gave no solutions. DMARCbis > replaces the evaluator with a mindless automaton, repeating all the worst > mistakes of RFC 7489. > > This is from a real-world conversation with a product support tech: >Me: I cannot use your DMARC implementation because it does not have an > exception mechanism. >Him: Why would you need exceptions? > I blame his ignorance, and his product's inadequacies, on RFC 7489, which > defined no exceptions. > > RFC 7489 falsely divides the mail stream into four groups: > >- Authenticated / Pass, >- Unauthenticated without Prejudice (None), >- Unauthenticated with Prejudice (Quarantine/Reject), and >- No Result. > > In reality, there are only two possible states: Authenticated and Not > Authenticated. > >- The Mailing List problem proves that the distinction between None >and Reject is a fiction. At best, Fail with Reject justifies a slightly >higher risk weight for environments that depend on weighting. >- "No Result" is an error in RFC 7489.The PSL and default >alignment rules allowed a result to be calculated on any domain. An >evaluator cannot excuse a decision to allow malware infestation by saying, >"the domain owner did not give me permission to check for malicious >impersonation." "No Result" is another way of saying, "I did not do my >job." >- Any unauthenticated message is a potential impersonation. It is the >evaluator's job to figure out whether malicious impersonation actually >occurred or not. > > Authentication failure provides a starting point, not an end point. The > risk of malicious impersonation applies to every unauthenticated message. > > Correct evaluation fixes the mailing list problem and fixes a lot of other > false blocks, while blocking the malicious traffic that RFC 7489 leaves > unmolested. > > We need a document that is targeted at evaluators, to help them make > correct disposition decisions for their organizations. The current > document blames the charter as the reason that it does not even try. > > Doug Foster > You are absolutely incorrect when you state that there are no exceptions provided. "Local policy" enables an evaluator to implement any exception(s) they wish. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC marketing on NPR
The gap between what is being attempted and what is needed is a huge personal disappointment. The DMARC goal should be to block malicious impersonation without blocking wanted messages, where "wanted" is in the eyes of the evaluator and his end user.That puts the onus on the evaluator. RFC 7960 said that evaluators need to be aware of problems, but gave no solutions. DMARCbis replaces the evaluator with a mindless automaton, repeating all the worst mistakes of RFC 7489. This is from a real-world conversation with a product support tech: Me: I cannot use your DMARC implementation because it does not have an exception mechanism. Him: Why would you need exceptions? I blame his ignorance, and his product's inadequacies, on RFC 7489, which defined no exceptions. RFC 7489 falsely divides the mail stream into four groups: - Authenticated / Pass, - Unauthenticated without Prejudice (None), - Unauthenticated with Prejudice (Quarantine/Reject), and - No Result. In reality, there are only two possible states: Authenticated and Not Authenticated. - The Mailing List problem proves that the distinction between None and Reject is a fiction. At best, Fail with Reject justifies a slightly higher risk weight for environments that depend on weighting. - "No Result" is an error in RFC 7489.The PSL and default alignment rules allowed a result to be calculated on any domain. An evaluator cannot excuse a decision to allow malware infestation by saying, "the domain owner did not give me permission to check for malicious impersonation." "No Result" is another way of saying, "I did not do my job." - Any unauthenticated message is a potential impersonation. It is the evaluator's job to figure out whether malicious impersonation actually occurred or not. Authentication failure provides a starting point, not an end point. The risk of malicious impersonation applies to every unauthenticated message. Correct evaluation fixes the mailing list problem and fixes a lot of other false blocks, while blocking the malicious traffic that RFC 7489 leaves unmolested. We need a document that is targeted at evaluators, to help them make correct disposition decisions for their organizations. The current document blames the charter as the reason that it does not even try. Doug Foster On Wed, Nov 22, 2023 at 5:58 PM Seth Blank wrote: > Is there a point to this thread, that affects the text in the DMARCbis > document under charter criteria? > > Seth, as Chair > > -mobile > > > On Wed, Nov 22, 2023 at 07:13 Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> RFC 7489 and DMARCbis are written as algorithms without exception >> conditions. That silence leads product developers and mail administrators >> to conclude that the algorithm can be implemented without allowing for >> exceptions. Why would we expect a different result? >> >> Withheld information can deceive. >> >> >> >> >> On Wed, Nov 22, 2023, 5:14 AM Alessandro Vesely wrote: >> >>> On Wed 22/Nov/2023 00:51:24 +0100 Jim Fenton wrote: >>> > I see that the DMARC marketing machine is hard at work. There was an >>> item on NPR (National Public Radio) “All Things Considered” this afternoon >>> heavily promoting DMARC: >>> > >>> > >>> https://www-cf.npr.org/2023/11/21/1214529474/how-to-keep-an-eye-out-for-cyber-scams-during-this-holiday-shopping-season >>> > >>> > I have strong feelings about this article that are off-topic for this >>> mailing list. >>> >>> >>> What is not off-topic is the consideration that such sentiment implies >>> that a >>> prohibitive statement would turn out to mean /MUST NOT use mailing >>> lists/. >>> >>> >>> Best >>> Ale >>> -- >>> >>> >>> >>> >>> ___ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC marketing on NPR
On Wed 22/Nov/2023 23:58:26 +0100 Seth Blank wrote: Is there a point to this thread, that affects the text in the DMARCbis document under charter criteria? The point I made —death sentence to mailing lists— affects the text as an exhortation to /not/ change Section 8.6. For Doug's point, that DMARC is not so perfect as it may appear, I let Doug speak for himself. Best Ale Seth, as Chair -mobile On Wed, Nov 22, 2023 at 07:13 Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: RFC 7489 and DMARCbis are written as algorithms without exception conditions. That silence leads product developers and mail administrators to conclude that the algorithm can be implemented without allowing for exceptions. Why would we expect a different result? Withheld information can deceive. On Wed, Nov 22, 2023, 5:14 AM Alessandro Vesely wrote: On Wed 22/Nov/2023 00:51:24 +0100 Jim Fenton wrote: I see that the DMARC marketing machine is hard at work. There was an item on NPR (National Public Radio) “All Things Considered” this afternoon heavily promoting DMARC: https://www-cf.npr.org/2023/11/21/1214529474/how-to-keep-an-eye-out-for-cyber-scams-during-this-holiday-shopping-season I have strong feelings about this article that are off-topic for this mailing list. What is not off-topic is the consideration that such sentiment implies that a prohibitive statement would turn out to mean /MUST NOT use mailing lists/. >>> Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC marketing on NPR
Is there a point to this thread, that affects the text in the DMARCbis document under charter criteria? Seth, as Chair -mobile On Wed, Nov 22, 2023 at 07:13 Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > RFC 7489 and DMARCbis are written as algorithms without exception > conditions. That silence leads product developers and mail administrators > to conclude that the algorithm can be implemented without allowing for > exceptions. Why would we expect a different result? > > Withheld information can deceive. > > > > > On Wed, Nov 22, 2023, 5:14 AM Alessandro Vesely wrote: > >> On Wed 22/Nov/2023 00:51:24 +0100 Jim Fenton wrote: >> > I see that the DMARC marketing machine is hard at work. There was an >> item on NPR (National Public Radio) “All Things Considered” this afternoon >> heavily promoting DMARC: >> > >> > >> https://www-cf.npr.org/2023/11/21/1214529474/how-to-keep-an-eye-out-for-cyber-scams-during-this-holiday-shopping-season >> > >> > I have strong feelings about this article that are off-topic for this >> mailing list. >> >> >> What is not off-topic is the consideration that such sentiment implies >> that a >> prohibitive statement would turn out to mean /MUST NOT use mailing lists/. >> >> >> Best >> Ale >> -- >> >> >> >> >> ___ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC marketing on NPR
RFC 7489 and DMARCbis are written as algorithms without exception conditions. That silence leads product developers and mail administrators to conclude that the algorithm can be implemented without allowing for exceptions. Why would we expect a different result? Withheld information can deceive. On Wed, Nov 22, 2023, 5:14 AM Alessandro Vesely wrote: > On Wed 22/Nov/2023 00:51:24 +0100 Jim Fenton wrote: > > I see that the DMARC marketing machine is hard at work. There was an > item on NPR (National Public Radio) “All Things Considered” this afternoon > heavily promoting DMARC: > > > > > https://www-cf.npr.org/2023/11/21/1214529474/how-to-keep-an-eye-out-for-cyber-scams-during-this-holiday-shopping-season > > > > I have strong feelings about this article that are off-topic for this > mailing list. > > > What is not off-topic is the consideration that such sentiment implies > that a > prohibitive statement would turn out to mean /MUST NOT use mailing lists/. > > > Best > Ale > -- > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC marketing on NPR
On Wed 22/Nov/2023 00:51:24 +0100 Jim Fenton wrote: I see that the DMARC marketing machine is hard at work. There was an item on NPR (National Public Radio) “All Things Considered” this afternoon heavily promoting DMARC: https://www-cf.npr.org/2023/11/21/1214529474/how-to-keep-an-eye-out-for-cyber-scams-during-this-holiday-shopping-season I have strong feelings about this article that are off-topic for this mailing list. What is not off-topic is the consideration that such sentiment implies that a prohibitive statement would turn out to mean /MUST NOT use mailing lists/. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
