On 26/07/2026 11:43 am, Steffen Nurpmeso wrote:
Inveigle.net wrote in
|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.
For sure.
|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.
I do not follow terms and speech.
You don't need to change core SMTP functionality for backscatter, bounce
and message replay protection, only for change tracking and a chain of
custody.
Vastly more users benefit from backscatter, bounce and message replay
protection than from change tracking and a chain of custody.
|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.
My english, i think i do not really understand what you are
saying. (To me SMTP is out of scope. It just works, as always.
And that means, pipelined and with as many recipients as possible,
without data duplication.)
RFC 5321 s3.9.2 only allows e-mail to be forwarded as if it were
continuing the delivery of the original e-mail under specific conditions.
Modern lists, including the IETF's own, do not meet those conditions and
are expected to post new e-mail. The list behaviour is broken, not DKIM.
Fix the list, don't change SMTP.
|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.
And then, one more.
You know the email standard for message/rfc822 does have
a technical failure, which actually makes its use impossible at
times? The problem is that RFC 2046 says that such an attachment
can only be 7bit, 8bit or binary encoding (whatever that binary
encoding actually is).
Yes, it was naively thinking the original message must be
correctly encoded, but what if it is not?
And you will find messages with ^From_ and other problems that
*will* cause problems for certain people, unless you *do* encode
them to something better. So then you *do* have to modify the
original message, breaking it.
The attached e-mail just becomes a blob of data (i.e. a raw .eml). Any
MIME encoding within the original e-mail remains unaltered.
Limiting the encoding ensures the original content is easily extracted
without a full MIME implementation and remains readable.
Regards,
R. Latimer
Inveigle.net
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
