verschickt Unitymedia Störungs-Mails, bei denen das Wort Spam schon im Betreff steht?

[GoaSkin]

Als ich an meine private-E-Mail-Adresse eine Mail mit dem folgenden Betreff erhalten habe:

*****SPAM***** Wartungsarbeiten am 9. Oktober 2019 und 10. Oktober 2019 im Raum Offenbach am Main

Dachte ich mir noch, dass ggf. ein Spamfilter des Mailanbieters hier "Spam" in den Betreff eingebaut hat.


Doch in der Firma ging dann der selbe Hinweis an eine Firmen-Mailadresse ein, die über einen eigenen Mailserver läuft, der bei erkanntem Spam zwar Mails taggt, aber nicht den Betreff manipuliert.


Panne seitens Unitymedia?

 

[boba]

Habe ich auch bekommen. Da läuft auf irgendeinem internen Mailserver von Unitymedia Spamassassin, und der hat die ausgehende Mail als Spam markiert. Eine Fehlkonfiguration, denn zum einen dürfte ausgehende Mail nicht auf diese Art und Weise markiert werden, und zum anderen wird bei mir in den Report-Headern von Spamassassin eine Empfänger-Adresse des Mailings enthüllt, die nicht enthüllt werden dürfte - also ein Privatsphärenproblem. Nicht besonders groß, aber immerhin. Das Spamassassin-Setup sieht deshalb etwas dilettantisch aufgesetzt aus.

 

[hajodele]

Das "Spam" kommt von deinem Mailprovider.
Ggf. musst du dort in den Einstellungen was ändern.

 

[GoaSkin]

Der Mail-Provider bin ich in einem von beiden Fällen selbst. Spam-Mails erhalten auf meinem einen Spam-Tag aber keinen veränderten Betreff.

 

[addicted]

zum anderen wird bei mir in den Report-Headern von Spamassassin eine Empfänger-Adresse des Mailings enthüllt, die nicht enthüllt werden dürfte

Hm, sollte das nicht entweder nur Deine eigene Adresse sein oder aber mehr als eine fremde Adresse?
Die Information wird doch vermutlich nicht an zwei Empfänger gesendet?
Wie heißt denn der Header?

 

[GoaSkin]

So viel steht dazu im Header:

X-Spamd-Bar: ++++++
Authentication-Results: mx.unitymedia.de; none
X-Rspamd-Server: ker-l-mtasrv01p
X-Spam-Status: Yes, score=6.01
X-Spam-Level: ******
X-Rspamd-Queue-Id: 46nW731SRjz57KnN
X-Spamd-Result: default: False [6.01 / 20.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; ZERO_FONT(1.00)[56]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_SPAM(0.00)[1.000,0]; URI_COUNT_ODD(1.00)[33]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; MANY_INVISIBLE_PARTS(1.00)[10]; DKIM_SIGNED(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_EQ_FROM(1.10)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FORGED_RECIPIENTS(2.00)[[email protected],[email protected] ...]; RCVD_TLS_LAST(0.00)[]; R_PARTS_DIFFER(0.01)[50.6%]

 

[boba]

@addicted Wenn du dir den X-Spamd-Result von @GoaSkin genau anschaust, siehst du beim Regelergebnis zu FORGED_RECIPIENTS zwei Adressen, wobei die zweite ([email protected]) die Adresse irgendeines unbekannten anderen Empfängers ist, aber nicht die eigene. Bei meiner Mail war das jedenfalls so.

Ich kenne die Regeldefinition für FORGED_RECIPIENTS nicht (das ist keine Standard Spamassassin Regel), von daher weiß ich nicht, was die genau überprüft, aber da im Quelltext der Mail diese Adresse nicht vorkommt, muss sie aus den SMTP Headern kommen. Vermutlich aus der SMTP Empfängerliste (RCPT TO: ...), denn der Regelname erwähnt was von Recipients, und sonst gibts auch nichts, wo diese Adresse sonst noch herkommen könnte. Ein Glück, dass da im Report nur die ersten beiden Adressen protokolliert werden, vermutlich hätte man sonst den halben Verteiler gesehen. Also hunderte oder gar tausende von Leuten.
Aber diese eine Adresse ist schon nicht in Ordnung. Solche Privatsphären-Situationen werden übrigens in der Dokumentation von SpamAssassin und Postfix explizit erwähnt. Nämlich dass man besondere Sorgfalt mit den Regeln walten lassen muss, wenn SpamAssassin global im SMTP-Datenfluss eingebunden wird und nicht nur am Ende der Lieferkette beim Zustellen in den Postkorb. In dem Fall gibts nämlich wie passiert die Möglichkeit, dass in Reports die sonstigen, eigentlich geheim zu bleibenden Empfänger einer Nachricht sichtbar werden.
Nach etwas suchen habe ich FORGED_RECIPIENTS im Regelsatz einer rspamd genannten Filterlösung gefunden, die auch SpamAssassin mitbringt. Da war man dann wohl doch nicht so sorgfältig wie erforderlich...

 

[addicted]

Danke für die Erklärung, das hätte ich schon noch selbst hinbekommen. Sie verwenden vmtl. BCC-Empfänger.
Ich empfehle eine Meldung an [email protected] – diese Debug-Infos haben in ausgehenden E-Mails nichts zu suchen.