Blacklist für eigene Domain mit Catchall

7556051 hat dies geteilt, 1 Jahr her
vorgeschlagen

Ich habe seit Jahren mit meiner eigenen Domain eine Catchall-Adresse im Einsatz um bspw. bei Registrierungen o.Ä. spezifische local-parts verwenden zu können. Als Ergebnis sind nun mittlerweile diverse local-parts "verbrannt" und werden mit Spam bombardiert. Da ich bisher den SMTP selbst betrieben habe, konnte ich verbrannte local-parts in einer Blacklist eingetragen und direkt im SMTP verwerfen.

Mit dem Umzug zu mailbox.org möchte ich den Betrieb des SMTP nun einstellen und die Blacklist bei mailbox.org führen. Wie in anderen Foren-Threads allerdings beschrieben, wird der Envelope-to bei Catchalls leider nicht in den Mail-Header eingetragen, so dass darauf nicht gefiltert werden kann. Auf der anderen Seite ist meine Blacklist deutlich länger als 25 Einträge, so dass ich die verbrannten Adressen auch nicht als Aliase eintragen und filtern kann.

Für mein Szenario wäre es deshalb wünschenswert, wenn Aliase geblacklisted werden könnten, die dann bereits vor dem Filtering direkt im SMTP verworfen werden. Als Gewinn für mailbox.org steht eine Entlastung des Spamfilters.

Kommentare (12)

Foto
1

Auf die Envelope-to-Adresse lässt sich via Mailsieve sehr wohl filtern, hier der Code-Schnipsel wie ich ihn selbst erfolgreich in Betrieb habe:

  1. if header :matches :index 3 "Received" "*<your_localpart@your_domain.tld>*"
  2. {
  3. fileinto "your_folder";
  4. }

So lassen sich beliebig viele 'verbrannte' local-parts ausfiltern. Die Sieve-Filter bearbeitet man am besten mit einem Addon für einen lokalen Mailclient wie z.B. https://addons.mozilla.org/en-US/thunderbird/addon/sieve/ (muss 'aus Datei' installiert werden und funktioniert dann auch mit der neusten Thunderbird-Version bestens).

Foto
1

Das Problem ist aber, dass der envelope_to bei catchall Adressen nicht durchgereicht wird. Sonst könnte man das auch schon in der Webmail als Filter einrichten.

Foto
1

Ob der envelope-to header durchgereicht wird oder nicht ist irrelevant denn wie in meinem Beispiel beschrieben kann auf das dritte (oder vierte oder fünfte) 'Received' gefiltert werden um die gewünschte Funktion zu realisieren:

  1. Return-Path: <sender@sender.tld>

    Delivered-To: hauptadresse@your_domain.tld

    Received: from director-03.heinlein-hosting.de ([80.241.60.215])

    by dobby5.heinlein-hosting.de (Dovecot) with LMTP id xyz

    for <hauptadresse@your_domain.tld>; Tue, 1 Feb 2013 03:02:53 +0100

    Received: from mx2.mailbox.org ([80.241.60.215])

    (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))

    by director-03.heinlein-hosting.de (Dovecot) with LMTP id xyz

    ; Tue, 1 Feb 2013 03:02:53 +0100

    Received: from spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117])

    by mx2.mailbox.org (Postfix) with ESMTP id xyz

    for <your_localpart@your_domain.tld>; Tue, 1 Feb 2013 03:01:52 +0100 (CET)

    X-Virus-Scanned: amavisd-new at heinlein-support.de

    Received: from mx2.mailbox.org ([80.241.60.215])

    by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [91.198.250.170]) (amavisd-new, port 10024)

    with ESMTP id xyz for <your_localpart@your_domain.tld>;

    Tue, 1 Feb 2013 03:01:49 +0100 (CET)

    X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-0.5 HELO_IP_IN_CL16_SUBNET=-0.31 (check from: .sender. - helo: .mail.sender. - helo-domain: .sender.) CL_HOSTNAME_MATCHES_FROM(DOMAIN)=-0.1; rate: -3.1

    Received: from mail.sender.tld (outm.sender.tld [1.2.3.4])

    (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))

    (No client certificate requested)

    by mx2.mailbox.org (Postfix) with ESMTPS

    for <your_localpart@your_domain.tld>; Tue, 1 Feb 2013 03:01:46 +0100 (CET)

Dazu braucht es selbstverständlich einen anständigen Sieve-Editor/Uploader wie das beschriebene Addon. Per Webmail-GUI geht das nicht.

Foto
1

Das ist aber auch ein ganz schöner Hack.

Ob und in welchem received header die ürsprüngliche Addresse steht kann sich mit serverseitigen Software-Updates und Architekturänderungen jederzeit ändern.

Vllt. besser einfach mal nachfragen, ob man mehr als 25 aliases bekommen kann.

Foto
Foto
2

Danke für den heißen Tipp mit Mailsieve! Das Ganze lässt sich natürlich auch per Webmail-GUI ohne spezielle Addons gut brauchbar einstellen:

