I concur with what Doug mentioned. As someone on the receiving end of bad press due to an exploit of what I perceive to be weaknesses in the DMARC standards particularly around depending on SPF [1], and then had to drop everything to mitigate, I would suggest taking this opportunity to strengthen DMARCbis. After all, preventing From header spoofing is the core of what DMARC is about. As for why a new tag, I noted in [2], we see a high degree of overlapping coverage in DKIM and SPF authentication, but there is a small set of SPF only authentication that likely needs coverage, and noted that different senders have different From header security needs e.g. those that use cloud services really should only use DKIM but a very small sender might not. As noted, I proposed language [3] for DMARC to enable this change, and at least on that thread there seemed to be consensus. -Wei
[1] There was an attack on BIMI starting on March 31. An attacker was able to exploit a large cloud provider that provides mail services for many well known companies to forward a message with a spoofed From header. That message could obtain SPF authentication using the relay's IP SPF, thereby getting a DMARC pass hence a BIMI pass. Agreed with the earlier statement that the fault here doesn't appear to lie with SPF domain owner as they appeared to have followed reasonable practices. Rather SPF relies upon IP which is very often shared between multiple senders. The Forward Pass paper documents this very well: https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf [2] https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/ I realized that the archived text version of tables there got munged, so putting the key table back to format for text: The following categorizes combination of SPF and DKIM authentication of percentage of traffic that Gmail sees on a given day. Of this traffic, DKIM is not passing for 5.56% and of that there's SPF coverage for 4.78% (86% of DKIM not passing). A large cause for this is messages that were not DKIM signed but could be validated with SPF at 3.91% (70% of DKIM not passing). ConcatSpfPassDkimAuthResults % TRUE,PASS 92.58% TRUE,NEUTRAL 3.91% FALSE,PASS 1.85% FALSE,NEUTRAL 0.72% TRUE,FAIL 0.69% TRUE,TEMPERROR 0.17% FALSE,FAIL 0.05% FALSE,TEMPERROR 0.02% TRUE,POLICY 0.00% FALSE,POLICY 0.00% Grand Total 100.00% [3] Initial "auth" tag proposal https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukLDgDqlp6NEGw/ and with comments rolled up https://mailarchive.ietf.org/arch/msg/dmarc/oqcJoGfBCX0C3Y7yZzCga3k6sTs/ On Thu, Oct 26, 2023 at 5:27 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Like Ale, I thought the group had agreed to implement an auth=DKIM-only > option of some type. > > I understood the motivation to be false pass created by malicious > forwarding through a legitimate hosting platform. Therefore SPF precision > is an unrelated issue. > > Doug > > On Thu, Oct 26, 2023, 5:46 PM Tero Kivinen <kivi...@iki.fi> wrote: > >> John Levine writes: >> > It appears that Scott Kitterman <skl...@kitterman.com> said: >> > >>* Is there consensus on moving ahead with the idea of a way to >> indicate >> > >>which authentication method(s) the Domain Owner wants Receivers to >> use? If >> > >>so, it doesn't seem to be in the document yet. >> > > >> > >I haven't seen any valid case for it yet. It adds complexity to >> > >little or no benefit. >> > >> > Normally I am in favor of keeping stuff simple, but I think in this >> case the >> > argument for "DKIM only" is quite strong. >> >> Actually removing SPF completely from DMARC would simplyfy the >> protocol a lot, and would solve several issues, where people use DMARC >> with only SPF, or claim to do dmarc, but do filtering based on the SPF >> records before getting to the actual email, thus not checking DKIM >> records at all. >> >> If the DMARC would only use DKIM, that would make it clear that if you >> want to publish DMARC records you needs to also use DKIM, and when >> checking DMARC records you need to check verify DKIM signatures. >> >> Whether you do SPF in addition to that before or after would be local >> implementation issue, and not part of the DMARC. >> >> There were people who wanted to keep SPF as part of the DMARC, who did >> not even do DMARC, because the used SPF only as a first step of >> filtering during the MAIL FROM phase (before being able to fetch DMARC >> records, or checking DKIM signatures)... >> >> > There's the counterargument "so don't publish SPF" but it's on so >> > many checklists that even though that would be a fine idea, it's not >> > practical. >> >> That is unfortunately true, but if we could decouple the DMARC from >> SPF, then at least we could fix the situation at some point... >> -- >> kivi...@iki.fi >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
