maceis schrieb:
Würdest Du den gleichen Maßstab an die Mailclients und/oder Betriebssysteme Deiner Kunden stellen, dann müsstest Du Den Einsatz von Outlook Express und Windows in Euren AGB ebenfalls verbieten.
Du weisst selbst, dass das nicht in unseren Kompetenzbereich gehört… und dass diese Maßnahme auch nur flächendeckend ausgeführt etwas bringen würde
Aber prinzipiell müsste M$ (und andere Anbieter von entsprechend nachlässig konzipierter Software) hier zur Rechenschaft gezogen werden! Da würde ich Dir komplett recht geben!
Wir empfehlen übrigens unseren Kunden generell Thunderbird/Firefox bzw. die Mozilla Suite und machen Ihnen dieses schmackhaft, indem wir Ihnen anbieten, dass Sie uns bei Verwendung dieser Clients unter unserer kostenlosen 0800 Supportnummer Step-By-Step eine Installations-/Konfigurationsanleitung bekommen.
Apple User haben wir nur einen Kunden… und der Sack muss ausgerechnet Entourage benutzen
maceis schrieb:
Woher die Virenflut kommt ist schließlich auch hinreichend "empirisch nachgewiesen".
Naklar. Deswegen, wie gesagt, die Softwarehersteller mehr in die Pflicht nehmen, Spammer härter bestrafen bzw. zumindest versuchen intensiver zu verfolgen… gegen Provider wird ja schon rechtlich vorgegangen (mittlerweile macht man sich mit einem OpenRelay unter Umständen strafbar… siehe o.g. BSI Studie).
maceis schrieb:
Abgesehen davon garantiert eine statische IP (die es ja bei Euch auch ohne TÜV gibt) ja nicht, dass ein selbst gemanagter Mailserver plötzlich keine potentielle Dreckschleuder mehr ist.
Gibt genügend Mailserver "mit TÜV", die absolut übel administriert werden.
Ok, das stimmt. Aber man kann halt eine statische IP relativ schnell blacklisten, den Admin ausfindig machen und entsprechende weitere Schritte gemäß eines Abuse-Scenarios einleiten.
Bei Dial-Up Hosts ist das doch kaum möglich… von daher haben statische IPs schon einen gewissen Vorteil bzw. sind gutmütiger als dyn. Ips zu behandeln.
maceis schrieb:
Mit dem Perl Skript meine ich einen selbstgeschriebenen Client, der problemlos beliebig viele Spam Mails in kurzer Zeit einliefern kann.
Ich hab jetzt nicht nachgesehen, aber ich bin mit ziemlich sicher, dass Net::SMTP AUTH beherrscht (was mich jetzt, wo ich drüber nachdenke, schon wieder auf den Gedanken bringt, dass ich so auch die emails meines privaten postfix bei meinem Provider einliefern kann
).
Ok, dann authentifizierst Du Dich ja auch als regulärer Kunde.
Dann ist es ja auch egal, von wo aus und wie Du deine Mails schickst…
Habe ich mich etwa da undeutlich ausgedrückt?
Dial-Up MTAs werden nur rejected, wenn Sie versuchen, ihnen zur Zustellung übermittelte Emails an uns zuzustellen.
Fungiert ein MTA aber (zweckentfremdet) als eine Art Client, der sich regulär authentifiziert, darf er seine Nachrichten abladen, die dann unseren Mailboxes natürlich zugestellt werden.
Möchte der MTA uns als SMTP Relay benutzen, muss er sich natürlich authentifizieren.
maceis schrieb:
Klar, dass man das dann zurückverfolgen kann - kann man beim lokal betriebenen Mailserver im Mißbrauchsfall ja ebenfalls.
Wesentlich schwerer! Bei einer statischen IP ist zunächst das Auswerten von verschiedenen Spamreports einfacher, da so verschiedene Vorfälle anhand derselben IP zusammengefasst werden können.
Dynamische IPs muss man, abhängig von Inhalt, erstmal als jeweils eigenständige Vorgänge ansehen.
Und die Herkunft statischer IPs und das Versenden von Abuse-Mails bzw. das Melden solcher Vorfälle ist so mit dyn. Ips nicht möglich.
maceis schrieb:
Dass keine Adressen oder Domains auf die Whitelist gesetzt werden sollten ist mir auch klar; bei den IP Adressen der eigenen Kunden (die sich ja beim "Einwählen" authentifizieren) seh' ich das aber schon als vertretbar an.
Woher wissen wir denn, wer unserer Kunden sich mit welcher IP im Internet bewegt? Das geht nur, wenn man Fullservice ISP wie z.B. 1&1 ist.
Da könnte man sagen, dass alle IPs aus dem Dial-Up Pool als vertrauenswürdig eingestuft werden.
maceis schrieb:
Mit dem reverse_lookup hast Du Recht; das geht nur mit dynDNS und entsprechendem $myorigin; das hatte ich ünersehen.
Ich dachte eigentlich, dass bisher nur China/HongKong die dynDomains generell aussperren
Wir sperren z.B. die Redirector-Service-Domains nicht generell… wir versuchen zumindest vorher unsere Gutmütigkeit zu beweisen, indem wir einen Reverselookup machen (der aber meistens in die Hose geht).
Schließlich soll es Admins geben, die auf z.B. DynDNS (oder einem anderen Redirector) eine FallOver Strategie bauen… Redirector Domains generell zu blocken halten ich daher für äußerst bedenklich.
Andererseits kann man natürlich sagen, dass es äußerst bedenklich ist, Fallover Strategien auf DynDNS aufzubauen (…was auch so ist
).
maceis schrieb:
Das machen die sicher; ist nur eine Frage der Bezahlung
.
In anderen Ländern ist es ja teilweise etwas einfacher (und billiger) an eine feste IP zu kommen. Aber was soll's.
maceis schrieb:
Ich werd doch tatsächlich mal ausprobieren, ob ich das hinbekomme, über ein Perlskript meine mails einzuliefern.
Denn wie Du sagst; meine aktuelle Lösung ist auch nicht dauerhaft verlässlich.
Nachdem der Postfix so herrlich modular aufgebaut ist, dürfte es auch nicht so schwer sein, so ein kleines "Weiterleitungsmodul" einzubinden.
Da müsste doch schon fast eine pipe in transport reichen *grübel*
Alles klar, berichte mal über Erfolg/Mißerfolg!