Re: [dmarc-ietf] DMARC and Data Hygiene

2023-06-20 Thread Dotzero
On Tue, Jun 20, 2023 at 11:18 AM Scott Kitterman wrote: > I am starting a separate thread, because this isn't just about SPF. > > I think the criticism of the reliability of SPF data is valid, but I think > DKIM is similarly problematic. Once you get rid of SPF, you'll find you > haven't really

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-20 Thread Scott Kitterman
On June 20, 2023 4:33:48 PM UTC, John Levine wrote: >It appears that Tobias Herkula said: >>-=-=-=-=-=- >>Sadly they can’t, there are Mailbox Providers that expect SPF Records, so to >>maintain deliverability to those, you have to keep SPF >>records in place and can’t switch to an DKIM only

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-20 Thread John Levine
It appears that Tobias Herkula said: >-=-=-=-=-=- >Sadly they can’t, there are Mailbox Providers that expect SPF Records, so to >maintain deliverability to those, you have to keep SPF >records in place and can’t switch to an DKIM only DMARC. Nobody's saying you can't publish SPF. We're just

[dmarc-ietf] DMARC and Data Hygiene

2023-06-20 Thread Scott Kitterman
I am starting a separate thread, because this isn't just about SPF. I think the criticism of the reliability of SPF data is valid, but I think DKIM is similarly problematic. Once you get rid of SPF, you'll find you haven't really solved much. The next logical step will be to get rid of DKIM.

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

2023-06-20 Thread Todd Herr
On Mon, Jun 19, 2023 at 8:25 PM John R Levine wrote: > On Mon, 19 Jun 2023, Patrick Ben Koetter wrote: > > I suggest that we do not only drop SPF, but also come up with better ways > > (simplification, tools, exchange formats) to implement DKIM in order to > allow > > for a smooth transition. >

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-20 Thread Douglas Foster
Currently, domain owners can disable SPF by removing their SPF policy, which can run into the problems that you raise, with evaluators that only understand SPF.But providing an authentication selector in the DMARC policy would remedy that risk. Evaluators who understand DMARC would use the

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-20 Thread Tobias Herkula
Sadly they can’t, there are Mailbox Providers that expect SPF Records, so to maintain deliverability to those, you have to keep SPF records in place and can’t switch to an DKIM only DMARC. / Tobias From: dmarc On Behalf Of Murray S. Kucherawy Sent: Sunday, June 18, 2023 2:42 AM To: Ken

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-20 Thread Alessandro Vesely
On Mon 19/Jun/2023 20:42:28 +0200 Patrick Ben Koetter wrote: The number of IP addresses in SPF-Records published by VLMPs foils the idea of "a controlled and limited number of host allowed to send on behalf of a senderdomain". Given the (internal routing) challenges you face when you try to

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-20 Thread David Verdin
Dear all, On the other hand for a hosting company, implementing SPF is just a matter of knowing where the emails are supposed to be sent from. You don't have anything to install on the outgoing mail servers to DKIM-sign. And with the "include" mechanism, it is very easy to maintain an

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

2023-06-20 Thread Wei Chuang
As DMARC is intended to protect the From header from spoofing, we support moving DMARCbis authentication to DKIM-only due to the recent demonstration of such spoofing that was enabled by an SPF upgrade attack as described in [1]. That paper cites the vulnerability of Federal government,