Newsletter | Wie macht man's richtig ?

[Martin Hein]

Hallo Forum,

ich bin immernoch mit der Frage beschäftigt, wie ich ein
Newsletter für meinen Kunden verschicke. Ich will einen
lokalen Newsletter-Client, statt einer webbasierten
Lösung verwenden. Mittlerweile habe ich das HTML-Newsletter
soweit fertig, ausserdem den Versand von 20.000 Mails mit
meinem Strato-Account getestet, indem ich ein alle Mails
an ein Catchall-Postfach geschickt habe.

Jetzt gibt es nur noch ein Problem, mit dem ich nicht klar
komme und gerne gewusst hätte, wie Ihr damit umgeht:

Im Absender der Mails soll '[e-mail]' stehen.
Den SMTP-Server des Kunden kann ich nicht nutzen, weil der
von aussen nicht zugänglich ist.
Wenn ich den Absender in meinem lokalen Client angebe, macht
der SMTP-Strato bei Strato das nicht mit ("Relaying Not Allowed"), was mir mittlerweile klar ist. Jetzt habe ich den Tipp bekommen,
dass ich mit bei eigenen Virtual Server bei Hosteurope.de das Relaying zulassen könne. In einem Gespräch mit deren Support,
stellte sich heraus, dass das zwar ginge, aber auch nicht das
wahre sei (Stichwort:Blacklisting).

Jetzt geht mir millerweile langsam die Fantasie aus.

Wie würdet Ihr das denn machen. Bzw. Wie verschickt man
seriös Newsletter ?

danke für eure Tipps und

beste gruesse,
martin

[Ines]

Hallo,

Den SMTP-Server des Kunden kann ich nicht nutzen, weil der
von aussen nicht zugänglich ist.

Und der Kunde kann nichts dran ändern? Es wäre die sauberste Lösung und da hat dein Kunde doch sicher auch Interesse daran.

Wie verschickt man seriös Newsletter?

Nur über einen zur Absenderdomain gehörenden SMTP-Server. Das muss nicht bedeuten, dass er unter der gleichen Domain läuft, aber es sollte erkennbar sein, dass er zur Domain gehört, zum Beispiel mittels SPF. Allerdings erfordert SPF einen Eintrag auf dem Kunden-DNS-Server.

Mit Von-hinten-durch-die-Brust-ins-Auge-Methoden aber sollte dein Kunde sich nicht wundern, wenn er, gerade bei den Massen, früher oder später irgendwo auf einer schwarzen Liste landet.

Ines

[Martin Hein]

Hallo Ines,

Und der Kunde kann nichts dran ändern? Es wäre die sauberste Lösung und da hat dein Kunde doch sicher auch Interesse daran.

Ja, das ist sicher richtig, aber weil die IT aus Sicherheitsgründen
nicht mal Ihren Mitarbeitern gewährt, ausserhalb des Netzwerks
auf den Mailserver zuzugreifen, wird sie mir das auch nicht gewähren,
um Newsletter zu verschicken.

Nur über einen zur Absenderdomain gehörenden SMTP-Server. Das muss nicht bedeuten, dass er unter der gleichen Domain läuft, aber es sollte erkennbar sein, dass er zur Domain gehört, zum Beispiel mittels SPF. Allerdings erfordert SPF einen Eintrag auf dem Kunden-DNS-Server.

Mit Von-hinten-durch-die-Brust-ins-Auge-Methoden aber sollte dein Kunde sich nicht wundern, wenn er, gerade bei den Massen, früher oder später irgendwo auf einer schwarzen Liste landet.

Ich sehe die Problematik mittlerweile auch kritischer, als anfangs,
als ich noch dachte, wenn der richtige Absendername in der Mail
steht, ist alles OK. Deshalb die Frage nach dem "seriösen Weg".

Ich tuhe mich noch mit meinem Verständnis schwer, wie die
Zusammenhänge zwischen Domain, Ip und SMTP-Server sind.

Wenn von der Website aus per PHP:mail() eine Mail verschicke, kann
ich in den Absender schreiben, was ich will. Schreibe ich da
[e-mail] rein, gibt es den Zusammenhang:

