As a receiver, I already reject some portions of traffic if it is unsigned or an existing signature does not verify. I would vote for a clear statement that failing DKIM2 signatures from a 100% DKIM2 mail chain should provoke a reject, as nice as "local policy" sounds, I don't like the burden of handling broken mail if I'm not responsible for breaking it. But DKIM2 will take time to get coverage and until then we will still see SPF/DKIM1/DMARC mails and we will handle them like we do today until they represent only a small part of incoming traffic and then we will start not accepting them anymore, like we do with traffic that is currently not signed at all.
>From the other perspective generating and sending DMARC reports costs money >and I currently do it to help senders get their systems fixed because that >helps me to make better decisions for my end-users, if at some point most >traffic is handled via DKIM2 and I don't need to generate the roughly 600000 >reports everyday I will happily stop investing the resources to produce them. TL/DR: DKIM2 rejecting is much cheaper than DMARC reporting. -- Tobias Herkula Senior Product Owner Mail Security Product Management Mail Transfer & Mail Security 1&1 Mail & Media GmbH ________________________________ From: Todd Herr Sent: Friday, March 21, 2025 15:41 To: ietf-dkim@ietf.org Subject: [Ietf-dkim] ELI5: DKIM2 and DMARC Colleagues, I am of the belief that if and when DKIM2 reaches a state of widespread adoption, there is no longer a need for Domain Owners signing with DKIM2 to participate in DMARC, a belief I expressed during the IETF 122 meeting. I did not hear consensus for my belief, but I still don't understand the reasons that I might be in the weeds on this, so I'm asking for further clarification here, perhaps in small words so that I can better understand. Let me preface my remarks here by saying that, as I am co-editor for DMARCbis, it might be assumed that I'm trying to protect my turf by asking this question, and that I'm pursuing some quest to wreck DKIM2 because of that. I assure you that nothing could be further from the truth; rather, I'm interested in making the email ecosystem better by whatever means make it better. Here is what I currently understand to be true: * DMARC provides the ability for a Domain Owner to request handling for messages that fail email validation (SPF and DKIM) and to receive reports about use of its domain * DKIM2, as currently described, allows and even encourages receivers to reject messages that fail DKIM2 validation To my mind, such rejection removes the need for a Domain Owner to express a preference, as the decision will be made independently of any such preference. Moreover it removes the need for any kind of reporting, as a Domain Owner will know from the rejections which messages that it authorized failed to authenticate and presumably why, and the Domain Owner will never see the rejections of unauthorized messages that did not originate at the behest of the Domain Owner, with the latter class of rejections being ones that the Domain Owner wouldn't find actionable, anyway. So, assuming a future world where a DKIM2 specification includes the text "Mail Receivers SHOULD reject any message that fails DKIM2 validation" or similar, and DKIM2 is widely adopted by mailbox providers and MTA vendors, I have some questions about that world: * Why would a Mail Receiver accept a message that fails DKIM2 validation? * Why would a Domain Owner publish a DMARC policy record when it's sending mail that is DKIM2-signed? * What would anyone hope to gain by issuing or consuming DMARC reports showing messages that failed DKIM2 validation but were accepted in spite of such failure? Thanks, and safe travels back from Bangkok to those who were there in person. -- Todd Herr Some Guy in VA LLC t...@someguyinva.com<mailto:t...@someguyinva.com> 703-220-4153 Book Time With Me: https://calendar.app.google/tGDuDzbThBdTp3Wx8
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
