Mail-Lasttests planen: Tools für 10'000-Mail-Bursts unter Linux und Windows im Vergleich

Ob ein neues Mailgateway die Spitzenlast eines nächtlichen Rechnungslaufs verkraftet, lässt sich nur mit einem Lasttest überprüfen. Wer eine Appliance ablöst, eine Exchange-Umgebung dimensioniert oder einen Newsletter-Versand über die eigene Infrastruktur plant, braucht vorher belastbare Zahlen: Wie viele Nachrichten pro Sekunde nimmt das System an, wie verhält sich die Queue unter Druck, und ab welchem Punkt beginnen Deferrals? Dieser Artikel vergleicht die gängigen Lastgeneratoren unter Linux und Windows und zeigt, wie ein Test mit Bursts von mehreren zehntausend Mails geplant, durchgeführt und ausgewertet wird.

Vorweg die wichtigste Regel: Lasttests gehören ausschliesslich in die eigene Infrastruktur oder in eine ausdrücklich dafür freigegebene Testumgebung. Ein Burst gegen fremde Systeme ist ein Angriff, und ein Test mit erfundenen Absenderadressen gegen produktive Ziele erzeugt Backscatter, der auf Blocklisten führt. Der saubere Aufbau besteht aus einem Lastgenerator, dem zu testenden System und einer kontrollierten Senke, die die Mails am Ende annimmt und verwirft.

Was ein Mail-Lasttest messen soll

Bevor ein Tool zur Sprache kommt, lohnt sich die Frage, welche Grösse eigentlich interessiert. In der Praxis sind es vier verschiedene, und sie verlangen unterschiedliche Testaufbauten:

1. Annahmerate: Wie viele Nachrichten pro Sekunde nimmt der erste Hop per SMTP entgegen? Das ist die klassische Durchsatzmessung und der Wert, den Lastgeneratoren direkt liefern.
2. Session-Latenz: Wie lange dauert eine einzelne SMTP-Transaktion vom Verbindungsaufbau bis zum 250 nach DATA? Unter Last steigt dieser Wert oft lange bevor die Annahmerate einbricht.
3. Ende-zu-Ende-Latenz: Wie lange braucht eine Nachricht vom Einliefern bis zur Zustellung an die Senke, über alle Zwischenstationen hinweg? Das ist die Grösse, die Anwender wahrnehmen.
4. Queue-Verhalten: Wie tief wächst die Warteschlange während des Bursts, und wie schnell läuft sie danach leer? Ein Gateway, das 50’000 Mails annimmt und dann drei Stunden abarbeitet, besteht den Annahmetest und fällt trotzdem durch.

Ein Test, der nur die Annahmerate misst, sagt über eine mehrstufige Umgebung mit Gateway, Verschlüsselungsstufe und Zielserver wenig aus. Gerade dort entscheidet die Ende-zu-Ende-Sicht.

Das Lastbild bestimmt das Werkzeug

Neben der Messgrösse entscheidet eine zweite Frage über die Werkzeugwahl, und sie wird häufig übersprungen: Welches Verbindungsverhalten hat die Last, die simuliert werden soll? Zwei Lastbilder sind zu unterscheiden.

Ein Bulk-Sender mit offenen Sessions ist das Lastbild von Rechnungsläufen, Lohnabrechnungen und Newsletter-Systemen: Ein einzelnes System baut wenige Verbindungen auf und schickt darüber hunderte bis tausende Nachrichten am Stück. Der Verbindungs-Overhead fällt einmal pro Session an, nicht einmal pro Nachricht, und das Gateway sieht wenige Verbindungen mit vielen Transaktionen.

Viele unabhängige Einlieferer sind das Lastbild von Applikationslandschaften und Benutzerverkehr: Zahlreiche Systeme liefern je einzelne Nachrichten über je eigene Verbindungen ein. Hier gehört der Verbindungsaufbau inklusive TLS und AUTH zu jeder Nachricht dazu.

Für die Dimensionierung eines Massenversands zählt das erste Lastbild, und dafür muss der Lastgenerator Sessions offenhalten können: smtp-source tut das (viele Nachrichten verteilt auf wenige Sessions), ebenso Postal und eigene Skripte mit persistenter Verbindung. JMeter kann es nicht; die Hintergründe stehen im Windows-Abschnitt. Für die Spitzenlast eines Rechnungslaufs ist deshalb dieses Session-Kriterium massgebend und nicht die Plattform; unter Windows führt der Weg dann über WSL.