IP der Website www.kundendomain.de = IP des SMTP-Servers, der mit
[e-mail] verschickt hat.

Wenn z.B. mein Ansprechpartner beim Kunden mir eine Mail schreibt,
ist der SMTP-Server aber ja ein ganz anderer. Wo da ein Zusammenhang
festgestellt werden kann, kann ich mir nicht vorstellen.

Mein jüngste Idee ist, das ganze mit einer Subdomain zu machen.
Darauf bin ich bei meinem Lufthansa Newsletter gestossen. Der
wird auch von [e-mail] versandt. Das könnte
gehen oder ?

danke und

beste gruesse,
martin

[Ines]

Mein jüngste Idee ist, das ganze mit einer Subdomain zu machen.
Darauf bin ich bei meinem Lufthansa Newsletter gestossen. Der
wird auch von [e-mail] versandt. Das könnte
gehen, oder?

Das ginge auch, ja.

Ines

[Sven Rautenberg]

Moin!

Und der Kunde kann nichts dran ändern? Es wäre die sauberste Lösung und da hat dein Kunde doch sicher auch Interesse daran.

Ja, das ist sicher richtig, aber weil die IT aus Sicherheitsgründen
nicht mal Ihren Mitarbeitern gewährt, ausserhalb des Netzwerks
auf den Mailserver zuzugreifen, wird sie mir das auch nicht gewähren,
um Newsletter zu verschicken.

Von außerhalb nicht. Von innerhalb?

Ich sehe die Problematik mittlerweile auch kritischer, als anfangs,
als ich noch dachte, wenn der richtige Absendername in der Mail
steht, ist alles OK. Deshalb die Frage nach dem "seriösen Weg".

Beim Mailversand hängt mittlerweile wegen des Spams viel von nichttechnischen Dingen ab.

Rein technisch gesehen hattest du mit deiner unkritischen Sichtweise vollkommen Recht: SMTP-Server finden, dem die beliebige Absendeadresse sagen, die Liste von Empfängern und die Mails übermitteln, und fertig.

Der Betrieb von Mailservern hat aber mittlerweile eben nicht mehr nur diese technische Komponente, sondern auch eine soziale. Wenn ein Mailserver eine Mail via SMTP-Protokoll annimmt, dann übernimmt dessen Betreiber für diese Mail die Verantwortung. Er hat sie dann, das ist zumindest meine persönliche Sichtweise, in jedem Fall dem Empfänger zuzustellen. Andernfalls hätte er sie im SMTP-Dialog mit einem Fehlerstatus ablehnen müssen.

Strato hat genau das getan, als du eine bei Strato unbekannte Domain als Absender verwenden wolltest; Strato wollte die Verantwortung nicht übernehmen, Mails versenden zu müssen, für deren Absenderdomain die Firma nicht zuständig ist, die also außerhalb ihres Einflußbereichs liegt. Denn das Szenario könnte ja auch so gehen: Du schickst bösartig einen Newsletter im Namen einer Firma raus, der eindeutig als Spam zu identifizieren ist und nur dazu dient, diese Firma als Spammer zu diskreditieren. Der Strato-Mailserver hat mit jeder akzeptierten aber nur zwei Möglichkeiten: 1. Auslieferung an den Empfänger. Und wenn der den Spam blockt: Rückgabe der Mail an die angegebene Absendeadresse - die die Mail ja auch nie geschickt hatte. Wenn auch dort geblockt wird, wird Strato die Mail nirgends los, sie landet dann beim dortigen Postmaster, der dann untersucht, was da wohl vorgefallen ist. Oder die Mail wird dann direkt gelöscht.

Genau die gleichen Optionen hat Strato natürlich auch, wenn die Mail zwar legitim ist, aber dennoch bei Empfänger oder Absendeadresse nicht angenommen wird. Das wäre dann aber schon deutlich unschöner, weil du bzw. dein Auftraggeber wissen wollen, welche Mails nicht ankommen.

