Autoresponder-, Ticket- & Support-Spam?

Plötzlich trudeln Mails ein, die ich nie initiiert hatte: Support-Bestätigungen, Autoresponder, sogar Ticket-IDs aus fremden Systemen. Die Inhalte wirken echt – sauber signiert, oft aus seriösen Tools. Und doch hat man mit den Absendern nie etwas zu tun gehabt. Was hier passiert, ist kein klassischer Hack des eigenen Postfachs oder „normaler Spam“, sondern eine fremde, offen konfigurierte Google-Group, die die eigene Adresse als Empfänger führt und seitdem alles ungefiltert weiterverteilt.

Genau das sieht man in den Kopfzeilen: Neben echten System-Absendern taucht eine List-ID wie kj.zf.thesparklebar.com auf; häufig sind weitere, dubiosere Gruppen-Domänen in der Kette zu finden, etwa ek.shirleyaraujo.com.br oder af.fluidcom.com.br. Die Gruppe ist der Dreh- und Angelpunkt: Sie nimmt Nachrichten aus allen Richtungen an – Spam, Autoresponder, legitime Tickets – und verteilt sie an alle eingetragenen Mitglieder. Ist die eigene Adresse (oder ein weitergeleiteter Alias) dort gelandet, spült es all das ins eigene Postfach.

Was da technisch im Hintergrund passiert

Google-Groups sind eigentlich praktische Verteiler. Wie offen eine Gruppe ist, entscheidet jedoch die Administration der jeweiligen Workspace-Domain. Viele ältere oder schlecht konfigurierte Gruppen erlauben das Hinzufügen externer Adressen ohne Verifizierung und akzeptieren Postings „von allen“. Trägt ein Bot dann ic*@*****le.tld als Mitglied ein, liefert die Gruppe ab sofort alles an diese Adresse aus. Das wird seit Jahren für Spam- und Backscatter-Ketten missbraucht. Derzeit aber wieder akut und sehr stark über die oben genannten Gruppen.

In den Mail-Headern erkennt man das verlässlich: Neben der List-ID stehen häufig Sender: <gruppenname@…> und X-Google-Group-Id. Der eigentliche Inhalt kann von seriösen Systemen stammen (z. B. su*****@******er.example via anbieter.zdesk.example), deshalb bestehen SPF/DKIM/DMARC dort oft sogar mit „pass“. Der Fehlkonfigurations-Hotspot ist nicht der Absender, sondern die Gruppe dazwischen.

Übrigens: Der Return-Path enthält bei weitergeleiteten Mails oft ein SRS-Präfix wie SRS0=…@meinedomain.tld. Das ist lediglich die Absender-Umschreibung deines Mailservers beim Weiterleiten, kein Zeichen, dass du versendet hättest.

Ist Google für diesen Spam verantwortlich?

Kurz: meist nein. Google stellt die Plattform bereit, aber die Verantwortung für Mitgliedschaften und Posting-Regeln liegt bei den Gruppen-Betreibern (also der jeweiligen Workspace-Domain). Rechtlich ist das Plattform-/Hoster-Logik: Google bietet standardisierte Abmeldewege (List-Unsubscribe) und reagiert auf Abuse-Meldungen, doch die Fehlkonfiguration liegt beim Gruppen-Owner. Das Ergebnis ist trotzdem nervig – aber es ist kein „Google verschickt Spam“, sondern „eine fremde Gruppe verteilt zu großzügig“.

Woran man das erkennt

Ein Blick in die Header reicht. Typische Marker:

  • List-Id: <kj.zf.thesparklebar.com> (oder ähnlich)
  • Sender: **@**************ar.com
  • X-Google-Group-Id: …
  • List-Unsubscribe: <mailto:…+un*********@**********ps.com> und/oder https://groups.google.com/...
  • Precedence: list

Sind diese Zeilen da, ist das Rätsel in der Regel gelöst.

