Joomla 5 und Mail-Forensik

Wer aus Joomla heraus Mailprobleme debuggt, darf einen erfolgreichen Testversand niemals mit erfolgreicher Zustellung gleichsetzen. Belastbar ist nur eine Handoff-Kette, die jeden Übergabepunkt separat bestätigt oder ausschließt.

Joomla-Outbound-Mail-Architektur

Die aktuelle Joomla-Dokumentation beschreibt den Versand ausdrücklich über die Klassen Mail und MailTemplate. Der Mailer wird dabei über den Dependency-Injection-Container geholt, typischerweise mit Factory::getContainer()->get(MailerFactoryInterface::class)->createMailer(). Joomla verwendet dabei standardmäßig die Werte aus Global Configuration / Server; Voraussetzung für jede saubere Analyse ist daher zuerst, dass die Instanz dort korrekt konfiguriert ist und Send Test Mail funktioniert.

Mit DI-basierter Mailer-Erzeugung ist hier nicht Theorie gemeint, sondern der konkrete Betriebsweg: Joomla legt MailerFactoryInterface::class im Container ab, der Code zieht diese Factory daraus und erstellt erst dann das Mail-Objekt. Für Administratoren und Integratoren ist das relevant, weil sich genau daran nachvollziehen lässt, wo Konfiguration endet und wo der Transport beginnt. Dass Joomla zusätzlich MailTemplate als Wrapper über dieselbe Mailer-Basis dokumentiert, ist wichtig für reale Projekte: Nicht jede Nachricht wird direkt aus einer Mail-Klasse gebaut, manche laufen über Template-Logik und müssen auch dort debuggt werden.

Joomla kann drei Dinge zuverlässig wissen: dass die Nachricht im Anwendungskontext erzeugt wurde, dass sie an den konfigurierten Mailer übergeben wurde und dass send() entweder erfolgreich zurückkam oder eine Exception geworfen hat. Joomla kann laut aktueller Doku außerdem bei aktiviertem Log Almost Everything die low-level Interaktionen mit dem Mailserver protokollieren. Joomla kann aber nicht selbst wissen, ob ein externer Relay die Nachricht später deferred, ob das Zielsystem sie annimmt oder ob sie im Empfängerpostfach in Inbox, Spam, Quarantäne oder durch eine Regel verschoben wurde. Genau dort endet die CMS-seitige Beweiskraft.

Die vollständige Handoff-Kette

Für einen belastbaren Incident müssen fünf Ebenen strikt getrennt werden: Mail generation, Mail submission, Relay acceptance, Remote delivery und Mailbox placement. Exchange Online Message Trace zeigt ausdrücklich, ob der Dienst eine Nachricht empfangen, abgelehnt, deferred oder zugestellt hat. Google Email Log Search zeigt zusätzlich auch nachgelagerte Zustände wie Labels, Speicherort, Spam-Markierung oder Löschung nach der Zustellung. Daraus folgt operativ: „Joomla erfolgreich“ beweist höchstens Generation und Submission, nicht aber Delivery oder Placement.

Die technisch sauberste Kurzform lautet daher: Generation ist der Joomla-interne Bau der Nachricht; Submission ist die Übergabe an SMTP oder einen lokalen MTA; Relay acceptance ist die erste bestätigte Annahme durch den nächsten Hop, typischerweise ein 250 nach DATA oder eine Queue-ID; Remote delivery ist die bestätigte Annahme am Zielsystem; Mailbox placement ist die tatsächliche Ablage im Benutzerkontext. RFC 5321 definiert die SMTP-Grundlogik, und genau daran hängen die Beweisebenen.

Szenario: Joomla mit Office 365 SMTP

Microsoft dokumentiert für Client SMTP submission den Host smtp.office365.com, Port 587 oder 25, aktiviertem TLS/StartTLS und die Empfehlung, Modern Authentication mit OAuth zu verwenden. Microsoft dokumentiert außerdem, dass SMTP AUTH typischerweise über Port 587 läuft, OAuth unterstützt und organisations- oder mailboxseitig deaktiviert sein kann. Zusätzlich gilt: Für Organisationen, die nach Januar 2020 erstellt wurden, ist SMTP AUTH standardmäßig deaktiviert, kann aber pro Mailbox wieder aktiviert werden.

