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

[Wei Chuang <[e-mail]>]

On Fri, Apr 14, 2023 at 8:13 PM Emanuel Schorsch <emschorsch=
[e-mail]> wrote:

> 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.
>

Emphatically agreed.


>
> 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
>>
>
I think DMARC (and -bis) as sender policy declaration protocol is fine.
Yes there is an interop problem, but the blame is misplaced.  DMARC depends
on email authentication protocols DKIM and SPF that break with legitimate
and commonplace forwarding flows that modify messages.  The place where the
IETF ought to put effort is updating the email authentication protocols to
support forwarders that modify the message.  To illustrate what is needed,
such a protocol must support mailing lists when they modify the Subject
header or add a footer to a mime part, and support enterprise gateways that
sometimes rewrites part of the message or deletes a dangerous attachment.
And I'm sure there are other important scenarios that the folks on this
list can help fill in.  One approach might be to update DKIM or SPF but I
doubt something can be done with those protocols that will support
forwarding with message modification and will be backwards compatible.
Another better approach in my opinion is to develop another email
authentication protocol that explicitly supports forwarding with message
modification.  Have DMARC-bis accept that third email authentication
protocol.  Yes it will be a long hard road, but I suspect that the
different parts of the community are incentivized to make this work.  The
alternative is to tolerate sender's FROM header identity spoofing and the
phishing that goes with it, or to tolerate missing wanted mail that gets
rejected or sent to the spam folder.  Neither seems like a good place for
email.
-Wei