Re: [dmarc-ietf] DMARC session at IETF 118
Hi Barry, We not both? A robust discussion on the mailing list coupled with a dedicated session at IETF 118. This issue has deep implications for everyone from small businesses to the large players in domain hosting like Microsoft, Google, and Yahoo. While these major players hold a disproportionate amount of influence given their scale, it's crucial that the IETF remains committed to standards that serve the broader community. The far-reaching impact of decisions related to SPF, DKIM, and DMARC policies cannot be overstated. Moreover, I believe that discussing these issues in a more dynamic setting like IETF 118 can bring fresh perspectives into the fold, especially from those who may not be regular mailing list contributors but have substantial stakes in this. Specifically, I want to draw attention to the idea of expanding our focus to include DKIM Policy Modeling. DMARC, a derivative of the incomplete ADSP/ATPS protocols, has its value but has also been commercialized to a degree that may not fully align with IETF standards. Instead of introducing new proposals, my suggestion aims to refocus our current discussions. I believe we could benefit from considering DMARC as an Informational document. This would allow us to collectively examine existing standards more critically and possibly identify areas for improvement that better align with IETF principles. Thank you for considering this perspective. Best, HLS On 10/28/2023 1:38 PM, Barry Leiba wrote: I'm starting this in a separate thread that I want to keep for ONLY the following question: Do we want to use the session we have scheduled at IETF 118 to talk about the issue that clearly is still in discussion about adding a tag to specify which authentication mechanism(s) to use when evaluating DMARC? Or shall I cancel the 118 session and just let the discussion continue on the mailing list? And being clear here: the "eliminate SPF entirely" suggestion is definitely out, failing rough consensus. We're *only* talking about the suggestion to add a tag to specify what the sender wants. Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118
On a theoretical level, probabilistic tools like spam assassin will be predictably wrong some of the time. Accurate disposition requires audits and overrides using static rules based on confirmed evidence. I cannot find much sympathy for sites that enforce SPF without considering DKIM and without an audit process. They are better off ignoring SPF completely. In the matter of SPF Upgrade attacks, we start from the assumption that SPF PASS is not reliably true, so neutral is closer to the truth. Doug On Sun, Oct 29, 2023, 8:41 PM Tero Kivinen wrote: > Murray S. Kucherawy writes: > > On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster < > > dougfoster.emailstanda...@gmail.com> wrote: > > > > By contrast, the new tag cannot be effective until DMARCbis is > published > > and filtering software updated. This involves years. Even then, > domain > > owners will never have confidence that the new token support has been > > implemented by all recipient evaluators. > > > > At least on its face, this is a big concern. A domain owner publishing > "auth= > > dkim" is going to get varying results as some sites update to software > > supporting such a tag while others ignore it. I don't know if the > potential > > for some benefit is a desirable trade for the potential for some > confusion. > > Varying meaning, those who implement auth=dkim will get extra > protection, and those who do not, are left as they are now. > > I myself think that adding clear indication that sender always uses > dkim, and evaluators can rely on that makes the DMARC better, and more > secure. > > And as every DMARC evaluator needs to support DKIM anyways (there is > no such thing as SPF only DMARC evaluator, both SPF and DKIM are > mandatory to implement), there is no real difference in complexity for > evaluators. > > > Seems like a slam dunk for SPF neutral. I said the problem and it's > > solution needs to be laid out in our document because I am one of > those > > who did not understand it as a possible strategy > > > > I think I agree. > > This will also change the behavior of the receivers. For example > spamassasin does give more points to SPF_NEUTRAL (around 0.6-0.7) than > SPF_PASS (-0.001) etc. I would assume other similar software also use > SPF results similarly. > > The reason why SPF_PASS gives only -0.001 is that it is assumed that > spammers will use their own domain and thus can get SPF records to > match (DMARC, DKIM and SPF are never meant to work against spammers). > -- > kivi...@iki.fi > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118
On Sun 29/Oct/2023 21:03:17 +0100 Mark Alley wrote: Giving this some more thought from the opposite point of view... the benefits to an auth=DKIM method in DMARC itself would remove the need for domain owners to do SPF tinkering for any upgrade mitigation, and shared mail infrastructure where one could potentially be affected by SPF upgrade could instead be mitigated by the new tag, but still retain positive SPF authentication. Hm... diligent SPF settings are still due. I don't think the ability to sweep SPF negligence under DMARC carpet can be considered an upside... So, theoretically, if we look at it that way, there are a couple of upsides, although obviously there is additional added complexity, and as Doug surmised, the adaptation of mail filters will take a significant amount of time before we see any semblance of ubiquitous adoption. For added complexity, we need to add an element to the PolicyPublishedType to account for auth=. I'm on the fence currently about the auth= method. +1, it's role for the next several years seems to be a gauge in the security theater. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC session at IETF 118
On Sat 28/Oct/2023 19:38:00 +0200 Barry Leiba wrote: Or shall I cancel the 118 session and just let the discussion continue on the mailing list? Cancel. All facets of auth= have been brought up already, methinks. We could hum on list. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
