Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Jim Fenton]

On 10 Sep 2023, at 18:14, Dotzero wrote:

>> I agree that the SHOULD language is not very useful because it’s likely to
>> be interpreted as only advice. Instead, I think we need a stronger
>> statement about the consequences of this policy. For example, “Domains
>> publishing p=reject MUST NOT expect mail to mailing lists and similar
>> forwarders to be delivered reliably.”
>>
>
> The “MUST NOT you suggest is normative language that many will ignore with
> no particular incremental negative impact to them beyond the current
> situation. I'm not thrilled with the proposed SHOULD NOT language but it
> makes much more sense to me than your proposal.

One of the fundamental problems here is that the domain publishing the policy 
is only indirectly affected by the negative consequences of a p=reject policy. 
The MUST NOT that I proposed was intentionally to get the reader’s attention, 
and directly point out what bad things might occur.

Of course, that assumes that the decision makers are reading the specification 
itself, and not some vendor marketing material. That is probably not a safe 
assumption.

-Jim

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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Dotzero]

On Mon, Sep 11, 2023 at 6:36 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> We are still trying to fix an evaluator problem by changing domain
> owner behavior.  No harm in giving domain owners the warning, but changing
> evaluator behavior would be much better.   Presumably, the evaluator
> behavior that we have today is the result of RFC 7489 wording, so we may be
> able to change future evaluator behavior by strategizing the language of
> DMARCbis.
>

IETF is not the behavior police.


>
> Compare email authentication to a controlled-access building.   On any
> given day, some employees will arrive at work to discover that their badge
> is back at home.   How is it handled?   By sending the employee to the
> physical equivalent of quarantine:  the pass office.Most employees can
> be validated by another method, such as driver's license or biometrics.
>  An employee who forgot his wallet and cannot be verified by biometrics
> will lose a day's work.   However, a person who is identified as using a
> fake ID will be led away by police.
>
> Email authentication is not much different.   We are judging message
> source acceptability, not individual messages.
>

Absolutely incorrect. DMARC is a deterministic pass|fail approach based on
validation through DKIM or SPF pass (or if both pass). It says nothing
about the acceptability/goodness/badness of a source.

100% email authentication is possible and should be the goal.   Quarantine
> is the preferred place to send unauthenticated mail, regardless of sender
> policy (or lack of policy).In quarantine, acceptable messages are given
> alternate authentication and released, just as the secure-building employee
> is given a temporary badge or replacement badge.   If lack of authenticated
> is discovered to be a fraudulent attacker, then all messages from the
> attacker should be blocked, not just the impersonation messages.
>
> When it seems impossible to quarantine and review every unauthenticated
> message, triage becomes necessary.  The messages with highest perceived
> risk are sent to quarantine and the lower-risk messages are released and
> reviewed as time permits after the fact.
>

This is the dumbest approach possible. Think about it. What you are saying
is "With all our expertise, technology and automation, we are going to hand
the messages we think are the riskiest to you, the end user, who has no
expertise to figure out whether this message is safe". What is wrong with
this picture?


> Either way, the workload steadily decreases as message sources become
> permanently authenticated or permanently blocked.
>

Maybe the workload decreases and maybe it doesn't. You are making a huge
assumption that an authenticated message source will permanently be
authenticated and a blocked message source will permanently be "bad". This
approach creates real problems. In any event, this isn't how DMARC works.
DMARC validates each message on its own. DMARC does not involve reputation.
Please stop trying to conflate things outside of DMARC with DMARC.

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

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Douglas Foster]

We are still trying to fix an evaluator problem by changing domain
owner behavior.  No harm in giving domain owners the warning, but changing
evaluator behavior would be much better.   Presumably, the evaluator
behavior that we have today is the result of RFC 7489 wording, so we may be
able to change future evaluator behavior by strategizing the language of
DMARCbis.

Compare email authentication to a controlled-access building.   On any
given day, some employees will arrive at work to discover that their badge
is back at home.   How is it handled?   By sending the employee to the
physical equivalent of quarantine:  the pass office.Most employees can
be validated by another method, such as driver's license or biometrics.
 An employee who forgot his wallet and cannot be verified by biometrics
will lose a day's work.   However, a person who is identified as using a
fake ID will be led away by police.

Email authentication is not much different.   We are judging message source
acceptability, not individual messages.  100% email authentication is
possible and should be the goal.   Quarantine is the preferred place to
send unauthenticated mail, regardless of sender policy (or lack of
policy).In quarantine, acceptable messages are given alternate
authentication and released, just as the secure-building employee is given
a temporary badge or replacement badge.   If lack of authenticated is
discovered to be a fraudulent attacker, then all messages from the attacker
should be blocked, not just the impersonation messages.

When it seems impossible to quarantine and review every unauthenticated
message, triage becomes necessary.  The messages with highest perceived
risk are sent to quarantine and the lower-risk messages are released and
reviewed as time permits after the fact.   Either way, the workload
steadily decreases as message sources become permanently authenticated or
permanently blocked.

Doug Foster


On Sun, Sep 10, 2023 at 8:46 PM Jim Fenton  wrote:

> On 7 Sep 2023, at 9:28, Wei Chuang wrote:
>
> Many enterprises already have "p=reject" policies. Presumably those
> domains were subject to some sort of spoofing which is why they went to
> such a strict policy.
>
> This is not necessarily the case. For example, DHS has directed
> 
> all Executive Branch federal agencies to publish a policy of reject,
> regardless of whether they were subject to spoofing (and with no mention of
> the problems with doing so. Others have published “Email Security Best
> Practices” advocating the use of p=reject. For example, one well-known
> email vendor has a tool that generates a warning if p=quarantine or
> p=reject isn’t configured, and says on their website, “We recommend reject,
> for reasons we’ll touch on later.”
>
> I agree that the SHOULD language is not very useful because it’s likely to
> be interpreted as only advice. Instead, I think we need a stronger
> statement about the consequences of this policy. For example, “Domains
> publishing p=reject MUST NOT expect mail to mailing lists and similar
> forwarders to be delivered reliably.”
>
> -Jim
> ___
> 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