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

[Scott Kitterman <[e-mail]>]

One thing that would be super nice and not have any negative interoperability 
impacts relative to DMARC is if the From munging was limited to domains that 
publish p=reject (as this list does).  I don't recall having seen it outside 
IETF lists.

Scott K

On Friday, April 14, 2023 11:12:25 PM EDT Emanuel Schorsch 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.
> 
> 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