[multiple responses aggregated] > On 6 Feb 2024, at 22:22, John R. Levine <[email protected]> wrote: > >>> Unless something important has changed since the last time we took up >>> and rejected this idea, I don't think we need to discuss it further. >> >> Is the reasoning documented? I have checked the list archives, but there is >> a LOT of list archives... > > The main reason is that it's much too late in the process for such a large > change, and a lesser reason is that it's not clear how it would interact with > the DKIM replay work that some people claim is going to happen real soon now. > >> For gmail.com <http://gmail.com/> as a very big example SPF passes due to >> ~all and the evaluation of DKIM can be ignored ... > > Uh, no. ~all is a soft fail.
Together with DMARC p=none as DKIM signature-presence is ignored and thus any email can pass. > The problem with SPF is that many (most?) senders include a whole bunch of > other people's records so a message can get a pass if sent from any of those > other hosts, and that some large senders like Microsoft make it way too easy > for one customer to send mail with another customer's address on it. > > The practical solution if you don't trust SPF is to DKIM sign everything and > don't publish SPF. SPF and DKIM are additional and solve different cases. Not having a SPF policy is guaranteed to get one rejected by any large mailer. It is not about 'trusting SPF' it is about indicating that when a DKIM Signature is missing it should be treated as an error. There is currently no way to indicate that. And thus, one of the likely largest mail domains in the world is operating with: - SPF ~all => anything - DKIM signing everything => but that can be skipped by a spammer - DMARC p=none And thus any spammer can send mail from @gmail.com from any IP, just do not add a signature and voila. Yes, if gmail enabled p=reject the world would become better. But they likely would be very very happy with a req=dkim,spf to require DKIM signatures and valid SPF. That policy cannot be expressed, by them, or anybody else in the world though. Hence why the are resorting to business tactics by enforcing the change there I guess... well for them receiving from the rest of the world, not for their domain being used to spamming to rest of the world... > On 6 Feb 2024, at 23:47, Murray S. Kucherawy <[email protected]> wrote: > > On Tue, Feb 6, 2024 at 2:33 AM Jeroen Massar > <[email protected]> wrote: > `req=dkim`: requires DKIM, messages not properly signed are then to be > rejected/quarantined based on 'p' policy. > > This sounds like what RFC 5617 tried to do, minus the constraint that the > signing domain be equal to the author domain, which is one of the key pieces > of DMARC. Isn't this a pretty big scope expansion? At that time, when DKIM deployment was low (though I have had DKIM since 2009 at least) and DMARC did not exist/heavy-use... it thus got marked historic again. It was also another separate TXT entry to check. But yes, ADSP would have covered the use case: to indicate that all received mail from a domain has to be properly signed with DKIM (+SPF etc). > Also, can't an attacker just sign the message with any old throwaway domain > and defeat this test without providing any new useful information to the > verifier? An invalid signature would indicate a fail for 'required DKIM'. Greets, Jeroen _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
