Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Douglas Foster]

If a mailing list can perform 100% sender authentication, it makes sense to
delegate that responsibility to the list  -- giving it the same treatment
as I am currently giving to the best-known ESPs.Getting there requires
a list that:
- wants one of my users as a subscriber,
- can perform 100% sender authentication,
- has activated a mechanism to notify me that it can perform delegated
authentication
- and provides ARC data to provide correlating evidence for whatever can be
correlated.

We do not currently have the policy communication mechanism, so the list
cannot give me the notification that I would want.

Doug


On Mon, Jul 24, 2023 at 11:57 AM Neil Anuskiewicz 
wrote:

>
>
> On Jul 23, 2023, at 9:39 PM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
> 
> Neil, this is about whether to block first and ask questions later:
>  quarantining first is safer, but not initially feasible.
>
> My working assumption is that essentially all evaluators release
> unauthenticated traffic to their users every day.   To fix the mailing list
> problem, we are proposing to ask them to do so on a slightly greater scale.
>
> If you start on a path toward 100% authentication, the assumption is that
> you cannot quarantine every unauthenticated message because you will not
> have the staffing resources to work the quarantine queue in a timely
> manner.   So you have to do triage.
>
> Authentication moves:
>
>- Start by updating your configuration to authenticate based on the
>DMARC concept instead of RFC 7489 and the sender policy.   Don't waste
>precious resources checking for impersonation on messages that already have
>verifiable authentication.   Don't allow the absence of someone else's
>DMARC policy record to become a reason to put your network at risk.
>
>- Also consider that authentication comes in multiple forms.   I
>decided that a few major ESPs could be trusted to enforce client
>authentication during account setup and account use, so I did not have to
>repeat the process on every message from them.   That does not mean that I
>accept every message, because I don't.   Some of them still send a lot of
>unwanted traffic.  But it does mean that I accept the From address as valid
>without requiring an aligned DKIM signature.   This move also improved my
>authentication percentage.
>
>- Collectively, these moves will decrease the false positives in your
>pool of unauthenticated messages.
>
> Audit moves:
>
>- Initially, you can start with after-the-fact audits on the most
>obvious suspects.   For example, find the messages that fail both sender
>authentication and content filtering.   These messages have a high
>probability of malice, so verify the assessment and then block the sender
>completely.   You can actually start anywhere, because any form of sampling
>will work.  You have a dual goal:   find the wanted-but-unauthenticated
>message senders, and give them an authentication rule, while also finding
>the unwanted message senders and giving them a block rule.  Every
>investigation moves a message source from unauthenticated to authenticated
>or from unauthenticated to blocked.  Since you have a finite number of
>message sources, you have a finite number of investigations to complete.
>
>- Gradually, send an increasing volume of messages to quarantine,
>based on perceived probability of fraud.   Assume that this queue will
>still contain wanted messages, so the quarantine volume has to be throttled
>by your capacity to review all of its traffic.  Wanted messages still need
>to be released to users in something approximating a timely manner.
>
>- Over time, this process is guaranteed to reduce the volume of
>unauthenticated traffic.   When my SPF non-PASS rate was down to a few
>messages per day, I decided that I could quarantine any SPF result other
>than PASS.   Some of my business partners had no SPF policy at all, so they
>were quarantined and then equipped with an alternate authentication rule.
> By now, virtually all of the authentication-related quarantine is unwanted
>traffic.I haven't yet enforced quarantine on From verification failure,
>but my FROM PASS rate is about 97%, and the remaining 3% is mostly ESPs
>that have not been given special treatment.   So I am focusing on content
>filtering.   Most of the malicious traffic comes from mailbox provider
>accounts used for malicious purposes, which was sort of the goal of the
>100% authentication effort.   I have to depend on content filtering to flag
>those suspicious actors, and the confirmed attackers will be given a block
>rule.
>
> Doug Foster
>
> On Sun, Jul 23, 2023 at 9:30 AM Neil Anuskiewicz 
> wrote:
>
>> Doug, you’ve done a fine job of explaining as I groked what you said. If
>> I get I think most people here got it. I’ve been busy with work 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Neil Anuskiewicz]

> On Jul 19, 2023, at 3:21 PM, Douglas Foster 
>  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.   

Doug, if what you’re saying is true then the root cause might be our fault. If 
we’ve not communicated clearly enough DMARC’s purpose. A communication problem 
likely needs to be solved with more and better communication via the standards 
doc itself and other channels.

N
___
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?

[Neil Anuskiewicz]

On Jul 23, 2023, at 9:39 PM, Douglas Foster  wrote:Neil, this is about whether to block first and ask questions later:   quarantining first is safer, but not initially feasible.My working assumption is that essentially all evaluators release unauthenticated traffic to their users every day.   To fix the mailing list problem, we are proposing to ask them to do so on a slightly greater scale.If you start on a path toward 100% authentication, the assumption is that you cannot quarantine every unauthenticated message because you will not have the staffing resources to work the quarantine queue in a timely manner.   So you have to do triage.   Authentication moves:Start by updating your configuration to authenticate based on the DMARC concept instead of RFC 7489 and the sender policy.   Don't waste precious resources checking for impersonation on messages that already have verifiable authentication.   Don't allow the absence of someone else's DMARC policy record to become a reason to put your network at risk.Also consider that authentication comes in multiple forms.   I decided that a few major ESPs could be trusted to enforce client authentication during account setup and account use, so I did not have to repeat the process on every message from them.   That does not mean that I accept every message, because I don't.   Some of them still send a lot of unwanted traffic.  But it does mean that I accept the From address as valid without requiring an aligned DKIM signature.   This move also improved my authentication percentage.Collectively, these moves will decrease the false positives in your pool of unauthenticated messages.Audit moves:Initially, you can start with after-the-fact audits on the most obvious suspects.   For example, find the messages that fail both sender authentication and content filtering.   These messages have a high probability of malice, so verify the assessment and then block the sender completely.   You can actually start anywhere, because any form of sampling will work.  You have a dual goal:   find the wanted-but-unauthenticated message senders, and give them an authentication rule, while also finding the unwanted message senders and giving them a block rule.  Every investigation moves a message source from unauthenticated to authenticated or from unauthenticated to blocked.  Since you have a finite number of message sources, you have a finite number of investigations to complete.Gradually, send an increasing volume of messages to quarantine, based on perceived probability of fraud.   Assume that this queue will still contain wanted messages, so the quarantine volume has to be throttled by your capacity to review all of its traffic.  Wanted messages still need to be released to users in something approximating a timely manner.Over time, this process is guaranteed to reduce the volume of unauthenticated traffic.   When my SPF non-PASS rate was down to a few messages per day, I decided that I could quarantine any SPF result other than PASS.   Some of my business partners had no SPF policy at all, so they were quarantined and then equipped with an alternate authentication rule.   By now, virtually all of the authentication-related quarantine is unwanted traffic.    I haven't yet enforced quarantine on From verification failure, but my FROM PASS rate is about 97%, and the remaining 3% is mostly ESPs that have not been given special treatment.   So I am focusing on content filtering.   Most of the malicious traffic comes from mailbox provider accounts used for malicious purposes, which was sort of the goal of the 100% authentication effort.   I have to depend on content filtering to flag those suspicious actors, and the confirmed attackers will be given a block rule.Doug FosterOn Sun, Jul 23, 2023 at 9:30 AM Neil Anuskiewicz  wrote:Doug, you’ve done a fine job of explaining as I groked what you said. If I get I think most people here got it. I’ve been busy with work and personal life so haven’t had as much time to lurk here. I’m curious what sparked your concern now? Also, isn’t it best to block first and ask questions later to mitigate damage while you investigate? I guess I’m saying the two ideas aren’t mutually exclusive.

