[Postfixbuch-users] T-Online whitelisten -- die Argumente

Fr Sep 23 21:23:21 CEST 2011

Hi,

 > Was ist, wenn ich Webhosting-Kunde bin? Ich weiß nicht wie vertraut ihr
 > alle mit "shared hosting" seid, aber betrachten wir nur einmal ein
 > einfaches LAMP-Hosting: Es braucht nicht viel um ein PHP-Skript zu
 > schreiben, was via mail() eine Nachricht als
 > "bill.gates at microsoft.invalid" an "steve.jobs at apple.invalid" sendet. Was
 > passiert da? PHP ruft einen sendmail-Wrapper auf, welcher in der Regel
 > die Mail bei localhost einliefert. Der lokale Mailserver kümmert sich
 > dann um die Bearbeitung (das ist keine "Gefahr" die speziell von PHP
 > ausgeht - bevor hier jemand meint gegen PHP schimpfen zu müssen).
 >
 > Was wollt ihr gegen solche Nachrichten machen?

Monitoring betreiben (Queue auf Anzahl usw. überwachen), dann 
Skripte/Auftrag sperren, Kunden-Domains sperren...... E-Mails 
zurückhalten und nicht senden.
Da schafft ein Spamer keine 500 Mails!

 > Mir ist keine Lösung bekannt. Ich würde eigentlich nur dafür Sorgen,
 > dass Webserver nicht über das zentrale Mailsystem senden (damit fallen
 > wohl Checks wie "Darf ich als microsoft.invalid senden senden?" raus).
 > Wenn, dann erwischt es eben die IP eines shared Webservers...

Manche Provider senden z.B. alle Mails von den Webservern über spezielle 
SMTP-Server raus, wo nur diese Mails rausgehen und wo es z.B. harte 
Limitierungen pro IP/Sender/Auftrag/usw./ gibt.

 > Wie will man sich dagegen schützen? Das kann einem kleinen Hoster mit
 > einem Kunden passieren... oder eben T-Online mit Millionen von Kunden.

Sobald eine Beschwerde eingeht, ist der Kunde gesperrt und wird gekündigt.
Wenn die Spamer wissen, das man beim Provider xxxx einen Fake-Account 
anlegen kann und nach 4 Minuten schon wieder gesperrt ist, lassen die es 
irgendwann, da für die der Aufwand zu groß ist.

Allgemein zum Spamfilterung auf ausgehende Mails.
Die Kunden lassen ja auch die eingehenden Nachrichten prüfen, wo evtl. 
die Antwort 5 mal (gequotet) enthalten ist......
Zudem die heutige Technik fast nur noch mit Hashwerten arbeitet und 
keine Einsicht mehr nötig ist.
Wer es nicht mag, verschlüsselt seine Mails.

 > Und um es noch zu erwähnen:
 > In den Premium-Paketen der Telekom steckt dieses E-Mailpaket drinnen -
 > manch einer mag es auch extra gebucht haben. U.a. ist da ein tolles
 > Feature bei: Ein Relay-Host! Gegen 5€ im Monat kann ich bei der Telekom
 > - Authentifizierung erfolgt über den Anschluss - beliebige Mails
 > einwerfen und die Telekom stellt sie dann zu. Eine sehr nette Sache, die
 > ich bspw. schon seit Jahren legitim nutze (es gab Zeiten, wo noch nicht
 > jede Software die Mailbenachrichtigungen angeboten hat SMTP-Auth
 > konnte). Manch einer wird sagen, "Ein gefährliches Features"... aber ich
 > denke es ist nicht gefährlicher als reines SMTP-Auth über normale 
Accounts.

Full-Ack!
Die meisten Bots klauen sowieso die Login-Daten oder haben diese bereits 
abgephisht oder gebrute-forced (schöne Wörter^^).
Und senden oft Mails über andere (gehackte) Webserver, wo dann ein 
Skript per SMTP die Mails über den Account dann versendet. Somit kann 
der DSL-PC für andere Sachen wie Proxys verwendet werden und der 
Webserver schafft mehr Mails einzuliefern als der PC...

Ich hatte bei uns auch über ein Jahr gesagt, das wir einiges tun müssen 
und konnte vieles umsetzten, aber bei paar Punkten, lehnte die 
Geschäftsleitung ab, bis unsere Server gelistet waren und die Kunden mit 
Anwälten da standen. Da hab ich dann auch gesagt "ich habs euch ja gesagt".

Diesen Prozess macht gerade die Telekom durch.
Man darf halt "Spam/Hacking/Malware/Bots" nicht mehr als "naja, passiert 
mal" so gelassen hinnehmen, sondern muss aktiv dagegen vorgehen (aber 
ohne Vorratsdatenspeicherung usw.!).

Falls es bissle vom Thema abgekommen ist, sorry ;-)

mfg Spamer

