DKMI/SPF/DMARC -> ARC / Was: #metoo, was Mailman? (war: Re:).eml

[Florian Lohoff]

Hola,

On Wed, Jan 21, 2026 at 02:54:13AM +0100, Kai 'wusel' Siering via Linux wrote:
>>The Authenticated Received Chain ARC - Mailman3 kann das.
>
>Und Mailman 3 hat keinen wirklichen Upgradepfad von Mailman 2, höre
>ich jedenfalls immer wieder. Kind, Bade, Auschüttung?

Du kannst nicht einfach upgraden. Mailman3 möchte eine Datenbank. 
sqlite, postgres, mysql - ist halt auf dem Django Framework.

D.h. du installierst mailman3 und dann kannst du die config files
vom mailman2 (Der hat ja alles in den .pck files) importieren 
in den mailman3. Und das mailbox/bsd mbox file kannst du in hyperkitty
importieren. Ist ne sache von wenigen minuten. Alles trivial.

Ich habe gerade ein Debian/etch mit mailman2 neu gemacht mit 
Debian/Trixie und mailman3

>>Dafür ist das da - Nur mit DKIM/SPF/DMARC wird das nichts. Microsoft
>>im o386/outlook.com supported und nutzt das ebenfalls.
>
>Ich verstehe diese Obsession, immer mehr Header auf das Problem zu
>kippen, wirklich nicht. Eine Mailingliste sendet eine neue Mail in

Falsch - Das hängt von der config der mailingliste ab. Früher waren 
alles nur forwards. D.h. nur der envelope hat sich geändert nicht
die mail header (Da ist maximal was angefügt worden).

D.h. deine DKIM signatur war nachwievor (Je nach signierten headern)
heile weil die signierten header sich nicht geändert haben.

Allerding kam/kommt die mail dann vom falschen MX - Also mit SPF + DMARC
war/ist die dann kaputt.

Du kannst die mailingliste so ändern das sie das From rewrited
und eine neue DKIM signatur dran baut. Dann ist das auch in Ordnung.
Ist aber eher schlechter stil das das From/Reply-To die mailingliste 
selber ist - und auch gefährlich bei kaputten recipients - so mail loop 
Themen.

Die Lösung ist den ganzen Pfad zu signieren. Das ist ARC - D.h. bei 
jedem forward (Nicht nur mailinglisten) erzeugst du eine chain
an signaturen. Hätte man bei DKIM gleich mit denken sollen - hat 
man eleganterweise vergessen, dabei ist das Thema forward eigentlich
eine Standard mail Lösung. IIRC kam DKIM aber von Microsoft und da hat
man das offensichtlich nicht org übergreifend gedacht.

Und ich habe das an andere Stelle auch. Ich hab einen verein die
gerne email addressen mit @verein.de rausgeben - Das sind aber
weil man nicht so viel mail machen will typischerweise einfach
eintragungen in /etc/aliases - Na super - mailweiterleitungen - gehen 
alle kaputt - SPF kaputt. 

Lösung? postsrs der dann die from addresse ist eine scheiss SRS addresse
wandelt damit du eine neue DKIM signatur schreiben kannst und vor
allem ggfs die bounces auch richtig zurück laufen.

Kommt dann halt als envelope sender sowas bei raus:

SRS0=zb+z=72=mannativf.com=info at verein.de

Damit ist SPF heile, und DKIM kann ich neu machen.

DKIM war und ist ein Schnellschuss der langfristig halt 
Probleme macht. ARC ist die Erweiterung die ein teil der Probleme
löst. Und das problem mit SPF und DKIM war lange vorher bekannt, 
bevor das weite verbreitung fand. War aber halt das was da war.
  
>Was offensichtliches übersehe ich, daß diese pragmatische Lösung
>nicht umgesetzt wird, sondern mit Klimmzügen und immer neuen RFCs
>ein wirklich simples Problem unnötig verkompliziert wird? Discourse,
>BTW, arbeitet im Grunde so — Mail kommt rein, wird zum Beitrag, Bei-
>trag wird zu Mail vom Forum (ohne direkte Reply-to-Author-Option,
>man verliert also schon Funktionalität ggü. einer klassischen Mail-
>ingliste, hat dafür aber die Forumsfunktionalität gewonnen).

Bei discourse ist FROM immer der discourse server - Der leitet keine
mails weiter. Das ist eine Web applikation mit einer halbgaren mail
Anbindung.

Flo
-- 
Florian Lohoff                                                     f at zz.de
   Any sufficiently advanced technology is indistinguishable from magic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20260121/87715894/attachment.sig>