Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

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 polic

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

Michael,As someone who did work for an ESP, your bit about the conflict between short term cash flow that a short term customer with some money to spend for a few months and the optimizing for customer lifetime value. That war, or shall I say tension, was always there. I’d imagine the little ESP I

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

> On Jul 12, 2023, at 3:47 AM, Scott Kitterman wrote: > > It's not news that there's a risk for SPF associated with shared IP > addresses. > That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before. > > I understand your view and agree on the problem. I also sympathize with

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

On Wed, Jul 12, 2023 at 6:47 AM Scott Kitterman wrote: > It's not news that there's a risk for SPF associated with shared IP > addresses. > That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before. > +1 > > I understand your view and agree on the problem. I also sympathize with

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

It's not news that there's a risk for SPF associated with shared IP addresses. That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before. I understand your view and agree on the problem. I also sympathize with the need to technically address conditions as they exist in operations

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

Hi, each mechanism approaches the problem in a different way: - SPF authorizes selected hosts (machines approved to send mail) - DKIM authenticates sender (proof of origin) - ARC authenticate senders chain (also proof of origin, but also proof of whole communication chain) we can also continue

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

So we disable SPF when the sender tells us to do so., but leave it enabled by defaultThat makes a lot of sense to me. When the domain passes SPF on a shared server farm, but provides no DKIM signatures, I currently have no choice other than to consider the message to be authenticated. The AUT

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

The data we presented June 20th (archive ) also suggests that it is premature to drop SPF from DMARC. However I differ in believing that we should accept the spoofing risk demonstrated recently via SPF, and that we shouldn't

[dmarc-ietf] Protocols All The Way Down (long - sorry)

I've been thinking about the thread on ditching SPF relative to DMARC. DMARC is built on other protocols. Piles of them. DMARC is built most directly on DNS, DKIM, and SPF. It is also built on SMTP and Email. DKIM and SPF are also built on DNS and SMTP (SPF) or Email (DKIM). These protocols