Dear user of facebook,

Because of the measures taken to provide safety to our clients, your password has been changed.
You can find your new password in attached document.

Thanks,
Your Facebook.

Also Finger weg. Neue Passwörter von Diensten werden nie als Anhang verschickt. Maximal kommt eine Aufforderung, dass das Passwort geändert wurde und man bitte es neu anfordern soll. Selbst wenn der Absender profile@facebook.com heisst und damit scheinbar ok ist… Emailabsender lassen sich sehr einfach fälschen.

Der Anhang ist übrigens ein ZIP-File mit einer ausführbaren Datei drin… was für ein Zufall!

Besonders nervig wird es, wenn jemand Reply drückt und dann mit diesem Logo und seinem eigenen Logo im Footer antwortet. Mehr Redundanz geht fast nicht.

Im Regelfall will nur jemand in der Firmenmarketingabteilung seine Anwesenheit rechtfertigen… gäbe einen schönen Dilbert ab

Wir möchten Ihnen mitteilen, dass wir Sie als Kunden schätzen und Ihre E-Mail-Adresse auf Ihren Wunsch hin aus der Abonnentenliste gestrichen haben.

Sie haben das Abonnement beendet unter: <hier war unsere Mailadresse>

Die Bearbeitung Ihrer Änderung kann bis zu 21 Arbeitstagen dauern. Deshalb können Ihnen zwischenzeitlich Marketing-E-Mails, die Sie abonniert haben, weiterhin zugesendet werden.

21Tage? Hallo? Muss da jemand eine Karteikarte aus dem Archiv holen und diese in den Aktenvernichter werfen? 21 Minuten wären schon lang. 21 Sekunden wären noch gerade so ok.

Nach vielen Lasttests in den letzten Tagen habe ich mal in meine Spezialmailbox geschaut und war ja etwas überrascht, dass es doch schon so viele Emails waren, die in der Zeit eingetrudelt sind. Man stelle sich mal vor, dass wäre alles als auf dem Server hängen geblieben bzw. mit Beschwerde an den Admin gegangen.

Wobei ein Test mit Unzustellbarkeit auch ein schönes Testszenario ist…

Heute habe ich meine Lasttest-Mailbox aufgeräumt, denn es stauten sich mehr als 5000 Test-E-Mails. Aber was ist eine Lasttest-Mailbox?

Für die meisten Testszenarien im E-Commerce-Bereich benötigt man E-Mail-Adressen, weil oft Nutzer über die E-Mail identifiziert, Bestellbestätigungen oder schlicht Passwort-Erinnerungen verschickt werden. Für einige Fälle ist es ausreichend, erdachte Adressen zu verwenden, die nur dem allgemeinen Format einer E-Mail-Adresse (name@server.domain) genügen müssen.

Sobald aber das System unter Test wirklich diese Adressen nutzt und E-Mails verschickt, muss man auf gültige Daten achten, weil sonst das System unter der Flut von Rückläufen zu leiden beginnt und/oder man von den Administratoren eine Verwarnung kassiert.

Die beste Idee wären natürlich jede Menge Postfächer bei Google, aber wenn man 10000 Nutzer mit individuellen E-Mails braucht, dann kann und darf man bei Google keinen Pool anlegen. Allein die Unterscheidung, ob man beim bereits eine E-Mail im Test verwendet hat oder nicht, ist sehr schwer. Zusätzlich ist die Pflege von Testdatensätzen im Allgemeinen sehr zeitintensiv und fehleranfällig.

Wie soll es aber dann gehen?

Bewährt haben sich Catch-All Mailboxen beim eigenen E-Mailprovider oder auch Mailboxen auf virtuellen Servern. Hier kann man eine Domain und eine Mailbox konfigurieren und dann durch das Catch-All unendlich viele E-Mail-Adressen nutzen, die man einfach zufällig erzeugt.

Unter Java 6 ist diese Zeile Code sehr nützlich. Sie erzeugt recht zufällige E-Mail-Adressen mit einer Länge von 15 Zeichen für den Namen. Da die JDK 6 UUID-Klasse genutzt wird, ist eine ausreichende Eindeutigkeit garantiert. Nun gut, eigentlich darf man dann den String nicht einkürzen, aber die meisten Dienste können lange E-Mail-Adressen nicht leiden und so muss man sich beschränken.

final String email =
    UUID.randomUUID().toString().substring(0, 15).
    replaceAll("[^A-Za-z0-9]", "A") + "@yourdomainname54678765.net";

Selbstverständlich muss die Domain yourdomainname54678765.net existieren, einem selbst gehören(!) und das Catch-All der Mailbox dafür korrekt konfiguriert sein.

P.S. Für den Test eines großen E-Mail Dienstes würde ich aber nicht darauf zurückgreifen, weil man zwar viele Mails erzeugen und versenden kann, aber diese Lösung nur für einen moderaten Verkehr ausgelegt ist. Schließlich gehen alle E-Mails den gleichen Weg und nisten sich im selben Briefkasten ein.

Für einen großen Test würde ich wohl eine Serverfarm bei Amazon-EC2 konfigurieren oder 20 virtuelle Server bei verschiedenen Hostern einkaufen.