On Fri 18/Apr/2025 23:59:35 +0200 Allen Robinson wrote:
On Fri, Apr 18, 2025, 2:10 p.m. Alessandro Vesely <[email protected]> wrote:
Not evil could be summarized in a few rules, such as:
* Can modify the Subject: by adding a tag. It must be in square brackets and
shorter than 20 chars.
* Can add a footer. It must be text/plain and shorter than five lines of 80
chars. It must be separated from the body by a line of dashes.
It is still possible to be malicious under these conditions, but they are safe
enough to ensure that the message is not distorted from the intentions of the
author, identified by the original From: field. Most mailing lists operate
within these conditions.
To the opposite, a forwarder that changes, say, all the URLs —perhaps to
redirect through a security filter— needs to be absolutely trusted by the
receiver. Its changes don't satisfy the above rules.
Footers produced by some mailing lists contain links, such as to
unsubscribe or to view the thread on a web interface. Classifying these as
malicious feels incorrect to me.
That's right, a footer can contain a (potentially harmful) link. As long as
it's clearly separated from the original content, the footer is acceptable.
Requiring it to be plain/text only ensures that the display games that are
possible with HTML don't happen. Images of limited size might also be allowed,
in their own appended MIME entities.
I could support the idea that types of modifications should be limited to
logical prepending and appending with no support for deletions. Doing
either operation on a multipart message and/or involving base64 encoding
ends up being complicated though, and that's one reason for why the algebra
has support for content deletion.
Transparent transformations, such as base64 encoding, must be recognized as
such by the algebra. Alternatively, we could require that hashing be performed
on the decoded content, but this would be a gratuitous incompatibility with DKIM1.
Signers should avoid signing quoted printable stuff, as its many possible
variations make any further conversion irreversible. Base64 encoding is
reversible as long as column width is 76 characters. I'm saying this after
coding it —zdkimfilter 3.0 (nov 2020) included reversing MLM transformation,
which is unreliable as it misses a modification algebra.
I generally don't see evaluation of the content as a problem DKIM2 needs to
solve. The modification algebra allows for attribution of content to a
signing domain. Local policy could always decide that certain classes of
changes aren't deemed acceptable, and having an identity to attach to the
content/changes could be useful for making those policy decisions.
If verifiers can't judge how acceptable a change is, change tracking will be
relegated to forensic analysis. That means we won't be able to distinguish
mailing lists from spammers and replayers, and we won't have solved anything.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