Neil

> On Jul 15, 2023, at 4:27 AM, Douglas Foster  wrote:
> 
> 
> Murray recently observed, correctly, that something went horribly wrong with the DMARC rollout, because it caused (continues to cause) many safe and wanted messages to be blocked.
> 
> My assessment was in a recent post:
> 
> Something about the language of RFC 7489 caused implementers to focus on blocking individual messages, when the appropriate use of DMARC is to identify and investigate potentially malicious sources.
> 
> The "message blocking" approach violates the interests of the users it is intended to protect:
> 
> - An attacker sends 10 messages that maliciously impersonates a big bank.  With help from DMARC p=reject, the evaluator 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Douglas Foster]

Neil, this is about whether to block first and ask questions later:
 quarantining first is safer, but not initially feasible.

My working assumption is that essentially all evaluators release
unauthenticated traffic to their users every day.   To fix the mailing list
problem, we are proposing to ask them to do so on a slightly greater scale.

If you start on a path toward 100% authentication, the assumption is that
you cannot quarantine every unauthenticated message because you will not
have the staffing resources to work the quarantine queue in a timely
manner.   So you have to do triage.

Authentication moves:

   - Start by updating your configuration to authenticate based on the
   DMARC concept instead of RFC 7489 and the sender policy.   Don't waste
   precious resources checking for impersonation on messages that already have
   verifiable authentication.   Don't allow the absence of someone else's
   DMARC policy record to become a reason to put your network at risk.

   - Also consider that authentication comes in multiple forms.   I
   decided that a few major ESPs could be trusted to enforce client
   authentication during account setup and account use, so I did not have to
   repeat the process on every message from them.   That does not mean that I
   accept every message, because I don't.   Some of them still send a lot of
   unwanted traffic.  But it does mean that I accept the From address as valid
   without requiring an aligned DKIM signature.   This move also improved my
   authentication percentage.

   - Collectively, these moves will decrease the false positives in your
   pool of unauthenticated messages.

Audit moves:

   - Initially, you can start with after-the-fact audits on the most
   obvious suspects.   For example, find the messages that fail both sender
   authentication and content filtering.   These messages have a high
   probability of malice, so verify the assessment and then block the sender
   completely.   You can actually start anywhere, because any form of sampling
   will work.  You have a dual goal:   find the wanted-but-unauthenticated
   message senders, and give them an authentication rule, while also finding
   the unwanted message senders and giving them a block rule.  Every
   investigation moves a message source from unauthenticated to authenticated
   or from unauthenticated to blocked.  Since you have a finite number of
   message sources, you have a finite number of investigations to complete.

   - Gradually, send an increasing volume of messages to quarantine, based
   on perceived probability of fraud.   Assume that this queue will still
   contain wanted messages, so the quarantine volume has to be throttled by
   your capacity to review all of its traffic.  Wanted messages still need to
   be released to users in something approximating a timely manner.

   - Over time, this process is guaranteed to reduce the volume of
   unauthenticated traffic.   When my SPF non-PASS rate was down to a few
   messages per day, I decided that I could quarantine any SPF result other
   than PASS.   Some of my business partners had no SPF policy at all, so they
   were quarantined and then equipped with an alternate authentication rule.
By now, virtually all of the authentication-related quarantine is unwanted
   traffic.I haven't yet enforced quarantine on From verification failure,
   but my FROM PASS rate is about 97%, and the remaining 3% is mostly ESPs
   that have not been given special treatment.   So I am focusing on content
   filtering.   Most of the malicious traffic comes from mailbox provider
   accounts used for malicious purposes, which was sort of the goal of the
   100% authentication effort.   I have to depend on content filtering to flag
   those suspicious actors, and the confirmed attackers will be given a block
   rule.

Doug Foster

On Sun, Jul 23, 2023 at 9:30 AM Neil Anuskiewicz 
wrote:

> Doug, you’ve done a fine job of explaining as I groked what you said. If I
> get I think most people here got it. I’ve been busy with work and personal
> life so haven’t had as much time to lurk here. I’m curious what sparked
> your concern now? Also, isn’t it best to block first and ask questions
> later to mitigate damage while you investigate? I guess I’m saying the two
> ideas aren’t mutually exclusive.
>
> Neil
>
> > On Jul 15, 2023, at 4:27 AM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> >
> > 
> > Murray recently observed, correctly, that something went horribly wrong
> with the DMARC rollout, because it caused (continues to cause) many safe
> and wanted messages to be blocked.
> >
> > My assessment was in a recent post:
> >
> > Something about the language of RFC 7489 caused implementers to focus on
> blocking individual messages, when the appropriate use of DMARC is to
> identify and investigate potentially malicious sources.
> >
> > The "message blocking" approach violates the interests of the users it
> is 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Neil Anuskiewicz]