Insofern ist es eigentlich schon fast Pflicht, dass alle Mails einer Domain immer über die zugehörigen Mailserver verschickt werden. Welche das sind, sagt ein passender SPF-Record dem interessierten Internet. Aber auch sonst wird in Logfiles und Whitelists dieser Mailserver schon durch früheren Mailversand positiv aufgefallen sein, so dass der Newsletter deutlich weniger Behinderung zu erwarten hätte, als wenn er von einem komplett anderen Mailserver käme. 20.000 Mails sind zwar einerseits keine ganz winzige Menge, andererseits sollten sie eigentlich innerhalb von einer Stunde aus der Queue wieder verschwunden sein. Wenn man das in die Abendstunden verlegt, wird kein regulärer Büromailverkehr gestört.

Ich tuhe mich noch mit meinem Verständnis schwer, wie die
Zusammenhänge zwischen Domain, Ip und SMTP-Server sind.

Es gibt da keinen direkten Zusammenhang.

Eine Domain ist sowas wie "example.org". Zu dieser Domain, wenigstens aber zur Subdomain "www.example.org" kann ein A-Record im DNS-System gehören, der die IP des Webservers definiert.

Durch die Existenz der Domain kann man auch Mailadressen "[e-mail]" festlegen. Als Zielserver wird im DNS ein MX-Record angelegt, der den Hostnamen des zu verwendenden SMTP-Servers enthält. Ein DNS-Lookup auf diesen Hostnamen ergibt dann die zu kontaktierende IP. Der MX-Hostname muß allerdings absolut nicht mit der Domain der Mailadresse übereinstimmen, er kann auch "mailserver.blafasel.invalid" heißen. Nur wenn für die Maildomain "example.org" kein MX-Eintrag im DNS gefunden wird, wird gesucht, ob ein A-Record (mit IP) für diese Domain existiert - dieser Fall ist aber extrem selten, solche Konstellation wird allein schon deshalb vermieden, weil es immer wieder Blödmänner unter den Programmierern gibt, die beim Mailversand nur nach MX-Records gucken, und den Teil mit "A-Records" in der Standardisierung überlesen oder vergessen. ;)

Soviel zum Mailempfang. Der Mailversand läuft anders. Ein sendender SMTP-Server muß nämlich zum Internet hin keinen Port offen haben - den bräuchte er nur, um auf reinkommende Mails zu warten. Man kann also problemlos zwei Maschinen haben: Eine empfängt nur Mails, die andere sendet nur. Wo viele Mails durchrauschen, lohnt sich das oft.

Das aber bedeutet, dass die zwei Maschinen auch zwei unterschiedliche IP-Adressen besitzen. Und die IP des Mailsenders ist im Prinzip nirgendwo im Internet als "ich darf Mails für example.org versenden" registriert, so wie der Empfänger es als MX-Eintrag ist. SPF hilft da zwar ein wenig weiter, aber das wird bislang nur von wenigen Domains genutzt (u.a. von selfhtml.org), und man muß sich dann als Empfänger auch so seine Gedanken machen, was man im Abweichungsfall mit so einer Mail machen würde.

SPF ist aber bis dato der einzige Versuch, DNS-seitig einen Vertrauensbeleg für andere Mailserver zu implementieren, der einer sendenden IP-Adresse eine "Mailerlaubnis" zuordnet.

Wenn von der Website aus per PHP:mail() eine Mail verschicke, kann
ich in den Absender schreiben, was ich will. Schreibe ich da
[e-mail] rein, gibt es den Zusammenhang:

IP der Website www.kundendomain.de = IP des SMTP-Servers, der mit
[e-mail] verschickt hat.

Richtig. Der Webserver ist aber aus zwei Gründen eine gute Location für Newsletter:
1. In der Regel ist zum Eintragen oder Austragen aus der Empfängerliste ein Webformular auszufüllen, bzw. es gibt sogar eine etwas umfangreichere Oberfläche für die Empfänger, auf der sie persönliche Einstellungen vornehmen können. Für so eine Aktion einen separaten Webserver zu verwenden ist meist nicht gerechtfertigt. Und da die Empfängeradressen ja auch irgendwo gespeichert werden müssen, ist dieser Ort oftmals eine ebenfalls dort vorhandene Datenbank. Da liegt es nahe, von dort auch den Newsletter wegzumailen.

2. Der Webserver wird in der Regel ohnehin einen Mailserver integriert haben, um eigene Statusmails zu versenden. Und da auch Webserver nicht 24 Stunden rund um die Uhr voll ausgelastet sind, ist gewöhnlich genug Leistungsreserve für den Newsletterversand.

