Developers of Sympa

["Bron Gondwana" <address@concealed>]

Greetings,

This is my first time posting to this list.  I'm one of the authors on the DKIM2 spec, and I'm keen to have Sympa support DKIM2 even in the early drafts.

I've been working on DKIM2 support for Sympa for a little while, there's a patched copy running on sympa.dkim2.com with my patches, plus the dkim2 branch on my fork at https://github.com/brong/sympa/

DKIM2

The IETF DKIM working group is working on DKIM2, a replacement for DKIM and ARC.  At this stage, the working group believes that the draft specification at https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/ is in a fit state for interoperability testing.

DKIM2 has three important new properties:

• Envelope addresses are signed (fixes DKIM replay); at every hop
• Envelope from aligns with signing domain (fixes backscatter)
• Changes are reversible and described by a recipe (not need to trust intermediates, you can verify

The proposed changes to Sympa in order to support DKIM2 are focused very much on the last one, the recipes.  Since you have to describe the changes you are making, it is sensible to make the minimum possible changes!

To this end, there are a couple of pre-cursor changes.  I'm just pasting the commit message here, since it describes what's involved pretty well.  It think these are good changes regardless of DKIM2.

Preserve the body encoding when decorating

    A DKIM2 Message-Instance Recipe is compact only when the lines of the
    original body survive decoration byte for byte. Four changes to
    Sympa::Message keep them that way:

    - Skip the decode/re-encode cycle when personalize_text() substituted
      nothing: base64 and quoted-printable are not canonical, and re-encoding
      unchanged content changes bytes for no reason.
    - Prefer the original charset when re-encoding a personalized or
      decorated body, falling back to UTF-8 only when the new content cannot
      be represented in it, so the Content-Transfer-Encoding stays put.
    - When an inline footer append fails, add the footer as a separate MIME
      part instead of dropping it, leaving the original body part untouched.
    - Quoted-printable bodies get the footer appended at the encoded level
      so only the footer lines are new; base64 bodies are re-wrapped at the
      sender's original line length by diffing the flat base64 with
      Algorithm::Diff, so only the last line and the footer change.

    These apply whether or not Message-Instance headers are enabled; they
    also make classic DKIM signatures over the body more likely to survive.

diffstat
 Message.pm |  243 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 234 insertions(+), 9 deletions(-)

Then of course there's the DKIM2 changes themselves, which track what was edited and build a "Message-Instance" header describing the changes, this is a bigger set of code changes:

 DKIM2-MESSAGE-INSTANCE.md                |  334 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 Makefile.am                              |    1
 src/lib/Sympa/Message.pm                 |  168 +++++++++++++++++++++++++++++++++++++
 src/lib/Sympa/Spindle/ProcessIncoming.pm |   10 ++
 src/lib/Sympa/Spindle/ProcessOutgoing.pm |   12 ++
 src/lib/Sympa/Spindle/ResendArchive.pm   |   15 +++
 src/lib/Sympa/Spindle/ToList.pm          |    7 +
 src/lib/Sympa/Spindle/ToMailer.pm        |    7 +
 src/lib/Sympa/Spool/Outgoing.pm          |   40 ++++++++
 t/Message_DKIM2.t                        |  737 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 1328 insertions(+), 3 deletions(-)

I

t's mostly just a couple of hook locations for the changes, and a new file which calculates the message-instance.  Plus a chunk of tests.

NOTE: this is largely Claude's work, with me guiding the output and reviewing the shape, but not the raw code itself.  I'm prepared to spend more time on human review and making this high quality if the project is willing to take my work on it.  I'm an experience Perl developer.

Cheers,

Bron.

--

  Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC

  address@concealed