Newsletterversand mit phpmailer

[Quetschi]

BTW:

SMTP mit KeepAlive schneidet heute deutlich besser ab als SMTP ohne KeepAlive - warum gestern die Unterschiede kaum ins Gewicht gefallen sind und heute die Geschichte mit KeepAlive in etwa doppelt so schnell abgearbeitet wird wundert mich zwar aber insgesamt scheint das doch die deutlich bessere Wahl zu sein.

Ist aber auch irgendwie klar - wenn ich mir vorstelle, mein Postbote würde für jeden Brief einzeln klingeln, ich mach die Tür auf, sag Hallo, nehm den Brief, sag Servus, schlag ihm die Tür wieder zu und beim nächsten Brief gehts von vorne los...

EDIT:
Dumm nur, dass ich gar keine Briefe kriege - nur Rechnungen

[onemorenerd]

Original geschrieben von Quetschi
Hmm - also ich hab 2 verschiedene "Fehlerquellen" mal eben getestet

- einmal eine eMail-Adresse, bei der zwar die Domain existiert, aber nicht der Alias
- einmal eine eMail-Adresse, bei der schon die Domain gar nicht existiert

In beiden Fällen bekomm ich beim versenden erstmal ein '250 2.1.5 ... Recipient ok'

Von wem kommt denn das OK für eine nicht existierende Domain? Wenn sie nicht existiert, kann es auch keinen MX dafür geben. Mit wem sprichst du also SMTP, um diese Mail loszuwerden?

[Quetschi]

Moment - vielleicht begreif ich jetzt grad was - ich verschicke diese Mails über unseren SMTP...

... sollte ich stattdessen erst den MX für die Empfänger-Domain ermitteln und direkt die Socketverbindung zu dem aufbauen?

[onemorenerd]

Achso! Darauf bin ich gar nicht gekommen.
Das wirft ein ganz anderes Licht auf deine Zeitmessungen. Du weißt jetzt, wie schnell du deinen SMTP-Server zustopfen kannst, aber nicht, ob er die Mails auch schnell genug wegschickt. Und meine Argumentation da oben trifft nicht zu, denn ich bin davon ausgegangen, dass du direkt mit fremden MXs sprichst.

[Quetschi]

Aja - jetzt bekomm ich natürlich gesagt, ob's den User gibt oder nicht.

Und mit getmxrr(); kriegt man vorab raus, ob die Domain da ist und ein MX-Record da ist.

Jetzt hab ich wieder ein bisschen was geschnallt

[Quetschi]

Ok - jetzt komm ich langsam auf den richtigen Weg denke ich.

Zuerst die Adressen nach Empfänger-Domain gruppieren, MX-Record ermitteln, danach in einer Session alle Adressen einer Domain beschicken, Session beenden und weiter zur nächsten Domain.


Ein interessanter Fall ergibt sich für uns noch mit unseren Kunden:

Wir betreiben 6 Server auf denen wir in etwa 1000 Kunden hosten. Für jede Domain gibts nen MX-Record mail.domain.de - also 1000 unterschiedliche MX-Records obwohl letztlich nur 6 reale Maschinen mit einer IP dahinterstehen - in dem Fall wäre es vielleicht noch sinnvoll etwas anders vorzugehen - also den A-Record für den MX-Eintrag direkt in die IP aufzulösen und nach IP gruppieren und hier wieder alle auf der gleichen IP in einer Session beschicken. In dem Fall könnt ich die IP des Emfpänger SMTP direkt zuordnen (in der DB) - wenn sich hier was ändert weiß ich es ja und kann entsprechend reagieren.
Lieg ich hier richtig?


Aber ich denke die Unterhaltung mit dir hier hat mich inzwischen auf alle Fälle ein gutes Stück weitergebracht

[onemorenerd]

Die Abonnenten des Newsletters sind alle eure Kunden, die Mails gehen also an die 1000 Domains, die ihr hostet? Das ist doch prima. Auf die Eigenheiten von 6 Mailserver kann man ein Script noch ausrichten. Wahrscheinlich läuft sogar auf allen 6 Maschinen die selbe Software mit gleicher Konfiguration. Dann kannst du perfekt optimieren.

in dem Fall wäre es vielleicht noch sinnvoll etwas anders vorzugehen - also den A-Record für den MX-Eintrag direkt in die IP aufzulösen und nach IP gruppieren und hier wieder alle auf der gleichen IP in einer Session beschicken. In dem Fall könnt ich die IP des Emfpänger SMTP direkt zuordnen (in der DB) - wenn sich hier was ändert weiß ich es ja und kann entsprechend reagieren.

Das habe ich überhaupt nicht verstanden, sorry.

[Quetschi]

Original geschrieben von onemorenerd
Das habe ich überhaupt nicht verstanden, sorry.

Folgendes:

kundendomain1.de - mx: mail.kundendomain1.de - IP 1.1.1.1
kundendomain2.de - mx: mail.kundendomain2.de - IP 1.1.1.2
kundendomain3.de - mx: mail.kundendomain3.de - IP 1.1.1.3
kundendomain4.de - mx: mail.kundendomain4.de - IP 1.1.1.1
kundendomain5.de - mx: mail.kundendomain5.de - IP 1.1.1.2
kundendomain6.de - mx: mail.kundendomain6.de - IP 1.1.1.3

kundendomain1.de und kundendomain4.de liegen also auf dem gleichen Server - haben jedoch eigene MX-Records. Wenn ich nun jedoch die SMTP-Session nicht mit dem mx-Record öffne sondern direkt mit der IP, brauch ich nur einmal eine SMTP-Session bei 1.1.1.1 öffnen und einfach alle Kunden, die auf dieser IP bzw. dieser Maschine gehostet sind beschicken.