Der positive Nebeneffekt ist, dass die sendende IP durchaus verifizierbar der Absenderdomain zugeordnet werden kann.

Mein jüngste Idee ist, das ganze mit einer Subdomain zu machen.
Darauf bin ich bei meinem Lufthansa Newsletter gestossen. Der
wird auch von [e-mail] versandt. Das könnte
gehen oder ?

Subdomains ändern an der Technik, den Umständen und den Verantwortlichkeiten eigentlich gar nichts. Dein Plan, die Mails eben gerade nicht von dem gewöhnlichen Mailserver oder dem Webserver der Absenderadresse versenden zu lassen, sondern von einem deiner eigenen Systeme, ist eigentlich das Problem.

Vom Strato-Mailserver geht das nicht, wie festgestellt. Von einer dynamischen IP aus sowieso nicht (landet mehrheitlich im Spamfilter).

Entweder du organisierst dir einen "passenden" Mailserver und läßt mit dieser Subdomain dorthin zeigen (und den Reverse-DNS-Eintrag für dessen IP wieder zurück auf diese Subdomain) - dann hast du Vertrauenspunkte gewonnen (wenngleich dir das bei schlecht formuliertem/formatiertem Mailinhalt trotzdem nicht durch die Spamfilter hilft).

Das ist allerdings im Prinzip genau dasselbe, als wenn du direkt über den zuständigen Mailserver oder Webserver deines Kunden sendest. Und das ginge eben ohne Subdomain - die die Admins des Kunden ja auch erstmal einrichten müßten, und wenn die schon wegen ihres Mailservers Paranoia haben, frage ich mich, wie die wohl auf diese Idee reagieren.

PS: Ich frage mich sowieso, wie man dieser Firma was mailen kann, wenn deren Mailserver von außen komplett unerreichbar ist. Es geht hier ja nicht darum, auf dein Postfach zuzugreifen, sondern lediglich darum, dass der Mailserver ein Relay ist für Mails von "außen" an beliebige Zieladressen, solange die Absenderadresse die festgelegte Newsletteradresse ist - am besten natürlich noch ergänzt um SMTP-Authentifizierung, damit niemand dieses Relay mißbraucht, indem auch er einfach die passende Absenderadresse einsetzt.

Oder eben der Newsletter wird von intern losgeschickt.

- Sven Rautenberg

[Martin Hein]

Hallo Sven,

tausend Dank für Deine ausführlichen Informationen !

Und der Kunde kann nichts dran ändern? Es wäre die sauberste Lösung und da hat dein Kunde doch sicher auch Interesse daran.

Ja, das ist sicher richtig, aber weil die IT aus Sicherheitsgründen
nicht mal Ihren Mitarbeitern gewährt, ausserhalb des Netzwerks
auf den Mailserver zuzugreifen, wird sie mir das auch nicht gewähren,
um Newsletter zu verschicken.

Von außerhalb nicht. Von innerhalb?

versteh' die Frage leider nicht.

Soviel zum Mailempfang. Der Mailversand läuft anders. Ein sendender SMTP-Server muß nämlich zum Internet hin keinen Port offen haben - den bräuchte er nur, um auf reinkommende Mails zu warten. Man kann also problemlos zwei Maschinen haben: Eine empfängt nur Mails, die andere sendet nur. Wo viele Mails durchrauschen, lohnt sich das oft.

Das müsste doch allerings heissen, dass ich den Mailserver, der laut
meinem Kunden von aussen nicht erreichebar ist, zum Senden verwenden
kann (weil er doch erreichbar ist?). Ergo:
Ich muss die Zugangsdaten des (bereits eingerichteten) SMTP-Accounts
für '[e-mail]' wissen und kann dann unter Angabe
dieses Absenders darüber versenden. Ich kann lediglich nicht
den Posteingangsserver abfragen (wegen des Ports).

Richtig. Der Webserver ist aber aus zwei Gründen eine gute Location für Newsletter:

