Support-Forum Mirko Böer Softwareentwicklungen

ich würde die Bilder trotzdem lieber mitschicken, gibt mir persönlich mehr Sicherheit.

Hallo Mirko,

Zur Minimierung der E-Mail-Größe ist es sinnvoll die Bilder nicht mit der E-Mail zu versenden, sondern übers Web laden zu lassen. Nachteile dabei sind:

* Empfänger muss eine bestehende Verbindung zum Internet haben
* das E-Mail-Programm des Empfängers blockt Bilder, die aus dem Web geladen werden, z.B. MS Outlook tut das. Der Nutzer muss auf klicken um die Bilder sehen zu können.

...dazu habe ich diesen interessanten Artikel gefunden. Das Einbinden von Bildern kann man sich demnach sparen ;o) und die E-Mails schlank halten.

Grüße, Hardy

Ahhhh super, es sind doch die Feinheiten, die das Programm auszeichnet! Danke für den klasse Tip!!!

...den ich immer noch mit einem \"p\" schreibe ;o)

Hardy

20.000 in einer Gruppe ist für einen schnellen PC mit Windows 2000 oder neuer kein Problem. Das beste ist die Gruppen nicht zu verwenden und alles in der Gruppe <keine> zu lassen. Ãœber der Empfängerliste kann man auf \"Empfänger auswählen\" - Empfängerbereich wählen klicken und z.B. sagen wähle Empfänger 1-20000 und danach 20001 bis 40000 usw..

Hallo Mirko,

erst einmal herzlichen Dank für die promte Antwort!

Den HELO Befehl habe ich noch einmal getestet, mein Server schreibt nun doch automatisch die richtige Domain-Absenderadresse in den E-Mail-Header, also kann ich das Feld tatsächlich leer lassen ;o)

Ich denke, noch einige Tests und dann kann ich langsam einen ersten Versuch wagen, und nächste Woche geht es los.

Eine Frage habe ich noch: Aufgrund der hohen Anzahl von E-Mails möchte ich den Versand splitten, d.h. in Gruppen zu 20.000 Empfängern versenden. Wenn ich den Performance-Hinweis in der Hilfe richtig verstanden habe, löse ich das besser über verschiedene Projekt-Dateien als über Empfängergruppen?

Besten Dank

Hardy

Hallo,

....


(1) Komprimierung: Obwohl phpinfo.php angibt, daß bzip2 Unterstützung vorhanden ist, bricht der Versand nach zwei bis vier Mails ab (Versand über eigenen Server/Webspace, maximal 10 E-Mails oder 1024 KB), egal, welchen Komprimierungsgrad für bzip2 ich angebe. Mit ZLib-Komprimierung \"maximal\" funktioniert es bei gleicher Einstellung tadellos. Kann dies an der Einstellung der bzip2-Komprimierung selbst liegen?

bzip2 ist nicht auf jedem Server gleich installiert, teilweise sind fehlerhafte Versionen drauf, aus diesem Grund hatte ich später ZLib noch hinzugefügt, da dies überall perfekt lief. Der Nachteil an ZLib ist die geringere Komprimierungsrate.

(2) Geschwindigkeit: Bei einer multi-part E-Mail mit 17 KB und Versand über eigenen Server/Webspace braucht SM für 100 Mails (inkl. der Skript-Ãœbertragung für Tracking etc.) bei 408 KB Uploadrate 23 Sek. Hat die E-Mail 87 KB, dauert es bereits 2 Min 36 Sek. Irgendwie habe ich auch durch andere Einstellungen und Versandarten keine schnelleren Ãœbertragungs-Geschwindigkeiten hinbekommen. Hat da vielleicht jemand einen Tip dazu?

Es kommt immer auf die Komprimierbarkeit des E-Mail-Texts inkl. Bilder an. Prinzipiell ist eine E-Mail reiner Text, also auch die enthaltenen Bilder werden in Text umgewandelt. Der Text lässt sich normalerweise gut komprimieren. Einen richtigen Geschwindigkeitsvorteil hat man jedoch nur, wenn man viele E-Mails auf einmal versendet, da immer der komplette Block komprimiert wird. z.B. 100 Mails a\' 87 KB = 8700 KB, das ganze wird durch die Komprimierung vielleicht auf 4000 KB komprimiert. Problem ist dabei jedoch immer der \"Speed\" des Servers, da natürlich die Daten wieder dekomprimiert werden müssen. Ist der Server langsam bzw. ausgelastet, dauert das eine ganze Weile. Die Mails müssen danach auch noch versendet werden, manche Server sind dabei langsam weil Erreichbarkeitsprüfungen (und Reverse-DNS) durchgeführt werden.

