Developers of Sympa

["John R Levine" <address@concealed>]

Thanks for your note.

I don't blame you for worrying that the undo algebra won't be adequate, 
but the guy working on it has Mailman and Sympa in mind and would 
appreciate more test cases to be sure he can handle them.

On Wed, 6 Nov 2024, IKEDA Soji wrote:

> 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

Regards,
John Levine, address@concealed, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly