Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Emanuel Schorsch <[e-mail]>]

I agree there are no silver bullets. But different policies make fighting
abuse harder or easier. To give a concrete example we see huge volumes of
abuse spoofing "gmail.com" fromHeader. There are also a huge number of
benign parties that have become accustomed to spoofing "gmail.com". This
makes it much more challenging to get it perfectly right when
distinguishing the abusive cases from the benign cases. I point this out
mainly to emphasize two points:
1) There is real abuse happening for domains that don't yet have a policy
beyond p=none. This abuse has noticeably higher volumes than other sources
of spoofing.
2) When benign traffic routinely follows the same practices as
spammers/phishers it makes it more difficult to cleanly separate the
buckets.

Compare this to the abuse levels we see spoofing Paypal, a domain with a
p=reject policy. Of course there's no silver bullet and the levels aren't
zero. There is DisplayName spoofing, there is cousin domain spoofing. But,
it is substantially easier to mitigate against these because there are very
few benign users sending mail from paypaI.com (using a capital i), or using
a display name of "Paypal" signing with random domains and sending large
volumes. From what I have seen, spoofing a domain like Paypal is
substantially harder to scale because the benign and abusive cases are much
more cleanly separated.

I would love to find a way for Mailing Lists to operate without the pain of
from-munging and also give domains like gmail.com a tool to protect
themselves. Obviously we are not there yet, so instead there is a very real
and painful tradeoff to consider. I don't know what the solution is (maybe
mailing lists can use from-munging, ARC and X-Original-From and destination
receivers that participate can then unmunge it if that receiving user
trusts that mailing list?). But I think we should be able to agree that
there is a real security risk that stricter DMARC policies provide value
against, AND that those stricter policies degrade the mailing list
experience. Of course that says nothing about whether or not that tradeoff
is reasonable or should be made :)

Instead of being forced to pick between two unappealing options I would
love to put more effort into figuring out solutions that make both cases
work. Maybe there is no solution. But I am optimistic that with some
creative thinking and group problem solving we can work out something that
protects against domain impersonation and allows Mailing Lists to work more
effectively than the current solutions.

On Fri, Apr 14, 2023 at 10:08 PM Murray S. Kucherawy <[e-mail]>
wrote:

> On Fri, Apr 14, 2023 at 6:47 PM Douglas Foster <
> [e-mail]> wrote:
>
>> Unless a mailing list has controls in place to ensure that EVERY post
>> comes from the asserted participant, it is the height of hypocrisy to ask
>> an evaluator to assume that the post is from the asserted participant.
>>  IETF cannot do even the easiest part of that task, so I have no reason to
>> expect better elsewhere.
>>
>
> Nobody is asking the evaluator to assume anything.  That's what email
> authentication is about; it shouldn't assume anything, and you only really
> know something when you get a "pass".  Reacting harshly to a "fail" when
> there are so many legitimate ways the current authentication schemes can
> fail is folly.  But people are looking for silver bullets, so here we are.
>
> A world free of fraudulent email is a laudable goal, of course.  But since
> DMARC can only actually affect direct domain attacks, and makes no
> discernible attempt to mitigate cousin domain or display name attacks to
> which attackers can trivially switch, I think I'd like to see some proof
> that it staves off enough of the darkness to be worth this level of defense.
>
> -MSK, participating
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>