Einstellungen -> Email -> Filterregeln -> Neuer Filter

Typ: Header

Name: Received

enthält: for <burned@example.com>

Aktion: Hier auf keinen Fall "Ablehnen mit Begründung" nutzen, siehe https://userforum.mailbox.org/topic/filterregel-aktion-ablehnen-f%C3%BChrt-zur-ver%C3%B6ffentlichung-der-mailbox-hauptadresse

Stattdessen einfach:

Umleiten nach: spam@example.invalid

So bekommt der Spam-Absender eine Benachrichtigung vom "Mail Delivery System" darüber, dass die Zustellung nicht erfolgreich war.

Foto
1

Auf das Problem mit der Veröffentlichung der Hauptadresse bin ich auch grade gestoßen. Leider führt die Umleitung auf eine ungültige EMail-Adresse wie spam@spam.spam dazu, dass der Absender keine Nachricht über die Unzustellbarkeit erhält (grade von gmail aus getestet).

Foto
1

Gerade nochmal getestet und kann ich nicht bestätigen. Klappt bei mir wie gehabt wie oben beschrieben. Ich gehe davon aus, dass Gmail sich hier möglicherweise wieder mal für schlau hält und die Mail herausfiltert?

Foto
1

Wie im benachbarten Thread geschrieben (https://userforum.mailbox.org/topic/filterregel-aktion-ablehnen-f%C3%BChrt-zur-ver%C3%B6ffentlichung-der-mailbox-hauptadresse#comment-14252) funktioniert es bei mir mit redirect "spam@example.invalid" oder anderer ungültigen Adresse auch nicht.

Getestet habe ich mit Absendern von verschiedenen Providern aus.

Mit den Filtern bei ox.io funktioniert es noch! Prinzipiell sollte es also gehen.

Foto
Foto
1

Also wenn ich

Umleiten nach: spam@example.invalid

verwende, erhalte ich eine "Undelivered Mail Returned to Sender" in der u.a. meine Hauptadresse sichtbar ist, was natürlich gar nicht geht. Da nehme ich doch lieber "Verwerfen".

Foto
1

Gerade nochmal getestet und kann ich einschränkt zustimmen.

Die Hauptaddresse taucht zwar nicht "sichtbar" im Text der Email auf, wohl aber wenn man in den Headern nach dem letzten Multipart "Content-Description: Undelivered Message" nachschaut (in etwa sowas wie ein üblicherweise nicht sichtbarer "Anhang" der Mail). Der durchschnittliche User oder auch Spammer sieht die Hauptadresse also wohl eher nicht, bei genauerem Hinschauen ist sie aber sehr wohl sichtbar.

Es ist und bleibt ein Hack - für meinen Verwendungszweck aktuell "okay", da besser als garkeine Mitteilung bei "Verwerfen" oder sichtbare Hauptadresse bei "Ablehnen mit Begründung" (YMMV).

Foto
1

Ja, stimmt, ist in den Headern sichtbar u.a.:

  1. X-Sieve-Redirected-From: <hauptadresse>@mailbox.org
  2. Delivered-To: <hauptadresse>@mailbox.org

Warum ist Dir die Rückantwort so wichtig? Wertet der durchschnittliche Spammer das aus und berücksichtigt es beim nächsten Mal? Bin nur neugierig.

Foto
1

> Ja, stimmt, ist in den Headern sichtbar u.a.: […]

Korrekt, wobei man anmerken sollte, dass die Adresse eben nicht in den Headern(!) der Antwort selber enthalten ist, sondern in den Headern der Nachrichtig die als "Anhang" der Antwort hinzugefügt wird. Das mag nach einer Spitzfindigkeit klingen, bedeutet in der Praxis aber eben, dass sie nicht als unmittelbarer Teil der Antwort automatisch ausgewertet werden.

> Warum ist Dir die Rückantwort so wichtig?

Das "Verwerfen" wirkt auf Absenderseite so, als wäre die Email erfolgreich zugestellt worden und somit wird üblicherweise weiterhin versucht an diese Adresse zuzustellen. Das "Weiterleiten" wie oben beschrieben sorgt dafür, dass der Absender einen Fehler zurückgeschickt bekommt und somit dafür sorgen kann, dass der Versand eingestellt wird. Das ist üblicher Bestandteil von Newsletter-Versendern (Bounce-Handling) und meiner Erfahrung nach nutzen auch einige Spam-Versender ähnliche Mechanismen. Inbesondere für nicht-automatischen Versand ist eine Rückmeldung in meinem Fall für "verbrannte" Empfänger mindestens genau so wichtig.

Der "durschnittliche Spammer" benutzt aus Resourcen-Gründen häufig nur rudimentäre SMTP-Implementierungen, die oft nicht mal Retries (Greylisting) oder Bounces unterstützen, für den Fall ist eine Rückantwort in aller Regel tatsächlich hinfällig.

Foto