>> 
>> 
> 
> I think it is a mistake to consider technologies such as SPF, DKIM, and DMARC 
> as anti-spam.  They are a component of spam mitigation, but authentication of 
> an identifier isn't a solution for spam.  Meng Wong (for those of you that 
> weren't around, he's the one that synthesized SPF out of previous proposals 
> and was the early leader of the SPF project) used to say that SPF is not 
> anti-spam in the same way that flour is not food.  I think that extends to 
> DKIM and DMARC as well.
> 
> The challenge with the argument that this is brand protection, so the brand 
> owner should decide is that it's primarily the receiver that needs to invest 
> in integrating these technologies into their systems and accept the 
> inevitable support burden that comes with them.  The brand owner wants 
> something from the receiver, so it needs to be simple and reliable enough to 
> be worthwhile.
> 
> SPF includes a policy mechanism so that receivers can reject mail that is not 
> authorized by SPF.  Outside of small sites with a lot of control over their 
> mail stream, it's almost never used .  It was tried and for large providers 
> with a heterogeneous user base it wasn't cost effective to support due to the 
> number of false positives and the associated tech support costs.
> 
> DMARC seems to be heading the same way due to domains using p=reject that (at 
> least in my opinion) shouldn't.
> 
> Since there are no internet police, deployment of these technologies is a 
> matter of incentives.  We do protocol design, not economics, so it's a tough 
> problem in the IETF context, but we need to keep it in mind.  Getting the 
> incentives right is probably the most important, but least tractable part of 
> https://www.ietf.org/mailman/listinfo/dmarc

I agree that none of this primarily anti spam. It’s pro brand rep and anti 
fraud. 

I saw what happened with SPF and how it seemed completely random who would 
decide to enforce on hardfail. I recall a client losing mail as they used a 
hard fail and suddenly one of the more well known hosting companies started 
honoring hard fails which was a fiasco for my client who had just copied and 
pasted the -all in without thought to the implications. The outcomes were bad 
in a random way. It wasn’t hard to persuade him back to soft fail.

I feel with dmarc people come to recognize dmarc as the policy layer. SPF had 
too much responsibility. When one goes to p=reject one’s palms get sweaty. It’s 
clearly the policy layer unlike -all which was a bit too subtle way to 
communicate policy intent. Dmarc has the intuitive grok advantage.

I hope you’re wrong or that there’s a way to mitigate this problem you speak 
of. As I remember that as a time of confusion. Confusion and chaos are our foes.
___
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?

[Scott Kitterman]

On July 21, 2023 6:53:03 PM UTC, "Jan Dušátko" 
 wrote:
>
>
>Dne 21. 7. 2023 v 16:34 Murray S. Kucherawy napsal(a):
>> On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster <
>> dougfoster.emailstanda...@gmail.com> wrote:
>> 
>>> I don't take DMARC as a certain result to be used in isolation, but
>>> clearly a quorum evaluators do, and hence the mailing list problem that has
>>> caused such consternation.
>>> 
>>> If we want to diminish their numbers, we have to communicate very
>>> differently than RFC 7489.
>>> 
>>> My problem with your favorite line is that the domain owner's preference
>>> is of no interest to my filtering decision, but the DMARC result is.
>>> 
>> Since even before SPF, people have been looking for a silver bullet to stop
>> spam and phishing.  I'm not surprised to hear that there are products out
>> there that promise or implement such, despite the specifications not
>> actually saying this is a good idea, or even (in DKIM's case, I believe)
>> being rather explicit that it isn't.
>> 
>> I don't think anyone is disputing that the DMARC result by itself is not a
>> clear answer about what one should do upon receiving a message.  The only
>> time you really know something is when DMARC passes, but even that isn't a
>> strong signal about the content of the message.  All other answers are
>> muddy, and should be treated that way.  If DMARCbis needs to make this more
>> explicit, I don't see a problem with doing so.
>> 
>> I think a DMARC-aware product that's reject-on-fail by default has made a
>> questionable choice, and not making that configurable is doubly so.
>> 
>> However, I don't think an evaluator should be looking at the "p=" value and
>> then trying to infer anything about the sending domain solely from that.
>> This, to me, is crystal ball territory.  We should omit it from our
>> calculus.
>> 
>> -MSK, participating
>> 
>Although SPF, DKIM, DMARC, and ARC are all intended to protect against SPAM, 
>it is not possible, as a matter of principle, to protect against such kind of 
>communications. They will only allow, to a certain extent, protection against 
>fake emails. But SPAM is junk mail, which includes official, albeit 
>unsolicited, communications from organizations that meet the requirements of 
>the technology. It is unethical, but technically acceptable.
>Moreover, the assessment of junk mail is highly subjective, for the reason I 
>prefer the term accepted censorship. Because censorship is an intervention 
>that, as a rule, cannot be influenced by the user. For the reason given, it is 
>not possible to protect against SPAM in its entirety. These technologies only 
>allow protection against fake mail.
>This leads me to the next step, which you may not agree with. If this 
>technology serves to protect against mail being counterfeited, it can be 
>argued, with a degree of simplification, that it provides some form of brand 
>protection. And the methods of brand protection, including the hardness of the 
>methods used, should be decided by the owner. And the enforcement of those 
>rules should be ensured by the administrator. Am I thinking correctly?
>

I think it is a mistake to consider technologies such as SPF, DKIM, and DMARC 
as anti-spam.  They are a component of spam mitigation, but authentication of 
an identifier isn't a solution for spam.  Meng Wong (for those of you that 
weren't around, he's the one that synthesized SPF out of previous proposals and 
was the early leader of the SPF project) used to say that SPF is not anti-spam 
in the same way that flour is not food.  I think that extends to DKIM and DMARC 
as well.

The challenge with the argument that this is brand protection, so the brand 
owner should decide is that it's primarily the receiver that needs to invest in 
integrating these technologies into their systems and accept the inevitable 
support burden that comes with them.  The brand owner wants something from the 
receiver, so it needs to be simple and reliable enough to be worthwhile.