Für Joomla-Administratoren ist 2026 vor allem ein Punkt kritisch: Microsoft hat angekündigt, Basic Authentication für Client Submission (SMTP AUTH) im März 2026 dauerhaft zu entfernen. Gleichzeitig dokumentiert die aktuelle Joomla-Mail-Seite zwar MailerFactory, Send Test Mail, Logging und MailTemplate, aber auf dieser Referenzseite keinen Core-Standardweg für SMTP-OAuth. Praktisch heißt das: Ein klassisches Joomla-Setup mit bloßem Benutzername/Passwort gegen Exchange Online darf nicht mehr als zukunftsfester Default angenommen werden. Tragfähig sind stattdessen ein OAuth-fähiger Transport, ein vorgelagerter Relay oder ein lokaler MTA, den Sie selbst kontrollieren. Diese Schlussfolgerung ist eine Betriebsableitung aus den offiziellen Microsoft- und Joomla-Dokumentationen.

Für den ersten technischen Nachweis auf Submission-Ebene ist ein nackter TLS-Test oft schneller als jedes Joomla-UI:

openssl s_client -starttls smtp -connect smtp.office365.com:587 -servername smtp.office365.com

Wenn dieser Handshake nicht sauber hochkommt, ist die Nachricht nie bei Exchange Online angekommen. Wenn der Connect funktioniert, aber Auth scheitert, liegt der Fehler noch vor Relay Acceptance. Wenn Submission funktioniert, ist Message Trace im Exchange Admin Center die maßgebliche Quelle für die nächste Stufe. Microsoft beschreibt dort explizit die Statuswerte received, rejected, deferred und delivered.

Wenn die Authentifizierung über ein anderes Konto erfolgt als die sichtbare Absenderadresse, verlangt Microsoft Send As-Berechtigungen; andernfalls droht etwa 5.7.60. Für die Mailbox-Platzierung bei Microsoft-365-Empfängern sind anschließend Header wie X-Forefront-Antispam-Report, X-Microsoft-Antispam und insbesondere Felder wie SCL, PTR und SFTY entscheidend. Der SCL-Wert steuert laut Microsoft direkt, ob eine Nachricht typischerweise im Posteingang, im Junk-Ordner oder in Quarantäne landet.

Szenario: Joomla mit Hoster-SMTP

Bei Hoster-SMTP ist die erste operative Frage nicht „funktioniert SMTP?“, sondern: Ist der Hoster nur Submission-Endpunkt oder zugleich der ausliefernde MTA? In cPanel/WHM sind die Standardpfade und Oberflächen gut dokumentiert. Exim schreibt auf unveränderten Installationen insbesondere nach /var/log/exim_mainlog, /var/log/exim_rejectlog und /var/log/exim_paniclog; cPanel weist zugleich darauf hin, dass Pfade in angepassten Setups abweichen können. Für Ubuntu-basierte cPanel-Systeme kommen zusätzlich allgemeine Dienstmeldungen typischerweise in /var/log/syslog, für Red-Hat-basierte Systeme in /var/log/messages.

Mit Root-Zugriff ist die Minimalspurensuche in Exim fast immer dieselbe:

grep -E Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.|<message-id>|<=|=>|==|Completed" /var/log/exim_mainlog
grep -E Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein." /var/log/exim_rejectlog
tail -n 100 /var/log/exim_paniclog

Dabei ist nicht die einzelne Zeile entscheidend, sondern die Exim-ID als Klammer über den gesamten Lebenslauf. <= markiert die Annahme, => die Auslieferung an den nächsten Pfad, == typischerweise einen noch offenen Deferred-Zustand, Completed das Ende des Exim-internen Bearbeitungspfads. Für Queue-Probleme verweist cPanel zusätzlich auf Mail Queue Manager und ausdrücklich auf /var/log/exim_mainlog, wenn mehrere Nachrichten eingefroren oder blockiert erscheinen.

Ohne Root-Zugriff sind Track Delivery und Mail Delivery Reports die Primärwerkzeuge. Track Delivery zeigt laut cPanel Zustellberichte und einen Tracing-Pfad für die Route einer Nachricht. Mail Delivery Reports erlaubt systemweite Suchen nach Empfänger, Zeitraum, Delivery-Typ und Suchbegriffen; standardmäßig werden dort unter anderem Event, From, Sender, Sent Time, Recipient, ID und Result angezeigt. Wichtig ist auch die von cPanel dokumentierte Einschränkung: Verwendet der Server einen Drittmaildienst wie MailScanner, kann Track Delivery ungültige Ergebnisse liefern.

Szenario: Joomla mit lokalem Postfix

