Grundsatzfrage SPAM Filterung

IP-Projects.de

Active Member
Guten Morgen,

aus gegebenen Anlass - Google SPAM Filtert, Locky Trojaner, ... - stellt sich mir als Anbieter die Frage, wie weit sollte man für den Kunden entscheiden, welche E-Mail er bekommen darf und welche nicht? In unseren Premium- Business- und JAVA Webhosting Paketen nutzen wir daher nur Markierungsfunktionen die z.B. eine E-Mail mit einem [SPAM] Tag versehen, die bestimmte SPAM Kriterien beinhaltet und Postgrey, welches den Mailverkehr zwar verzögert aber viel SPAM ad hoc vermeidet. Für Kunden die einen "keine Werbung" Aufkleber auf das Postfach haben möchten, haben wir vor Kurzem ein extra Produkt Mail Security eingeführt welches Aktiv E-Mails ablehnt nach Blacklisten, RDNS, ... Kriterien.

Ich sehe das schon seit Jahren etwas kritisch für den Kunden / E-Mail Konto Nutzer zu entscheiden, welche E-Mail er bekommen darf und welche nicht. - der Postbote, der mir die Briefe zukommen lässt entscheidet für mich ja auch nicht, welche Briefe ich bekommen darf und welche nicht. Und er öffnet ja die Briefe auch nicht um zu schauen, ob die Briefe eventuell böse sind. Wenn natürlich der Postbote spürt, dass dort eine Briefbombe enthalten ist, würde ich mich natürlich auch darüber freuen, wenn er diesen Brief nicht zustellt, aber würde ihn auch nicht verklagen wenn die Briefbombe im Briefkasten landet.

Zudem ist mir aufgefallen, dass viele Blacklisten ohne Sinn und Verstand IP-Adressen einfach blockieren. So sperren manche Blacklisten ganze /24 IP Bereiche wenn 1-2 IPs daraus SPAM verschicken. Teilweise bleiben solche Blocks über Jahre in der Blacklist aktiv. Wir hatten hier kürzlich den Fall wo Blacklist Blocks teilweise aus 2009 noch in der Blacklist vorhanden waren und man nur über tagelanges Hin- und Her mit dem Blacklistbetreiber (Privatpersonen oder Private Unternehmen) ein delisting erwirken konnte. Hier werden teilweise weltfremde und datenschutzkritische Informationen verlangt um Blocks die ohne Sinn und Verstand ausgeführt werden wieder zu entfernen.

Mich würde daher einmal interessieren, was Ihr als Kunden / IT Systemadministratoren von dieser Thematik haltet.
 
Wir verwenden generell Greylisting, amavisd (Virus/Spam Checks aktiviert und entpacken von Anhängen), Spamassassin, sowie Spamcop und Spamhaus als RBLs. Dazu noch razor2 und pyzor. Ich muss dir zustimmen, dass einige RBLs nicht zuverlässig sind und zum Teil legitime Mails nicht ankommen, da ganze IP Blocks von Anbietern geblacklistet werden, weil ein kleineres Subnet oder nur einzelne IPs von Spammern missbraucht werden oder wurden. Bei Spamhaus/Spamcop ist das aber meistens noch akzeptabel - z.B. abuseat.org und spamcannibal.org sind da weitaus aggressiver.

Also: Falls RBLs überhaupt in Frage kommen, dann sollte man sie nur mit Vorsicht genießen und nicht blind jede RBL einsetzen, die man findet. Eine totsichere Methode, um Spam ohne irgendwelche False Positives zu filtering, gibt es aber leider auch nicht wirklich. Selbst mit Greylisting kann es zu Problemen kommen. Die Frage ist also immer nur, was für ein Risiko man eingehen möchte, um Spam zu vermeiden. Ich würde das je nach Fall entscheiden. Bei Shared Hosting würde ich zu dem oben beschriebenen Setup greifen und die Kunden darauf hinweisen, dass bei diesen Hostingpaketen ggf. Mails von schlecht konfigurierten Mailservern nicht ankommen. Im Normalfall erhält der Absender ja auch eine Return Mail und kann sein Setup entsprechend korrigieren oder einen anderen Service verwenden.
 
Das ist das Maximum was ich Kunden an Bevormundung zumuten würde und mehr ist auch generell nicht nötig (der Kunde muss gelegentlich auch mal Spam bekommen, sonst meckert er wieder):
Code:
cat >> /usr/local/etc/postfix/main.cf << "EOF"
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites =
  zen.spamhaus.org*3
  bl.mailspike.net*3
  ix.dnsbl.manitu.net*2
  bl.spameatingmonkey.net*1
  cbl.abuseat.org*1
  bl.spamcop.net*1
  swl.spamhaus.org*-10
  wl.mailspike.net*-10
postscreen_dnsbl_threshold = 5
postscreen_greet_action = enforce
postscreen_non_smtp_command_enable = yes
postscreen_pipelining_enable = yes
smtpd_client_restrictions =
  sleep 1,
  permit
smtpd_data_restrictions =
  reject_unauth_pipelining,
  reject_multi_recipient_bounce,
  permit
smtpd_end_of_data_restrictions =
  permit
smtpd_etrn_restrictions =
  reject