SPF includes a policy mechanism so that receivers can reject mail that is not 
authorized by SPF.  Outside of small sites with a lot of control over their 
mail stream, it's almost never used .  It was tried and for large providers 
with a heterogeneous user base it wasn't cost effective to support due to the 
number of false positives and the associated tech support costs.

DMARC seems to be heading the same way due to domains using p=reject that (at 
least in my opinion) shouldn't.

Since there are no internet police, deployment of these technologies is a 
matter of incentives.  We do protocol design, not economics, so it's a tough 
problem in the IETF context, but we need to keep it in mind.  Getting the 
incentives right is probably the most important, but least tractable part of 
this.

Scott K

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

[Neil Anuskiewicz]

Doug, you’ve done a fine job of explaining as I groked what you said. If I get 
I think most people here got it. I’ve been busy with work and personal life so 
haven’t had as much time to lurk here. I’m curious what sparked your concern 
now? Also, isn’t it best to block first and ask questions later to mitigate 
damage while you investigate? I guess I’m saying the two ideas aren’t mutually 
exclusive.

Neil

> On Jul 15, 2023, at 4:27 AM, Douglas Foster 
>  wrote:
> 
> 
> Murray recently observed, correctly, that something went horribly wrong with 
> the DMARC rollout, because it caused (continues to cause) many safe and 
> wanted messages to be blocked.
> 
> My assessment was in a recent post:
> 
> Something about the language of RFC 7489 caused implementers to focus on 
> blocking individual messages, when the appropriate use of DMARC is to 
> identify and investigate potentially malicious sources.
> 
> The "message blocking" approach violates the interests of the users it is 
> intended to protect:
> 
> - An attacker sends 10 messages that maliciously impersonates a big bank.  
> With help from DMARC p=reject, the evaluator blocks them all.  The attacker 
> follows up with 10 messages that maliciously impersonate a major university.  
>  The stupid evaluator says, "p=none means no problem here".   The message is 
> accepted and the user is harmed because the evaluator learned nothing from 
> blocking the successful attack.
> 
> Consider a variant of the above:   The attacker never impersonates a big bank 
> with p=reject, it only impersonates big universities with p=none.   The 
> foolish evaluator blocks nothing because it only acts on domains with 
> p=reject.  Again, the user is harmed.
> 
> And we know the flip side:   Safe and wanted messages get blocked because 
> p=reject is enforced without investigation against mailing lists and other 
> traffic.
> 
> Security theory says that ANY unauthenticated message COULD be a malicious 
> impersonation, and worthy of investigation.   Experience says that malicious 
> impersonations are a small percentage of all unauthenticated messages.  As a 
> result, the appropriate response to an authentication failure is to 
> investigate, not to block.
> 
> I don't know exactly how to communicate the difference between message 
> blocking and sender investigation in DMARCbis, but I sure hope that we will 
> try.
> 
> Doug Foster
>  
> ___
> 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] How did DMARC go wrong, and how does our document fix it?

[Alessandro Vesely]

On Fri 21/Jul/2023 20:53:03 +0200 Jan Dušátko wrote:

Dne 21. 7. 2023 v 16:34 Murray S. Kucherawy napsal(a):

On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster 
 wrote:

My problem with your favorite line is that the domain owner's preference 
is of no interest to my filtering decision, but the DMARC result is.


Since even before SPF, people have been looking for a silver bullet to stop 
spam and phishing.  [...]


Although SPF, DKIM, DMARC, and ARC are all intended to protect against SPAM, it 
is not possible, as a matter of principle, to protect against such kind of 
communications. They will only allow, to a certain extent, protection against 
fake emails. But SPAM is junk mail, which includes official, albeit 
unsolicited, communications from organizations that meet the requirements of 
the technology.



Exactly.  The silver bullet goal was exactly to force spammers to send their 
junk with their own name and credentials.  At that point, the narration goes, 
it will be easy to obtain domain reputation or age.


That trend is already ongoing.  There are even specialized registrars.  For 
example NameSilo offers discounts for customers who buy 5000+ (privacy 
protected) domains[*].


To be precise, SPF, DKIM, DMARC, and ARC are intended to protect against spoof, 
not against spam.  Thereafter, the focus moves to registration data and 
reputation, balancing the right to anonymity with domain responsibility.  IMHO, 
anonymity has to be granted by someone who is not anonymous in turn.



Best
Ale
--

[*] https://www.namesilo.com/pricing












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

[Douglas Foster]

Yes, a message can be malicious or unwanted, with or without correct
identification.  But the two ARE correlated, not independent.  Correct
identity allows correct attribution of sender reputation.  Successful
impersonation allows an attacker to obtain more favorable treatment from
both the evaluator and the recipient.   Finally, there is a subset of
spammers who are unauthenticated because they are hasty and sloppy.

Overall, this means that the  probability of unwanted mail is higher when
the message cannot be authenticated.   (But I do not recommend filtering on
probabilities.).   Malicious email comes from malicious people.   When a
malicious email is detected, the question should always be, "what
identifiers can be used to identify and block messages from this malicious
actor?"   If you have an hour to spend on locking down your defenses,
investugating unauthenticated email is likely to be high payback

Doug

On Fri, Jul 21, 2023, 2:53 PM Jan Dušátko 
wrote:

