Subscription-Bombing bei Anmeldeformularen verhindern

Was ist Subscription-Bombing?

Subscription-Bombing ist ein Angriff, bei dem Ihr Anmeldeformular dazu missbraucht wird, das Postfach einer anderen Person zu überfluten. Der Angreifer nimmt die E-Mail-Adresse eines Opfers und übermittelt sie innerhalb kurzer Zeit an Hunderte oder Tausende ungeschützter Formulare. Jede dieser Websites sendet eine Willkommens- oder Bestätigungsnachricht an diese Adresse. Zusammen verdecken diese Nachrichten die E-Mails, die das Opfer tatsächlich lesen muss.

Das Ziel ist die Person, der das Postfach gehört. Während es sich mit Anmeldebestätigungen füllt, gibt der Angreifer Geld mit der Karte dieser Person aus oder setzt das Passwort eines ihrer Konten zurück. Die Betrugswarnung der Bank kommt weiterhin an. Sie landet unter zweitausend anderen Nachrichten, die innerhalb derselben Stunde eingegangen sind. Deshalb sieht sie niemand rechtzeitig.

Ihr Server ist das Werkzeug, mit dem der Angriff ausgeführt wird. Auf Ihrem System ist nichts beschädigt. Kein Konto von Ihnen wurde kompromittiert. Jemand hat eine Adresse in ein öffentliches Formular eingegeben, und Ihre Software hat genau das getan, wofür sie entwickelt wurde: Sie hat eine E-Mail an diese Adresse gesendet. Das macht den Angriff schwer erkennbar. In Ihren Logs gibt es keinen Einbruch, weil kein Einbruch stattgefunden hat.

Wie der Angriff auf Ihrer Seite aussieht

Der Angriff tritt in einer von zwei Formen auf.

Die auffällige Form ist eine Welle. Innerhalb weniger Minuten gehen mehrere hundert POST-Anfragen an ein Formular ein. Sie kommen von vielen verschiedenen Quell-IP-Adressen und enthalten Adressen von Domains, an die Sie bisher noch nie versendet haben. Diese Form ist leicht zu erkennen, sobald Sie danach suchen.

Die unauffällige Form wird oft übersehen. Der Angreifer verfügt über eine Liste mit Tausenden verwundbarer Formulare. Daher muss Ihr Formular nur ein oder zwei Übermittlungen pro Stunde beitragen. Jye Cusch beschrieb einen Angriff genau in dieser Form auf einer von ihm betriebenen Website: kein Anstieg des Datenverkehrs, sondern stetig eingehende Anmeldungen zu Uhrzeiten, die nicht zu seiner Zielgruppe passten. Ein einzelnes Formular wirkt unverdächtig, weil es allein kaum etwas tut. Der Schaden ergibt sich aus der Summe aller Formulare auf der Liste des Angreifers.

Beide Formen haben anschließend dasselbe Merkmal: Danach geschieht nichts. Die Adressen werden nie bestätigt. Niemand öffnet eine Nachricht oder klickt auf einen Link. In einer Liste mit bestätigtem Opt-in bleiben sie dauerhaft im Status unconfirmed. Diese Ansammlung ist der eindeutigste Beleg, den Sie erhalten werden.

Beginnen Sie damit, die Übermittlungen pro Minute in Ihrem Zugriffslog zu zählen.

sudo awk '/POST \/subscription\/form/ {print substr($4, 2, 17)}' \
  /var/log/nginx/access.log | uniq -c | sort -rn | head

$4 ist im standardmäßigen kombinierten Logformat der Zeitstempel in eckigen Klammern. Der Befehl gibt daher für jede Minute eine Anzahl aus, absteigend sortiert. Wenn ein Formular normalerweise vier Anmeldungen pro Tag erhält und innerhalb einer Minute sechzig anzeigt, läuft nicht einfach ein besonders guter Tag.

Bestätigtes Opt-in: die wirksamste Abwehr