Auf Ubuntu ist Postfix der standardmäßig unterstützte MTA; die Konfiguration läuft über main.cf, und Ubuntu dokumentiert Postfix als sendmail-kompatiblen Transport im Server-Handbuch. Für Debian- und Ubuntu-Systeme landen Mail-Logs typischerweise in /var/log/mail.log, auf vielen AlmaLinux- oder Red-Hat-basierten Systemen in /var/log/maillog. Die Postfix-Manpages dokumentieren postconf für die Konfiguration und postqueue für die Queue-Operationen.

Für den Incident sollten zuerst Dienstzustand, effektive Konfiguration und Queue abgefragt werden:

systemctl status postfix
journalctl -u postfix -S "2026-04-21 10:00:00"
postfix check
postconf -n
postqueue -p

postqueue ist laut Manpage die Standardoberfläche für Queue-Management; postsuper ist den Operationen vorbehalten, die Superuser-Rechte verlangen, etwa Löschen oder Statusänderungen im Queue-Bestand. Das ist nicht nur ein Bedienungsdetail, sondern die operative Grenze zwischen Diagnose und Eingriff.

Für die eigentliche Korrelation genügen häufig zwei Muster:

grep -E Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.|QUEUEID|status=|message-id= /var/log/mail.log
grep -E Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.|QUEUEID|status=|message-id= /var/log/maillog

status=sent belegt die erfolgreiche Übergabe an den nächsten Hop, status=deferred einen temporär offenen Zustand, status=bounced einen endgültigen negativen Abschluss. Auch hier gilt: status=sent ist noch kein Inbox-Beweis, sondern nur ein Remote-Accept-Nachweis.

Log-Korrelation und Beweisführung

In professionellen Mail-Incidents reichen Absender und Empfänger allein nicht. Die belastbare Korrelation läuft immer über Timestamp, Empfängeradresse, Message-ID, Queue-ID oder Provider-ID und die letzte relevante SMTP-Response-Line. Google ELS erlaubt ausdrücklich Suchen nach Absender, Datum oder Message-ID; Exchange Message Trace arbeitet über Zeitfenster, Sender und Empfänger; cPanel Mail Delivery Reports liefert Such- und Ergebnisfelder für Event, Sender, Recipient, ID und Result. Ohne diese Identifier landet jede Eskalation bei „nicht reproduzierbar“.

Die Message-ID ist dabei fast immer der wertvollste Cross-System-Identifier. Sie verbindet Joomla-nahe Belege, Exim- oder Postfix-Logs und Empfängerseite. Die Queue-ID ist dagegen hop-spezifisch: Exim-ID und Postfix-Queue-ID sind lokal oder relay-spezifisch und müssen bei jedem Übergang neu in die Beweiskette aufgenommen werden. Praktisch heißt das: zuerst Message-ID sichern, dann pro Hop die jeweilige Queue- oder Trace-ID ergänzen.

SMTP-Statuscodes und Queue-Analyse

RFC 5321 und die erweiterten DSN-Codes unterscheiden grob zwischen Erfolg (2xx), temporären Problemen (4xx) und permanenten Fehlern (5xx). Für den Betrieb bedeutet das: 4xx gehört in Queue-, Retry- und Remote-Konnektivitätsanalyse; 5xx führt typischerweise in Authentifizierungs-, Policy-, Rechte- oder Formatdiagnose. Genau diese Trennung verhindert hektische Fehlkonfigurationen an der falschen Schicht.

Google dokumentiert für aktuelle Senderanforderungen mehrere praxisrelevante Fehlerbilder. Die Sender-Guidelines verlangen für Zustellbarkeit an persönliche Gmail-Konten unter anderem SPF oder DKIM, gültige Forward- und Reverse-DNS-Einträge, TLS sowie RFC-5322-konforme Nachrichten. In der FAQ zu den Richtlinien werden außerdem konkrete Enforcement-Folgen benannt, etwa temporäre oder permanente Fehlercodes beziehungsweise Spam-Foldering bei fehlender Alignment-, Authentifizierungs- oder DNS-Basis. Zusätzlich nennt Google 4.7.28 als typisches Rate-Limit-Signal.

DNS- und Authentifizierungsabhängigkeiten

Ohne saubere DNS- und Authentifizierungsbasis ist jede Delivery-Analyse unvollständig. Google fordert für alle Sender an persönliche Gmail-Konten mindestens SPF oder DKIM, gültiges Forward- und Reverse-DNS, TLS und RFC-5322-konforme Nachrichten; für höhere Versandvolumina kommen strengere Anforderungen hinzu. Microsoft verweist in Exchange- und Defender-Dokumentationen auf SMTP AUTH, OAuth, Message Trace und Authentifizierungsheader; für Microsoft-365-Empfänger liefern Authentication-Results, X-Forefront-Antispam-Report und die SCL-Auswertung die praktische Diagnoseschicht.