(3) Bilder im HTML-Teil: Zum Testen habe ich bei einigen \"freien\" E-Mail-Providern Konten eingerichtet, u.a. web, freenet, gmx, google, arcor, yahoo, lycos... Dabei hat sich gezeigt, daß die Darstellung meist reibungsloser funktioniert, wenn die Bilder von einem Webserver \"nachgeladen\" werden. Zudem ist die E-Mail selbst natürlich deutlich kleiner. Ist das \"Auslagern\" von Bildern auch Eure Empfehlung?

Zur Minimierung der E-Mail-Größe ist es sinnvoll die Bilder nicht mit der E-Mail zu versenden, sondern übers Web laden zu lassen. Nachteile dabei sind:

* Empfänger muss eine bestehende Verbindung zum Internet haben
* das E-Mail-Programm des Empfängers blockt Bilder, die aus dem Web geladen werden, z.B. MS Outlook tut das. Der Nutzer muss auf klicken um die Bilder sehen zu können.

(4) SMTP HELO-Name: Mein Server gibt als HELO-Name im E-Mail-Header nur die interne Bezeichnung des Providers aus, aber keine \"gültige\" Webadresse oder IP-Nummer. Ist es dann nicht besser, eine \"gültige\" Absenderdomain \"www.meinedomain.de\" einzutragen?

der SMTP HELO-Name ist eigentlich nur für den Versand direkt an den Server des Empfängers notwendig. Versendet man über SMTP-Server dann muss man den Wert nur ändern, wenn der SMTP-Server den Namen des eigenen PCs nicht mag z.B. weil Umlaute/Sonderzeichen enthalten sind.
Auf keinen Fall sollte man Domains eintragen, denn die Auflösung der Domain muss auf den Server verweisen und genauso wieder zurpck (Reverse DNS).

(5) Mailanzahl / E-Mail-Provider: Wie unter (3) angegeben, habe ich einige \"freie Accounts\" eingerichtet. Natürlich könnte ich jetzt deren und weitere SMTP Zugänge nutzen, um für einen Kunden einen avisierten, personalisierten Newsletter von 200.000 Stück / monatlich zu versenden, aber da es sich um Confirmed-Opt-In-Adressen handelt, der Absender offiziell auftritt und die HTML-E-Mail alle Bestandteile nach DDV-Richtlinien und deutschen Rechtsvorschriften enthält gibt es doch eigentlich keinen Grund, nicht über meinen (gemieteten) Webserver zu versenden, auch wenn die IP meines Servers natürlich im E-Mail-Header mit drin steht. \"Direktversand an den Server des Empfängers\" kommt wegen Spam-Filtern und aus Geschwindigkeitsgründen wohl eher nicht in Betracht. Würde dazu gerne einmal Eure Meinung hören.

Der Versand über einen SMTP-Server ist immer vorzuziehen. Der direkte Versand kommt nur in Fragen wenn man eine Leitung mit fester IP-Adresse hat (keine Einwahlverbindung z.B.- Modem, ISDN, DSL). Auch bei einer Leitung mit fester IP-Adresse ist der Versand über einen Server besser, den kann man auch lokal auf den eigenen PC installieren. Der Server versucht mehrfach die Mails zuzustellen, SuperMailer nur einmal. Ist der Server des Empfängers gerade nicht erreichbar z.B. wird neugestartet, dann kann SuperMailer die Mail nicht zustellen, der Server versucht es später nochmal und gibt nach einigen Tagen erst auf.

Hallo, liebe Leute im Forum!

Als SuperMailer-Neukunde (BCC-Version) habe ich mich nun intensiv mit dem Programm und der enthaltenen Hilfe auseinander gesetzt und auch hier im Forum bereits viel gelesen. Dennoch sind mir ein paar Dinge nicht ganz klar bzw. würde gerne Eure Meinung dazu hören:

