Eingehende E-Mails: Antworten auf Kampagnen

Wenn ein Empfänger bei einer Kampagnen-E-Mail auf Antworten klickt, kommt die Antwort zu WeZend zurück und landet in der Inbox — im gleichen Thread wie alles andere, was Sie an diese Adresse gesendet haben, und genau der Kampagne und genau der Nachricht zugeordnet, auf die geantwortet wurde. E-Mail wird zur Zwei-Wege-Kommunikation, so wie SMS und WhatsApp es bereits waren.

Wie die Zuordnung funktioniert

Jede Kampagnen-E-Mail erhält ein Reply-To pro Nachricht in der Form reply+<nachrichten-id>@reply.ihrefirma.de (VERP). Das Token ist die eigene UUID der Nachricht, sodass beim Eintreffen der Antwort nichts über Adresse und Zeitnähe geraten wird: die id löst sich deterministisch auf genau einen Kunden, eine Kampagne und eine Ursprungsnachricht auf.

Zwei Regeln halten das vorhersehbar:

• Nur Kampagnen-Sendungen werden gestempelt — ein transaktionales POST /v1/messages/send bleibt unberührt.
• Ein explizites reply_to beim Versand gewinnt immer. Setzen Sie es, lässt WeZend es unangetastet, die Antwort geht stattdessen in Ihr eigenes Postfach und nichts landet in der Inbox.

Was mit einer Antwort passiert

1. Der empfangende Transport parst die MIME-Nachricht und sendet sie per POST an POST /v1/webhooks/inbound-email — mit Shared Secret authentifiziert, dieselbe Konvention wie bei den Zustellbericht-Webhooks.
2. Die Antwort wird für die dauerhafte Verarbeitung in eine Queue gestellt und über ihre Message-ID dedupliziert, sodass ein Provider, der dieselbe Mail erneut POSTet, keine Kopie erzeugen kann. Ist die Queue nicht verfügbar, verarbeitet der Webhook die Antwort inline statt sie zu verwerfen, und der Endpoint antwortet immer mit 2xx, damit der Provider nie hart wiederholt.
3. Die Antwort wird in die Konversation für diese Adresse eingefädelt und mit Betreff, HTML-Body, den SPF/DKIM/DMARC-Ergebnissen und der id der beantworteten Kampagne gespeichert.
4. Ein message.received-Plattform-Event wird ausgelöst, sodass Ihr CRM oder Helpdesk die Antwort ohne Polling erhält. Wenn Sie eine eingehende Webhook-URL gesetzt haben, wird die Antwort auch dorthin weitergeleitet.

Was verworfen wird, bevor es Sie erreicht

• Spam und Authentifizierungsfehler — ein Spam-Score von 8 oder höher oder ein DMARC fail wird in Quarantäne gestellt und wird niemals ein Kontakt oder eine Konversation.
• Autoresponder — alles mit einem Auto-Submitted-Header außer no (Abwesenheitsantworten, Ticket-Bestätigungen) wird ignoriert, damit Antworten nicht in Schleifen laufen.
• Nicht zuordenbare Mail — eine Antwortadresse ohne gültiges Nachrichten-Token oder mit einem Token, das zu keiner Nachricht passt, wird abgewiesen statt geraten.

Eine Antwort, die nur STOP lautet (oder unsubscribe, afmeld, framelding …), wird als Abmeldung behandelt, bevor sie ein Support-Ticket wird: die Adresse landet auf der Sperrliste, ein Einwilligungsnachweis wird geschrieben, und contact.unsubscribed wird ausgelöst — siehe Einwilligung.

Anhänge

Anhänge werden pro Antwort gespeichert: JPEG, PNG, GIF, WebP und PDF, bis zu 15 MB pro Datei und 20 Dateien pro Nachricht. Andere Content-Typen werden als übersprungen vermerkt statt gespeichert.

Jeder Anhang wird an ClamAV gestreamt (clamd, über dessen INSTREAM-Kommando), bevor irgendetwas auf die Festplatte geschrieben wird — die Datei wird im Speicher geprüft, und nur ein sauberes Ergebnis wird geschrieben. Die Entscheidung ist fail-closed: eine infizierte Datei wird als skipped: "virus" vermerkt, und ist clamd nicht erreichbar, läuft auf einen Fehler oder in einen Timeout, wird die Datei als skipped: "scan_unavailable" vermerkt und eine Operator-Warnung ausgelöst. Ein Scan, der nie ein Ergebnis liefert, gilt nie als sauber — ein Scanner-Ausfall kann also nicht stillschweigend darauf zurückfallen, ungeprüfte Fremddateien zu speichern. Die Antwort selbst landet weiterhin in der Inbox, zurückgehalten wird nur die Datei.

Gespeicherte Dateien sind nicht öffentlich. Sie werden ausschließlich über GET /v1/media/inbound/:name heruntergeladen, was eine Dashboard-Session erfordert und den Pfad auf der Festplatte aus der eigenen customer_id des Aufrufers ableitet, nie aus der URL — ein nicht erratbarer Dateiname ist damit nicht mehr der einzige Schutz, und ein Kunde kann niemals die Datei eines anderen abrufen. Der Name wird gegen ein festes Muster geprüft (16 Hex-Zeichen plus erlaubte Endung), Path Traversal wird entfernt. Jeder Download wird mit Content-Disposition: attachment und X-Content-Type-Options: nosniff erzwungen, sodass ein bösartiges PDF eines externen Absenders nicht inline auf einem wezend.com-Origin rendern kann, und Cache-Control: private, no-store verhindert, dass eine später als bösartig erkannte Datei weiter unten in der Kette liegen bleibt. Der öffentliche /media-Mount antwortet auf alles unter inbound/ mit 404. Kampagnenbilder bleiben öffentlich — E-Mail-Clients müssen sie ohne Session laden können — und Fremd-Mail ist bewusst der umgekehrte Fall.

Das Scannen gehört zum Operator-Setup, genau wie das DNS weiter unten: clamd wird im Backend verdrahtet (CLAMAV_SOCKET, oder CLAMAV_HOST/CLAMAV_PORT), bevor eingehende E-Mail eingeschaltet wird. Ist kein Scanner konfiguriert, werden Anhänge gespeichert und mit scanned: false vermerkt — dieser Pfad existiert für Dev- und Test-Builds, nicht für eine Domain, die echte externe Mail annimmt.

Einschalten

Eingehende E-Mail bleibt inaktiv, bis ein Operator sie konfiguriert — es gibt keinen Schalter im Dashboard, weil DNS dafür nötig ist. Das Setup ist ein MX-Record auf einer dedizierten Reply-Subdomain (zum Beispiel reply.ihrefirma.de), der auf den empfangenden Transport zeigt, plus diese Domain im Backend gesetzt. Der bestehende MX Ihrer Apex-Domain bleibt unberührt, das stört also nicht, wo die Postfächer Ihrer Firma heute liegen.

In der Praxis ist das SendGrid Inbound Parse: der MX der Antwort-Subdomain zeigt darauf, es bewertet SPF, DKIM und DMARC und POSTet die geparste Nachricht an den Ingestion-Endpoint. Ihr DNS bleibt, wo es ist — der Eintrag ist ein MX auf einer Subdomain, keine Migration.

Der Transport wird bewusst auf Distanz gehalten: der Ingestion-Endpoint normalisiert alles Empfangene in eine interne Payload, sodass ein Wechsel oder ein zusätzlicher empfangender Anbieter ein Mapper ist, keine Neuentwicklung. Das ausgehende Setup ist unverändert — siehe E-Mail: Domains, DNS & Versand.