Weist ihr outgoing ab wenn es Spam ist?

D

DarkFather

Member
Servus,

nachdem ich in der vergangenen Woche durch ein Absue von mail.ru als Spamversender geoutet wurde :eek: und herauskam, dass ein geknacktes Passwort von einem Kunden die Ursache war (also für mich keine Möglichkeit das zukünftig zu verhindern) habe ich meine Konfiguration nochmal verschärft und nehme Mails ab einem SA-Score von 8.0 nicht mehr an. Gelöst wurde das per ACL-Condition.

Das sind vier Zeilen Code, aber in keinem Tutorial habe ich sowas entdeckt.
Macht ihr das auch?
Wenn nein, warum nicht?

MfG
Rudi

P.S. Meine Konfiguration:
Debian Squeeze
Exim4, Spamassassin, MySQL, php-cli

Vexim und Roundcube sind auf einem anderen Server, so spare ich mir den apache und fühle mich bedeutend sicherer. Die Datenbank wird regelmäßig per cron vom Webserver geholt
 
Wir monitoren die Größe der Queue. Wenn die über einen bestimmten Wert geht, bekommen wir das schnell genug mit und können reagieren. Hatten wir in letzter Zeit zwei mal, dass da Spam mit gültigen User-Logins versendet wurde.
 
Auch eine gute Idee. Schadet sicher nicht, kostet auch nichts.
Vorallem einfach ins paniclog geschrieben das kommt eh per Mail wenn existent.

Welchen Wert setzt ihr dafür an? 20 hätte ich jetzt aus dem Bauch heraus gesagt.
 
DarkFather said:
....also für mich keine Möglichkeit das zukünftig zu verhindern
Click to expand...
Doch das geht, als erstes sollte man die Passwort Richtlinien verschärfen und
wenn möglich auch das Passwort ablaufen lassen.

Die Richtlinien geben vor wie komplex das Passwort sein muss und das Verfallsdatum schützt ein bisschen davor das alte oder Verwaiste Accounts unter den Tisch fallen.
Gerade in größeren Umgebungen kann das ein ganzes Stück die Sicherheit erhöhen.

Sven
 
Ersteres muss ich mal schauen. Das könnte man u.U. umsetzen.

Aber wenn mir ein Provider sagt mein Passwort ist abgelaufen dann lauf ich schneller weg als der schauen kann. Das halte ich für Gängelung. Vorallem weil die Kunden ihre Mailadressen einfach mitnehmen können.
Und was das für einen Supportaufwand gibt, wenn dauernd Kunden anrufen weil der MUA ihr Passwort nicht mehr annimmt. Die meisten sind halt doch DAUs :mad:
 
Zumindest bei Postfix gibt es noch Einstellungen, die limitieren wie viele Mails an wie viele verschiedene Empfänger ein Benutzer innerhalb von X Minuten senden darf.
(Stichwort: smtpd_client_message_rate_limit, smtpd_client_recipient_rate_limit).

Das hat zumindest bei uns in der Vergangenheit immer wieder geholfen eine Spam-Welle sehr klein zu halten, denn wenn der Benutzer über dieses Limit kommt kann er schlicht und ergreifend keine Mails mehr versenden.
Zusätzlich prüfen wir ausgehend grundsätzlich auch immer auf Viren (und lassen in diesem Fall auch an den echten Absender zurückbouncen), denn wegen Malware-Versand auf irgendwelchen Blacklisten zu stehen ist so ziemlich der Worst-Case.
 
Ich denke man sollte auch erwähnen, dass es stark abhängig davon ist, welche Art von Hosting man betreibt.
Die bisherigen Tipps sind bei (günstigem) Massenhosting akzeptabel.
Bei Business-Hosting ist hingegen jede Art von Reglementierung ein No-Go.
Insbesondere ein Löschen oder unterdrücken von Spam-Verdächtigen Emails ist in dieser Umgebung recht kritisch.

huschi.
 
DarkFather said:
Aber wenn mir ein Provider sagt mein Passwort ist abgelaufen dann lauf ich schneller weg als der schauen kann. Das halte ich für Gängelung. Vorallem weil die Kunden ihre Mailadressen einfach mitnehmen können.
Und was das für einen Supportaufwand gibt, wenn dauernd Kunden anrufen weil der MUA ihr Passwort nicht mehr annimmt. Die meisten sind halt doch DAUs :mad:
Click to expand...
Dem würde ich SOO nicht zustimmen. Wir Verwalten unsere Userdaten über LDAP und mit LDAP kann man da ein Ablaufdatum vorgeben. Diese Ablaufdatum kann man Rechtzeitig per Mail an Kunden weitergeben, bei uns geht das ziemlich gut, es gibt wenige die sich darüber beschweren oder das nicht auf die Reihe bekommen.

Außerdem läuft das Passwort ja nicht gleich nach einer Woche ab, ab so nach maximal 12 Monaten gehen da schon einige Mails durchs System. Meist reicht aber eine gute Passwort Richtlinie.

Sven
 
Huschi said:
Insbesondere ein Löschen oder unterdrücken von Spam-Verdächtigen Emails ist in dieser Umgebung recht kritisch.
Click to expand...

Gelöscht wird nichts, zumindest nicht sofort. Alle eingehenden Spams (Score 5) werden in den Spam-Ordner verschoben, alles was dort 30 Tage lag wird gelöscht. Abgewiesen, aber nicht unterdrückt, wird eine ausgehende Spam-Mail (Score 8). Das bekäme der Kunde direkt beim Versand mit, weil der MUA die Mail garnicht an den MTA übergibt, sondern eine Fehlermeldung (also keinen Returned to Sender!) ausgibt. Aber ich kann mir nicht vorstellen wie ein Kunde mit einer Mail den Score 8 erreichen sollte und bei welchem anderen Provider seine Mail nicht im Spam-Ordner landen würde. Aber wie gesagt, die Mail wird nicht einfach "verschluckt".

@ Sven:
Stellt ihr auch sicher, dass der Kunde nicht das gleiche Passwort wieder nutzt (auch der Umweg über neues PW zurück zum Alten)? Das mache ich nämlich in so einem Fall.

MfG
Rudi
 
Huschi said:
Die bisherigen Tipps sind bei (günstigem) Massenhosting akzeptabel. Bei Business-Hosting ist hingegen jede Art von Reglementierung ein No-Go.
Click to expand...
Wir reglementieren, dass pro Benutzer in einem Zeitfenster von fünf Minuten 4500 Mails mit insgesamt 450 Empfängern verschickt werden dürfen.
Das ist selbst für Firmen ziemlich hoch gegriffen und wird auch so ganz offen kommuniziert. Will ein Kunde mehr, dann bekommt er auch mehr.
In der Vergangenheit hat es aber gezeigt dass gerade diese Limitierungen geholfen haben die Queue vor dem Überlaufen und die IP vor der Blockade zu retten - eben weil man bei Überschreitung von 450 Mails (wenn 1 Mail = 1 Empfänger) schnell reagieren kann ohne dass sämtliche Blacklisten auf einen Aufmerksam werden. Und bisher hat es kein Kunde geschafft dieses Limit im Normalen Tagesgeschäft zu erreichen!

Für höheres Volumen (Newsletter, Massenbenachrichtigung...) haben die Kunden Zugriff auf ein speziell dafür optimiertes SMTP-Relay was dann nur noch die Anzahl paralleler Verbindungen limitiert - damit nicht ein Kunde das Dingen ganz für sich beanspruchen kann.
 
You must log in or register to reply here.
Back
Top