nicht angemeldet
Moin!
Interessanter Lesestoff: http://www.faqs.org/faqs/de-net-abuse/email-header-faq/
Jap. Merci. Nicht ganz klar geworden ist mir, inwieweit der SMTP-Envelop eine Rolle spielt, und ob es für erwünschte Viel-Empfänger-Mails sinnvoller wäre, bei mit PHP generierten Mails die Funktion SMTP zu nutzen.
Das, was du an Headern präsentiert hast, ist allenfalls für die userbasierte Contentfilterung relevant, im Bayesfilter.
Serverseitige RFC-strenge Filterung orientiert sich nicht an den von dir angeführten Headern, denn die sind bereits Mailinhalt - und Mailinhalte filtern ist auf dem Server aufwendig, da man die Mail dazu komplett empfangen und dann analysieren müßte.
Relevant sind die im SMTP-Dialog VOR der Mailauslieferung ausgetauschten Informationen. Diese sind im Verhältnis zu den noch nicht übermittelten Mailnutzdaten klein und können mit verhältnismäßig geringem Aufwand analysiert und zum Filtern herangezogen werden.
Deinem verlinkten Artikel zufolge werden mittlerweile ja vermutlich Spamfilter eher auch Details auswerten, um "trusted Server" aus der Analyse der "Received:"-Einträge, auch wenn die ausgenommen dem letzten, eigenen ja gefälscht sein könnten, wenn der letzte, durchreichende Server nicht als "sicher" angesehen wird (wie zB. T-online oder GMX oder???).
Sowas tut nur der Bayes-Filter - wenn programmiert oder konfiguriert.
Kleines vor-Fazit: PHPs Mailfunktion ist genauso RFC-konform wie eine Mail via Thunderbird, und somit nicht (zwangsläufig) spamfilteraffiner.
Das liegt primär daran, dass das mail()-Kommando die Post an den internen Mailserver übergibt, der sich um das gesamte weitere Vorgehen kümmert. Also auch die korrekte SMTP-Kommunikation mit dem Zielserver kann.
Abgesehen davon ist es vermutlich sinnvoll, die Päckchen nicht zu groß zu schüren. Da man PHP ja nicht so schön schlafen schicken kann (oeder wird dann die max-execution-time nicht weiterberechnet) wäre vielleicht ein kleines Javascript möglich, dass den Server alle paar Minuten anschubbst, bis die Mail-Liste abgearbeitet ist?
Das ist ein ganz anderes Problem, welches ausschließlich auf der gewollt begrenzten Laufzeit beruht, die bei via HTTP aufgerufenen Skripten üblicherweise greift. Das ist ausschließlich ein Sicherheitsmechanismus, damit dumme PHP-Kiddies keine Endlosschleifen programmieren und damit den Providerrechner zum Stillstand bringen.
Auf der Kommandozeile gestartete PHP-Skripte haben diese Laufzeitbegrenzung nicht - und auch vom Apache gestartete Skripte müssen keine maximale Laufzeit haben - allerdings wirken hier noch andere Komponenten mit, die evtl. in ein Timeout laufen könnten, wenn zu lange "nix" passiert, deshalb wäre ich bei langlaufenden Skripten via HTTP immer skeptisch.
- Sven Rautenberg
"Love your nation - respect the others."