Ein bestätigtes Opt-in, meist als Double-Opt-in bezeichnet, bedeutet, dass eine Adresse erst dann als Abonnent gilt, wenn eine Person auf einen Link in einer an diese Adresse gesendeten Nachricht klickt. Aktivieren Sie diese Option. Dann erzeugt jede eingetragene Adresse genau eine Nachricht. Die Adresse wird nie in die Liste aufgenommen und erhält daher weder eine Kampagne noch eine Willkommenssequenz.

In listmonk, dem selbst gehosteten Newsletter-Server ist dies eine Einstellung pro Liste: Eine Liste verwendet entweder Single-Opt-in oder Double-Opt-in. Die Dokumentation beschreibt den Unterschied eindeutig. Bei einer Double-Opt-in-Liste "bestätigen Abonnenten das Abonnement ausdrücklich, indem sie auf die Bestätigungs-E-Mail klicken, die sie erhalten. Bis dahin erhalten sie keine Kampagnennachrichten." Ein Abonnent befindet sich zunächst im Status unconfirmed, wechselt nach dem Klick zu confirmed, und nur Abonnenten im Status confirmed einer Opt-in-Liste erhalten Kampagnen-E-Mails.

Seien Sie bei der Wirkung realistisch. Ein bestätigtes Opt-in reduziert Ihren Beitrag nicht auf null. Es begrenzt ihn auf eine Nachricht pro Adresse. Das Opfer erhält diese Nachricht weiterhin, und jeweils eine Nachricht von tausend Websites reicht für den gesamten Angriff aus. Das bestätigte Opt-in verhindert alles, was danach käme: Ihre Liste bleibt sauber, und Sie senden nie eine zweite Nachricht an jemanden, der die erste nie angefordert hat.

Zwei weitere Einstellungen sind wichtig und werden leicht vergessen. Begrenzen Sie erstens die erneuten Sendungen der Bestätigung. Wenn dieselbe Adresse erneut eingetragen werden kann und dabei jedes Mal eine weitere Bestätigungs-E-Mail erhält, benötigt der Angreifer keine tausend Formulare, weil Ihr Formular allein tausend Nachrichten versendet. Eine Adresse, die sich auf dieser Liste bereits im Status unconfirmed befindet, sollte mindestens einen Tag lang keine weitere Nachricht erhalten. Löschen Sie zweitens unbestätigte Einträge nach einem festen Zeitplan. Eine Adresse, die seit dreißig Tagen nicht bestätigt wurde, ist kein ausstehender Abonnent. Wenn Sie sie behalten, besteht lediglich die Möglichkeit, dass später versehentlich eine Nachricht an sie gesendet wird.

Ratenbegrenzung für das Registrierungsformular am Reverse Proxy

Setzen Sie die Begrenzung vor der Anwendung und nicht innerhalb der Anwendung. Eine am Proxy blockierte Anfrage öffnet nie eine Datenbankverbindung und beginnt nie eine SMTP-Konversation (Simple Mail Transfer Protocol). Eine Begrenzung innerhalb der Anwendung greift erst, nachdem die Anfrage bereits einen Worker-Prozess und eine Abfrage gekostet hat. In vielen Stacks wird die Nachricht außerdem bereits in die Warteschlange gestellt, bevor eine Missbrauchsprüfung erfolgt. Die Proxy-Begrenzung bleibt auch nach einem Upgrade der Anwendung bestehen, weil sie nicht in dem Code liegt, den Sie ersetzen.

Das folgende Beispiel verwendet nginx. Das Prinzip lässt sich auf den Reverse Proxy übertragen, den Sie vor Ihrer Anwendung betreiben, auch wenn die Direktiven anders heißen.

Fügen Sie dies in den http-Block ein, beispielsweise in einer Datei wie /etc/nginx/conf.d/signup-limit.conf:

map $request_method $signup_key {
    POST    $binary_remote_addr;
    default "";
}

limit_req_zone $signup_key zone=signup:10m rate=2r/m;
limit_req_status 429;
limit_req_log_level warn;