Der Pflichtblock im Shell-Incident ist daher schlicht:

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com
dig +short A mail.example.com
dig +short -x <sending-ip>

Damit sichern Sie MX, SPF, DMARC, DKIM und PTR in einem Durchgang. Wenn diese Basis nicht stimmt, sind Deferreds, Spamfoldering und harte Rejects keine Überraschung, sondern erwartbare Folge.

Empfängerseitiges Tracing

Bei Microsoft 365 als Empfänger ist Message Trace die erste administrative Instanz. Dort lässt sich laut Microsoft feststellen, ob der Dienst die Nachricht erhalten, zurückgewiesen, deferred oder zugestellt hat. Für die Frage, warum eine zugestellte Nachricht nicht in der Inbox liegt, folgt danach die Header-Analyse über X-Forefront-Antispam-Report, X-Microsoft-Antispam und Authentication-Results; der SCL-Wert ist dabei der unmittelbarste Hinweis auf Junk- oder Quarantäne-Verhalten.

Bei Google Workspace als Empfänger ist Email Log Search das stärkste Standardwerkzeug. Google dokumentiert, dass ELS nicht nur fehlende Nachrichten finden und Zustellung analysieren kann, sondern auch Status nach der Zustellung, etwa Labels, Speicherort, Spam-Markierung oder Löschung. Gleichzeitig sagt Google ausdrücklich, dass ELS keine Nachrichtinhalte anzeigt. Für Inhalts- oder Regelanalysen braucht es daher andere Admin-Werkzeuge, etwa den Investigation-Workflow für Gmail-Log-Events und Header.

Bei einem generischen IMAP-Host gibt es keinen einheitlichen Admin-Trace-Standard wie Message Trace oder ELS. Praktisch brauchen Sie dort mindestens die vollständigen Header der empfangenen Nachricht, Spam- oder Quarantäne-Nachweise des Providers und – falls administrierbar – Mailstore- oder Zustell-Logs. In cPanel-Umgebungen kommen zusätzlich benutzer- oder kontobezogene Email Filters in Betracht, die Nachrichten automatisch verschieben oder löschen können; auch das gehört zur Schicht Mailbox placement, nicht mehr zu Submission oder Delivery.

Die Troubleshooting-Matrix

Die folgende Matrix verdichtet die Joomla-, Microsoft-, Google-, cPanel- und Postfix-Quellen auf Incident-Ebene. Sie ist keine Theorie-Tabelle, sondern die schnellste Zuordnung von Symptom zu beweisbarer Schicht.

Das Live-Incident-Playbook

Starten Sie mit einem Einzelempfänger-Test, einer eindeutigen Subject-Markierung und einem exakt notierten Zeitfenster inklusive Zeitzone. Danach sichern Sie die Joomla-Ebene: wurde die Nachricht gebaut, wurde send() ohne Exception abgeschlossen, und sind bei aktiviertem Logging low-level Interaktionen sichtbar. Erst dann wechseln Sie auf den ersten beweisbaren Hop: Exchange Submission, Exim, Postfix oder Hoster-Trace. Von dort arbeiten Sie hop-by-hop weiter bis zu Message Trace, ELS oder Headern auf Empfängerseite. Alles andere ist operativ unsauber, weil es mehrere Schichten gleichzeitig vermischt.

Im laufenden Incident gilt eine eiserne Regel: Nicht eskalieren, bevor die aktuelle Schicht bewiesen oder ausgeschlossen ist. „Mail kommt nicht an“ ist kein Befund. „Joomla submit erfolgreich, Exim accept vorhanden, Remote Delivery noch offen“ ist einer. „Exchange Message Trace = delivered, Mailbox placement ungeklärt“ ist ein noch besserer. Erst diese Präzision zwingt Hoster, Provider oder Kunden-IT auf die richtige Ebene.

Die Eskalations-Checkliste

Ein eskalationsfähiger Fall enthält immer dieselben Artefakte: exakte Versandzeit mit Zeitzone, Sender, Empfänger, Subject-Testmarke, vollständige Message-ID, erste Queue- oder Trace-ID, relevante SMTP-Response-Lines, die entscheidenden Logauszüge, den DNS-Snapshot für MX, SPF, DKIM, DMARC und PTR sowie eine klare Aussage dazu, welche Handoff-Schicht bereits bewiesen und welche noch offen ist. Fehlt einer dieser Bausteine, wird aus einem technischen Ticket fast zwangsläufig ein Ping-Pong zwischen Joomla, Hoster und Empfängerseite.