Vorab: Die Installation des Programmes, der PHP-Skripte für Double-Opt-In, Einrichting der POP / SMTP Postfächer, FTP-Upload, Trackingfunktion, Bounce-Bearbeitung etc. war nach Einarbeitung relativ leicht zu bewerkstelligen, die Funktionstests haben nachher auch alle funktioniert (Versand an 100 eigene Adressen mit ein paar falschen drin).

Jetzt meine Fragen:

(1) Komprimierung: Obwohl phpinfo.php angibt, daß bzip2 Unterstützung vorhanden ist, bricht der Versand nach zwei bis vier Mails ab (Versand über eigenen Server/Webspace, maximal 10 E-Mails oder 1024 KB), egal, welchen Komprimierungsgrad für bzip2 ich angebe. Mit ZLib-Komprimierung \"maximal\" funktioniert es bei gleicher Einstellung tadellos. Kann dies an der Einstellung der bzip2-Komprimierung selbst liegen?

(2) Geschwindigkeit: Bei einer multi-part E-Mail mit 17 KB und Versand über eigenen Server/Webspace braucht SM für 100 Mails (inkl. der Skript-Ãœbertragung für Tracking etc.) bei 408 KB Uploadrate 23 Sek. Hat die E-Mail 87 KB, dauert es bereits 2 Min 36 Sek. Irgendwie habe ich auch durch andere Einstellungen und Versandarten keine schnelleren Ãœbertragungs-Geschwindigkeiten hinbekommen. Hat da vielleicht jemand einen Tip dazu?

(3) Bilder im HTML-Teil: Zum Testen habe ich bei einigen \"freien\" E-Mail-Providern Konten eingerichtet, u.a. web, freenet, gmx, google, arcor, yahoo, lycos... Dabei hat sich gezeigt, daß die Darstellung meist reibungsloser funktioniert, wenn die Bilder von einem Webserver \"nachgeladen\" werden. Zudem ist die E-Mail selbst natürlich deutlich kleiner. Ist das \"Auslagern\" von Bildern auch Eure Empfehlung?

(4) SMTP HELO-Name: Mein Server gibt als HELO-Name im E-Mail-Header nur die interne Bezeichnung des Providers aus, aber keine \"gültige\" Webadresse oder IP-Nummer. Ist es dann nicht besser, eine \"gültige\" Absenderdomain \"www.meinedomain.de\" einzutragen?

(5) Mailanzahl / E-Mail-Provider: Wie unter (3) angegeben, habe ich einige \"freie Accounts\" eingerichtet. Natürlich könnte ich jetzt deren und weitere SMTP Zugänge nutzen, um für einen Kunden einen avisierten, personalisierten Newsletter von 200.000 Stück / monatlich zu versenden, aber da es sich um Confirmed-Opt-In-Adressen handelt, der Absender offiziell auftritt und die HTML-E-Mail alle Bestandteile nach DDV-Richtlinien und deutschen Rechtsvorschriften enthält gibt es doch eigentlich keinen Grund, nicht über meinen (gemieteten) Webserver zu versenden, auch wenn die IP meines Servers natürlich im E-Mail-Header mit drin steht. \"Direktversand an den Server des Empfängers\" kommt wegen Spam-Filtern und aus Geschwindigkeitsgründen wohl eher nicht in Betracht. Würde dazu gerne einmal Eure Meinung hören.

Ich danke Euch schon einmal für Eure Rückmeldungen!

Und an Mirko Böer: Vielen Dank, ich bin vom SuperMailer sehr angetan! Mit der Skriptunterstützung, der Bounce-Funktion, der Tracking-Auswertung und in diesem Preis-/Leistungsverhältnis steht der SM vermeintlich professionelleren, aber erheblich teureren Lösungen in nichts nach!

Viele Grüße,

Hardy

-------------------------------------------------

PC-System: W2k, Pentium 4, 1 GB RAM.
Internet-Anschluß: DSL 6k (allerdings gebremst auf 3048kbit/s), ATM Nutzrate 408 kbit/s, dynamische IP von T-Online.
Webspace: Bei einem Provider gemieteter Webserver mit PHP / POP3 / SMTP und allem pi-pa-po.