Re: [dmarc-ietf] Eliminating From Munging from this list
It is not at all clear that my goals for this effort match with others, so I will state mine: My goal is to develop documents that help evaluators make better disposition decisions, to save civilization from as much malicious content as possible. An inference from my piece of reality is that this effort has a large upside potential. Sender authentication is the core of this effort because it is something that we can actually specify. Defining a standard for defenses against malicious content seems infeasible. For all its difficulties, sender authentication is relatively feasible. Verification of RFC5322.From is the linchpin to Sender Authentication because the RFC5322.From address links the user-visible content to the invisible document metadata and SMTP protocol parameters. DMARC defines a formula for declaring the RFC5322.From address verified, thereby separating a general mailstream into two sub-streams: the verified portion and the unverified portion. This group has taken the position that a message is only verified if the domain owner has published a DMARC policy and the message produces DMARC PASS. From my data, that works out to about 40% of the traffic, most of which is Gmail. My results seem roughly consistent with data from other sources.This means that 60% of the traffic has no defined method for detecting possible impersonation, so network safety depends entirely on the strength of your content filtering. However, it is easy to note that the DMARC concept of Aligned SPF PASS or Aligned DKIM PASS is applicable to any message, with or without a DMARC policy. There is a minor complication about choosing between relaxed and strict authentication, which is solvable by local policy.Applying the DMARC formula to a general mailstream, the DMARC-equivalent PASS percentage suddenly jumps into the vicinity of 85%. The remaining 15% of mail has uncertain impersonation risk, but is much more manageable than 60%. It has been a fertile field for investigation. When I ask, "Why is this message not impersonated?", the investigation produces one of three answers: - The message stream is acceptable, but needs a local policy to allow future messages to appear authenticated. - The message stream is unwanted even though it is not an impersonation, so this and future messages from this sender should be blocked. - The message stream is from a malicious impersonator, so this and future messages from this sender should be blocked. Whichever conclusion is reached, investigation is a one-time effort per message source. So a technical path exists for ensuring 100% authentication of all allowed messages, and quarantining the uncertain messages for investigation. In my experience, the middle result dominates. As my recurring and wanted traffic gets an authentication rule, and unwanted traffic gets blocked, the volume of investigations goes down while the percentage of block results goes up. When I examine the language of RFC 7489 and our proposed documents, I find no path toward 100% authentication. Instead, I see language that drives people to fixate on the 1% of traffic that has a DMARC policy with p=reject. Then we are disappointed if they don't look for exceptions, including mailing list messages, within the Failure subset of the 1% subset. If we don't change strategy, nothing will change. Desperate evaluators will continue to read our document as a ticket to unconditionally block that tiny portion of their mailstream which produces Fail with p=reject, and more importantly, will continue to be vulnerable to impersonation attacks buried in the other 99%. Doug Foster On Thu, Jul 20, 2023 at 3:53 PM Jan Dušátko wrote: > Dne 20. 7. 2023 v 14:46 Barry Leiba napsal(a): > >> I think that it shouldn't affect the answer about what to put in the > document. Those of us here are a > >> miniscule slice of the overall user base for email, I think it's a > serious mistake to think peculiarities of > >> the exact lists we use is relevant to anything. > > Indeed: I caution everyone about making assumptions based on what we > > think we know, and extending those assumptions to the entire Internet. > > There are things we can study (by, for example, doing DNS queries and > > analyzing results), and there are things about which we just say, "I > > don't know anyone who does [or doesn't do] this, so that must be the > > case overall." The latter is hazardous. > > > > Barry > > > > > I couldn't agree more. Thinking and knowing are two different things. > Assuming what others want on the Internet is another thing. > For that reason, I would also like to ask. What are that technologies > supposed to be for? The ability to define a domain owner's policy? > Covering tools to provide protection against counterfeiting? Or a > meta-tool for authenticity? > In my opinion, this is an effort to secure what email technology lacks. > The ability to protect against communication co
Re: [dmarc-ietf] Eliminating From Munging from this list
Dne 20. 7. 2023 v 14:46 Barry Leiba napsal(a): I think that it shouldn't affect the answer about what to put in the document. Those of us here are a miniscule slice of the overall user base for email, I think it's a serious mistake to think peculiarities of the exact lists we use is relevant to anything. Indeed: I caution everyone about making assumptions based on what we think we know, and extending those assumptions to the entire Internet. There are things we can study (by, for example, doing DNS queries and analyzing results), and there are things about which we just say, "I don't know anyone who does [or doesn't do] this, so that must be the case overall." The latter is hazardous. Barry I couldn't agree more. Thinking and knowing are two different things. Assuming what others want on the Internet is another thing. For that reason, I would also like to ask. What are that technologies supposed to be for? The ability to define a domain owner's policy? Covering tools to provide protection against counterfeiting? Or a meta-tool for authenticity? In my opinion, this is an effort to secure what email technology lacks. The ability to protect against communication counterfeiting and, under tight conditions, to verify the authenticity of the source. The problem is the wide mutual possibilities of communication, which have been designed with accessibility and flexibility in mind. I apologize for such a broad response. I'm trying to understand what your goals are to avoid misunderstanding. Sometimes I'm lost in translation. Regards Jan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
> I think that it shouldn't affect the answer about what to put in the > document. Those of us here are a > miniscule slice of the overall user base for email, I think it's a serious > mistake to think peculiarities of > the exact lists we use is relevant to anything. Indeed: I caution everyone about making assumptions based on what we think we know, and extending those assumptions to the entire Internet. There are things we can study (by, for example, doing DNS queries and analyzing results), and there are things about which we just say, "I don't know anyone who does [or doesn't do] this, so that must be the case overall." The latter is hazardous. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?
On Wed, Jul 19, 2023 at 10:42 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Can you find a commercial product that can configure a rule which says, > "Don't worry about DMARC if Mail from = bounceaddtess@listdomain and the > MailFrom address produces SPF PASS"? > > Simple enough rule. If vendors understood what we want them to > understand, they would allow creation of multipe-attribute rules like this, > combining authentication results and identifier values, to provide local > authentication overrides. But they don't, or at least I have not found > one after diligently searching. > YOU keep on substituting "we" for "I" when YOU have not gained a consensus on what YOU want. YOU have not searched very diligently if you couldn't find a single vendor who can do what YOU want. As Olivier pointed out, Cisco AsyncOS can do this. I was an early customer of IronPort (when the company was still code named "GodSpeed" and that capability existed in the early 2000's, so even well before DMARC even existed. Another company product that has had that capability is MessageSystems and their Momentum servers. You'd have to write the rule in Lua. A very flexible implementation. The fact that YOU don't know something exists after "searching diligently" doesn't mean it doesn't exist. Perhaps asking the community yields results when "searching diligently" does not. > > On the other hand, finding products that block unconditionally on FAIL is > pretty easy. > > We need to find words in our document that begin to fix this, to obtain > the products and evaluator behavior that we both want and their users need. > YOU are again substituting "we" for "I". You have also wandered from writing a protocol to telling people how they (actually YOUR preference) should implement their operational choices for local policy. Trying to dictate local policy choices is a losing proposition. Trying to dictate to vendors YOUR policy choices is also a losing proposition. Local policy choices != protocol. Michael Hammer > Doug > > On Wed, Jul 19, 2023, 8:07 PM Dotzero wrote: > >> >> >> On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster < >> dougfoster.emailstanda...@gmail.com> wrote: >> >>> Perhaps you can clarify what you think DMARC is. >>> >>> Apparently a significant number of evaluators think that "DMARC Fail >>> with p=reject always means unwanted mail". Or to use Michael Hammer's >>> language, "DMARC Fail with p=reject means the domain owner wants it >>> rejected so I will reject it."These are exactly the attitudes that >>> cause us so much trouble because (a) DMARC Fail with p=reject does not mean >>> that rejection is always the correct response, and (b) DMARC Fail with >>> p=none is an important piece of information. >>> >> >> You are misrepresenting my position by ignoring local policy. A DMARC >> policy of quarantine or reject is a request by the domain owner or >> administrator. While consideration of a sending domain's request should be >> given consideration, a receiving domain is free to do as it wishes. A >> receiving domain may choose not to implement DMARC validation at all. A >> sending domain may believe that the risk of some legitimate emails being >> rejected or quarantined is an acceptable tradeoff in order to protect >> itself and users/recipients. You appear to have a problem with these >> choices being made by both the sending domain and the receiving domain. Why >> do you presume to know better than they as to what they should do? >> Certainly, if I publish a policy of p=reject and a receiver allows an email >> that should have been rejected to reach their user/customer and that person >> contacts me because that message caused them a problem, I'm going to tell >> them they need to speak with their mail administrator, mailbox provider, >> etc. I've done that in the past and I'll do it in the future. What others >> choose to do is their choice. While I may have an opinion, I recognize that >> it is their choice. >> >>> >>> We have only two ways to block unwanted messages: Identify unwanted >>> and malicious messages based on the sender, or based on the content. >>> Impersonation interferes with the sender reputation assessment, so we know >>> that attackers have an incentive to impersonate. Sender Authentication >>> provides information about messages that MIGHT be impersonations >>> because they are not authenticated. Fortunately, most messages can be >>> authenticated. >>> >> >> You are again misrepresenting what DMARC is and does. It is NOT a >> guessing game about whether a recipient might want a given email. It is a >> simple pass/fail that should be automated before a message ever >> (potentially) gets to a recipient. It may be as simple as the message took >> an unintended or unexpected path which potentially creates risks from the >> perspective of the sending domain. DMARC knows nothing about whether email >> is wanted or unwanted on the receiving side of the mailstream. I
Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?
To supplement Oliver's reply, and Doug's question, most commercial secure
email gateways are capable of this in terms of granular inbound email
authentication customization. (Proofpoint, Mimecast, Cisco, Barracuda, etc.)
- Mark Alley
On Thu, Jul 20, 2023, 4:15 AM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:
> Hi,
>
> > Can you find a commercial product that can configure a rule which says,
> "Don't worry about DMARC if Mail from = bounceaddtess@listdomain and the
> MailFrom address produces SPF PASS"?
>
> The solution I can propose to you is using Cisco AsyncOS (
> https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0.html)
> software.
>
> Ciscos's solution does have Email authentication global settings where you
> can bypass the DMARC verification if the message contains a specific header.
>
>
> https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_010110.html#con_1225789
>
> Let's assume the header we are looking for is 'X-MAILFROM-SPF-PASS:TRUE'
>
> The idea is then to use the Message Filters features of AsyncOs to add a
> specific header using the action 'insert-header'
>
> You can then use the SPF-Status Rule (
> https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_01000.html#con_1132105)
> and EnvelopeFrom such as :
>
> overpass_dmarc_if_spf_mailfrom_pass:
> if (EnvelopeFrom == "bounceaddtess@listdomain" AND spf-status("mailfrom")
> == "Pass"){
> insert-header("X-MAILFROM-SPF-PASS","TRUE")
> }
>
> I am not a Cisco expert but, to be confirmed.
>
> Regards,
> Olivier Hureau
>
> --
> *De: *"Douglas Foster"
> *À: *"Dotzero"
> *Cc: *"IETF DMARC WG"
> *Envoyé: *Jeudi 20 Juillet 2023 04:41:57
> *Objet: *Re: [dmarc-ietf] How did DMARC go wrong, and how does our
> document fix it?
>
> Can you find a commercial product that can configure a rule which says,
> "Don't worry about DMARC if Mail from = bounceaddtess@listdomain and the
> MailFrom address produces SPF PASS"?
>
> Simple enough rule. If vendors understood what we want them to
> understand, they would allow creation of multipe-attribute rules like this,
> combining authentication results and identifier values, to provide local
> authentication overrides. But they don't, or at least I have not found
> one after diligently searching.
>
> On the other hand, finding products that block unconditionally on FAIL is
> pretty easy.
>
> We need to find words in our document that begin to fix this, to obtain
> the products and evaluator behavior that we both want and their users need.
>
> Doug
>
> On Wed, Jul 19, 2023, 8:07 PM Dotzero wrote:
>
>>
>>
>> On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>>
>>> Perhaps you can clarify what you think DMARC is.
>>> Apparently a significant number of evaluators think that "DMARC Fail
>>> with p=reject always means unwanted mail". Or to use Michael Hammer's
>>> language, "DMARC Fail with p=reject means the domain owner wants it
>>> rejected so I will reject it."These are exactly the attitudes that
>>> cause us so much trouble because (a) DMARC Fail with p=reject does not mean
>>> that rejection is always the correct response, and (b) DMARC Fail with
>>> p=none is an important piece of information.
>>>
>>
>> You are misrepresenting my position by ignoring local policy. A DMARC
>> policy of quarantine or reject is a request by the domain owner or
>> administrator. While consideration of a sending domain's request should be
>> given consideration, a receiving domain is free to do as it wishes. A
>> receiving domain may choose not to implement DMARC validation at all. A
>> sending domain may believe that the risk of some legitimate emails being
>> rejected or quarantined is an acceptable tradeoff in order to protect
>> itself and users/recipients. You appear to have a problem with these
>> choices being made by both the sending domain and the receiving domain. Why
>> do you presume to know better than they as to what they should do?
>> Certainly, if I publish a policy of p=reject and a receiver allows an email
>> that should have been rejected to reach their user/customer and that person
>> contacts me because that message caused them a problem, I'm going to tell
>> them they need to speak with their mail administrator, mailbox provider,
>> etc. I've done that in the past and I'll do it in the future. What others
>> choose to do is their choice. While I may have an opinion, I recognize that
>> it is their choice.
>>
>>>
>>> We have only two ways to block unwanted messages: Identify unwanted
>>> and malicious messages based on the sender, or based on the content.
>>> Impersonation interferes with the sender reputation assessment, so we know
>>> that attackers have an incentive to impersonate. Sender Authentication
>>> provides informati
Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?
Hi,
> Can you find a commercial product that can configure a rule which says,
> "Don't worry about DMARC if Mail from = bounceaddtess@listdomain and the
> MailFrom address produces SPF PASS"?
The solution I can propose to you is using Cisco AsyncOS ( [
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0.html
|
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0.html
] ) software.
Ciscos's solution does have Email authentication global settings where you can
bypass the DMARC verification if the message contains a specific header.
[
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_010110.html#con_1225789
|
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_010110.html#con_1225789
]
Let's assume the header we are looking for is 'X-MAILFROM-SPF-PASS:TRUE'
The idea is then to use the Message Filters features of AsyncOs to add a
specific header using the action 'insert-header'
You can then use the SPF-Status Rule ( [
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_01000.html#con_1132105
|
https://www.cisco.com/c/en/us/td/docs/security/esa/esa14-0/user_guide/b_ESA_Admin_Guide_14-0/b_ESA_Admin_Guide_12_1_chapter_01000.html#con_1132105
] ) and EnvelopeFrom such as :
overpass_dmarc_if_spf_mailfrom_pass:
if (EnvelopeFrom == "bounceaddtess@listdomain" AND spf-status("mailfrom") ==
"Pass"){
insert-header("X-MAILFROM-SPF-PASS","TRUE")
}
I am not a Cisco expert but, to be confirmed.
Regards,
Olivier Hureau
De: "Douglas Foster"
À: "Dotzero"
Cc: "IETF DMARC WG"
Envoyé: Jeudi 20 Juillet 2023 04:41:57
Objet: Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix
it?
Can you find a commercial product that can configure a rule which says, "Don't
worry about DMARC if Mail from = bounceaddtess@listdomain and the MailFrom
address produces SPF PASS"?
Simple enough rule. If vendors understood what we want them to understand, they
would allow creation of multipe-attribute rules like this, combining
authentication results and identifier values, to provide local authentication
overrides. But they don't, or at least I have not found one after diligently
searching.
On the other hand, finding products that block unconditionally on FAIL is
pretty easy.
We need to find words in our document that begin to fix this, to obtain the
products and evaluator behavior that we both want and their users need.
Doug
On Wed, Jul 19, 2023, 8:07 PM Dotzero < [ mailto:dotz...@gmail.com |
dotz...@gmail.com ] > wrote:
On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster < [
mailto:dougfoster.emailstanda...@gmail.com |
dougfoster.emailstanda...@gmail.com ] > wrote:
BQ_BEGIN
Perhaps you can clarify what you think DMARC is.
Apparently a significant number of evaluators think that "DMARC Fail with
p=reject always means unwanted mail". Or to use Michael Hammer's language,
"DMARC Fail with p=reject means the domain owner wants it rejected so I will
reject it." These are exactly the attitudes that cause us so much trouble
because (a) DMARC Fail with p=reject does not mean that rejection is always the
correct response, and (b) DMARC Fail with p=none is an important piece of
information.
You are misrepresenting my position by ignoring local policy. A DMARC policy of
quarantine or reject is a request by the domain owner or administrator. While
consideration of a sending domain's request should be given consideration, a
receiving domain is free to do as it wishes. A receiving domain may choose not
to implement DMARC validation at all. A sending domain may believe that the
risk of some legitimate emails being rejected or quarantined is an acceptable
tradeoff in order to protect itself and users/recipients. You appear to have a
problem with these choices being made by both the sending domain and the
receiving domain. Why do you presume to know better than they as to what they
should do? Certainly, if I publish a policy of p=reject and a receiver allows
an email that should have been rejected to reach their user/customer and that
person contacts me because that message caused them a problem, I'm going to
tell them they need to speak with their mail administrator, mailbox provider,
etc. I've done that in the past and I'll do it in the future. What others
choose to do is their choice. While I may have an opinion, I recognize that it
is their choice.
BQ_BEGIN
We have only two ways to block unwanted messages: Identify unwanted and
malicious messages based on the sender, or based on the content. Impersonation
interferes with the sender reputation assessment, so we know that attackers
have an incentive to impersonate. Sender Authentication provides info
Re: [dmarc-ietf] Eliminating From Munging from this list
On July 20, 2023 7:46:57 AM UTC, Alessandro Vesely wrote: >On Wed 19/Jul/2023 21:38:44 +0200 Scott Kitterman wrote: >> >> >> On July 19, 2023 5:38:08 PM UTC, Alessandro Vesely wrote: >>> On Wed 19/Jul/2023 15:25:17 +0200 Scott Kitterman wrote: On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely wrote: > On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote: >> On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster < >> dougfoster.emailstanda...@gmail.com> wrote: >> >>> 1) For evaluators that enforce DMARC against lists, are they willing to >>> consider any concessions to list traffic? If so, do they favor an >>> exemption process where the list avoids munging, or an unmunging >>> solution implemented at their inbound gateway? >> >> How do you determine that an evaluator is enforcing DMARC "against >> lists"? > > That assumes there are lists that don't munge From:. Is that real today? Most of my list mail is from lists that don't. >>> >>> Oops, I had in mind that lists modify messages. Some of them don't, that >>> way they don't need From: munging. It is quite common too. >>> >>> Let me reword the question: Are there lists that modify messages and don't >>> munge From:? >> >> Yes, although those are fewer. > > >That's interesting. Do they have different workarounds or ban p=reject? >Please describe something about them, or just share a pointer to their archive >if you prefer. > >I think it's crucial, since we're weighting how to word the theoretical >prohibition to use DMARC, to know what's the actual reality. Many opponents >to MUST NOT argue about the usefulness of closing the stable door after the >horses have bolted out. So, knowing there are some horses still in makes a >difference, doesn't it? Presumably, they're never going to leave even if we >leave the doors open? And why? > I really don't know. These aren't lists I administer. I think that it shouldn't affect the answer about what to put in the document. Those of us here are a miniscule slice of the overall user base for email, I think it's a serious mistake to think peculiarities of the exact lists we use is relevant to anything. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Wed 19/Jul/2023 23:42:55 +0200 Tero Kivinen wrote: Wei Chuang writes: 2) The proposed language calls out "“alumni forwarders”, role-based email aliases, and mailing lists" for consideration by receivers. How should receivers be aware that traffic failing authentication should be reconsidered? Mailing-lists sometimes uses RFC2919 List-id headers. Can Section 5.8 [1] call out more strongly the application of those List-id headers? Can something be done so that receivers can identify the other scenarios e.g. role-based email aliases and alumni-forwarders? For alumni forwarders / role-based forwarders things are different, as users who set those up, actually knows who does the forwarding, and they themself recognize that emails coming to those addresses are important to them, and they also trust (university etc) the one doing forwarding. That's particularly true for internal role forwarding. As time goes by, maintenance almost always forget to whitelist forwarders. So if the alumni forwarder / role-based forwarder adds ARC signatures, then the final recipient can whitelist that ARC signer in their setup and say that the policy code that checks the SPF/DKIM/DMARC results can fully trust the signed ARC authentication results from that signer. Setting up an maintaining such trust lists is an effort which requires some planning. And learning about new forwarders who deserve trust is not easily automated too. This of course requires that the recipient SMTP server can't simply reject the incoming email after the MAIL FROM because SPF checks do not match, they actually need to receive the email so they can check ARC and DKIM headers... Shared whitelists may seem to help smoothing this corner. Granting just the minimal trust necessary to receive the message could be afforded at minimal cost. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
On Wed 19/Jul/2023 21:38:44 +0200 Scott Kitterman wrote: On July 19, 2023 5:38:08 PM UTC, Alessandro Vesely wrote: On Wed 19/Jul/2023 15:25:17 +0200 Scott Kitterman wrote: On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely wrote: On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote: On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: 1) For evaluators that enforce DMARC against lists, are they willing to consider any concessions to list traffic? If so, do they favor an exemption process where the list avoids munging, or an unmunging solution implemented at their inbound gateway? How do you determine that an evaluator is enforcing DMARC "against lists"? That assumes there are lists that don't munge From:. Is that real today? Most of my list mail is from lists that don't. Oops, I had in mind that lists modify messages. Some of them don't, that way they don't need From: munging. It is quite common too. Let me reword the question: Are there lists that modify messages and don't munge From:? Yes, although those are fewer. That's interesting. Do they have different workarounds or ban p=reject? Please describe something about them, or just share a pointer to their archive if you prefer. I think it's crucial, since we're weighting how to word the theoretical prohibition to use DMARC, to know what's the actual reality. Many opponents to MUST NOT argue about the usefulness of closing the stable door after the horses have bolted out. So, knowing there are some horses still in makes a difference, doesn't it? Presumably, they're never going to leave even if we leave the doors open? And why? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