Werkzeuge unter Linux

smtp-source und smtp-sink aus dem Postfix-Paket sind der Standard für rohe SMTP-Last und auf praktisch jedem System verfügbar, das Postfix installiert hat. smtp-source erzeugt Nachrichten mit einstellbarer Grösse, Parallelität und Anzahl, smtp-sink ist das Gegenstück: ein SMTP-Server, der alles annimmt und verwirft. Ein Burst von 10’000 Mails mit 50 parallelen Sessions und 5-KB-Nachrichten ist ein Einzeiler:

time smtp-source -s 50 -m 10000 -l 5120 -c -f last@test.example -t senke@test.example gateway.test.example:25

Optionen erklärt

Option	Wirkung
time	Misst die Gesamtdauer des Aufrufs; daraus ergibt sich die Rate in Mails pro Sekunde
-s 50	50 parallele SMTP-Sessions
-m 10000	Gesamtzahl der Nachrichten, verteilt auf die Sessions
-l 5120	Grösse des Nachrichtentexts in Bytes (ohne Header), hier 5 KB
-c	Laufender Zähler abgesetzter Nachrichten als Fortschrittsanzeige
-f last@test.example	Absenderadresse
-t senke@test.example	Empfängeradresse
gateway.test.example:25	Zielhost und Port der Einlieferung

Wichtige Grenzen: smtp-source misst keine Latenz-Perzentile und die Nachrichten sind synthetisch gleichförmig. Für die Frage “wie viel nimmt das System maximal an” ist es dennoch erste Wahl, weil es selbst auf schwacher Hardware zehntausende Nachrichten pro Minute erzeugt und der Generator praktisch nie zum Engpass wird.

Postal ist der klassische dedizierte Mailserver-Benchmark unter Linux. Es variiert Absender, Empfänger und Nachrichtengrösse automatisch, hält eine Zielrate über lange Zeiträume und schreibt minütliche Statistiken. Damit eignet es sich besser als smtp-source für Soak-Tests, also Dauerlast über Stunden. Das zugehörige bhm (Black Hole Mailer) übernimmt die Rolle der Senke. Postal ist alt, aber genau dafür gebaut und in den Paketquellen der meisten Distributionen enthalten.

swaks ist kein Lastgenerator, gehört aber in jeden Testplan. Es spricht eine einzelne SMTP-Transaktion mit voller Kontrolle über jeden Schritt: Authentifizierung, STARTTLS, beliebige Header, Anhänge. Vor jedem Lasttest gehört ein swaks-Durchlauf als Funktionstest, damit der Burst nicht an einem falschen Empfänger oder einem TLS-Problem scheitert und die Messung wertlos macht. In einer Schleife mit xargs -P lässt sich swaks auch als kleiner Lastgenerator missbrauchen, für zehntausende Mails ist der Prozess-Overhead aber zu gross.

Eigene Skripte in Python (smtplib, aiosmtplib) oder Go sind der Weg, wenn der Test realistische Nachrichtenmixe braucht: unterschiedliche Grössen, echte Anhänge, variierende Empfängerzahlen pro Transaktion, gezielte Fehlerfälle. Der Aufwand ist höher, dafür misst das Skript genau das, was die eigene Umgebung später sieht, und kann pro Nachricht Zeitstempel für die Latenzauswertung mitschreiben.

Werkzeuge unter Windows

Apache JMeter ist unter Windows das passende Werkzeug, wenn das Lastbild viele unabhängige Einlieferer sind oder wenn Perzentile, Nachrichtenmix und Reports im Vordergrund stehen. Der eingebaute SMTP Sampler beherrscht Auth, STARTTLS, Anhänge und EML-Dateien als Nachrichtenquelle, und die JMeter-Mechanik liefert das, was den Postfix-Tools fehlt: Thread-Gruppen für gestufte Lastprofile, Antwortzeit-Perzentile, Fehlerraten und Reports. Für Bursts jenseits von ein paar tausend Mails pro Minute gilt die übliche JMeter-Regel: GUI nur zum Erstellen des Testplans, die Messung selbst im CLI-Modus fahren, sonst misst man die Oberfläche mit.

