Hiya, Note: I'm not arguing here that this ought not proceed unless my opinion "wins", but I do think it worthwhile teasing it out a bit more so the IESG may be more informed when deciding stuff. On 28/11/2024 02:39, John R. Levine wrote:
On Wed, 27 Nov 2024, Stephen Farrell via Datatracker wrote:I think I see two issues with this draft: (1) Recent papers e.g. [1,2] argue that the centralisation of mail means that SPF is by now less useful than originally. Given it's been 9 years since RFC7489, one would assume it'll be a while before this document gets an update, and it seems possibly unwise to still consider SPF as "good enough" for that time period. Shouldn't this draft at least indicate that SPF alone (without DKIM) is unlikely to remain sufficient for a DMARC pass?We discussed this at ength and considered adding an option to say DKIM only and rejected it.
I'd say it might be useful to have (a URL for) the summary of that discussion available for the IESG. (It's not needed for this thread.)
You're right that SPF is very weak and I personally wish it would go away, but we don't see that happening any time soon.
I'm not asking that SPF be banished, (none of us are good at going back and deleting RRs we wish we'd forgotten:-), but more that some domain owner/sender could indicate via DMARC to receivers that they think SPF is no longer good enough by itself, in their opinion, for email claiming to be from them (the sender). Personally, I do think it odd there's no way for a sender to use DMARC to say "I know I still have to publish SPF stuff, so as not to break things, but I'd really prefer you ignore that and depend only on my DKIM stuff if you know how to parse this new bit of a TXT RR for DMARC."
If things change, it wouldn't be out of the question to update DMARC later and add a DKIM only flag.
My main point is that "things" (i.e. mail centralisation) have already changed, and very significantly since RFC7489. Even though the WG discussed that, the draft doesn't say anything about that (actual) change in the efficacy of SPF. I'd argue that's a thing that requires change to the draft. You I guess will argue otherwise, and the IESG can figure it out. (So you and I do not need to thrash it out:-)
(2) The tree-walk calls for querying TLDs for TXT RRs. Was that discussed with DNS operators for TLDs?Yes. The whole idea for PSDs and the psd=x flags comes from the operator of the .BANK and .INSURANCE TLDs. They've gone through all the paperwork at ICANN and have DMARC records. There are also a few ccTLDs with DMARC records and we've at least tried to talk to all of them.Keep in mind that if a TLD doesn't publish a DMARC record, the results in nearly every case will be the same as it is now. I would be surprised if generic TLDs like .com and .org ever publish DMARC records.
With the same attitude as above (no harm for us to clarify a bit more, but "secdir-reviewer being happy" is not a required outcome here), I'd say being able to convince the IESG that more than a couple of oddball TLDs are ok with this would be a good plan. (When I tried a few, I got NXDOMAIN answers, other than for the couple you mentioned.) Maybe one way to argue that is to say that those DMARC queries won't even be noticed, but that kind of assertion probably needs to come from some DNS type folks. (I guess there'll be a dnsdir review too and they'll bring that up if it's real.) Cheers, S.
Otherwise the draft seems good, if very very wordy.No argument there. R's, John
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
