On Sat, Apr 19, 2025, 9:02 a.m. Alessandro Vesely <[email protected]> wrote:
> 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. > This is why I don't think the modification support needs to concern itself with evaluating the content. A HTML footer isn't inherently bad, but a HTML footer that substantially alters what gets rendered is bad. > > > > 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. > The proposed body algebra is simple addition or removal of bytes in a range, applied to the transmitted body. We could also have steps representing mechanical transformations. Something to allow a signer to communicate a sequence of modifications against the encoded text: * I base64 decoded this MIME part. * I inserted bytes N-M * I trimmed the text "foobar" starting at byte N * I base64 encoded the MIME part This would be quite a bit more complicated to implement. However, modification handling would be entirely encapsulated and not require changes to how body hashes on the transmitted body are computed. This would also mean it could be optional. Adding an entire MIME part wouldn't require using it, for example. 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. > I disagree, or maybe I'm working with a different idea of what forensic analysis means. Doing content filtering at SMTP transaction time based on the results of authentication checks is certainly possible without the authentication mechanism being able to decide whether the content is malicious or not. For a DKIM2 message with modifications, evaluating the delivered message is probably sufficient as a first pass, potentially with some metadata about the modifications (location, edit distance). In the event that the first pass has some suspicion of being unacceptable, unwinding the modifications and doing further checks may be necessary to apply checks based on finer-grained reputation. What's being solved is not that changes can be classified, but that changes can be verifiably attributed to the domain performing them. > > Best > Ale > -- > > > > > > > >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