Am 23.09.2011 20:45, schrieb Igor Sverkos:
> Hallo,
>
> worüber reden wir denn konkret? Um Hosting-Kunden. Aber Hosting ist
> nicht gleich Hosting - hier muss man differenzieren:
>
> Wenn ich einen eigenen Server habe (egal ob managed oder nicht), dann
> ist es ganz alleine meine Sache was ich mache. Wenn ich dann SPAM
> verursache, hat meine IP auf solchen Listen zu landen und *ich* habe das
> Problem. Die Telekom selber hat das nicht zu beeinträchtigen (vom
> normalen Abuse-Handling abgesehen). Denke hierüber sind wir uns alle
> einig - das Problem hat die Telekom aber auch nicht.
>
> Was ist, wenn ich Webhosting-Kunde bin? Ich weiß nicht wie vertraut ihr
> alle mit "shared hosting" seid, aber betrachten wir nur einmal ein
> einfaches LAMP-Hosting: Es braucht nicht viel um ein PHP-Skript zu
> schreiben, was via mail() eine Nachricht als
> "bill.gates at microsoft.invalid" an "steve.jobs at apple.invalid" sendet. Was
> passiert da? PHP ruft einen sendmail-Wrapper auf, welcher in der Regel
> die Mail bei localhost einliefert. Der lokale Mailserver kümmert sich
> dann um die Bearbeitung (das ist keine "Gefahr" die speziell von PHP
> ausgeht - bevor hier jemand meint gegen PHP schimpfen zu müssen).
>
> Was wollt ihr gegen solche Nachrichten machen?
>
> Selbst wenn der raussendende Mailserver weiß ob die Mail als
> microsoft.invalid gesendet werden darf - was im shared Hosting Bereich
> eher nicht der Fall sein dürfte - besteht das Problem: Diese Mail würde
> also evtl. zurück gehalten werden, aber wenn ein Absender gewählt wurde,
> für den der raussendende Mailserver auch verantwortlich ist...
>
> Klärt mich auf: Was würdet ihr hier machen?
>
> Mir ist keine Lösung bekannt. Ich würde eigentlich nur dafür Sorgen,
> dass Webserver nicht über das zentrale Mailsystem senden (damit fallen
> wohl Checks wie "Darf ich als microsoft.invalid senden senden?" raus).
> Wenn, dann erwischt es eben die IP eines shared Webservers...
>
> Aber es gibt noch ein anderes Problem, was ich bei euch nicht gelöst
> sehe: Jetzt habt ihr bspw. wie Driessen angesprochen hat ein aktives
> Monitoring. Ihr seht nun, dass euer Kunde tollerKunde123 dabei ist
> 10.000 Mails und mehr bei eurem Mailsystem einzuwerfen... also drückt
> ihr da auf Halt und fragt bei tollerKunde123 nach. Dieser wird euch nun
> bestätigen, dass er gerade so viele Nachrichten bewusst sendet und kein
> Virus am Werke ist. Jetzt hakt ihr auch noch nach:
>
> I: "Was sind das denn für Nachrichten?"
> K: "Angebote..."
>
> ...ihr werdet hellhörig:
>
> I: "Angebote? An wen senden sie die denn?
> K: "An meine Kunden...."
> I: "Wirklich ihre Kunden? Haben die solchen Mailings zugestimmt? Sie
>     wissen ja bestimmt, dass sie das nur dürfen, wenn..."
> K: "Na klar..."
>
> ...ihr lasst euch sogar etwas unterzeichnen, wo er es noch einmal bestätigt.
>
> Aber trotzdem passiert es: Euer Kunde hat euch verarscht (ob bewusst
> oder unbewusst ist egal). Selbst wenn tollerKunde123 von jedem Empfänger
> ein notariell beglaubigtes Dokument vorlegen kann, wo dieses Mailing
> explizit angefordert wurde... es reicht heute doch, wenn genug Empfänger
> bei ihrem Provider die Mail als SPAM gemeldet haben (was einfacher ist,
> als sich aus Mailings auszutragen), was zur Folge hatte, dass mehrere
> Provider Abuse-Meldungen versendet haben... in letzter Konsequenz mit
> der Folge, dass die Mail jetzt von vielen Systemen als "unerwünscht"
> betrachtet wird und euer Mailsystem als Versender auf die ersten Listen
> kommt.
>
> Wie will man sich dagegen schützen? Das kann einem kleinen Hoster mit
> einem Kunden passieren... oder eben T-Online mit Millionen von Kunden.
>
> Und wir sprechen hier noch nicht einmal von dem Fall, wo jemand über
> geknackte Accounts Phishing-Mails und Viren einwirft :)
>
>
> Und um es noch zu erwähnen:
> In den Premium-Paketen der Telekom steckt dieses E-Mailpaket drinnen -
> manch einer mag es auch extra gebucht haben. U.a. ist da ein tolles
> Feature bei: Ein Relay-Host! Gegen 5€ im Monat kann ich bei der Telekom
> - Authentifizierung erfolgt über den Anschluss - beliebige Mails
> einwerfen und die Telekom stellt sie dann zu. Eine sehr nette Sache, die
> ich bspw. schon seit Jahren legitim nutze (es gab Zeiten, wo noch nicht
> jede Software die Mailbenachrichtigungen angeboten hat SMTP-Auth
> konnte). Manch einer wird sagen, "Ein gefährliches Features"... aber ich
> denke es ist nicht gefährlicher als reines SMTP-Auth über normale Accounts.
>
>