Schlagwort-Archiv: spam

Amavis/Spamassassin: Änderung der ixHash-Server

Bei dem Nachschauen einer Konfigurationseinstellung stieß ich auf die Nachricht, dass sich bereits vor einer Weile die Server des ixHash-Projektes geändert haben und dadurch die Hash-Abfragen bis zur Anpassung der Config nicht mehr funktionieren.

[…]

As mentioned a few weeks ago, the domains ‘nospam.login-solutions.de’
and ‘nospam.login-solutions.ag’ will reach EOL in the near future. They
are being replaced by the single DNS zone ‘generic.ixhash.net’

[…]

Auf der in der Mail (siehe Linklist) genannten URL gibt es eine aktualisierte Beispielkonfiguration für die ixhash.cf.

Links:

  • iXHash-Projektseite @ Sourceforge.net
  • Erklärung des Projektes auf der iX-Homepage
  • iXhash in Spamassassin einbinden
  • SpamAssassin-Mailinglist: Important info for iXhash users
  • Beispielkonfiguration für ixhash.cf (Spamassassin-Modul)
  • Anti-Spam-Blacklist ORDB ist am Ende

    Wer Spam bekämpft findet in Realtime-Blacklists ein gutes Hilfsmittel zum Aussperren bekannter Spamserver. Leider ist die Wirksamkeit nur so gut wie die Blacklist selbst. Die schon länger inaktive ORDB (Open Relay Database) wird noch immer von vielen Mailservern abgefragt und das obwohl sie schon längere Zeit keine Einträge mehr enthält.

    Um auch den letzten Mailserver-Admin davon zu überzeugen, dass die Liste nichts mehr bringt, haben sie die Betreiber dazu entschlossen, nun jede Anfrage als Hit zu beantworten. Die Folge: Mailserver, die keine Gewichtung in den Blacklists haben weisen jede Mail ab. Anwender von policyd und anderen erhalten zwar eine höhere Spamwahrscheinlichkeit, aber die Mails werden nicht grundsätzlich abgelehnt.

    Die Bitte der Betreiber und auch die logische Schlussfolgerung: Entfernt ordb.org aus Euren Mailservern – es hat keinen Nutzen!

    Die Standardconfig von policyd-weight enthält die ordb übrigens nicht.  Generell rate ich auch zu dem Einsatz eines gewichteten Blacklistings – mehr dazu in diesem älteren Beitrag.

    Artikel: Anti-Spam-Blacklist ORDB listet alles @ heise online

    Kommentarspam bekämpfen und helfen mit recaptcha.net

    Spam ist ein grundlegendes Problem mit dem sich jeder im öffentlichen Raum beschäftigen muss. Im Fall eines Blogs geht es dabei um Kommentarspam.

    Es gibt unterschiedliche Wege, gegen diese Störer vorzugehen. Eine ganze Zeit lang arbeitete ich zufrieden stellend mit WP-Gatekeeper.

    Zufällig stieß ich nun aber auf das Projekt recaptcha.net, welches sich zum Ziel gemacht hat, das Angenehme mit dem Nützlichen zu kombinieren. Die angezeigten Captchas ermöglichen, dass alte Bücher digitalisiert werden, wo bisher OCR nicht erfolgreich war. Mehr Infosdazu gibt es auf der Website. Dort gibt es auch fertige APIs zum Verstecken von Mailadressen u.a.

    Die netten Jungs (und Mädels?) von recaptcha haben auch gleich ein fertiges WordPress-Plugin im Angebot, was zusätzlich sogar noch eine alternative Audio-Challenge anbietet und damit der Barrierefreiheit wieder ein bißchen näher kommt.

    Wir werden das Plugin hier mal eine Weile laufen lassen und dann Bilanz über die Effektivität ziehen.

    Probleme und Meinungen können hier gern hinterlassen werden.

    MailZu – Userbasierte Spameinschätzung

    Über einen Hinweis in der Postfix-Maillingliste bin ich auf MailZu gestoßen.

    Es soll, wie es aussieht, einem User ermöglichen, eingegangene Mails selbst nachträglich einzuschätzen und so die Spamerkennung zu verbessern. Weiterhin wird so eine Nicht-Zustellung wegen hohem Spamverdacht (Spam-Kill-Level) vermieden. Im großen und ganzen arbeitet die Websoftware damit wie Maia Mailguard.

    Letzteres hatte ich bereits vor einiger Zeit ausprobiert, konnte es aber damals nicht fehlerfrei in meine Umgebung integrieren. Mit etwas Zeit werde ich die beiden Systeme nochmal genauer untersuchen und die Effizienzsteigerungen sowie Benutzerfreundlichkeit prüfen.

    Insofern ist dieser Post eher eine Erinnung an mich selbst und ein Grund zu fragen: Hat jemand bereits Erfahrungen mit einem der Systeme? 

    DNSBL database check

    Auf der Suche nach einer doofen Blacklist, die meinen Server eventuell doch gelistet hat und daher die mir berichteten Spam-Einschätzungen von ausgehenden Kundenmails zu erklären, stieß ich u.a. auf die DB-Suche von relays.osirusoft.com. Aber ich musste dann doch schmunzeln, als ich die diese Meldung bekam. (Siehe vor allem den Fettdruck).

    (127.0.0.2) 85.214.85.117 is DNSbl listed. by relays.osirusoft.com
    Relays.osirusoft.com has not had valid data in years
    Anyone using relays.osirusoft.com to stop spam must be intellectually challenged
    Please stop using relays.osirusoft.com

    Ich finde es recht mühseelig, die Infos den Datenbanken manuell zu entlocken. Habt ihr noch weitere Checks? Immer her damit!

    Link: DNSBL database check

    Hilferuf (für pimp my mailgraph)

    Hallo allerseits,

    nachdem meine persönlichen Kontakte in dieser Frage leider nicht helfen konnten nun die Frage an die Allgemeinheit, also DICH:

    Wenn Du einen Server mit Debian Etch betreibst und darauf Postfix mit dem amavisd-new Standard-Deb laufen hast, würde ich mich freuen, wenn Du mir mal einen Logauszug (mail.log) für folgende Fälle zusenden kannst:

    • Spam (Kill-Level)
    • Spam-Tag (Tag-Level)
    • Virus
    • Banned

    Die Einträge können selbstverständlich anonymisiert sein, denn es geht mir nur um die Syntax der Einträge.

    Hilferuf (für pimp my mailgraph) weiterlesen

    Neues Hobby: SPAM or NOT

    Nachdem ich noch einmal etwas in einem älteren Artikel auf adminlife.net nachsehen wollte, habe ich etwas gefunden, was ich beim ersten Lesen wohl übersehen hatte: SPAM or NOT

    Das Spiel ist ganz einfach: Man bekommt immer wieder Grafiken angezeigt und muss entscheiden, ob diese Spam oder Ham sind. Wenn man sich nicht sicher ist, kann man auch neutral entscheiden.

    Die gesammelten Userwertungen fließen dann in die Entscheidungen von MSRBL ein.

    Neben der Tat für die Allgemeinheit (bessere Spamerkennung) hat man persönlich den Vorteil, den Spam auch mal zu sehen, der sonst Dank policyd-weight und spamassasssin (hoffentlich) gar nicht erst beim Mailprogramm ankommt. So bleibt man trotzdem auf dem laufenden, wo es gerade die günstigsten Viagra-Pillen gibt. 😉

    Postfix: optimierte Konfiguration gegen Spam und Missbrauch

    In einem früheren Artikel versprach ich, eine Postfix-Konfiguration zu posten, die nach (meinen) neuen Erkentnissen eingerichet ist.

    So sah meine Konfiguration nach der Einrichtung von sqlgrey aus:

    [...]
    smtpd_recipient_restrictions =
    permit_sasl_authenticated
    permit_mynetworks
    reject_invalid_hostname
    reject_non_fqdn_sender
    reject_non_fqdn_recipient
    reject_unauth_destination
    reject_unknown_sender_domain
    reject_unknown_recipient_domain
    reject_rbl_client dnsbl.ahbl.org
    reject_rbl_client cbl.abuseat.org
    reject_rbl_client sbl-xbl.spamhaus.org
    reject_rbl_client dul.dnsbl.sorbs.net
    reject_rbl_client bl.spamcop.net
    check_policy_service inet:127.0.0.1:60000
    reject_unknown_client
    warn_if_reject reject_unknown_hostname
    permit
    [...]

    Mehrere Hinweise aus der Postfix-Mailgruppe brachten mich jedoch auf folgende Konfiguration, die weiter unten noch genauer erläutere:

    
    #
    # restrictions
    #
    smtpd_helo_required = yes
    strict_rfc821_envelopes = yes
    disable_vrfy_command = yes
    smtpd_delay_reject = yes
    
    #
    # Recipient Restrictions
    #
    
    smtpd_recipient_restrictions =
        reject_unlisted_sender
        reject_unlisted_recipient
        reject_unknown_sender_domain
        reject_unknown_recipient_domain
        permit_sasl_authenticated
        permit_mynetworks
        reject_invalid_hostname
        reject_non_fqdn_sender
        reject_non_fqdn_recipient
        reject_unauth_destination
        #policyd-weight
        check_policy_service inet:127.0.0.1:60001
        #sqlgrey
        check_policy_service inet:127.0.0.1:60000
        reject_unknown_client
        reject_unknown_hostname
        permit

    Es handelt sich hier natürlich nur um einen Ausschnitt aus der main.cf, diese Parameter sind sehr wichtig, wenn es darum geht, welche Mails von Postfix zur Zustellung angenommen werden.

    Postfix: optimierte Konfiguration gegen Spam und Missbrauch weiterlesen

    policyd-weight: Score-basierte Spamabwehr für Postfix

    Es ist immer wieder das gleiche: Sobald man denkt, dass man das System perfekt eingerichtet hat, bekommt/ findet man gleich mehrere Hinweise, die einen daran zweifeln lässt.

    Ausgangslage

    Bei vielen, die sich halbwegs um einen spamgeschützten Postfix-Mailserver kümmern, wird die Konfiguration ungefähr so aussehen:

    
    [...]
    smtpd_recipient_restrictions =
    permit_sasl_authenticated
    permit_mynetworks
    reject_invalid_hostname
    reject_non_fqdn_sender
    reject_non_fqdn_recipient
    reject_unauth_destination
    reject_unknown_sender_domain
    reject_unknown_recipient_domain
    reject_rbl_client dnsbl.ahbl.org
    reject_rbl_client cbl.abuseat.org
    reject_rbl_client sbl-xbl.spamhaus.org
    reject_rbl_client dul.dnsbl.sorbs.net
    reject_rbl_client bl.spamcop.net
    check_policy_service inet:127.0.0.1:60000
    reject_unknown_client
    warn_if_reject reject_unknown_hostname
    permit
    [...]

    Anmerkung: Diese Konfiguration hatte ich bereits hier gepostet, wurde von mir nun aber mehrfach verfeinert (siehe weiter unten).

    Wie man sehen kann, sind mehrere RBL-Checks (Realtime-Blackhole-List) in der Konfiguration, welche bei jedem SMTP-Connect von anderen Mailservern überprüft werden und bei einem positiven Treffer sofort zum REJECT führen. Dies hat zwar funktioniert, birgt aber die Gefahr, dass man einen legitimen Mailserver ablehnt, weil er durch einen Fehler in einer der RBL landete.

    Besser wäre es also doch, wenn man nachschauen könnte, ob der Mailserver in mehr als einer dieser RBLs steht. Mit Boardmitteln von Postfix ist dies vorerst nicht möglich.

    Einführung in policyd-weight

    Hier kommt policyd-weight als policy-Server ins Spiel und bietet folgende Zusatzfunktionen in der Standardkonfiguration an (Auszug von der Website):

    • Score-basierte Auswertung von RBL/RHSBL
    • Score-basierte Auswertung der Beziehung und Korrektheit von DNS-Einträgen, HELO und MAIL-FROM
    • Caching von a) DNS-Request und b) Score-Ergebnissen (= Beschleunigung und weniger Traffic)
    • eigene, schnelle DNS-Lookup.Routine
    • frei konfigurierbare Scores und RBLs (sinnvolle Standardwerte bereits enthalten)
    • keine Datenbank-Abhängigkeit
    • Einrichtung auch nur für eine Teilmenge von Mails/Mailservern nutzbar (via postfix restriction classes)

    Policyd-weight arbeitet als Policy-Server mit Postfix zusammen und entgegen z.B. AMAViS noch auf der Ebene des SMTP-Connects und ist daher in der Lage, Postfix einen REJECT der Verbindung zu empfehlen und die Mail erst gar nicht anzunehmen zu lassen. (Dies ist auch im Hinblick auf die Rechtslage ein wichtiger Unterschied.)

    Diese Vorteile sprechen ja deutlich für den Einsatz von policyd-weight und daher nahm ich mir auch gleich die Installation vor, welche im Folgenden beschreiben werde.

    policyd-weight: Score-basierte Spamabwehr für Postfix weiterlesen

    rechtliche Fallstricke beim Filtern von Spam

    Mit dem wachsenden Aufkommen von Spam und den dazu eingeleiteten Gegenmaßnahmen müssen auch rechtliche Aspekte in den Fokus eines Admins bzw. eines beauftragenden Geschäftsführers kommen.

    Der hier verlinkte Artikel der c’t ist bereits älteren Datums, aber jedoch nichtsdestotrotz aktuell.

    Hier geht’s zum c’t-Artikel (26/2003, S. 186)

    Die einzige Möglichkeit des Spamhandlings ohne eine dieser Betriebsvereinbarungen und/oder Servicevereinbarungen zur Einwilligung der Spamfilterung ist imho die Ablehnung einer Mail (keine Annahmen = keine Zustellpflicht) oder – nach der Annahme – die unbedingte Zustellung der Mail, ggf. unter Hinzufügung von Spamtags.

    Meine Frage an Euch, geschätzte Leser, ist, ob Ihr Vorlagen für solcher Art Vereinbarungen habt und wenn ja, ob ihr mir bzw. den anderen Lesern eventuell diese zur Verfügung könntet?!

    Mail-Logs im Auge behalten

    Ich habe mir, nachdem ich der Postfix-Mailgruppe mehrere Hinweise las, die diversen Tools zur Logfile-Analyse angesehen und mich danach entschieden, ein paar auf regelmäßiger Basis einzusetzen.

    Folgende Tools sind nun bei mir im Einsatz:

    • pflogsumm: Postfix-Logs analysieren und zusammengefasst ausgeben (englische Version / deutsche Version)
      Es läuft nächtlich als cron, analysiert den vorherigen Tag und wird mir via Mail zugesendet.
    • mailgraph: Postfix-Logs graphisch darstellen (z.B. ACCEPTs, REJECTs, BOUNCEs usw.) (Beispielausgabe)
    • queuegraph: Postfix-Queue-Belastung wird graphisch aufbereitet
    • couriergraph: Courier-Logs graphisch darstellen (z.B. LOGINs)
      Die *graph-Tools sind jeweils eine Kombination aus Perl-Script (laufen als cron (queuegraph) oder daemon (mailgraph/couriergraph)) und Web-CGI für die Ausgabe im Web.

    Sämtliche Tools sind zwar als Debian-Pakete erhältlich, aber die deutsche Pflogsumm-Version kann man derzeit nur über den o.g. Download installiert werden.

    Fragen? Probleme? Immer her damit, denn dafür sind die Comments da…

    Spam in neuen Dimensionen

    In einem Nachrichtenbeitrag von tecchannel.de fand ich die interessante Neuigkeit, dass es nun eine neue Methode der Spammer gibt: 3D-Spam.

    Dabei wird beim Bilderspam (“Werbe”-Text ist im Bild eingebettet) statt der mittlerweile üblichen Verfremdungen wie zusätzlicher Linien oder Rauschen der Text in 3D-dimensionaler Art verschoben und damit für OCR-Verfahren noch schwerer erkennbar gemacht. Soweit ich das verstanden habe, soll diese Verfremdung sogar für jeden Spamempfänger individuell gemacht werden, um eine Erkennung durch Bildsignaturen u.ä. möglichst auszuschließen.

    Im Blog von F-Secure sind ein paar Beispiele für die neue Methode zu sehen.

    Ich persönlich habe mit Spam ja zur Zeit wenig Probleme, denn meine Helfer + Filter (sqlgrey und amavisd-new mit Spamassassin sowie einige wichtige RBL-Checks) halten mein Postfach ziemlich sauber.

    Wie geht es euch damit? Habt Ihr große Mengen täglich zu löschen? Müsst Ihr die eine wichtige Nachricht stets suchen? Habt Ihr Ideen, wie man den 3D-Spam erkennen und damit filtern kann?

    Der bloggende Wurm

    Wir haben alle gewusst, dass E-Mail-Spam nicht das Ende der Fahnenstange ist und wir haben ja auch schon die gleichen, wenn nicht sogar mehr, Anti-Spam-Systeme für Blogs erfunden und installiert.

    Aber dass nun ein Scheiß böser Bot bloggt, um nicht nur Werbung zu machen, sondern mittels Kommentaren auch die Leute auf infizierte Websites locken möchte finde ich persönlich dann doch wieder eine Steigerung.

    Nachzulesen bei heise online…

    PS: Wenn ihr also Links in Euren Blogs findet, die offensichtlich zu youtube gehen sollen, dann checkt bitte vor dem Klick noch einmal das Ziel des Links.