On Tue, Jul 11, 2023, at 7:49 PM, Wei Chuang wrote:
> Also can we do more to harden SPF? The SPF upgrade attacks needs three
> things:
> • IPs shared by multiple sending domains
> • Some sender uses those IPs that permits spam and phish traffic
> • Those multiple sending domains have SPF policies that include those IPs
To the last item. We (as an ESP) only send with relaxed SPF alignment. Therefor
our SPF include should [ideally] not be on the RFC5322.From domain (granted, I
am working on revising some docs that still rely on PRA assumptions).
> Perhaps one way to harden to SPF for DMARC is to detect if the IPs are
> shared. The authenticator in addition to regular to SPF validation, might be
> able to use reverse PTR lookup and match the SPF record domain name (or match
> some subset like the org domain) to forward validate. Only one domain can
> claim ownership for the IPs and be allowed to SPF authenticate for DMARC.
I think that with relaxed alignment it requires that a potential spoofer
(through our service) to be able to produce an SPF aligned result that is a
subdomain of the RFC5322.From domain (which I don't think is happening with the
SPF upgrade attacks today, at least for us) and the spoofer would need to be
able to know and use the same subdomain (which includes our SPF) that has a
high reputation in your trust models. I do have concerns about penalizing
shared IPs in general, since they are a necessity with IPv4.
Jesse
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
