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

[Mark Alley <[e-mail]>]

I'm aware of some mail relays of several orgs and a few SaaS providers that
from munge to prevent spoofing of other domain's from their internal
users/servers that may be sending through them.

I believe NETsuite is one such example, not necessarily conditionally, it's
just blanket munging (regardless of policy) with the display name field
reflecting the actual sender.

- Mark Alley


On Fri, Apr 14, 2023, 10:28 PM Scott Kitterman <[e-mail]> wrote:

> 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
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>