Versand Massenmail

PapaBaer

Registered User
Ahoi Forum,

ich sitze gerade an einem Projekt ein Newsletter-System umzusetzen (legal, Double-Opt-In, kein Spam). Der Versand der einzelnen Mails wird in einen Hintergrund-Job verschoben. Nun soll der absendende Server natürlich nicht sofort auf nem Spam-Filter landen, wenn er den ersten Newsletter raus schickt. Daher die Frage: Weiß hier jemand, in welchen Raten man Mails an bestimmte Provider schicken kann, damit das nicht als Spam gewertet wird?

Alle Systeme, die ich auf die Schnelle im Netz finde, hauen die Mails einfach in Masse raus.
 
Ich habe auf meinem Server ein paar Newsletter mit relativ kleinen Verteilern (zwischen 20 und 100 Abonnenten) laufen - das ganze über Mailman, da ich das auch für normale Mailinglisten brauche. Dabei konnte ich bemerken, daß einige Provider den Versand ausbremsen und schon nach recht wenigen Mails erst mal 4xx-Fehler werfen (bei Yahoo und web.de reichten da schon mehr als 5 Abonnenten aus). Allerdings scheint mir solch ein Newsletter von Mailman auch nicht ganz optimal an Postfix übergeben zu werden, sondern wird von Mailman schon in mehrere Versandaufträge gestückelt, die sich teilweise nicht nach den Domains richten.
 
Ich habe dieses Problem auch auf einem Mailinglisten-Server von mir. Dort habe ich in der Postfix-Konfiguration (vielleicht haben das andere Mailserver auch) die Option "default_destination_concurrency_limit" auf den Wert 1 (eins) gestellt.
Diese Direktive weist Postfix an, maximal eine E-Mail gleichzeitig an den selben Server zu schicken. Zumindest web.de und GMX scheinen mir nun wohlgesonnener zu sein.
Immerhin werden die jetzt bei Listen, in denen 200 web.de-Empfänger sind nicht mehr zugedrückt sondern schön langsam nacheinander eingeworfen :)

Das dürfte einen Teil dazu beitragen dass dich entfernte Mailsysteme nicht mehr hassen :)
Wenn du die Möglichkeit hast, solltest du deinem Newsletter-Versandsystem beibringen möglichst nicht 100 Mails nacheinander an @t-online.de-Adressen einzuliefern sondern schön bunt gemischt mit kleinen Pausen dazwischen. Und wenn der Versand drei Stunden dauert ist das allemal besser als alle Mails in 20 Minuten losgeworden und dafür auf vier Blacklisten gelandet zu sein.
 
Wie groß wird denn Dein Verteiler voraussichtlich werden?

Wenn es nur eine Handvoll (ein paar hundert) Aussendungen sind, dann ist die Idee mit den Pausen schon sinnvoll.

Wenn Du aber z.B. 10.000 oder 100.000 Mails verschicken musst, dann macht das in Päckchen von 100 Stück nicht so viel Sinn.

Es gibt da ausserdem noch ein paar andere Dinge, die man da tun kann. Z.B. bieten tatsächlich einige große potentielle Empfänger (z.B. Google) an, dass man sich als Versender registrieren kann.

Um da mehr zu zu sagen müsste man mal ein paar Details wissen.
 
Bei uns geht es um 2000 - 5000 Mails. Wir wollen das ganze später als PlugIn veröffentlichen und anderen zugänglich machen. Von da her sollte es schon möglichst robust sein.
 
Also Du willst das nicht (nur) selber benutzen sondern quasi als Produkt für andere anbieten?

Du schreibst "Plugin". Worein denn? Also wie muss ich mir das vorstellen. Ist das eine PHP-Anwendung oder so?
 
Konkret ein PlugIn für refinery, also Rails. Und ja, es soll für andere verfügbar werden, deswegen solide skalieren.

Da wir Rails benutzen, ist es kein großer Handstand, das Versenden der Mails vom eigentlichen HTTP-Request zu entkoppeln. Die Frage ist halt, wie stückelt man das sinnvoll.
 
Tja, also da hast Du meiner Meinung nach zwei grundsätzliche Optionen:

a) Du stellst Dich in einem Plugin einigermassen dumm und übergibst die zu versendende Mail einfach an einen entsprechend konfigurierten Smarthost. Da gibt es ja Anbieter, die sich extra auf sowas spezialisiert haben, z.B.:

http://www.gtc.de/produkte/e-mail-versand.html
http://www.rapidmail.de/

(willkürliche Auswahl)

Dann brauchst Du natürlich in Deinem Plugin nichts wirklich aufregendes zu tun oder

b) Du verpasst Deinem Plugin die entsprechende Intelligenz, die ein MTA beim Massenversand haben sollte oder

c) Du implementierst da gleich Deinen eigenen MTA. Der braucht ja nicht so viel zu können, wenn er nur senden soll. Allerdings bedeutet das nicht, dass Du Net::SMTP benutzt sondern vielmehr, dass Du tatsächlich Deine eigene SMTP-Implementierung schreibst. Das klingt jetzt vielleicht ein wenig wüst, aber SMTP ist an sich ein relativ triviales Protokoll.

Der Charme von c) wäre halt, dass Du von Deiner Anwendung aus direktes Feedback darüber hast, welche Mails weg sind, welche noch in der Queue liegen, welche Meldungen es vom annehmenden SMTP-Server gegeben hat, usw.

Wenn Du Deine Mails einfach an einen SMTP-Server übergibst, dann sind die halt weg. Das ist so wie wenn Du die Post in den Briefkasten wirfst. Du musst Dich dann halt drauf verlassen, dass das Postunternehmen das schon irgendwie richtig macht.

Für eine Inhouse-Lösung würde ich persönlich am MTA rumschrauben, weil ich den ja dann auch unter Kontrolle habe und drauf gucken kann, was los ist. Aber für eine von Dir geschilderte Lösung, die ich verkaufen will und die möglichst überall laufen soll würde ich in Richtung c) gehen.

Wenn Du Dich fragst, was mit "Intelligenz" gemeint ist: Simples "langsam verschicken" löst Dein Problem nicht wirklich. Aber die großen Provider (auf der Empfänger-Seite) haben da jeweils ganz gute Infos, z.B.:

http://help.yahoo.com/l/us/yahoo/mail/postmaster/
http://faq.gmx.net/messages/email/optionen/antispam/1.html
u.s.w.

Einige Regeln sind bei allen deckungsgleich, bei anderen Sachen kocht da jeder sein Süppchen. Daher ist das halt auch Spezial-Knowhow. Will sagen: Wenn Du einen Newsletter für eine wirklich große Zielgruppe machst (es gibt ja Newsletter mit 100.000 oder 500.000 Empfängern) dann musst Du da schon so einiges dafür tun, damit die nicht straight in die Spam-Ordner oder auf /dev/null gehen.

Übrigens würde ich dann auch mal routinemässig die eigene IP in relativ kurzen Abständen automatisch auf den wichtigsten DNS-Blacklisten abfragen, quasi als Frühwarnsystem, so dass Du z.B. den Versand einstellen kannst, wenn Du merkst, dass Du ein Problem bekommst.
 
Last edited by a moderator:
Back
Top