Developers of Sympa

[IKEDA Soji <address@concealed>]

Hi John,

> 2024/10/31 8:47、John Levine <address@concealed>のメール:
> 
> As you may have noticed, the DMARC mail security scheme screwed up mailing
> lists, forcing ugly workarounds like putting the list address on the From
> line so you can't tell who sent each message.  Then they invented ARC,
> which was supposed to help lists deal with DMARC but turned out not to be
> useful for reasons I can discuss if you want.
> 
> The DMARC problem is due to the fact that DMARC wants senders to put a DKIM
> signature on the mail, but when lists make normal changes to messages it
> invalidates the DKIM signature.  It turns out that's not the only problem
> with DMARC and DKIM, e.g., it allows replay attacks, in which someone sends 
> himself
> a message that passes DMARC and DKIM and then spams out a zillion copies to
> other people.
> 
> Rather than put another band-aid (sticking plaster) on DMARC, we have a
> new propsal to fix DKIM, described here:
> 
> https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motivation/
> 
> For mailing lists, it will define an algebra the list can put in the
> message header describing what changes it made to the message.  This lets
> the recipient reconstruct the original message and validate the original
> DKIM2 signature, and accept the message if so.  We're reasonably sure this
> will work if list software can describe the modifications they made.  (The
> draft describing the algebra in detail will be out on Monday.)

Thank you for your efforts to keep the mailing list useful!

I skimmed through the two I-Ds (both in revision 00):
- https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motivation/
- https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modification-alegbra/

I don’t have enough knowledge to discuss this in depth, but I hope my 
comments will be useful in your future work.

There is no doubt that this is a useful proposal for an alternative solution 
to ARC. The concern I have is the effectiveness of the “algebra” for 
recording message modifications.

It seems to me that there are several cases of message modifications by 
mailing list systems, including Sympa, that cannot be handled by this algebra 
properly.  For example:

* Insertion of message header/footer for text part, not as a separate MIME 
part but as the content of text part.  It may be considered a total 
replacement of the content, due to character set conversion or re-encoding by 
transfer encoding.  This situation can be more prevalent especially in 
non-Latin script languages.

* So-called “text-only” mode, non-plain text parts are scraped off to make a 
single-part message.  Most of the message body is removed.

These result in a copy of most of the message before modification (or its 
BASE64 encoding) being added as the DKIM2-Diff-Body field to cause 
significant header bloat.

> Take a look and see if you think this is workable.  If so, there'll probably
> be money to pay someone to do the necessary changes to list software.  It
> might be me, since I did the ARC code for Sympa.

Your contribution on ARC is deeply appreciated.

(Regarding money, I am currently personally considering having a way to raise 
money for Sympa.)


Regards,
— Soji

> Regards,
> John Levine, address@concealed, Primary Perpetrator of "The Internet for 
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly