Wat ging KPN hier aan doen?

Die mailing list is stuk.
Ik had dat recent ook op een andere list, er is kennelijk een update geweest op een vaker gebruikt mailinglist programma waardoor het dit soort false positives geeft.
Wel jammer dat het natuurlijk weer een tijd duurt voor daar weer een update op is en de diverse beheerders die geinstalleerd hebben.
(dan moeten ze eerst in de gaten hebben dat ze de list kapot gemaakt hebben)

Dat heb ik niet gevraagd, want dat zou zonde zijn van mijn tijd. KPN gaat hier niets aan doen want het is een generiek probleem: veel mails landen met, toegevoegd door KPN, "[DKIM] " aan het begin van de "Subject" regel.

Nee, die mailing list werkt net zoals jaren geleden. Steeds meer legitieme mails belanden in mijn spambox terwijl spam en phishing mails in mijn inbox worden afgeleverd.

Zie ook wat ik over DMARC e.d. schreef in https://security.nl/posting/842870.

Al die lapmiddelen hebben e-mail qua inhoud niet betrouwbaarder gemaakt terwijl de zekerheid dat e-mails überhaupt worden afgeleverd steeds verder afneemt - vooral als de afzender niet bij "big tech zit".

Microsoft had een tijd een "handig" systeem: als je een afzender als "safe sender" aanmerkte, kwamen mails met het "gewitlijstte" SMTP-afzenderadres gewoon in jouw inbox - ook als DMARC faalde (https://security.nl/posting/767981). Dat was omdat klanten klaagden dat zij allerlei e-mails niet ontvingen.

Nadat phishers daar misbruik van maakten, heeft Microsoft die maatregel weer teruggedraaid. Uit https://learn.microsoft.com/en-us/defender-office-365/secure-by-default?view=o365-worldwide:

Dus weer uitgezet, probleem opgelost. Of?

Ik kan je verzekeren dat er op dit moment een veelgebruikte (opensource) mailing list handler is die stuk is!
Ik krijg dit soort mail (Your membership in the mailing list XXXXXX has been disabled due to excessive bounces) terwijl ik ZELF mijn EIGEN mailserver draai en er AANTOONBAAR GEEN bounces geweest zijn.
Toch denkt die mailinglist van wel!
Ik denk dat er ergens een returncode niet goed gechecked wordt ofzo.

Dat er ook dingen fout kunnen gaan met DKIM/SPF/DMARC is bekend, maar een goede mailinglist zorgt dat dit geen probleem is door de headers goed in te stellen (dus geen mail van een submitter adres te spoofen).

Veel Nederlands email providers en overheden hebben allerlei technische maatregelen tegen spam ingevoerd.
Naast de afgesproken standaard met SPF, DMARC en DKIM zijn ook allerlei andere maatregelen aangezet..

Zo zijn er mailproviders die in de strijd tegen spam ook de PTR-record ( of Pointer Record ) controleren. Dit staat nergens in de standaard. Ook checken sommige of domain voorzien is van een certificaat en ook staat nergens in de standaard.

Veel extra checks die nergens afgesproken, worden uit gevoerd, waardoor veel juist verstuurde mail niet of niet juist aankomt.

Zelf draai in mijn mailserver in de US, dat vinden bepaalde providers verdacht en leveren daardoor mail niet af.

Ik ben nu met een zakelijk domain verhuist naar Strato en ook mail vanaf Strato wordt door een aantal providers gezien als
verdacht van spam.

Conclusie mail is defentief kapot.

Laten we maar gaan whatappen.

Als de mailserver van KPN rechtstreeks mail weigert van een mailing list tijdens de SMTP sessie, is de kans groot dat zij dit kunnen verhelpen. Bij mij (andere provider) komen die mailings wel gewoon aan, de kans is groot dat KPN een specifieke filter gebruikt die dit probleem veroorzaakt. Omdat het kennelijk wel de administratieve mails bezorgd, is de kans aanwezig dat dat een foute contentfilter is en niet bijvoorbeeld een DNS blocklist. Vaak worden alleen DNS blocklists gebruikt voor weigeren tijdens de SMTP sessie, maar dat lijkt hier niet aan de orde tenzij er verschil is in afzender IP tussen de mailing list en administratieve berichten van die mailing list.

Een DKIM faal is iets anders, dat komt waarschijnlijk omdat de emails zijn veranderd door de mailing list software. Kennelijk worden berichten met (enkel) een DKIM fail wel bezorgd, dat veroorzaakt dus geen SMTP bounce. DKIM is gebaseerd op headers en die blijven in het doorgestuurde bericht staan. Het bericht zelf wordt voorzien van andere headers en aangepaste content, vandaar dat de DKIM check faalt.