nicht angemeldet
kennt jmd "letterit" - oder sonst Rat zu Verteiler-Form-Mailer
Hellihello
kennt jemand http://letterit.de? Gibt es Erfahrungen. Ratschläge für oder gegen solch eine netzwerkinterne Mailverteiler-Datenbank-Sharing-Geschichte inklusive der Möglichkeiten, des per Online-Forumlar-Versendens (möglichst häppchenweise 200-300 Stück). Kommaseparierte Ausgabe fürs Copy/Paste in den User-Mail-Client wäre natürlich auch brauchbar.
Und, die Diskussion gab es schon, landen denn aus solch einem Form-Mailer mehr Mails im Spam-Catcher des Gegenübers?
Und wie handlet "man" am besten die Auspflege durch
a) aktives Austragen durch einen Empfänger
b) Austragen wegen nicht mehr existenter Mailadresse?
Dank und Gruß,
-
Ich habe da mal einen relativ interessanten Thread gelesen. Ich glaube das war bei abakus-internet-marketing, könnte zwei Jahre her sein.
-
Hellihello Texter mit x,
merci für die Antwort.
Ich habe da mal einen relativ interessanten Thread gelesen. Ich glaube das war bei abakus-internet-marketing, könnte zwei Jahre her sein.
Ich habe den Eindruck, dass gerade jetzt spamvermeidetechnisch einiges in der Mache ist bei den Providern, und zwar bei allen. Und dass die Situation kaum vergleichbar ist mit der vor 24 Monaten.
Was die Erleichterung der Wartung durch Auspflege von Mailadressen angeht, mag sich vielleicht nicht soviel getan haben. Wobei sich viele Softwar ja immer noch recht stetig weiterentwickelt.
Dank und Gruß,
-
Moin!
Ich habe da mal einen relativ interessanten Thread gelesen. Ich glaube das war bei abakus-internet-marketing, könnte zwei Jahre her sein.
Ich habe den Eindruck, dass gerade jetzt spamvermeidetechnisch einiges in der Mache ist bei den Providern, und zwar bei allen. Und dass die Situation kaum vergleichbar ist mit der vor 24 Monaten.
Gewisse Mechanismen arbeiten heute noch so gut, wie vor zwei Jahren.
Genauer betrachtet hat sich zumindest an _meinen_ Spamfilter-Vorkehrungen (auch bei SELFHTML) in den letzten Jahren eigentlich gar nichts verändert - aber erzähls bitte nicht weiter.
Der Klassiker ist immer noch strenge Kontrolle der Einhaltung der RFC, dann eine IP-basierte Blacklist, zusammen mit Greylisting. Was jeder einzelne User noch praktiziert (Bayes-Filterung), entzieht sich für alle User außer mir meiner Kenntnis - aber Thunderbird liefert ja brauchbare Mechanismen direkt mit, was die jedoch filtern, ist individuell verschieden.
Google verliert gerade zunehmend seine Reputation, weil die es nicht in den Griff kriegen, maschinelle Accountanmeldungen und Spamläufe in ihrem Mailsystem zu verhindern.
Unter dem Strich bleibt: Die Anforderung an legitime Massenmailings sind eigentlich durch jeden vernünftigen Mailserver, der auch für Einzelmails genutzt werden kann, erfüllt. Im Einzelfall kann natürlich die Masse der Mails einen Spamfilter triggern - das erfordert dann manuelles Nachfassen beim Admin des Empfängerservers, damit man ggf. in eine Whitelist eingefügt wird.
Was die Erleichterung der Wartung durch Auspflege von Mailadressen angeht, mag sich vielleicht nicht soviel getan haben. Wobei sich viele Softwar ja immer noch recht stetig weiterentwickelt.
Ich hab zuwenig Kontakt mit derartiger Software, als dass ich abschätzen könnte, was da derzeit funktioniert, und was nicht. Das Auswerten von Rückläufern ist eine Kunst für sich, da es tausend Gründe geben kann, warum eine Mail unzustellbar ist, die aber nicht dazu führen sollen, dass die Mailadresse direkt gekickt werden soll. Vermutlich ist dieser Punkt deshalb bei vielen Programmen einfach ausgespart worden.
Vermutlich ist manuelles Nachbearbeiten einfacher - zumindest aus Sicht der Programmierer solcher Software. ;)
- Sven Rautenberg
--
"Love your nation - respect the others."-
Hellihello Sven,
Ich habe da mal einen relativ interessanten Thread gelesen. Ich glaube das war bei abakus-internet-marketing, könnte zwei Jahre her sein.
Ich habe den Eindruck, dass gerade jetzt spamvermeidetechnisch einiges in der Mache ist bei den Providern, und zwar bei allen. Und dass die Situation kaum vergleichbar ist mit der vor 24 Monaten.
Gewisse Mechanismen arbeiten heute noch so gut, wie vor zwei Jahren.
Gut zu wissen, aber: den Artikel find ich trotzdem nicht (;-).
Dank und Gruß,
-
Kein Artikel ein Thread. Der an den ich mich erinnert habe war der hier: http://www.abakus-internet-marketing.de/foren/viewtopic.php?t=22475
Es gibt aber noch mehr.
-
-
Hellihello
Der Klassiker ist immer noch strenge Kontrolle der Einhaltung der RFC
Das will heißen: die versandte Mail sollte eben strict RFC-konform sein.
Ich habe mal die Mail-Header einer Thunderbird-Testmail und einer durch eine PEAR-Klasse generierte mail, die auf PHPs mail()-Funktion basiert (ohne SMTP) versucht zu vergleichen.
Unterschiede unter anderem:
TB : X-Envelope-From: robert@example.de
PHP: X-Envelope-From: postmaster+140757@post.webmailer.de??? was sagt mir das?
TB : X-RZG-FWD-BY: test@example.de
PHP: nischt...???
Die "Received" Zeilen unterscheiden sich auch dem Inhalt nach, zudem sind
X-RZG-CLASS-ID, Message-ID, Date, From, To und Subject nicht in der selben Reihenfolge.
Klar, dass beim TB eine Zeile "User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)", die es bei PHPs erweiterter Mail-Funktion nicht gibt.
Das alles irgendwie relevant oder im Rahmen von zulässigen Variationen, also RFC-konform?
Falls es jemand interessiert hier die kompletten Header der beiden Versionen. Die Leerzeilen habe ich zu besseren Vergleich dort eingefügt, wo in der jeweils anderen Mail was anderes steht:
Thunderbird-Mail:
************************************
X-Envelope-From: robert@example.de
X-Envelope-To: mail@example.de
X-Delivery-Time: 1218279453
X-UID: 24887
Return-Path: robert@example.de
X-RZG-FWD-BY: test@example.de
Received: from localhost (client mail forwarder)
by mailin.webmailer.de (lemon mi62) (RZmta 16.48)
for mail@example.de; Sat, 9 Aug 2008 12:57:33 +0200 (MEST)Received: from mo-p05-ob.rzone.de ([81.169.146.180])
by mailin.webmailer.de (lemon mi62) (RZmta 16.48)
with ESMTP id e0080ak79AkNOJ for test@example.de;
Sat, 9 Aug 2008 12:57:33 +0200 (MEST)
(envelope-from: robert@example.de)
X-RZG-CLASS-ID: mo05
X-RZG-AUTH: :IW0NeWC7euopovfTnZlF0t7UXMdLXMUcLvzfy+rhg9GlU0MFgH+wwU7EgrjDxIc=
Received: from [192.168.178.36]
(brln-4db95147.pool.einsundeins.de [77.185.81.71])
by post.webmailer.de (mrclete mo12) (RZmta 16.47)
with ESMTP id N064dbk799jn7u ; Sat, 9 Aug 2008 12:57:32 +0200 (MEST)
(envelope-from: robert@example.de)
Message-ID: 489D781E.5030702@example.de
Date: Sat, 09 Aug 2008 12:57:34 +0200
From: "R. example/example.de" robert@example.de
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: test@example.de
Subject: testBetreff
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
...************************************
X-Envelope-From: postmaster+140757@post.webmailer.de
X-Envelope-To: test@example.de
X-Delivery-Time: 1217773893
X-UID: 2342
Return-Path: postmaster+140757@post.webmailer.deReceived: from cg-p00-ob.rzone.de ([81.169.146.193])
by mailin.webmailer.de (plinge mi44) (RZmta 16.48)
with ESMTP id m045e2k73ERLmT for test@example.de;
Sun, 3 Aug 2008 16:31:33 +0200 (MEST)
(envelope-from: postmaster+140757@post.webmailer.de)
X-RZG-CLASS-ID: cg00
Received: from sharron.store ([192.168.40.139])
by bjorn-cg-04.store (RZmta 16.42) with ESMTP id 004f0fk73EHnXY ;
Sun, 3 Aug 2008 16:31:33 +0200 (MEST)
(envelope-from: postmaster+140757@post.webmailer.de)Received: (from Unknown UID 140757@localhost)
by post.webmailer.de (8.13.7/8.13.7) id m73EVXcj028487;
Sun, 3 Aug 2008 14:31:33 GMTDate: Sun, 3 Aug 2008 14:31:33 GMT
Message-Id: 200808031431.m73EVXcj028487@post.webmailer.deTo: test@example.de
Subject: example.de test
MIME-Version: 1.0
From: test@example.de
Content-Type: ...************************************
Dank und Gruß,
-
Hallo Robert,
Der Klassiker ist immer noch strenge Kontrolle der Einhaltung der RFC
Die "Received" Zeilen unterscheiden sich auch dem Inhalt nach, zudem sind
X-RZG-CLASS-ID, Message-ID, Date, From, To und Subject nicht in der selben Reihenfolge.ich zitiere aus RFC2822:
3.6 Field Definitions
[...]
It is important to note that the header fields are not guaranteed to
be in a particular order. They may appear in any order,[...]
The only required header fields are the origination date field and
the originator address field(s). All other header fields are
syntactically optional.jetzt sollte Dir schon einiges klarer erscheinen
Die x-Header sind sowieso proprietär, auch wenn es einige von vielen Mail-Clients unterstützte gibt.Interessanter Lesestoff: http://www.faqs.org/faqs/de-net-abuse/email-header-faq/
Freundliche Grüße
Vinzenz
-
Hellihello Vinzenz,
jetzt sollte Dir schon einiges klarer erscheinen
jau.
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.
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???).
Kleines vor-Fazit: PHPs Mailfunktion ist genauso RFC-konform wie eine Mail via Thunderbird, und somit nicht (zwangsläufig) spamfilteraffiner.
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?
Dank und Gruß,
Robert aka
-
Hallo Robert,
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)
man kann es schlafen schicken, siehe z.B. Archiv :-)
wäre vielleicht ein kleines Javascript möglich, dass den Server alle paar Minuten anschubbst, bis die Mail-Liste abgearbeitet ist?
Das kannst Du nicht ernst meinen. Solch eine Krücke baut man sich nicht. Wenn schon, dann cron-Job. Hinweise, wie über einen solchen cron-job ein großes Mailing paketweise abgehandelt werden kann, findest Du übrigens ebenfalls im Archiv.
Freundliche Grüße
Vinzenz
-
Hellihello Vinzenz,
Hallo Robert,
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)
man kann es schlafen schicken, siehe z.B. Archiv :-)
Dann doch. Das erübrigt aber dann den cron-job, oder?
wäre vielleicht ein kleines Javascript möglich, dass den Server alle paar Minuten anschubbst, bis die Mail-Liste abgearbeitet ist?
Das kannst Du nicht ernst meinen. Solch eine Krücke baut man sich nicht. Wenn schon, dann cron-Job. Hinweise, wie über einen solchen cron-job ein großes Mailing paketweise abgehandelt werden kann, findest Du übrigens ebenfalls im Archiv.
Einen cron-job kann ich aber nur mit shell_exec() und somit safe_mode = off anstoßen? Ich weiß, dass der safe_mode abgeschafft werden soll, weiß aber nicht, welche Sicherheitslücken ich im Zweifel aufreissen würde, wenn ich ihn anstelle. Oder könnte ich mit der Directory-Direktive den safe_mode für den vhost und allein den einen Unterornder aktivieren?
Oder wäre ein shell-script im cgi-bin "besser"?
Robert aka
Dank und Gruß,
-
Hallo Robert,
Einen cron-job kann ich aber nur mit shell_exec() und somit safe_mode = off anstoßen? Ich weiß, dass der safe_mode abgeschafft werden soll, weiß aber nicht, welche Sicherheitslücken ich im Zweifel aufreissen würde, wenn ich ihn anstelle. Oder könnte ich mit der Directory-Direktive den safe_mode für den vhost und allein den einen Unterornder aktivieren?
keine Ahnung, vom Safe Mode habe ich glücklicherweise immer erfolgreich Abstand halten können :-) Einen cron-job richte ich am liebsten über die Konsole ein und cron-jobs nutzen bei mir höchst selten[*] PHP.
Freundliche Grüße
Vinzenz
[*] Wenn ich's mir richtig überlege, bisher noch nie ...
-
-
-
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."-
Hellihello Sven,
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.
O.k., gut zu wissen, das wird in dem von Vinzenz verlinkten Artikel auch beschrieben. Ich hatte das erstmal überflogen, weil das ja eh nicht beeinflussbar ist, zumindest nicht unmittelbar im Skript:
"Eine E-Mail besteht aus mehreren Teilen. Wenn man den Vergleich mit
einem konventionellen Brief suchen möchte, könnte man sagen, es gibt
einen Umschlag (den sog. "SMTP-Envelope"), einen Briefkopf (den sog.
"Header" oder die "Kopfzeilen") und den eigentlichen Brieftext oder
-inhalt (den sog. Body)." ... (aus o. verlinkter Quelle).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.
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.
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.
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.
Dank und Gruß,
-
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."
-
-
-
-
-
-
-
-