Eine Grenze des SMTP Samplers muss dabei bekannt sein: JMeter kann SMTP-Sessions nicht offenhalten. Jeder Sample-Durchlauf öffnet eine neue Verbindung, durchläuft den kompletten Dialog aus TCP-Handshake, EHLO, gegebenenfalls STARTTLS und AUTH, sendet genau eine Nachricht und beendet die Verbindung mit QUIT. Mehrere Nachrichten über dieselbe offene Verbindung, wie es Massenversender mit Session-Wiederverwendung tun, lassen sich nicht abbilden; smtp-source verteilt dagegen viele Nachrichten auf wenige offene Sessions. Der Grund liegt in der Architektur: JMeter ist ein protokollübergreifendes Lasttest-Framework, kein SMTP-Werkzeug. Sein Ausführungsmodell behandelt jeden Sampler als in sich geschlossene, unabhängig gemessene Einheit, denn nur so funktionieren Timer, Assertions und die Perzentil-Auswertung für alle unterstützten Protokolle einheitlich. Der SMTP Sampler ist entsprechend ein dünner Aufsatz auf die JavaMail-Bibliothek, die als Client-API pro Sendevorgang eine Verbindung aufbaut und wieder schliesst; eine Verbindungs-Wiederverwendung über Samples hinweg, wie sie der HTTP-Sampler mit Keep-Alive bietet, wurde für SMTP nie implementiert. Für die Messung bedeutet das: JMeter erzeugt das Lastbild vieler einzelner Einlieferer, nicht das eines Bulk-Senders mit offener Session. Der gemessene Durchsatz enthält pro Nachricht den vollen Verbindungs- und TLS-Overhead, und Verbindungs-Limits am Gateway greifen entsprechend früher als bei Session-Wiederverwendung. Für das Bulk-Sender-Lastbild eines Rechnungslaufs ist JMeter damit nicht das richtige Werkzeug; unter Windows ist der WSL-Weg mit smtp-source die bessere Wahl.

PowerShell mit MailKit ist der Bordmittel-Weg. Das früher übliche Send-MailMessage markiert Microsoft selbst als veraltet und empfiehlt den Umstieg; MailKit lässt sich per NuGet laden und aus PowerShell 7 heraus mit Runspaces parallelisieren. Realistisch sind damit einige hundert bis wenige tausend Mails pro Minute, genug für Funktions- und Regressionstests, zu wenig für die Maximallastmessung. Der Vorteil: Das Skript läuft ohne Zusatzinstallation auf jedem Admin-Arbeitsplatz und kann Ergebnisse direkt als CSV für die Auswertung schreiben.

Microsoft Exchange Load Generator (LoadGen) war jahrelang das offizielle Werkzeug, um Exchange-Umgebungen mit simulierten Benutzerprofilen (Outlook, ActiveSync, OWA) zu belasten. Microsoft hat es nach Exchange 2013 nicht weitergepflegt und den Download eingestellt. Für reine SMTP-Last war LoadGen ohnehin das falsche Werkzeug; wer heute Exchange-Postfachlast simulieren will, steht ohne offizielles Tool da und testet den SMTP-Pfad besser direkt.

WSL verdient einen eigenen Punkt: Wer auf einer Windows-Maschine sitzt, aber Linux-Tools braucht, kann smtp-source und Postal in einer WSL-Distribution installieren und hat damit die vollen Linux-Werkzeuge ohne separate Test-VM. Für die hier diskutierten Lasten ist der WSL-Netzwerkpfad kein relevanter Engpass.

Vergleich

Die Senke: wohin mit den Mails

Die unterschätzte Hälfte des Testaufbaus ist das Ziel. Drei Varianten haben sich bewährt:

• smtp-sink oder bhm als schwarzes Loch: nimmt alles an, verwirft alles, misst die reine Transportkette. smtp-sink kann auf Wunsch künstliche Antwortverzögerungen und Fehlercodes erzeugen und damit auch das Verhalten des Testsystems bei einem langsamen oder fehlerhaft antwortenden Ziel prüfen.
• Postfix mit discard-Transport als realistischere Senke, wenn das Ziel selbst ein vollwertiger SMTP-Server mit Queueing sein soll.
• Einige wenige echte Seed-Postfächer zusätzlich zur Senke, um stichprobenartig zu prüfen, dass Nachrichten inhaltlich unversehrt ankommen, inklusive Verschlüsselungs- oder Signaturstufe.

