nicht angemeldet
Moin!
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.
Daraus schließe ich: für diese Mailfilterung ist es schlicht egeal, ob ich eine Mail mit 200 BCC-Empfängern per HTML-Forumlar=>PHP-Skript mit SMTP (!)verschicke, oder über einen Mailclient wir Thunderbird. Nutze ich im PHP-Skript die SMTP-Funktion, heißt das, ich kann kann die Mail auch über einen anderen Server verschicken, also nicht zwingend dem, auf dem das Skript läuft. Nutze ich nur die "normal" mail()-Funktion, wird eben der localhost-Mailserver benutzt. Was ja im Zweifel dann auch der Mailserver eines Massenabieters ist, wenn ich da mein Web-Paket habe.
"Die SMTP-Funktion" ist ja nichts, was in PHP direkt eingebaut ist - jedenfalls nicht zwingend. Windows-PHP muß, da unter Windows Mailserver nicht garantiert anzutreffen sind, ein Hilfskonstrukt mittels SMTP-Kommunikation zu einem zuständigen Mailserver aufbieten, um die mail()-Funktion dort ebenfalls anbieten zu können. Das trifft für Linux-PHP aber ja nicht zu, da ausnahmslos alle Linux-Systeme über einen mail-entgegennahmefähigen Systembestandteil verfügen. Das können so kastrierte Dinger wie "ssmtp" sein, die ihrerseits die Daten in Echtzeit und ohne Speicherung einfach nur an einen anderen Mailserver weiterreichen, oder halt ausgewachsene Mailserver wie Postfix, QMail oder Sendmail.
Welchem Mailserver du die Mail übergibst, kann allerdings Einfluß auf die Spamwertung haben - aber dies primär deswegen, weil manche Mailserver eben in der Vergangenheit schon unangenehm durch Spam aufgefallen sind. Mailserver von Massenhostern zählen potentiell häufiger dazu, als jene von kleinen Hostern, oder gar lokal vollständig funktionsfähige Einzelsysteme (also Webserver plus Mailserver ausschließlich für eine einzige Domain).
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.
Und da ist es dann wurscht, Hauptsache ich nutze einen korrekten Provider/Hoster, ob der jetzt 1und1, strato, t-online, gmx oder hosteurope heißt, dürfte dann wohl egal sein. Nicht egal vermutlich, wenn er irgendwo in virutellem Niemandsland beheimatet wäre.
Es ist so eine zweiseitige Medaille. Einerseits dürften die Mailserver der großen Provider deshalb, weil es große Provider sind, in den Whitelisten der anderen großen Provider stehen, zumindest aber dürfte schnell dafür gesorgt werden, dass eventuellen Blacklist-Einträgen nachgegangen wird.
Andererseits sind naturgemäß auf Mailservern mit hohem Traffic auch die Zahl ausgesendeter Spammails höher als Null, weil es definitiv keinen absoluten Schutz gegen idiotische Kunden gibt.
Kleine Mailserver mit überschaubarer Nutzerschaft werden hingegen vermutlich nie Spam aussenden - leiden aber mitunter unter schlechter Nachbarschaft. Wenn ein überreagierender Admin anstatt des einen spammenden VServer (als Beispiel) gleich das ganze /24-Netz auf die Blacklist setzt, in dem sich auch dein Mailserver befindet, hängst du unschuldig mit drin.
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.
Det ist mein Junk-Filter im Thunderbird u.a., oder? Der "lernfähig" ist und sich auch daran orientiert, was ich als Junk oder Nicht-Junk deklariere.
Richtig. Gerade die Angaben in den Received-Zeilen sind manchmal ziemlich typisch für Spam - sei es aufgrund des eintönigen Erfindungsreichtums der angeblichen Weiterleitungsstationen, oder weil tatsächlich gewisse wirklich genutzte Providernetze bei dir überdurchschnittlich oft durch Spam auffallen.
Das ist ein ganz anderes Problem, welches ausschließlich auf der gewollt begrenzten Laufzeit beruht, die bei via HTTP aufgerufenen Skripten üblicherweise greift.
Welche aber durch "sleep()" unterbrochen wird, wie ich mittlerweile mitbekommen habe.
Viele Wege führen nach Rom - unter dem Strich ist es egal, wie du den Default "begrenzte Laufzeit" umgehst.
- Sven Rautenberg
"Love your nation - respect the others."