>
>
> Dne 21. 7. 2023 v 16:34 Murray S. Kucherawy napsal(a):
> > On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster <
> > dougfoster.emailstanda...@gmail.com> wrote:
> >
> >> I don't take DMARC as a certain result to be used in isolation, but
> >> clearly a quorum evaluators do, and hence the mailing list problem that
> has
> >> caused such consternation.
> >>
> >> If we want to diminish their numbers, we have to communicate very
> >> differently than RFC 7489.
> >>
> >> My problem with your favorite line is that the domain owner's preference
> >> is of no interest to my filtering decision, but the DMARC result is.
> >>
> > Since even before SPF, people have been looking for a silver bullet to
> stop
> > spam and phishing.  I'm not surprised to hear that there are products out
> > there that promise or implement such, despite the specifications not
> > actually saying this is a good idea, or even (in DKIM's case, I believe)
> > being rather explicit that it isn't.
> >
> > I don't think anyone is disputing that the DMARC result by itself is not
> a
> > clear answer about what one should do upon receiving a message.  The only
> > time you really know something is when DMARC passes, but even that isn't
> a
> > strong signal about the content of the message.  All other answers are
> > muddy, and should be treated that way.  If DMARCbis needs to make this
> more
> > explicit, I don't see a problem with doing so.
> >
> > I think a DMARC-aware product that's reject-on-fail by default has made a
> > questionable choice, and not making that configurable is doubly so.
> >
> > However, I don't think an evaluator should be looking at the "p=" value
> and
> > then trying to infer anything about the sending domain solely from that.
> > This, to me, is crystal ball territory.  We should omit it from our
> > calculus.
> >
> > -MSK, participating
> >
> Although SPF, DKIM, DMARC, and ARC are all intended to protect against
> SPAM, it is not possible, as a matter of principle, to protect against
> such kind of communications. They will only allow, to a certain extent,
> protection against fake emails. But SPAM is junk mail, which includes
> official, albeit unsolicited, communications from organizations that
> meet the requirements of the technology. It is unethical, but
> technically acceptable.
> Moreover, the assessment of junk mail is highly subjective, for the
> reason I prefer the term accepted censorship. Because censorship is an
> intervention that, as a rule, cannot be influenced by the user. For the
> reason given, it is not possible to protect against SPAM in its
> entirety. These technologies only allow protection against fake mail.
> This leads me to the next step, which you may not agree with. If this
> technology serves to protect against mail being counterfeited, it can be
> argued, with a degree of simplification, that it provides some form of
> brand protection. And the methods of brand protection, including the
> hardness of the methods used, should be decided by the owner. And the
> enforcement of those rules should be ensured by the administrator. Am I
> thinking correctly?
>
> Regards
>
> Jan
>
> ___
> 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] How did DMARC go wrong, and how does our document fix it?

[Jan Dušátko]

Dne 21. 7. 2023 v 16:34 Murray S. Kucherawy napsal(a):

On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:


I don't take DMARC as a certain result to be used in isolation, but
clearly a quorum evaluators do, and hence the mailing list problem that has
caused such consternation.

If we want to diminish their numbers, we have to communicate very
differently than RFC 7489.

My problem with your favorite line is that the domain owner's preference
is of no interest to my filtering decision, but the DMARC result is.


Since even before SPF, people have been looking for a silver bullet to stop
spam and phishing.  I'm not surprised to hear that there are products out
there that promise or implement such, despite the specifications not
actually saying this is a good idea, or even (in DKIM's case, I believe)
being rather explicit that it isn't.

I don't think anyone is disputing that the DMARC result by itself is not a
clear answer about what one should do upon receiving a message.  The only
time you really know something is when DMARC passes, but even that isn't a
strong signal about the content of the message.  All other answers are
muddy, and should be treated that way.  If DMARCbis needs to make this more
explicit, I don't see a problem with doing so.

I think a DMARC-aware product that's reject-on-fail by default has made a
questionable choice, and not making that configurable is doubly so.

However, I don't think an evaluator should be looking at the "p=" value and
then trying to infer anything about the sending domain solely from that.
This, to me, is crystal ball territory.  We should omit it from our
calculus.

-MSK, participating

Although SPF, DKIM, DMARC, and ARC are all intended to protect against 
SPAM, it is not possible, as a matter of principle, to protect against 
such kind of communications. They will only allow, to a certain extent, 
protection against fake emails. But SPAM is junk mail, which includes 
official, albeit unsolicited, communications from organizations that 
meet the requirements of the technology. It is unethical, but 
technically acceptable.
Moreover, the assessment of junk mail is highly subjective, for the 
reason I prefer the term accepted censorship. Because censorship is an 
intervention that, as a rule, cannot be influenced by the user. For the 
reason given, it is not possible to protect against SPAM in its 
entirety. These technologies only allow protection against fake mail.
This leads me to the next step, which you may not agree with. If this 
technology serves to protect against mail being counterfeited, it can be 
argued, with a degree of simplification, that it provides some form of 
brand protection. And the methods of brand protection, including the 
hardness of the methods used, should be decided by the owner. And the 
enforcement of those rules should be ensured by the administrator. Am I 
thinking correctly?


Regards

Jan

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

[Murray S. Kucherawy]

On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I don't take DMARC as a certain result to be used in isolation, but
> clearly a quorum evaluators do, and hence the mailing list problem that has
> caused such consternation.
>
> If we want to diminish their numbers, we have to communicate very
> differently than RFC 7489.
>
> My problem with your favorite line is that the domain owner's preference
> is of no interest to my filtering decision, but the DMARC result is.
>

Since even before SPF, people have been looking for a silver bullet to stop
spam and phishing.  I'm not surprised to hear that there are products out
there that promise or implement such, despite the specifications not
actually saying this is a good idea, or even (in DKIM's case, I believe)
being rather explicit that it isn't.

I don't think anyone is disputing that the DMARC result by itself is not a
clear answer about what one should do upon receiving a message.  The only
time you really know something is when DMARC passes, but even that isn't a
strong signal about the content of the message.  All other answers are
muddy, and should be treated that way.  If DMARCbis needs to make this more
explicit, I don't see a problem with doing so.

I think a DMARC-aware product that's reject-on-fail by default has made a
questionable choice, and not making that configurable is doubly so.

However, I don't think an evaluator should be looking at the "p=" value and
then trying to infer anything about the sending domain solely from that.
This, to me, is crystal ball territory.  We should omit it from our
calculus.

-MSK, participating
___
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?

[Dotzero]

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. 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Mark Alley]

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 adminis

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[OLIVIER HUREAU]

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 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Douglas Foster]

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 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. It knows nothing about
> reputation. DMARC is not a substitute for other filtering or reputation
> systems. DMARC is not a Swiss Army knife, was never intended to be one, nor
> is it appropriate to pretend you can contort it into one.
>
> I absolutely agree with John regarding his comments and agree with his
> sentiment of " I am so tired of people imagining that DMARC is more than it
> is."
>
> Michael Hammer
>
>
>>
>> Doug
>>
>>
>>
>>
>> On Wed, Jul 19, 2023 at 5:32 PM John Levine  wrote:
>>
>>> It appears that Barry Leiba   said:
>>> >> - An attacker sends 10 messages that maliciously impersonates a
>>> >> big bank.  With help from DMARC p=reject, the evaluator blocks
>>> >> them all.  The attacker follows up with 10 messages that
>>> >> maliciously impersonate a major university.   The stupid
>>> >> evaluator says, "p=none means no problem here".   The message is
>>> >> accepted and the user is harmed because the evaluator learned
>>> >> nothing from blocking the successful attack.
>>> >
>>> >This is a useful point, and I think we should do something with it.
>>>
>>> Sorry, but I completely disagree.
>>>
>>> The interesting filtering data is that a bunch of unauthenticated mail
>>> arrived from some source. As we have learned over and over, someone's
>>> DMARC policy tells you nothing about the threat level or whether the
>>> failure is 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Douglas Foster]