Jetzt verstanden was ich meine?

[onemorenerd]

Jetzt hab ich es kapiert. Und ja, durch die Gruppierung nach IP sparst du nochmal einige Connects - 3 in deinem Beispiel von eben.

Hoffen wir, dass die Sortierung nach IP nicht länger dauert, als diese 3 Connects.

Und bedenke: Wenn du MX A, dann MX B ... und dann erst wieder A beschickst, kann A in der Zwischenzeit etwas aufatmen. Besser für die Kundenzufriedenheit.

[Quetschi]

Ich weiß ja wer auf welcher IP liegt - drum meinte ich, dass ich die IP direkt in der DB lagern kann - das Gruppieren in der DB wird dann hoffentlich ned so lang dauern - aber die Geschichte mit unseren Kunden ist jetzt gar ned so vordergründig - war nur so ein Gedanke wie man hier theoretisch noch optimieren könnte.

[Quetschi]

Original geschrieben von onemorenerd
Es kann auch einen spürbaren Unterschied machen, wenn man alle Abonnenten eines Providers wie GMX in einem Rutsch beschickt. Auf diese Weise sind weniger SMTP handshakes nötig.

Wie gruppierst du da eigentlich? Ich überlege gerade die eMail-Adressen nach Alias und Host aufzusplitten und getrennt in der DB abzulegen um beim Abfragen ganz simpel danach zu gruppieren können.

Wie machst du das? Hab ich nen Denkfehler? Bei den Hosts könnte man dann wegen der Häufigkeit bestimmter Hosts (t-online.de, gmx.de, web.de, freenet.de usw...) wieder nochmal weiter "runternormalisieren" - ob das dann noch sein muss?

[onemorenerd]

Ich speichere von jeder Mailadresse den Teil nach dem @ in einer separaten Spalte und zwar rückwärts, damit ich beim SELECT einfach alphabetisch sortieren kann.
So sind automatisch alle Adressen eines Provides hintereinander.

SELECT ... FROM subscriber ... ORDER BY domain_rev ASC, id ASC

ed.bew
ed.xmg
ed.xmg
ed.liameerf
moc.liamtoh
moc.liamtoh
ten.xmg

Diese Methode ist nicht perfekt. Beispiel: gmx.net und gmx.de liegen nicht beeinander, haben aber den selben MX, könnten also in einem Rutsch beschickt werden.
Man könnte beim Eintragen eines Abonnenten den MX nachschlagen und in einer weiteren Spalte speichern, die man dann im ORDER BY mitbenutzt.
Dadurch könnte man sich auch die DNS-Lookups beim Versenden sparen ... eine geeignete Fehlerbehandlung vorausgesetzt.

[Quetschi]

Das gleiche hab ich auch vor - aber warum rückwärts? das hab ich jetzt nicht ganz verstanden?

Ist das nicht egal ob beim Abfragen dann:

gmx.com
gmx.com
gmx.de
gmx.de
web.de
web.de
web.de

kommt?

Klar bleiben immer noch ein paar über die den gleichen MX hätten und man sich nochmal den Handshake sparen könnte - aber da wird man langsam päpstlicher als der... - drum ging mein Gedanke zunächst sogar nochmal soweit in dieser Spalte nochmal eine Normalisierung vorzunehmen:

Tabelle eMailAdressen
ID - eMailAlias - eMailHostID

Tabelle eMailHosts
ID - HostName - MX-Record

Beim Versenden müsste dann die Tabelle eMailHosts erst mit den MX-Records aktuallisiert werden, danach könnte man nach den MX-Records sortiert ausgegeben und bei nem Gruppenwechsel eben alte Session zumachen und neue aufmachen. Aber ob das noch lohnt?

Ich begreif aber den Zweck deines "Rückwärts-speicherns" noch nicht ganz - du hast dann halt alles nach TLD's beginnend sortiert - aber wo liegt da der Vorteil?

[onemorenerd]

Ich speichere rückwärts, weil das der Hierarchie eines Domain Names entspricht. Es geht mir dabei nicht darum, alle Domains einer TLD hintereinander zu haben. Abschneiden und weglassen kann ich die TLD aber auch nicht, weil web.com nun mal nicht das selbe ist wie web.de.
Mit Hierarchie meine ich, dass jeder Teil eines Domain Name wie foo.example.com von spezifisch nach allgemein geht. Rückwärts gelesen gehts von allgemein nach spezifisch. Warum das wichtig ist, siehst du an folgendem Beispiel:

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

Wenn du es vorwärts speicherst, bekommst du die beiden uni-muenster-Domains nicht zusammen. Rückwärts gespeichert bekommst du

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

Es sind also nicht nur die TLDs gruppiert, sondern innerhalb solcher TLD-Gruppen auch die Domains und darin wiederum die Subdomains usw.

[Quetschi]

Hmm - bringt dir aber nur was, wenn egora.uni-muenster.de und wiwi.uni-muenster.de den gleichen MX haben - es könnten theoretisch ja auch hier wieder eigene MX eingetragen sein.

An deiner Stelle hätt ich aber einfach am Punkt (.) gesplittet und das Array rückwärts zusammengesetzt gespeichert - also so:

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

das wär wenigstens noch lesbar, was nicht so schlecht ist, wenn man mal eben schnell "händisch" einen DS editieren möchte - vielleicht nur mal so als Tipp für dich