Re: [dmarc-ietf] Reversing modifications from mailing lists

[Alessandro Vesely <[e-mail]>]

On Sun 05/Dec/2021 20:55:30 +0100 Wei Chuang wrote:
> On Wed, Dec 1, 2021 at 3:45 AM Alessandro Vesely <[e-mail]> wrote:
>> On Tue 30/Nov/2021 18:30:39 +0100 John R Levine wrote:
>>> On Tue, 30 Nov 2021, Wei Chuang wrote:
>>>> What about adding a footer to some html mime part is poorly handled when
>>>> using "l="?  Multipart bodies could be handled by other techniques.
>>>
>>> See section 8.2 in the DKIM spec which says if you use l= you need to
>>> be careful with your MIME boundaries so naughty people can't add another
>>> part that overlays the real message. >
> Agreed there's risk in HTML hiding content and showing malicious things but
> that risk has existed before.  An updated DKIM authenticator could help us
> understand who did those malicious updates along some forwarding path.


ARC can do better for such kind of forensic analysis.


>> [...]  Hence I retract what I said in my previous message[*], that l=
>> works well with a wide range of mailing lists. >
> Could a way of dealing with "l=" is extending the list-canon
> <https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon> ideas
> of identifying signatures by mime-parts into identifying length as well?
> In other words, with list-canon each part generates a hash, and similarly
> each part can have a length of the content in that part that is claimed.
> It also records the content-type for each part.  I'm going to guess that
> this is to help identify changes like what I believe you are concerned
> with.


Those ideas have been ruminated for a while.  See also
https://datatracker.ietf.org/doc/html/draft-crocker-dkim-doseta-00
https://datatracker.ietf.org/doc/html/draft-vesely-smooth-canon-00

In fact, at this point DKIM is what it is, for the good and the bad of it.


>> Anyway, I wouldn't want to authenticate a message that underwent an HTML 
>> footer addition, because it can completely replace the original content in
>> the end recipient's eyes.  My draft requires footers to be plain text.
> 
> I was looking at the footers that Googlegroups puts in, and it seems to add
> them to both the text/plain and text/html parts.  At least one IETF mailing
> list adds a new mime-part with text/plain.  BTW has someone cataloged all
> these possible mailing list changes?


Wikipedia has a list of ten software packages, dunno if it's complete:
https://en.wikipedia.org/wiki/List_of_mailing_list_software
It doesn't dig into their peculiarities.

Mailing lists existed before computers, and are not regulated by strict rules, 
so trying to harness their behavior holds little water.  For example, it is 
customary these days to have discussion fora backed by mailing lists, where 
messages arrive with a From: display name referring to a user while the address 
part points to the forum server.  In that case, the user most likely typed the 
text in a web page, so the From: is not /re/-written, it's written that way 
from the start.  Although those messages have parts that were not written by 
the user, it is not possible to catalogue the changes.  And not even ARC can 
handle such messages in a way that would results in a From: address pointing to 
the real author.


Best
Ale
--