Newsletterversand mit phpmailer

[onemorenerd]

UPDATE ... SET domain_rev=REVERSE('foo.example.com') ...

ist doch lesbar.

[Quetschi]

Angenommen es müsste jemand mit deiner DB arbeiten und er weiß praktisch nichts darüber (ok, du vergibst schon einen entsprechenden Spaltennamen) - er guckt sich erstmal die Tabelle an und findet ne Spalte mit Einträgen wie

ed.bew
ed.retsnuem-inu.aroge
ed.retsnuem-inu.iwiw
ed.liameerf

also ich hätte erstmal ein Fragezeichen übern Kopf - naja, wenn jemand

de.freemail
de.gmx
de.uni-muenster.egora
de.uni-muenster.wiwi
de.web

sieht, denkt er sich wohl auch erst mal was da wohl los ist...

Das kommt wohl an nem Punkt an wo man wirklich von "Geschmackssache" reden kann.

Wenn ich drüber nachdenke - wenn ich schon soweit gehen würde, dann lese ich noch die IP zum MX-Eintrag aus, speichere die mit ab (muss vor jedem Versand natürlich erfolgen, da sich IP's ja ändern) und beschicke dann eben alles nach IP sortiert.

Ich denk aber das die Hauptlast schon durch das Gruppieren der Domains abgefangen wird - das was man danach noch optimieren kann hat dagegen vermutlich nur noch einen verhältnismäßig geringen Effekt.

[onemorenerd]

In meiner Welt werden DB-Inhalte nur dann direkt verändert, wenn man sich ihrer Bedeutung und Verwendung bewußt ist. Das heißt, wer an einer Applikation vorbei direkt auf der Datensicherungsebene arbeitet, muß wissen, was er da macht.
Dieses Wissen kann man im Idealfall aus der technischen Dokumentation der Applikation ziehen. Wenn man dort nichts findet, schaut man sich die COMMENTs der Tabellen und Spalten an. Gibt es keine, liest man die Kommentare im Applikationscode. Geben die nichts her, liest man den Code ... und denkt darüber nach, diese Applikation durch eine vernünftig dokumentierte zu ersetzen oder sie nachträglich zu dokumentieren.

IMO muß sich die Datensicherung nicht selbst erklären. Deswegen müssen die Daten auch nicht lesbar sein.
Ich würde jedem Kollegen auf die Finger hauen, der glaubt, er könne mal eben Daten manipulieren, weil er sie ja lesen kann und sich einbildet, er wüßte wozu/wie sie verwendet werden.

Zum Thema: Eine halbwegs gesunde Gruppierung hat einen großen Effekt (weniger SMTP-Handshakes). Man könnte nun noch viel Hirnschmalz reinstecken, der zusätzliche Gewinn wird aber minimal sein (ein paar Handshakes weniger). Wie du siehst, habe ich diesen Ansatz ja auch nicht bis ins letzte Detail durchgezogen.
Wenn du wirklich die MX beim Subscribe nachschlagen und speichern willst (egal ob deren Name oder IP), zieht das einen Rattenschanz an Fehlerquellen und Arbeit nach sich. Zu einer Mailadresse kann es ja beliebig viele MX geben. Der eine oder andere davon kann man unerreichbar sein. MX-Einträge können sich auch ändern - Namen und/oder IPs.
Der Entwicklungsaufwand steht da wahrscheinlich nicht mehr in einem gesunden Verhältnis zur gewonnenen Performance.

[Quetschi]

Beim Subscribe würd ich mir den MX sowieso noch nicht holen - das hätte kaum Sinn - wie gesagt - erst direkt vor Versand. Aber wie du schon sagst - der Aufwand, um die dadurch weiter möglichen Fehlerquellen abzufangen, lohnt wohl kaum noch.

Ich hab mir eben mal eine DB durchgesehen:
Knapp 20.000 Datensätze - ca. 2.300 Hosts, also ca. 2.300 Handshakes nötig - vom groben drübersehen her würd ich sagen, dass ich nach einer Optimierung bis ins letzte Detail auch (wenn überhaupt) kaum noch unter 2.000 kommen würde. Das ist die Sache wirklich nicht wert.

Was anderes:
Wie validierst du die Mail-Adressen auf gültige Syntax?
Ich hab momentan folgende Regexp im Einsatz:

/[a-z0-9!#$%&'*+\/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[a-z]{2}|aero|asia|biz|com|gov|info|jobs|mil|mobi|museum|name|net|org)\b/

Vorteil:
- unsinnige TLDs wie adfadf.adfdf werden schon hier abgefangen

Nachteil:
- Änderung nötig, wenn neue TLDs hinzkommen

[onemorenerd]

Original geschrieben von Quetschi
Wie validierst du die Mail-Adressen auf gültige Syntax?

Gar nicht. Double-Opt-In.

Um dem User Feedback zu geben i.S.v. "du hast dich wohl vertippt", mußt du die Zeichen vor dem @ prüfen und den MX für den Teil nach dem @ suchen.
Aber lies mal http://www.regular-expressions.info/email.html.

[Quetschi]

Das sowieso - aber ohne valide eMail-Syntax trag ich gar nicht erst ein und versuche ne Mail mit Bestätigungslink zu versenden.

Jep - den Ausdruck hab ich genau von der Seite

[Quetschi]

Hmm - hab grad erst dein Edit gelesen.

Also den Alias kann man ja nur auf Validität prüfen - beim Host kann man dann eben noch gucken ob da überhaupt ein MX da ist. So wär ja

blubb@t-onlin.de

von der Syntax her ja schon mal in Ordnung, da aber für t-onlin.de kein MX eingetragen ist, kann man dem User eben bei der Eingabe schon sagen, dass da was nicht stimmen kann.

[Quetschi]

@onemorenerd

Hast du Erfahrung in Sachen yahoo.de-Adressen beschicken?

Ich spiel mich heut schon den halben Tag damit und hab die entsprechenden Hilfeseiten bei Yahoo durchgesehen.

Ich hab von geschätzten 25 Versuchen es gerade 3mal geschafft an meinen Yahoo-Account zu senden. Die restlichen Male bekomm ich folgendes ausgespuckt wenn ich das Debugging vom PHPMailer aktiviere:

MX: g.mx.mail.yahoo.com

meine.adresse@yahoo.de
SMTP -> FROM SERVER:
421 Message from (IPunseresServers) temporarily deferred - 4.16.50. Please refer to [url]http://help.yahoo.com/help/us/mail/defer/defer-06.html[/url]
SMTP -> FROM SERVER: 
SMTP -> ERROR: EHLO not accepted from server: 
SMTP -> FROM SERVER: 
SMTP -> ERROR: HELO not accepted from server: 
SMTP -> NOTICE:
EOF caught while checking if connected: Die folgende Absenderadresse ist nicht korrekt: info@unsereDomain.de

Gestern hatte ich zunächst Probleme an freenet.de zu schicken - das Problem war, dass unser Server auf dedizierter Hardware - jedoch virtuallisiert läuft. Dadurch habe ich von PHP aus nach aussen hin eine abweichende IP, für welche kein PTR eingetragen war. Ich hab von unserem Server-Anbieter einen PTR mail2.unsereDomain.de eintragen lassen und einen A-Record für mail2.unsereDomain.de auf die "äußere" ServerIP angelegt, damit der PTR in sich konsistent ist. Dadurch gings dann eben auch an freenet.de

Warum yahoo mich jetzt aber noch in ca. 90% der Versuche ablehnt raff ich noch ned.

Das
http://help.yahoo.com/help/us/mail/defer/defer-06.html
das
http://help.yahoo.com/l/us/yahoo/mai...?terms=4.16.50
und das
http://help.yahoo.com/l/us/yahoo/mai...master-02.html

hab ich mir schon durchgelesen - nichts davon sollte auf mich zutreffen bzw. die Bedingungen um an Yahoo senden zu können sollten erfüllt sein.

Hat irgendwer nen Wink mit dem Zaunpfahl für mich?

[lennart]

Original geschrieben von Quetschi
Warum yahoo mich jetzt aber noch in ca. 90% der Versuche ablehnt raff ich noch ned.

Original geschrieben von Quetschi

421 Message from (IPunseresServers) temporarily deferred - 4.16.50. Please refer to [url]http://help.yahoo.com/help/us/mail/defer/defer-06.html[/url]
SMTP -> ERROR: HELO not accepted from server: 
SMTP -> NOTICE:
EOF caught while checking if connected: Die folgende Absenderadresse ist nicht korrekt: [email]info@unsereDomain.de[/email]

?!

[onemorenerd]

Ja, ich habe auch so meine Erfahrungen mit Yahoo. Bei mir war es allerdings mal ein User, der einen Newsletter jede Woche als Spam markiert hat, statt zu unsubscriben. Irgendwann hat es dem Yahoo-weiten Spamfilter ausgereicht, den Newsletter abzulehnen. Ich habe Tage gebraucht, um das herauszufinden.

Bei dir dürfte das Problem ein anderes sein. Du testest ja noch, beschickst also bisher nur deine eigenen Postfächer und wirst die Testmails ja kaum als Spam markiert haben. Dennoch ist der Grund für dein Scheitern offensichtlich der Spamfilter. Sonst hättest du wohl kaum 3 von 25 Mails durchbekommen. Die 3 Mails unterschieden sich vom Rest irgenwie. Entweder sie hatten unverfänglicheren Inhalt oder sie kamen an, bevor der Spamfilter gemerkt hat, dass du "in Massen" sendest. Es wäre hilfreich, wenn du dazu nähere Angaben machen würdest. Was genau war bei den 3 Mails anders oder waren es einfach die ersten 3?

Schau dir auch mal die Header der 3 Mails im Postfach an. Eventuell scheibt der Spamfilter irgendwas rein, woran man sieht, was er macht.

Die Sache mit äußere IP und PTR-Record habe ich nicht verstanden.
Wie siehts mit SPF aus? Hast du das auch gleich mit eintragen lassen?

[Quetschi]

Ich hab gestern nach meinem Post hier nochmal 2 oder 3 an Yahoo rausbekommen, also insgesamt 5 oder 6.

2 davon sind im Spam-Ordner gelandet, die anderen gingen direkt in den Posteingang.

Die Header waren meine erste Anlaufstelle in der Problemeingrenzung - Einträge von nem Spamfilter ala Spam-Assasin und Co. finden sich hier nicht.

Der Inhalt war immer der gleiche, außerdem war es eine reine Text-Mail.

Im übrigen - wenn ich mir den Auszug aus dem Debugging anschau, scheint Yahoo mich von vornherein abzulehnen, bevor ich überhaupt die Mail selbst sende. Das mit dem SPF-Record könnte durchaus interessant sein. Laut Wikipedia scheint Yahoo selbst gar keinen SPF-Record angelegt zu haben - was aber scheinbar nicht heißen muss, dass Yahoo bei eigehenden Mails hier nicht auch überprüft.

An irgendetwas in dieser Richtung muss es aber scheinbar liegen - ich habe gestern probehalber auch ein paar über unseren SMTP senden lassen - die kamen allesamt an - spreche ich direkt einen SMTP von Yahoo an, wirds zur Lotterie.


Hmmm - wie erklär ich dir jetzt das mit dem "inneren" und "äusseren" (<- weiß nicht wie ich es sonst nennen soll) IP's

Wie gesagt - wir haben eine dedizierte Maschine mit einer eigenen IP (die "äussere") - darauf läuft ein virtuallisiertes System mit wiederrum einer eigenen IP (die "innere") <- diese IP ist unsere eigentliche IP unter der der Webserver, Mail-Server, MySql-Server usw. von aussen erreichbar sind.

Öffne ich jedoch in PHP eine Socket-Verbindung "sieht" der entfernte Rechner die "äussere" IP der Maschine. Für diese IP gab es aber keinen PTR. Ich habe dann zuerst für diese IP noch einen PTR auf den Namen unseres Servers einrichten lassen - jedoch waren dann die Ergebnisse der Rückwärts->Vorwärts-Auflösung nicht konsistent. Der PTR für die äussere IP lieferte unseren Server-Namen - der A-Record für unseren Server-Namen lieferte jedoch die innere IP <- die Sache war also nicht in sich konsistent und freenet mochte das nicht.

Ich habe dann den PTR für die äussere IP nochmal ändern lassen auf mail2.unsereDomain.de - für mail2.unsereDomain.de habe ich dann noch einen eigenen A-Record angelegt, der eben wieder die äussere IP liefert - jetzt passt Rückwärts- und Vorwärtsauflösung zusammen und freenet war zufrieden und nimmt nun Mails von uns entgegen.

Jetzt verstanden?

[Quetschi]

Hmmm - eben nochmal ein paar Sendeversuche sehr kurz hintereinander gestartet:

Die ersten 3 wurden abgelehnt, weitere 3 gingen dann anstandslos raus - sorry, das ist mir zu hoch

[Quetschi]

@lennart

sorry, dein Post war mir gar nicht aufgefallen

Die Absender-Adresse die ich beim Verschicken benutze ist natürlich bei uns eingerichtet.

Diese Fehlermeldung

Die folgende Absenderadresse ist nicht korrekt: info@unsereDomain.de

wird scheinbar fälschlicher Weise von der phpMailer-Klasse selbst produziert und gibt nicht wirklich immer das zurück, was da an SMTP gesprochen wird.


@onemorenerd
Einen SPF hab ich nun für unsere Absender-Domain eingerichtet

v=spf1 ip4:xxx.xxx.xxx.1 ip4:xxx.xxx.xxx.2 -all

wobei xxx.xxx.xxx.1 für unsere "innere" IP und xxx.xxx.xxx.2 für unsere äußere IP steht. Weitere IP's haben mit unserer Domain als Absender nichts zu verschicken. Der SPF sollte also so seinen Zweck erfüllen. Bis jetzt hat sich allerdings nicht wirklich was an der Situation geändert, allerdings sind die DNS-Einträge bei yahoo vielleicht noch gecached - also ist jetzt nochmal abwarten bis morgen angesagt.