smtpd_helo_required = yes
smtpd_helo_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_invalid_helo_hostname,
  reject_non_fqdn_helo_hostname,
  permit
smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  check_recipient_mx_access cidr:${config_directory}/mx_access,
  check_recipient_access pcre:${config_directory}/recipient_checks.pcre,
  permit
smtpd_relay_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination,
  permit
smtpd_sender_restrictions =
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  permit
strict_rfc821_envelopes = yes
"EOF"

cat > /usr/local/etc/postfix/recipient_checks.pcre << "EOF"
/^\@/                 550 Invalid address format.
/[!%\@].*\@/          550 This server disallows weird address syntax.
/^postmaster\@/       OK
/^hostmaster\@/       OK
/^security\@/         OK
/^abuse\@/            OK
/^admin\@/            OK
"EOF"

cat > /usr/local/etc/postfix/mx_access << "EOF"
0.0.0.0/8                REJECT MX in RFC 1122 Broadcast Network
10.0.0.0/8               REJECT MX in RFC 1918 Private Network
100.64.0.0/10            REJECT MX in RFC 6598 Shared Address Space
127.0.0.0/8              REJECT MX in RFC 1122 Loopback Network
169.254.0.0/16           REJECT MX in RFC 3927 Link Local Network
172.16.0.0/12            REJECT MX in RFC 1918 Private Network
192.0.0.0/24             REJECT MX in RFC 6890 IETF Protocol Assignments Network
192.0.0.0/29             REJECT MX in RFC 6333 DS-Lite Network
192.0.2.0/24             REJECT MX in RFC 5737 Documentation (TEST-NET-1) Network
192.168.0.0/16           REJECT MX in RFC 1918 Private Network
198.18.0.0/15            REJECT MX in RFC 2544 Interconnect Device Benchmark Testing Network
198.51.100.0/24          REJECT MX in RFC 5737 Documentation (TEST-NET-2) Network
203.0.113.0/24           REJECT MX in RFC 5737 Documentation (TEST-NET-3) Network
224.0.0.0/4              REJECT MX in RFC 5771 Multicast Network
240.0.0.0/4              REJECT MX in RFC 1122 Reserved Network
255.255.255.255/32       REJECT MX in RFC 919  Limited Broadcast Destination Address
::/128                   REJECT MX in RFC 4291 Unspecified Address
::1/128                  REJECT MX in RFC 4291 Loopback Address
::ffff:0:0/96            REJECT MX in RFC 4291 IPv4-mapped Address
100::/64                 REJECT MX in RFC 6666 Discard-Only Network
2001::/23                REJECT MX in RFC 2928 IETF Protocol Assignements Network
2001::/32                REJECT MX in RFC 4380 TEREDO Network
2001:2::/48              REJECT MX in RFC 5180 Interconnect Device Benchmark Testing Network
2001:db8::/32            REJECT MX in RFC 3849 Documentation Network
fc00::/7                 REJECT MX in RFC 4193 Unique-Local Network
fe80::/10                REJECT MX in RFC 4291 Linked-Scoped Unicast Network
ff00::/8                 REJECT MX in RFC 4291 Multicast Network
"EOF"

Diese Config ersetzt Postgrey, Spamassassin und Co nahezu vollständig und ist dabei auch noch sehr ressourcenschonend.
 
Als Kunde erwarte ich mir zumindestens, dass keine bekannte Viren durchkommen. Gut, mir persönlich wärs unter meinen Linux Desktops und mit Brain 2.0 egal, aber ich denke da auch an den typischen Windows-DAU, den sicher jeder irgendwo mindestens privat "mitbetreut". Mailsysteme ohne grundlegenden Virenscan sind leider etwas witzlos. Das liegt aber weniger an den aktuellen Problemen, eher daran dass immer mehr Menschen den PC benutzen, ohne irgendeine Ahnung zu haben oder einmal kurz nachzudenken.

Weil es angesprochen wurde: Bei Spamfiltern halte ich gar nichts von Betreffmodifizierung. Das mag für viele Kunden zwar bequem und sofort sichtbar sein, erzeugt aber mehr Probleme als es bringt. Das soll ordentlich in einem Header eingetragen werden, der Kunde kann dann durch Filterregeln (am Server oder Client) immer noch machen was er will. Automatisches Löschen von eindeutigem Spam sehe ich kritisch, wenn dann maximal vor der Annahme abweisen.

Zum Thema Blacklists enthalte ich mich vorerst meiner Meinung. Nur soviel: Wenn schon, dann bitte erst reagieren, wenn mehrere anschlagen. Ein einzelner Treffer sagt leider oft nichts aus. Ob man sie sich ganz sparen kann, möchte ich nicht beurteilen.


MfG Christian
 
Ich kenne einige Firmen bis 150 Mitarbeiter die wollen einfach nur, dass Spam & Viren verlässlich gefiltert werden. Und dass, ohne das der IT Verantwortliche dort jeweils mehr können muss als Häkchen zu setzen (will ich / will ich nicht). Die wollen auch kein Geld ausgeben für einen Linux Admin der auf der Höhe der Zeit ist. Dafür sind sie im Gegenzug auch mal bereit zum Telefon zu greifen, wenn eine Mail nicht ankam oder mit Lesebestätigungen zu arbeiten.
 
Back
Top