Rauskommen: korrekt austragen – so findet man die Adresse

Der eleganteste Weg führt nicht über eine Antwort an die Gruppe, sonst erhältst du E-Mails, die du wahrscheinlich auch schon bekommen hast: „Stop Spamming“ oder „Unterlassen sie das!“ landet dann ebenfalls wieder bei ALLEN Empfängern der Gruppe. Nutze stattdessen die standardisierte List-Unsubscribe-Adresse, die ebenfalls im Header steht. Sie sieht typischerweise so aus:

List-Unsubscribe: <mailto:googlegroups-manage+XXXXXXXXXXXX+un*********@**********ps.com>

Man muss genau diese Adresse verwenden, die in DEINEM Header steht. Diese sieht vermutlich anders aus als die in meinem Beispiel! Das Schreiben an List-Post (die Gruppenadresse selbst) wäre kontraproduktiv – das würde nur in die Gruppe posten.

Wenn die betroffene Zieladresse ein Alias der eigenen Domain ist (z. B. al***@*********in.tld), kann man die Abmeldung direkt und „sauber“ vom eigenen Mailserver mit korrektem Envelope-Absender senden. Beispiel mit Postfix/Sendmail:

sendmail -f al***@*********in.tld \
  googlegroups-manage+XXXXXXXXXXXX+un*********@**********ps.com <<'EOF'
Subject: unsubscribe
From: al***@*********in.tld
To: googlegroups-manage+XXXXXXXXXXXX+un*********@**********ps.com

unsubscribe
EOF

Der Body kann leer bleiben; wichtig sind die Envelope-From-Adresse (-f alias@…) und die exakte Unsubscribe-Adresse. Je nach Gruppen-Einstellung erhält man entweder keine Rückfrage (sofort ausgetragen) oder eine kurze Bestätigungsmail, die man einmalig quittieren muss.

Wenn Austragen (noch) nicht greift: gezielt spam blocken statt Holzhammer

Pauschal „alle Google-Groups“ zu sperren, ist selten sinnvoll – es erwischt auch legitime Listen. Besser ist ein gezielter Schnitt auf die konkrete Gruppe, erkennbar an der List-Id.

  • Postfix (serverseitig, präzise): # /etc/postfix/header_checks /^List-Id:\s*<kj\.zf\.thesparklebar\.com>$/ REJECT Unwanted Google Group In main.cf aktivieren: header_checks = regexp:/etc/postfix/header_checks Dann postfix reload.
  • SpamAssassin (nur score erhöhen): header GGLGROUP_SPAM List-Id =~ /zf\.thesparklebar\.com/i score GGLGROUP_SPAM 6.0 describe GGLGROUP_SPAM Unwanted Google Group
  • Client-seitig (z. B. Outlook 365):
    Eine Regel, die Nachrichten mit List-Id: kj.zf.thesparklebar.com in einen Ordner verschiebt oder löscht – als Sicherheitsleine, falls serverseitig nichts geändert werden soll.

Und vorbeugend?

Für die eigene Domain lohnt es sich ohnehin, die Hausaufgaben zu machen: DMARC konsequent auf p=reject, SPF/DKIM sauber halten, keine Catch-Alls, unbekannte Empfänger ablehnen und Logs im Blick behalten. Das verhindert nicht jede fremde Gruppen-Fehlkonfiguration, reduziert aber Backscatter generell und hilft beim Troubleshooting.

Fazit: Nicht dein Postfach ist „gehackt“, sondern eine fremde Google-Group verteilt zu großzügig – und deine Adresse hing oder hängt als Empfänger drin. Der Ausweg ist unspektakulär: List-Unsubscribe aus dem Header nehmen, austragen, fertig. Falls das (noch) nicht greift, hilft ein gezielter Header-Filter auf die konkrete List-Id. So bleibt der Rest deiner legitimen Gruppen unberührt – und das Postfach wieder ruhig.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert