On 25/07/2026 3:13 am, Steffen Nurpmeso wrote:Steffen Nurpmeso wrote in
<20260722225956.YiFNSrni@steffen%sdaoden.eu>: |It does not change anything really, it actually addresses problems |already pointed out in RFC 6376, the DKIM that is now known. |(Backscatter bounces, and message replay. Good that this is |addressed, yes.) | |In order to do that it dramatically changes SMTP. |That effectively becomes single-recipient. |How can a simple (though cryptographic) helper dare to mutilate |its base protocol like this? |What a massive transaction overhead! Unbelievable!!
Agreed. None of these problems are shortcomings of DKIM as it was never intended to address them, however, all can be easily addressed by extending DKIM as it exists now, without mutilating SMTP.
It's only change tracking and the chain of custody (which isn't necessary to prevent backscatter) that necessitate extensive protocol changes. That functionality would be solely for the benefit of larger scale receivers and at the expense of established DKIM behaviour. The benefits to the majority or e-mail users can, and should be, achieved through less invasive means.
|Unfortunately the email part of the IETF only has balls to create |barriers and distress for administrators and email users, but not |for creating a slim, efficient and practicable solution to fix the |mess they themselves have created.
The scope of this Working Group permits them to recommend a solution that addresses this ongoing issue, although I feel they have gone off track by focusing on an ARC replacement.
The tidiest solution IMO is to bite the bullet and insist on strict alignment from the sender to receiver. This eliminates the need for SPF, DMARC (except possibly for reporting), and IP reputation filtering except under extreme circumstances, such as a large scale leak of private keys by an ESP. Far from being a significant imposition, this would deliverer the greatest benefits senders, many of whom are struggling with deliverability and being forced down the path of using ESPs or hosting services out of necessity.
Only mailing lists where true continuation of transit is permissible would be affected. The realities of the modern Internet mean few such lists would exist these days. The expectations of RFC 5321 are clear. You don't 'fix' SMTP to accommodate broken software.
Forwarders would be able to comply by simply switching to MIME encapsulation, wrapping the original e-mail in a message/rfc822 container, as defined in RFC 1341.
Regards, R. Latimer Inveigle.net
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