I don't take DMARC as a certain result to be used in isolation, but clearly
a quorum evaluators do, and hence the mailing list problem that has caused
such consternation.

If we want to diminish their numbers, we have to communicate very
differently than RFC 7489.

My problem with your favorite line is that the domain owner's preference is
of no interest to my filtering decision, but the DMARC result is.

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. It knows nothing about
> reputation. DMARC is not a substitute for other filtering or reputation
> systems. DMARC is not a Swiss Army knife, was never intended to be one, nor
> is it appropriate to pretend you can contort it into one.
>
> I absolutely agree with John regarding his comments and agree with his
> sentiment of " I am so tired of people imagining that DMARC is more than it
> is."
>
> Michael Hammer
>
>
>>
>> Doug
>>
>>
>>
>>
>> On Wed, Jul 19, 2023 at 5:32 PM John Levine  wrote:
>>
>>> It appears that Barry Leiba   said:
>>> >> - An attacker sends 10 messages that maliciously impersonates a
>>> >> big bank.  With help from DMARC p=reject, the evaluator blocks
>>> >> them all.  The attacker follows up with 10 messages that
>>> >> maliciously impersonate a major university.   The stupid
>>> >> evaluator says, "p=none means no problem here".   The message is
>>> >> accepted and the user is harmed because the evaluator learned
>>> >> nothing from blocking the successful attack.
>>> >
>>> >This is a useful point, and I think we should do something with it.
>>>
>>> Sorry, but I completely disagree.
>>>
>>> The interesting filtering data is that a bunch of unauthenticated mail
>>> arrived from some source. As we have learned over and over, someone's
>>> DMARC policy tells you nothing about the threat level or whether the
>>> failure is an attack or a mailing list, only that someone decided for
>>> whatever reason to publish p=reject.
>>>
>>> If a source sends a burst of unauthenticated mail, it could often be a
>>> good idea to give that source a poor reputation. Or maybe you have a
>>> reason to believe otherwise, e.g., it's been sending bursts of
>>> 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Dotzero]

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. It knows nothing about
reputation. DMARC is not a substitute for other filtering or reputation
systems. DMARC is not a Swiss Army knife, was never intended to be one, nor
is it appropriate to pretend you can contort it into one.

I absolutely agree with John regarding his comments and agree with his
sentiment of " I am so tired of people imagining that DMARC is more than it
is."

Michael Hammer


>
> Doug
>
>
>
>
> On Wed, Jul 19, 2023 at 5:32 PM John Levine  wrote:
>
>> It appears that Barry Leiba   said:
>> >> - An attacker sends 10 messages that maliciously impersonates a
>> >> big bank.  With help from DMARC p=reject, the evaluator blocks
>> >> them all.  The attacker follows up with 10 messages that
>> >> maliciously impersonate a major university.   The stupid
>> >> evaluator says, "p=none means no problem here".   The message is
>> >> accepted and the user is harmed because the evaluator learned
>> >> nothing from blocking the successful attack.
>> >
>> >This is a useful point, and I think we should do something with it.
>>
>> Sorry, but I completely disagree.
>>
>> The interesting filtering data is that a bunch of unauthenticated mail
>> arrived from some source. As we have learned over and over, someone's
>> DMARC policy tells you nothing about the threat level or whether the
>> failure is an attack or a mailing list, only that someone decided for
>> whatever reason to publish p=reject.
>>
>> If a source sends a burst of unauthenticated mail, it could often be a
>> good idea to give that source a poor reputation. Or maybe you have a
>> reason to believe otherwise, e.g., it's been sending bursts of
>> unauthenticated mail for years, nobody's ever marked it as spam,
>> because it's some kind of courtesy forward.
>>
>> Note that you would do exactly the same thing if the burst of
>> unauthenticated university mail preceded the burst of bank mail. It's
>> the authentication failure that tells you that there may be a problem,
>> not the DMARC policy.
>>
>> Mail filtering is complicated, so much so that handling the signals is
>> more than a full time job at many mail systems. I expect that large
>> mail systems have their own ideas abou who's a bank, who's a
>> university, who's a public 

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Douglas Foster]

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.

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.

Doug




On Wed, Jul 19, 2023 at 5:32 PM John Levine  wrote:

> It appears that Barry Leiba   said:
> >> - An attacker sends 10 messages that maliciously impersonates a
> >> big bank.  With help from DMARC p=reject, the evaluator blocks
> >> them all.  The attacker follows up with 10 messages that
> >> maliciously impersonate a major university.   The stupid
> >> evaluator says, "p=none means no problem here".   The message is
> >> accepted and the user is harmed because the evaluator learned
> >> nothing from blocking the successful attack.
> >
> >This is a useful point, and I think we should do something with it.
>
> Sorry, but I completely disagree.
>
> The interesting filtering data is that a bunch of unauthenticated mail
> arrived from some source. As we have learned over and over, someone's
> DMARC policy tells you nothing about the threat level or whether the
> failure is an attack or a mailing list, only that someone decided for
> whatever reason to publish p=reject.
>
> If a source sends a burst of unauthenticated mail, it could often be a
> good idea to give that source a poor reputation. Or maybe you have a
> reason to believe otherwise, e.g., it's been sending bursts of
> unauthenticated mail for years, nobody's ever marked it as spam,
> because it's some kind of courtesy forward.
>
> Note that you would do exactly the same thing if the burst of
> unauthenticated university mail preceded the burst of bank mail. It's
> the authentication failure that tells you that there may be a problem,
> not the DMARC policy.
>
> Mail filtering is complicated, so much so that handling the signals is
> more than a full time job at many mail systems. I expect that large
> mail systems have their own ideas abou who's a bank, who's a
> university, who's a public mail system, and so forth. You get exactly
> none of that from DMARC. After all, yahoo is p=reject, gmail and
> hotmail/outlook are p=none.
>
> I am so tired of people imagining that DMARC is more than it is.
>
> R's,
> John
>
> ___
> 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] How did DMARC go wrong, and how does our document fix it?