map übernimmt die eigentliche Arbeit. nginx zählt keine Anfrage, deren Schlüssel eine leere Zeichenfolge ist. Deshalb gelangen nur POST-Anfragen in die Zone. Das mehrmalige Laden der Registrierungsseite kostet den Benutzer nichts. Ohne diese Map würde jemand, der die Seite zweimal aktualisiert, sein eigenes Kontingent aufbrauchen, bevor überhaupt eine Übermittlung erfolgt.

$binary_remote_addr ist die Clientadresse in komprimierter Form. Deshalb kann eine 10-Megabyte-Zone ungefähr 160,000 Adressen aufnehmen. rate=2r/m erlaubt eine Übermittlung alle dreißig Sekunden. limit_req_status 429 gibt HTTP 429 Too Many Requests statt des nginx-Standardwerts 503 zurück. Das ist der korrekte Statuscode und derjenige, den eine Clientbibliothek erwartet.

Fügen Sie anschließend im server-Block für Ihre Site Folgendes ein:

location = /subscription/form {
    limit_req zone=signup burst=3 nodelay;
    proxy_pass http://127.0.0.1:9000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

burst=3 nodelay lässt eine Person passieren, die doppelt auf die Schaltfläche klickt, und weist die vierte Anfrage sofort zurück, statt sie in die Warteschlange zu stellen.

sudo nginx -t && sudo systemctl reload nginx

nginx -t sollte configuration file /etc/nginx/nginx.conf test is successful ausgeben. Übermitteln Sie das Formular nun fünfmal schnell hintereinander und überwachen Sie das Fehlerprotokoll:

sudo tail -f /var/log/nginx/error.log

Eine blockierte Anfrage schreibt eine Zeile. Nach dieser Zeichenfolge suchen Sie:

2026/08/13 09:14:22 [warn] 812#812: *4412 limiting requests, excess: 3.400 by zone "signup", client: 203.0.113.10, server: news.example.com, request: "POST /subscription/form HTTP/1.1", host: "news.example.com"

Wenn überhaupt keine Zeile erscheint, wird die Begrenzung nicht angewendet. Die übliche Ursache ist, dass limit_req in einem location-Block steht, den die Anfrage nicht erreicht. Prüfen Sie dies daher mit curl -si -X POST https://news.example.com/subscription/form mehrmals hintereinander und bestätigen Sie, dass Sie ein 429 erhalten.

Vor einer Begrenzung pro IP-Adresse sollten Sie zwei Probleme kennen.

Hinter einem CDN oder einem anderen Proxy ist $binary_remote_addr dieser Proxy. Alle Besucher landen im selben Kontingent. Dadurch sperren die ersten Übermittlungen jeder Minute alle anderen Besucher aus. Beheben Sie das mit dem Modul für die echte IP-Adresse: set_real_ip_from für jeden veröffentlichten Bereich Ihres CDN (Cloudflare führt diese unter cloudflare.com/ips) und real_ip_header CF-Connecting-IP. Bestätigen Sie die Korrektur, indem Sie $remote_addr in Ihrem Access-Log auslesen und prüfen, dass dort eine Besucheradresse und nicht die Adresse Ihres CDN steht.

IPv6 macht eine Begrenzung pro Adresse schwach. $binary_remote_addr speichert das vollständige /128-Präfix. Eine private IPv6-Zuweisung ist normalerweise ein /64 oder größer. Das sind deutlich mehr Adressen, als ein Angreifer nutzen kann. Jede Adresse hat dabei ein eigenes, ungenutztes Kontingent. Fügen Sie eine zweite Zone als Obergrenze für den Endpunkt selbst hinzu. Verwenden Sie dafür einen konstanten Schlüssel, damit für das Formular unabhängig von der Anzahl der verwendeten Quelladressen eine Gesamtrate gilt:

map $request_method $signup_total_key {
    POST    "signup";
    default "";
}

limit_req_zone $signup_total_key zone=signup_total:1m rate=30r/m;

Fügen Sie limit_req zone=signup_total burst=10 nodelay; in dasselbe location ein. Setzen Sie die Rate mit ausreichendem Spielraum über Ihre höchste tatsächliche Auslastung pro Stunde. Diese grobe Begrenzung weist während eines Angriffs auch legitime Registrierungen ab. Das ist der richtige Kompromiss, weil die Alternative darin besteht, dass Ihr Server die E-Mail versendet.

Warum das Limit pro Adresse nicht am Proxy umgesetzt werden kann

Die E-Mail-Adresse steht im POST-Body, und nginx wertet Request-Bodies nicht aus. Jede Variable, limit_req_zone anhand derer der Proxy einen Schlüssel bilden kann, stammt aus der Request-Zeile, den Headern oder der Verbindung. Eine Regel wie „Diese Adresse darf höchstens eine Bestätigung pro Tag erhalten“ muss daher in der ersten Komponente umgesetzt werden, die den Body liest. Das ist Ihre Anwendung.

Umgehen Sie das nicht, indem Sie die Adresse in den Query-String verschieben, damit $arg_email verfügbar wird. Dadurch schreiben Sie die Adresse jedes Abonnenten im Klartext in Ihr Access-Log und in jeden nachgelagerten Log-Sammler. Sie würden ein Rate-Limit gegen ein Datenschutzproblem eintauschen.

Es gibt eine echte Ausnahme. Das nginx-JavaScript-Modul njs kann den Request-Body lesen und daraus eine Variable setzen. Damit können Sie am Proxy einen Schlüssel pro Adresse bilden. Das ist eine reale Option, bringt aber auch neuen Code in Ihren Request-Pfad. Bei den meisten Websites gehört die Begrenzung pro Adresse neben die Datenbank, die bereits weiß, ob für diese Adresse eine ausstehende Bestätigung vorhanden ist. Der Proxy übernimmt dagegen die Limits pro IP-Adresse und Endpunkt, für die er gut geeignet ist.

Eingaben nicht in der Nachricht wiederholen

Halten Sie jede vom Angreifer übermittelte Zeichenfolge aus der gesendeten Nachricht heraus. Dafür gibt es zwei voneinander unabhängige Gründe. Beide Angriffsmethoden wurden bereits in der Praxis eingesetzt.

Wenn Ihre Bestätigungs-E-Mail den Namen aus dem Formular verwendet, trägt der Angreifer seine Nachricht in das Namensfeld ein. Ihr Server übermittelt diesen Text anschließend von Ihrer Domain an das Opfer und signiert ihn mit Ihrem DKIM-Schlüssel (DomainKeys Identified Mail). Ihre Website dient damit als Versanddienst für den Missbrauch durch Dritte. Beim empfangenden Provider erscheint dabei Ihre Domain als Absender.

Der zweite Grund ist schwerwiegender. Wenn ein übermitteltes Feld manuell in einen Mail-Header eingefügt wird, kann ein Zeilenumbruch in diesem Feld beliebige Header des Angreifers hinzufügen, darunter Bcc. Moderne Mail-Bibliotheken lehnen Zeilenumbrüche in Header-Werten ab. Code, der Text aus einem Shell-Skript an sendmail weiterleitet, tut dies häufig nicht.

Eine sichere Bestätigungsnachricht enthält den Namen Ihrer Website und einen Link sowie einen erklärenden Satz. Die Adresse selbst erscheint nur dort, wo der Mail Transfer Agent sie benötigt, im Header To. Testen Sie dies: Senden Sie das Formular mit einem Namensfeld ab, das einen Zeilenumbruch und einen offensichtlichen Link enthält. Lesen Sie anschließend die empfangene Rohfassung der Nachricht mit less und prüfen Sie, dass beides nicht enthalten ist.

Sorgen Sie außerdem dafür, dass die Erfolgsseite für jede Adresse denselben Text anzeigt. Eine Seite, die für eine Adresse „Sie sind bereits registriert“ und für eine andere „Prüfen Sie Ihren Posteingang“ anzeigt, macht Ihr Formular zu einem Abfragewerkzeug für die Mitgliedschaft. Jeder, der eine Liste zu prüfender Adressen besitzt, kann es dafür verwenden.

Welche Bot-Prüfung sollten Sie verwenden?

Wählen Sie die Prüfung mit Blick auf die Barrierefreiheit genauso sorgfältig wie mit Blick auf die Wirksamkeit aus. Ein Captcha zur Bildauswahl kann von blinden Menschen nicht gelöst werden. Die Audio-Alternative ist für Menschen mit gewöhnlichem Hörvermögen schwierig. Wenn eine Prüfung dazu führt, dass eine legitime Person die Registrierung abbricht, ist diese Abwehrmaßnahme zugleich ein Kostenfaktor. Es gibt vier Optionen, die Sie in dieser Reihenfolge ausprobieren sollten.

Proof of Work im Browser. Der Browser berechnet einen Hash, den der Server kostengünstig verifizieren kann. Die Person muss dabei nichts lösen. listmonk bietet diese Option unter Settings und anschließend Security mit ALTCHA an. Dafür ist kein Drittanbieterdienst erforderlich. Seit August 2026 empfiehlt listmonk diese Option anstelle der veralteten hCaptcha-Option. Die Kosten trägt, wer die meisten Anfragen sendet, also der Angreifer.

Eine verwaltete, nicht interaktive Prüfung. Cloudflare Turnstile zeigt den meisten Besuchern überhaupt nichts an und fordert nur dann eine Prüfung an, wenn seine Signale verdächtig wirken. Die Lösung ist wirksam, bindet aber einen Drittanbieter in den Registrierungsvorgang ein.

Ein Honeypot-Feld. Dabei handelt es sich um ein Texteingabefeld, das eine Person nicht sieht, das ein einfacher Bot aber ausfüllt. Verwenden Sie einen Namen, den Ihr Formular an keiner anderen Stelle nutzt, und setzen Sie autocomplete="off", tabindex="-1" und aria-hidden="true", damit ein Passwortmanager das Feld nicht ausfüllt und ein Screenreader es nicht ansagt. Ein Feld mit dem Namen email2 oder address wird vom Browser automatisch ausgefüllt. Dadurch würden Sie anschließend echte Personen ablehnen.

<div style="position:absolute; left:-9999px;" aria-hidden="true">
  <label for="hp_ref">Leave this field empty</label>
  <input type="text" id="hp_ref" name="hp_ref" autocomplete="off" tabindex="-1">
</div>

Eine Prüfung der Übermittlungsdauer. Fügen Sie beim Rendern der Seite einen signierten Zeitstempel in ein verborgenes Feld ein. Lehnen Sie eine Übermittlung ab, die weniger als zwei Sekunden später eintrifft. Eine Person kann ein Formular nicht lesen und eine Adresse nicht so schnell eingeben. Signieren Sie den Zeitstempel. Andernfalls sendet der Bot einfach einen alten Zeitstempel.

Unabhängig von Ihrer Wahl müssen Sie einen Punkt prüfen: Das Token muss genau einmal verwendet werden. Wenn ein Skript die Prüfung einmal lösen und dieses Token anschließend für tausend Adressen wiederverwenden kann, hat die Prüfung lediglich bewiesen, dass einmal ein Browser ausgeführt wurde, und nicht mehr.

Woran erkennen Sie den Missbrauch, bevor die Abuse-Meldung eintrifft?

Ihre eigenen Diagramme sollen Sie informieren, nicht der Abuse-Desk des Hosting-Anbieters. Überwachen Sie zwei Werte.

Zählen Sie die Übermittlungen je Quelladresse im gesamten Log:

sudo awk '/POST \/subscription\/form/ {print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

Lassen Sie fail2ban anschließend dieselben limiting requests-Zeilen auswerten, die nginx bereits schreibt, und wiederholte Angreifer sperren. fail2ban enthält dafür bereits einen passenden Filter. Erstellen Sie /etc/fail2ban/jail.d/nginx-limit-req.local:

[nginx-limit-req]
enabled  = true
filter   = nginx-limit-req
port     = http,https
logpath  = /var/log/nginx/error.log
findtime = 600
maxretry = 10
bantime  = 3600

sudo systemctl reload fail2ban
sudo fail2ban-client status nginx-limit-req

Die Statusausgabe zeigt den Filter des Jails sowie die aktuelle Anzahl fehlgeschlagener und gesperrter Versuche. Currently banned: 0 an einem ruhigen Tag ist korrekt. Wenn das Jail überhaupt nicht erscheint, hat fail2ban die Datei nicht geladen. Mit sudo fail2ban-client -d | grep nginx-limit-req geben Sie die Konfiguration aus, die tatsächlich eingelesen wurde. Der mitgelieferte Filter erfasst jede limit_req-Zone. Beschränken Sie ihn auf Ihre Anmeldezone, indem Sie ngx_limit_req_zones = signup in einem [Definition]-Abschnitt von /etc/fail2ban/filter.d/nginx-limit-req.local setzen. Der Aufbau der Jail-Datei und die Sperrbefehle werden ausführlicher im fail2ban-Leitfaden für Ubuntu 24.04 beschrieben.

Das zweite Signal ist ein Verhältnis und erfordert keine neue Software: Übermittlungen geteilt durch Bestätigungen. Bei einer gesunden Liste klicken die meisten Personen, die eine Adresse übermitteln, auf den Link, normalerweise deutlich mehr als die Hälfte. Wenn dieses Verhältnis sinkt, während die Zahl der Übermittlungen steigt, wird Ihr System missbraucht. Vergleichen Sie die Anzahl der in der letzten Stunde erstellten unconfirmed-Abonnenten mit der Anzahl der confirmed-Abonnenten, und zwar nach dem Zeitplan, nach dem Sie ohnehin bereits Berichte erstellen.

Was es Sie kostet: Absenderreputation und Blocklists

Das ist der Punkt, an dem aus einem Ärgernis eine Rechnung wird.

Die für solche Bombing-Angriffe verwendeten Adresslisten werden zusammengetragen. Diese Listen enthalten Spamtraps: Adressen, die sich nirgendwo für etwas registriert haben und ausschließlich dazu veröffentlicht werden, Absender zu identifizieren, die ohne Einwilligung E-Mails versenden. Ihre Bestätigungsnachricht erreicht eine solche Adresse. Für manche Betreiber von Blocklists reicht das bereits aus.

Empfänger, die Ihre Nachricht nie angefordert haben, klicken nicht auf „Abbestellen“. Sie klicken auf „Spam melden“. Die seit Februar 2024 geltenden Bulk-Sender-Regeln von Google verlangen von Absendern, die mindestens 5,000 Nachrichten pro Tag an Gmail senden, eine in Postmaster Tools gemessene Spam-Beschwerderate von unter 0.3 %. Ein kleinerer Absender wird nicht an diesem Wert gemessen. Dasselbe Beschwerdesignal fließt jedoch in die Filterentscheidungen ein, durch die Ihre E-Mails im Spam-Ordner landen. Die gefälschten Adressen im Lauf erzeugen außerdem viele Hard Bounces. Eine steigende Hard-Bounce-Rate ist bei jedem großen Provider ein eigenes Reputationssignal.

Wenn Sie Ihren eigenen Mailserver auf einem VPS mit mailcow betreiben, wird Ihre IP-Adresse und Ihre Domain auf die Blocklist gesetzt. Die Entfernung durch einen Betreiber wie Spamhaus erfordert ein Formular und Wartezeit. Währenddessen werden auch Ihre Rechnungen und Passwort-Zurücksetzungen nicht zugestellt. Wenn Sie stattdessen über einen gemeinsam genutzten Provider versenden, müssen Sie damit rechnen, dass dieser zuerst Ihr Konto sperrt und erst danach Ihre Erklärung liest. Ihr Netzwerkverkehr stellt ein Risiko für alle anderen Absender auf dieser IP-Adresse dar.

Dem gegenüber steht ein geringer Arbeitsaufwand. Aktivieren Sie noch heute Confirmed Opt-in, weil dies pro Liste nur eine Einstellung erfordert. Fügen Sie anschließend das Rate-Limit im Proxy hinzu, weil dafür nur eine Datei und ein Reload erforderlich sind. Die Bot-Prüfung und das Alerting können im Laufe dieser Woche folgen.

FAQ

Stoppt Double-Opt-in Subscription-Bombing?

Es verhindert, dass Ihre Liste mit unbestätigten Einträgen verunreinigt wird, und begrenzt Ihren eigenen Beitrag auf eine Nachricht pro übermittelter Adresse. Das ist die wichtigste einzelne Verbesserung, die Sie umsetzen können. Das Füllen des Posteingangs des Opfers verhindert es nicht, weil der Angriff aus jeweils einer Nachricht von tausend Websites besteht. Kombinieren Sie es mit einem Limit pro IP-Adresse an Ihrem Proxy und einer Begrenzung für erneute Bestätigungsnachrichten. Dadurch erzeugt die zweimalige Übermittlung derselben Adresse keine zweite Nachricht.

Woran erkenne ich einen Bombing-Angriff im Gegensatz zu einem guten Tag mit echten Anmeldungen?

Prüfen Sie, was nach der Übermittlung geschieht. Echte Anmeldungen werden bestätigt, normalerweise innerhalb weniger Stunden. Bei einem Bombing-Angriff bleibt eine große Zahl von Adressen übrig, die nie bestätigt werden, nie geöffnet werden und nie angeklickt werden. Auch die Übermittlungen weisen ungewöhnliche Muster auf: viele Quelladressen, die Sie bisher nicht gesehen haben, Empfängerdomänen, an die Sie normalerweise nicht senden, und gleichmäßig über den ganzen Tag verteilte Eingangszeiten statt einer Verteilung entsprechend den Wachzeiten Ihrer Zielgruppe.

Sollte ich die übermittelten Adressen löschen?

Ja. Löschen Sie unbestätigte Einträge, die älter als etwa dreißig Tage sind, und automatisieren Sie dies zeitgesteuert statt manuell. Senden Sie diesen Adressen niemals etwas anderes, auch keine Entschuldigung und keine Nachricht wie „War das von Ihnen?“. Das wäre eine zweite unaufgeforderte Nachricht an jemanden, dessen Posteingang bereits mit solchen Nachrichten gefüllt wurde. Wenn einige dieser Adressen Spamtraps waren, ist eine Folgem Nachricht genau die Bestätigung, auf die der Betreiber der Blocklist wartet.

Werden durch Rate Limiting echte Abonnenten abgewiesen?

Ein Limit pro IP-Adresse von einer Übermittlung alle dreißig Sekunden mit einem Burst von drei ist für eine Person, die ein Formular einmal ausfüllt, nicht wahrnehmbar. Es wird sichtbar, wenn sich viele echte Personen eine Adresse teilen, etwa in einem Büro hinter einem einzelnen NAT-Gateway (network address translation), oder wenn Ihr Proxy statt der Besucheradresse die Adresse Ihres CDN sieht. Lesen Sie $remote_addr in Ihrem Access-Log, bevor Sie die Limits verschärfen, und setzen Sie das Endpoint-Limit über das Niveau Ihrer geschäftigsten realen Stunde.

Meine sendende IP-Adresse steht nach einem Angriff auf einer Blocklist. Was soll ich zuerst tun?

Senden Sie nichts mehr von dieser Adresse, bevor Sie weitere Schritte einleiten. Pausieren Sie die Kampagnenwarteschlange, beheben Sie das Formular und löschen Sie die unbestätigten Adressen. Eine Entfernung von der Blocklist, auf die erneut derselbe Netzwerkverkehr folgt, führt schneller zu einer erneuten Aufnahme als beim ersten Mal. Ermitteln Sie anschließend, auf welcher Liste Ihre Adresse steht. Die meisten Betreiber bieten eine Suchseite an, die Ihre IP-Adresse verwendet, und beschreiben dort das Verfahren zur Entfernung. Rechnen Sie mit einer Wartezeit von mehreren Tagen. Nutzen Sie diese Zeit, um zu prüfen, ob Ihr SPF-Eintrag (sender policy framework) und Ihre DKIM-Signatur weiterhin erfolgreich validiert werden.