Martin Hein: Newsletter | Wie macht man's richtig ?

Beitrag lesen

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 'newsletter@kundendomain.de' 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 'newsletter@meinedomain.de'
'newsletter@sub.kundendomain.de' 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