[John Levine]

It appears that Barry Leiba   said:
>> - An attacker sends 10 messages that maliciously impersonates a
>> big bank.  With help from DMARC p=reject, the evaluator blocks
>> them all.  The attacker follows up with 10 messages that
>> maliciously impersonate a major university.   The stupid
>> evaluator says, "p=none means no problem here".   The message is
>> accepted and the user is harmed because the evaluator learned
>> nothing from blocking the successful attack.
>
>This is a useful point, and I think we should do something with it.

Sorry, but I completely disagree.

The interesting filtering data is that a bunch of unauthenticated mail
arrived from some source. As we have learned over and over, someone's
DMARC policy tells you nothing about the threat level or whether the
failure is an attack or a mailing list, only that someone decided for
whatever reason to publish p=reject.

If a source sends a burst of unauthenticated mail, it could often be a
good idea to give that source a poor reputation. Or maybe you have a
reason to believe otherwise, e.g., it's been sending bursts of
unauthenticated mail for years, nobody's ever marked it as spam,
because it's some kind of courtesy forward.  

Note that you would do exactly the same thing if the burst of
unauthenticated university mail preceded the burst of bank mail. It's
the authentication failure that tells you that there may be a problem,
not the DMARC policy.

Mail filtering is complicated, so much so that handling the signals is
more than a full time job at many mail systems. I expect that large
mail systems have their own ideas abou who's a bank, who's a
university, who's a public mail system, and so forth. You get exactly
none of that from DMARC. After all, yahoo is p=reject, gmail and
hotmail/outlook are p=none.

I am so tired of people imagining that DMARC is more than it is.

R's,
John

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

[Barry Leiba]

> - An attacker sends 10 messages that maliciously impersonates a
> big bank.  With help from DMARC p=reject, the evaluator blocks
> them all.  The attacker follows up with 10 messages that
> maliciously impersonate a major university.   The stupid
> evaluator says, "p=none means no problem here".   The message is
> accepted and the user is harmed because the evaluator learned
> nothing from blocking the successful attack.

This is a useful point, and I think we should do something with it.  I
don't think it belongs in this document -- the DMARC protocol -- but I
*do* think it's in scope for this working group and would be good to
cover in a BCP that talks about how to use DMARC as *part* of an
overall antispam/antiphishing/antispoofing system.  Specifically, use
the results you get from blocking with DMARC -- with sensible analysis
to assure yourself that this is mail that *should* be blocked -- to
train the system to better detect similar junk that doesn't have DMARC
to help it.

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?

[John Levine]

It appears that OLIVIER HUREAU   said:
>-=-=-=-=-=-
>
>Hi, 
>
>> The stupid evaluator says, "p=none means no problem here". 
>
>And the non-stupid evaluator knows that p=none means that the domain owner 
>doesn't (yet) have the appropriate sending infrastructure to have
>p=reject. 

Or it means that the domain owner has decided that the costs of
p=reject outweigh the benefits, and has no plans ever to change.
Either way I agree it doesn't mean "no problem here".

R's,
John

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

[Douglas Foster]

I know what "p=none" means to the sender, but that is no reason to ignore
authentication failures when "p=none" or "no policy".

About DMARC wrong results:

We will always have these types of messages:
1) Domain owner messages transmitted and received with authentication
2) Domain owner messages transmitted without authentication
3) Domain owner messages transmitted with authentication but received
without authentication
4) Messages originating outside domain owner control for the benefit of a
domain member
5) Messages originating outside domain owner control for bad purposes

"p=reject" simply tells the evaluator that the domain owner believes he
will never see a message in category 2.  In many cases, this assertion is
even true, but alas not always.The domain owner cannot know whether
the evaluator will receive messages in category 3 or 4.   Nor can he tell
the evaluator how to distinguish unwanted category 5 messages from the
messages in category 3 or 4.

My main point was that DMARC FAIL is always a probability, not a certainty,
so evaluators who treat it as a certainty are unwise.

But about how to handle "p=none":

"p=none" says that the evaluator might receive a message in category 2.
 Based on this discussion, another reason for "p=none" is that the domain
owner is afraid of category 3 and 4 messages being rejected if they move to
"p=reject".

The only way for an evaluator to distinguish between the last three
categories is to examine messages in greater detail, so that a judgement
can be made about the identity of the sender and the motivation of the
sender.   This really needs to be done only once.   After concluding that
the sender is malicious or his messages are unwanted, the sender needs to
be blocked.   After concluding that the sender is benign and his messages
are wanted, a local policy needs to be configured to authenticate that mail
stream using alternate methods.  (Alternate authentication does not require
exemption from content filtering.)

Since any unauthenticated message carries an impersonation risk, every
unauthenticated message should be considered for in-depth review.As
reviews are completed, the volume of messages requiring review gets
steadily smaller.

As you observed, lots of authenticated accounts are used for malicious
purposes, but that is not relevant here.   Experience has shown that
unauthenticated traffic has a high percentage of malicious and unwanted
messages, so time spent pruning out that traffic is time well spent.  If
there is value in the sender's disposition policy, it is as a tool for
prioritizing which messages should be reviewed first.

Doug Foster





On Sun, Jul 16, 2023 at 6:50 PM OLIVIER HUREAU <
olivier.hur...@univ-grenoble-alpes.fr> wrote:

