On June 26, 2023 12:51:06 PM UTC, [email protected] wrote:
>
>> In theory, DKIM is enough for DMARC (this was always true), but in practice
>> it
>> is not.
>
>May be you can afford to use SPF, DKIM, DMARC in pure theory for your day job,
>but people here expect to apply it to solve real problems with real email in
>real life.
>*SCNR* ... do not take that personally.
>
>
>> I don't think there's evidence of a systemic weakness in the protocol. We've
>> seen evidence of poor deployment of the protocol for SPF, but I think the
>> solution is to fix that (see the separate thread on data hygiene).
>
>
>The problem with DMARC is, there's no easy way to decide you can rely on SPF
>as long as it references shared IP infrastructure (because you can't decide
>whether an IP is shared or dedicated).
>In my view this is a tremendous weakness of the SPF protocol.
>(maybe only 'cause I do not trust shared infrastructure providers to get their
>customers right all the time, 'cause I know how hard that is from being an ISP
>mailer)
>
>So to remove or at least ignore SPF from DMARC is minimal requirement for
>DMARC being worth mentioning supportive of sender authentication at all.
>Meanwhile it's a pretty viable attack vector against DMARC, foiling the idea
>of sender authentication.
That's true if you change the semantics of what a DMARC pass means. It means
it came via an authorized source. It does not mean anything about if the
message is "good" or "bad". It doesn't and can't solve the problem of
inappropriately injected mail in the authorized stream.
When a domain publishes a public key in its DNS that's been given to it by a
third party provider, DKIM is also exposed to third party provider data hygiene
risks.
Even if DKIM were perfect and we ditch SPF, users get compromised and bad stuff
still gets into the authenticated stream.
I think people are attributing a lot of badness to SPF when it's a more general
problem. It's just easier to identify with SPF. Currently, bad ingress
controls for third party providers mostly imposes external costs (from their
point of view). Until that changes, it will be a mess no matter what the
underlying authentication technology is.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