1. In der Regel ist zum Eintragen oder Austragen aus der Empfängerliste ein Webformular auszufüllen, bzw. es gibt sogar eine etwas umfangreichere Oberfläche für die Empfänger, auf der sie persönliche Einstellungen vornehmen können. Für so eine Aktion einen separaten Webserver zu verwenden ist meist nicht gerechtfertigt. Und da die Empfängeradressen ja auch irgendwo gespeichert werden müssen, ist dieser Ort oftmals eine ebenfalls dort vorhandene Datenbank. Da liegt es nahe, von dort auch den Newsletter wegzumailen.

2. Der Webserver wird in der Regel ohnehin einen Mailserver integriert haben, um eigene Statusmails zu versenden. Und da auch Webserver nicht 24 Stunden rund um die Uhr voll ausgelastet sind, ist gewöhnlich genug Leistungsreserve für den Newsletterversand.

Der positive Nebeneffekt ist, dass die sendende IP durchaus verifizierbar der Absenderdomain zugeordnet werden kann.

Und genau das geht eben leider nicht ;(

Klar, Du hast schon Recht. Das läge eigentlich nahe und dahin
will ich den Kunden auch über kurz oder lang bringen. Zwei Dinge
sprechen zur Zeit dagegen:

1. Es gibt ein CRM (?). Der Kunde nennt das Internet-
   Geschäftsstelle, dass ich auch der Seite einbinde.
   Da werden hochsensible Kundendaten hin- und her-
   geschoben (Versicherungsdaten). Ein Teil dieser
   'IGS' ist die Bestellung eines Newsletter. In seinem
   CRM hat der Kunde also Informationen über den Nutzer,
   der sich ein Newsletter bestellt, wie z.B. Alter und
   Familienstand. Die 20.000 Abonenten werden monatlich
   neu exportiert und an eine Schnittstelle ist (noch)
   nicht zu denken.

2. Der Webserver 'schwächelt'. Sprich: Er ist langsam,
   zeitweise schwer und oft genug garnicht erreichbar.
   Aus bisher unerfindlichen Gründen. Ich habe z.B.
   basierend auf TinyMCE ein CMS für die Website gebaut.
   Die Arbeit damit (also Pflege der Seiten direkt auf
   dem Webserver) ist eine Qual für den Redakteur.

Entweder du organisierst dir einen "passenden" Mailserver und läßt mit dieser Subdomain dorthin zeigen (und den Reverse-DNS-Eintrag für dessen IP wieder zurück auf diese Subdomain) - dann hast du Vertrauenspunkte gewonnen (wenngleich dir das bei schlecht formuliertem/formatiertem Mailinhalt trotzdem nicht durch die Spamfilter hilft).

Unter einem "passender" Mailserver verstehe ich in dem Kontext
"irgendeinen" Mailserver auf dem ein ordentlicher Mail-Account
eingerichtet wird, der eben statt '[e-mail]'
'[e-mail]' heisst.

PS: Ich frage mich sowieso, wie man dieser Firma was mailen kann, wenn deren Mailserver von außen komplett unerreichbar ist. Es geht hier ja nicht darum, auf dein Postfach zuzugreifen, sondern lediglich darum, dass der Mailserver ein Relay ist für Mails von "außen" an beliebige Zieladressen, solange die Absenderadresse die festgelegte Newsletteradresse ist - am besten natürlich noch ergänzt um SMTP-Authentifizierung, damit niemand dieses Relay mißbraucht, indem auch er einfach die passende Absenderadresse einsetzt.

Mit scheint, genau das ist der Punkt. Die Absage meines Kunden,
ich könne nicht über seinen Mailserver versenden, weil er von
aussen nicht erreichbar ist unsinnig. Ich kann von aussen nicht
auf das POP3-Postfach zugreifen, aber es spricht nicht dagegen
den SMTP-Server zum Versenden zu benutzen, weil dazu garkein
Post offen sein muss. Ich muss lediglich die Zugangsdaten dazu
kennen, die wenn ich das ganze richtig verstehe nur darin bestehen,
dass ich weiss, wie er heisst (z.B. post.kundendomain.de).

Oder eben der Newsletter wird von intern losgeschickt.

was mir bedeutet, dass jemand dort den NL-Client bedienen muss.
Das sehe ich kritisch.

tausend Dank,
martin