Werkzeuge mit Web-Oberfläche wie Mailpit sind für die Entwicklung gedacht und bei zehntausenden Mails schnell selbst der Engpass. Als Senke für einen Lasttest sind sie ungeeignet; die Messung würde das Analysewerkzeug statt das Testsystem vermessen.

Den Test planen

Ein belastbarer Test läuft in drei Stufen, jede mit eigener Fragestellung:

1. Baseline: Eine moderate, bekannte Last (etwa 10 Prozent der erwarteten Spitze) über einige Minuten. Sie liefert die Referenzwerte für Latenz und Ressourcenverbrauch und deckt Konfigurationsfehler auf, bevor sie in der Burstmessung untergehen.
2. Burst: Die eigentliche Spitzenlastmessung, zum Beispiel 10’000 bis 50’000 Mails so schnell wie möglich oder mit definierter Zielrate. Mehrere Durchläufe mit steigender Parallelität zeigen, wo die Annahmerate abflacht und die Latenz kippt.
3. Soak: Die erwartete Tageslast über mehrere Stunden. Erst hier zeigen sich Speicherlecks, volllaufende Spool-Partitionen, Log-Rotation unter Last und Verbindungs-Limits, die ein kurzer Burst nie erreicht.

Beim Nachrichtenmix gilt: so realistisch wie nötig. Eine Messung mit ausschliesslich 5-KB-Textmails überschätzt den Durchsatz einer Umgebung, deren Alltag aus PDF-Anhängen besteht, um ein Mehrfaches. Sinnvoll ist ein Mix aus dem eigenen Bestand, etwa 70 Prozent klein, 25 Prozent mit typischem Anhang, 5 Prozent gross. Ebenso gehört TLS in den Test, wenn die Produktion TLS spricht: Der Handshake kostet pro Verbindung deutlich mehr als die Nachrichtenübertragung selbst, und Generatoren, die pro Mail eine neue Verbindung öffnen, messen sonst primär die TLS-Terminierung.

Für die spätere Auswertung bekommt jede Testnachricht einen eindeutigen Marker, am einfachsten einen eigenen Header wie X-Loadtest-Id mit Lauf-Nummer und Zeitstempel und eine wiedererkennbare Betreffkonvention. Damit lassen sich Testläufe in den Logs sauber voneinander und vom übrigen Verkehr trennen, und die Testmails lassen sich nach dem Lauf gezielt aus Quarantänen und Journalen räumen.

Drei Punkte, die in der Planung regelmässig vergessen gehen: Erstens Rate-Limits und Tarpitting auf dem Testpfad; ein Gateway, das nach 100 Mails pro Minute pro Quell-IP drosselt, testet sonst nur seine eigene Drossel (für die Maximallastmessung gezielt ausnehmen, für den Realitätscheck bewusst drinlassen). Zweitens DNS: Wenn das Testsystem für jede Nachricht Empfängerdomains auflöst oder DNSBL-Abfragen stellt, gehört ein Resolver mit in die Testumgebung, sonst misst der Test den Upstream-DNS. Drittens der Generator selbst: Vor dem ersten Lauf gegen das Zielsystem gehört ein Lauf des Generators direkt gegen die Senke, um zu belegen, dass der Generator die Zielrate überhaupt erzeugen kann.

Auswerten

Die Messwerte des Lastgenerators sind nur die halbe Wahrheit, denn sie zeigen die Sicht des Einlieferers. Die andere Hälfte steht in den Logs des Testsystems.

Unter Postfix liefert das Maillog pro Nachricht die Felder delay und delays, letzteres aufgeschlüsselt nach Zeit in der Queue, Verbindungsaufbau und Übertragung. Eine Auswertung über einen Testlauf ist mit Bordmitteln erledigt:

grep "status=sent" /var/log/mail.log |
  grep -o "delay=[0-9.]*" | cut -d= -f2 | sort -n |
  awk '{a[NR]=$1} END {print "n="NR, "p50="a[int(NR*0.5)], "p95="a[int(NR*0.95)], "p99="a[int(NR*0.99)], "max="a[NR]}'

Optionen erklärt