> Hi,
>
> >  The stupid evaluator says, "p=none means no problem here".
>
> And the non-stupid evaluator knows that p=none means that the domain owner
> doesn't (yet) have the appropriate sending infrastructure to have p=reject.
>
>
> > The appropriate response to an authentication failure is to
> investigate, not to block.
>
> When I first became interested in DMARC, I thought the idea of forensic
> reports was brilliant, as I was able to carry out investigations thanks to
> them. Today, however, forensic reports are not a trend.
> How can you properly investigate with limited information on the aggregate
> report?
>
> > that maliciously impersonate a major university
>
> It is not that related to DMARC but from what I've seen in France,
> scammers do not spoof domains name. They already have a pool of infected
> users in other universities and use those credentials to send us phishing
> emails (all the phishing I have seen comes from authenticated users at
> other universities)
>
> > How did DMARC go wrong?
>
> This is just my opinion, and I've published very little on this list. I
> just curiously read the discussions (especially the catchy subject like
> this one).
> I think DMARC went wrong as soon as the big organizations started to break
> away from the IETF and RFC7489 in particular.
> You only have to look at the inconsistencies between what is suggested and
> stated in the RFC and what happens in reality to understand why it went
> wrong.
>
>
> Best,
> Olivier Hureau
>
> --
> *De: *"Douglas Foster" 
> *À: *"IETF DMARC WG" 
> *Envoyé: *Samedi 15 Juillet 2023 13:27:04
> *Objet: *[dmarc-ietf] How did DMARC go wrong, and how does our document
> fix it?
>
> Murray recently observed, correctly, that something went horribly wrong
> with the DMARC rollout, because it caused (continues to cause) many safe
> and wanted messages to be blocked.
> My assessment was in a recent post:
>
> Some

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[OLIVIER HUREAU]

Hi, 

> The stupid evaluator says, "p=none means no problem here". 

And the non-stupid evaluator knows that p=none means that the domain owner 
doesn't (yet) have the appropriate sending infrastructure to have p=reject. 


> The appropriate response to an authentication failure is to investigate, not 
> to block. 

When I first became interested in DMARC, I thought the idea of forensic reports 
was brilliant, as I was able to carry out investigations thanks to them. Today, 
however, forensic reports are not a trend. 
How can you properly investigate with limited information on the aggregate 
report? 

> that maliciously impersonate a major university 

It is not that related to DMARC but from what I've seen in France, scammers do 
not spoof domains name. They already have a pool of infected users in other 
universities and use those credentials to send us phishing emails (all the 
phishing I have seen comes from authenticated users at other universities) 

> How did DMARC go wrong? 

This is just my opinion, and I've published very little on this list. I just 
curiously read the discussions (especially the catchy subject like this one). 
I think DMARC went wrong as soon as the big organizations started to break away 
from the IETF and RFC7489 in particular. 
You only have to look at the inconsistencies between what is suggested and 
stated in the RFC and what happens in reality to understand why it went wrong. 


Best, 
Olivier Hureau 


De: "Douglas Foster"  
À: "IETF DMARC WG"  
Envoyé: Samedi 15 Juillet 2023 13:27:04 
Objet: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it? 

Murray recently observed, correctly, that something went horribly wrong with 
the DMARC rollout, because it caused (continues to cause) many safe and wanted 
messages to be blocked. 
My assessment was in a recent post: 

Something about the language of RFC 7489 caused implementers to focus on 
blocking individual messages, when the appropriate use of DMARC is to identify 
and investigate potentially malicious sources. 

The "message blocking" approach violates the interests of the users it is 
intended to protect: 

- An attacker sends 10 messages that maliciously impersonates a big bank. With 
help from DMARC p=reject, the evaluator blocks them all. The attacker follows 
up with 10 messages that maliciously impersonate a major university. The stupid 
evaluator says, "p=none means no problem here". The message is accepted and the 
user is harmed because the evaluator learned nothing from blocking the 
successful attack. 

Consider a variant of the above: The attacker never impersonates a big bank 
with p=reject, it only impersonates big universities with p=none. The foolish 
evaluator blocks nothing because it only acts on domains with p=reject. Again, 
the user is harmed. 

And we know the flip side: Safe and wanted messages get blocked because 
p=reject is enforced without investigation against mailing lists and other 
traffic. 

Security theory says that ANY unauthenticated message COULD be a malicious 
impersonation, and worthy of investigation. Experience says that malicious 
impersonations are a small percentage of all unauthenticated messages. As a 
result, the appropriate response to an authentication failure is to 
investigate, not to block. 

I don't know exactly how to communicate the difference between message blocking 
and sender investigation in DMARCbis, but I sure hope that we will try. 

Doug Foster 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

[Douglas Foster]

Murray recently observed, correctly, that something went horribly wrong
with the DMARC rollout, because it caused (continues to cause) many safe
and wanted messages to be blocked.

My assessment was in a recent post:

Something about the language of RFC 7489 caused implementers to focus on
blocking individual messages, when the appropriate use of DMARC is to
identify and investigate potentially malicious sources.

The "message blocking" approach violates the interests of the users it is
intended to protect:

- An attacker sends 10 messages that maliciously impersonates a big bank.
With help from DMARC p=reject, the evaluator blocks them all.  The attacker
follows up with 10 messages that maliciously impersonate a major
university.   The stupid evaluator says, "p=none means no problem here".
 The message is accepted and the user is harmed because the evaluator
learned nothing from blocking the successful attack.

Consider a variant of the above:   The attacker never impersonates a big
bank with p=reject, it only impersonates big universities with p=none.
 The foolish evaluator blocks nothing because it only acts on domains with
p=reject.  Again, the user is harmed.

And we know the flip side:   Safe and wanted messages get blocked because
p=reject is enforced without investigation against mailing lists and other
traffic.

Security theory says that ANY unauthenticated message COULD be a malicious
impersonation, and worthy of investigation.   Experience says that
malicious impersonations are a small percentage of all unauthenticated
messages.  As a result, the appropriate response to an authentication
failure is to investigate, not to block.

I don't know exactly how to communicate the difference between message
blocking and sender investigation in DMARCbis, but I sure hope that we will
try.

Doug Foster
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc