nicht angemeldet
Moin!
Mercury local sendet dann per SMTP an den mail.example.com? Bzw. senden ist ja wohl immer SMTP. Aber gibts einen Unterschied zwischen Client-an-Server oder Script-an-Server(das ja auf jeden Fall) und Server-to-Server? Im Protokoll?
Nein, es gibt keinen Unterschied im Protokoll. Alles ist immer "SMTP via TCP".
Die Angst vor der mail()-Funktion ist erstmal unbegründet. Diese ist eine sehr gute Möglichkeit, Mails einem queuenden, standardkonformen Mail-Transfer-Agent zur Auslieferung zu übergeben.
Skripte, die direkt ausliefern wollen (egal ob selbst mit fsockopen(), oder mit Klassen), müssen aufwendig gestaltet sein, um sich wie ein kompletter SMTP-MTA zu verhalten.
Natürlich ist das Thema "Spamfilter" ein Problem beim Mailversand. Aber gerade weil Spamfilterei höchst individuell passiert (nur als ein Aspekt: bedenke, dass der Erfolg von Bayes-Filtern darauf beruht, dass die Wortwahl in Ham-Mails des einzelnen Benutzers sich von der in Spam-Mails erkennbar unterscheidet - jeder Benutzer hat also ein anderes Ham- und Spam-Profil), ist es beim Mailversand fast unmöglich, auf jeden denkbaren individuellen Aspekt exakt einzugehen.
Selbstverständlich muß man sich mit den verfügbaren und deshalb real anzutreffenden Techniken beschäftigen und seine Infrastruktur danach ausrichten:
1. Greylisting darf einen nicht aus der Bahn werfen. Eine Mailqueue ist deshalb unerläßlich, Mails können prinzipiell nie direkt und ohne Warteschlange per Skript verschickt werden, wenn temporäre SMTP-Fehler den Versand insgesamt scheitern lassen.
2. Wenn die Mailabsender-Domain Dinge wie SPF oder DomainKeys nutzt, muß man sich natürlich an die daraus resultierenden Vorgaben halten, oder diese öffentlichen Angaben so korrigieren, dass sie den Massenmailserver mit einschließen.
3. Die bis aufs Komma exakte Implementierung des SMTP- und Mime-Standards ist unerläßlich. Spambots sind glücklicherweise oft nachlässig programmiert und eröffnen deshalb eine Filtermöglichkeit, in der man selbst lieber nicht hängenbleiben sollte. Gerade dieser letzte Punkt führt oft zu Empfangsproblemen, weil die Inhaltsfilter wie Spamcop einfach keine Freestyle-Mails mögen, die nur mit halber Kenntnis der RFCs zusammengefummelt werden.
Zunächst machtlos ist man allerdings gegen "gegnerische" Filter, die Dinge wie "Anzahl pro Zeit versendeter Mails" registrieren und dann dichtmachen, oder bei Nutzern von Blacklists fragwürdiger Qualität. Das ist allerdings eher ein Problem der Empfänger bzw. deren Verhältnis zum Mailadmin. Wer sich legitime Mails z.B. eines bestellten Newsletters wegfiltern läßt (u.U. ohne Kenntnis), weil der Mailadmin merkwürdige Ansichten über Spamfilterung hat, der hat's nicht anders verdient. Wer seinen selbstgepflegten, strengen Spamfilter nicht auf Durchlass für den Newsletter stellt, hat ebenfalls selbst Schuld. Je nach SMTP-Antwort des Mailservers sollten solche Zieladressen nach einigen final scheiternden Versuchen lieber aus der Datenbank gelöscht werden, weil sie nur Rechenzeit verschwenden.
- Sven Rautenberg
"Love your nation - respect the others."