Option	Wirkung
grep "status=sent" /var/log/mail.log	Filtert das Maillog auf erfolgreich zugestellte Nachrichten
grep -o "delay=[0-9.]*"	-o gibt nur den Treffer selbst aus, hier das delay-Feld mit seinem Wert
cut -d= -f2	Trennt am = (-d) und behält das zweite Feld (-f2), also den Zahlenwert
sort -n	Sortiert numerisch statt alphabetisch; Voraussetzung für die Perzentilbildung
awk '…'	Sammelt die sortierten Werte in einem Array und gibt Anzahl, p50, p95, p99 und Maximum aus

Auf Exchange-Seite ist das Message Tracking Log die zentrale Quelle. Für einen Testlauf mit Betreffkonvention:

$p = @{
    Start          = "24.08.2026 14:00"
    End            = "24.08.2026 15:00"
    MessageSubject = "LOADTEST"
    ResultSize     = "Unlimited"
}
Get-MessageTrackingLog @p | Group-Object EventId |
    Sort-Object Count -Descending | Format-Table Name, Count

Optionen erklärt

Option	Wirkung
Start / End	Zeitfenster der Log-Suche; hier per Splatting (@p) übergeben
MessageSubject "LOADTEST"	Filtert auf Nachrichten, deren Betreff den Marker enthält
ResultSize Unlimited	Hebt die Standardgrenze von 1000 zurückgegebenen Einträgen auf
Group-Object EventId	Gruppiert die Tracking-Ereignisse nach Typ (RECEIVE, DELIVER, DEFER, …)
Sort-Object Count -Descending	Sortiert die Ereignisgruppen absteigend nach Häufigkeit
Format-Table Name, Count	Zeigt pro Ereignistyp die Anzahl

Die Differenz der Zeitstempel zwischen RECEIVE- und DELIVER-Ereignis derselben MessageId ergibt die Ende-zu-Ende-Latenz pro Nachricht; exportiert als CSV lässt sich daraus die Perzentilverteilung rechnen.

Bei der Interpretation zählen drei Grundsätze. Erstens: Perzentile statt Mittelwerte. Ein Durchschnitt von zwei Sekunden kann bedeuten, dass alles zwei Sekunden dauert, oder dass 95 Prozent in einer halben Sekunde durch sind und der Rest in der Queue hing; p50, p95 und p99 unterscheiden diese Fälle. Zweitens: SMTP-Antwortcodes pivotieren. Die Verteilung der 4xx-Antworten über die Zeit zeigt, wann das System zu drosseln beginnt, und welche Codes es sind (Verbindungs-Limit, Queue-Schutz, Greylisting) zeigt, welcher Mechanismus zuerst greift. Drittens: Queue-Tiefe über die Zeit auftragen, unter Postfix per qshape beziehungsweise postqueue -j, auf Exchange per Get-Queue im Minutentakt. Die Fläche unter dieser Kurve, nicht die Annahmerate, entscheidet, ob die Umgebung einen Burst wegsteckt oder ihn nur einlagert.

Parallel zu den Maillogs gehören die Systemmetriken des Testsystems in die Auswertung: CPU, I/O-Wartezeiten auf der Spool-Partition, Dateideskriptoren, Verbindungszähler. Der häufigste Befund bei mehrstufigen Umgebungen ist, dass nicht der Mailprozess limitiert, sondern eine Content-Inspection-Stufe (Virenscanner, Verschlüsselungsmodul, DLP) mit fixer Worker-Zahl. Genau solche Befunde sind der eigentliche Wert des Tests: Sie benennen die Stellschraube, bevor die Produktion sie findet.

Fazit

Für die schnelle Maximallastmessung unter Linux führt kein Weg an smtp-source mit smtp-sink vorbei; Postal ergänzt den Dauerlastfall. Unter Windows liefert JMeter die vollständigste Messung, PowerShell mit MailKit deckt Funktions- und Regressionstests ab, und WSL holt bei Bedarf die Linux-Werkzeuge auf den Admin-Arbeitsplatz. Wichtiger als das Tool ist der Plan: getrennte Messung von Annahme, Latenz und Queue-Verhalten, ein realistischer Nachrichtenmix, ein markierter Testlauf und eine Auswertung, die Perzentile und Logs des Zielsystems einbezieht statt nur den Zähler des Generators.