24/7 Support
24/7 Support
Zurück zur Suchliste
04.05.2010 - Fachbeitrag

DKIM-Signierung in Amavis einrichten

So richten Sie mit Amavis in wenigen Handgriffen eine DKIM-Signierung für ausgehende E-Mails ein. Als erstes sollte man von Amavis die Keys generieren lassen: host:~ # amavisd genrsa /var/spool/amavis/example.com.pem

 

Bei Debian bietet sich der Pfad /var/lib/dkim/example.com.pem an.

Anschließend muß DKIM in der Amavis-Config aktiviert werden:

$enable_dkim_verification = 1; # enable DKIM signatures verification $enable_dkim_signing = 1; # load DKIM signing code, dkim_key('example.com', 'abc', '/var/spool/amavis/example.com.pem');

 

 

Ist alles richtig eingetragen, sollte Amavis alle eingetragenen Schlüssel heraussuchen und anzeigen lassen können – diese Einträge sind gleich fertig für die Cut&Paste-Übertragung in das jeweilige DNS-Zonefile formatiert:

host:~ # amavisd showkeys abc._domainkey.example.com. 3600 TXT ( "v=DKIM1; p=" "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQcNuAysGQ4YxBhgPl6u" "JutgxhazJDOEw0zeNNbor9nPhDllMwT9WHPBCxQEpE4NvwDFmhaBh0/jdjYEl/kZ" "11u5bsMWo/8cf4RYgrEbklc0f9HJ+pyx4eNq9BTgWn8mDFc2Y36cmz5K2tBrpPT0" "ElR7qsLo5bIKjBAFkQIDAQAB")

 

 

Ist der Public-Key im DNS verfügbar gemacht worden, so kann man mit Amavis einen Testdurchlauf starten, der als Ergebnis natürlich „pass“ liefern sollte:

host:~ # amavisd testkeys TESTING: abc._domainkey.example.com => pass

 

Und noch ein wichtiger Stolperstellenhinweis: Die Domains sollten sauber in der Amavis-Konfiguration auch sauber „@local_domains_maps“ aufgeführt werden, damit Amavis diese Domains als eigene/lokale erkennt und Mails dieser Absender auch sauber signiert. Aber dort sollten diese Domains sowieso stehen, ganz gleich ob man DKIM nutzt, oder nicht :-)

 

Übrigens: Unser Vortrag "SPF, DKIM & Co" beleuchtet die Vor- und Nachteile der verschiedenen Mechanismen genauer.

 

Die Rechtslage (in Kürze und ohne verbindliche Rechtsberatung...)

 

 

§ 206 StGB, Verletzung des Post- oder Fernmeldegeheimnisses:

 

  • Mitarbeiter eines Unternehmens, das geschäftsmäßig Post- oder Telekommunikationsdienste erbringt...

  • ...der unbefugt eine einem solchen Unternehmen zur Übermittlung anvertraute Sendung unterdrückt...

  • ...wird mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe bestraft.

  • (Gilt auch für Unternehmen im Umfeld oder Zulieferer.)

 

Betriebsrat in Firmen:

 

  • Mitbestimmungsrecht, §87 Betriebsverfassungsgesetz

  • Kann zustimmen, ersetzt individuelle Vereinbahrung mit AN

  • Konflikt mit Admin: Wann ist allg. technischer Schutz ein individueller Eingriff?

  • Betriebsrat muß gefragt werden, muß aber auch zustimmen, wenn alles zulässig ist (Chance zur Überwachung).

 

Lösungen:

 

  • Eindeutige schriftl. Regelung mit Betriebsrat, Arbeitnehmer oder Kunden

  • "Tag only", Kunde kann selber filtern

  • "opt in" in das Schutz-System

 

 

Kompetenter Rechtsanwalt: Kai Bodensiek, kb@bvm-law.de

 

 

 

Schlußfolgerungen:

 

SPAM muß im Annahmeprozeß geblockt werden. Kein store+forward vor dem Spam-Filter, sondern „pre-queue“-Modus, also Einbindung „smtpd_proxy_filter“. Spam darf gar nicht erst empfangen werden – was man nicht übertragen bekommen hat, kann man nicht unterdrücken.

 

Zu beachten: Provider und Dienstleister haben ggf. zivilrechtliche (!) Pflicht den Spam anzunehmen – eben lt. Hosting/Providervertrag.

 

Vorsicht: Laut BGH haben Provider aus nebenvertraglichen Pflichten eine allgemeine Schutzpflicht und müssen ihre Kunden vor Viren und Malware schützen! Verletzung dieser Schutzpflicht kann ggf. Schadensersatzforderungen nach sich ziehen!

 

 

 

content_filter oder smtpd_proxy_filter?

 

Postfix kennt „content_filter=smtp:[localhost]:10024“ und „smtpd_proxy_filter=localhost:10024“. Leicht anderer Syntax beim proxy_filter – kein Tippfehler.

 

Der content_filter (alias „post queue“) ist einfacher und in jeder Doku zu finden: Die Mail wird in die Postfix-Queue eingestellt und irgendwann später an den Filter weitergereicht. Also store + forward.

 

  • Das glättet Lastspitzen und das Gesamtsystem läßt sich besser limitieren.

  • Problem: Beim content_filter kann keine Ablehnung der e-Mail mehr im Annahmeprozeß erfolgen!

 

Der smtpd_proxy_filter geht -wie der Name schon sagt- nur für Mails, die per SMTP angenommen werden, nicht also für Mails, die auf Shell-Ebene erzeugt werden. Er reicht die Mail „life“ an den Filter-Prozeß weiter. Die Folgen:

 

  • Mail kriegt keine Queue-ID, erst nach dem Filter-Prozeß.

  • Instanzenanzahl muß klar limitiert werden, 100 Filterprozesse sind unmöglich!

  • virtual_maps, body-/header_checks erst nach dem Rückspielen auf localhost:10025...

  • Überlastungen des Filters führt zu Timeouts, ggf. Verbindungsabbruch, ggf. auch „Verdopplung“ der e-Mails.

 

 

Schlußfolgerung:

 

  • Mails von Desktop-Nutzer per content_filter bearbeiten

  • Ggf. auch Mails von lokalen Webservern per content_filter bearbeiten

  • Alle Mails von anderen Servern („MX-Mails“) wegen Backscatter-Problem nur über smtpd_proxy_filter bearbeiten

 

Über die master.cf ist eine flexible Konfiguration möglich:

 

# mail.provider.local -- unsere Nutzer mit SMTP-Auth

192.168.150.102:smtp inet n - n - - smtpd

-o content_filter=smtp-amavis:[127.0.0.1]:10024

-o smtpd_proxy_filter=

-o receive_override_options=no_header_body_checks,no_address_rewrite

 

# mx1.provider.local -- andere Mailserver über DNS-MX

192.168.150.199:smtp inet n - n - - smtpd

-o content_filter=

-o smtpd_proxy_filter=127.0.0.1:10024

 

localhost:10025 inet n - n - - smtpd

-o content_filter=

-o smtpd_proxy_filter=

-o receive_override_options=no_unknown_recipient_checks

 

smtp-amavis unix - - n - 5 smtp

amavisd.conf: Logik & Syntax

 

Die amavisd.conf ist praktisch purer Perl-Code. Entsprechend mächtig ist sie für Perl-Hacker; entsprechend verwirrend kann sie für Perl-unkundige Laien (wie mich) sein...

 

Hier eine kurze Zusammenfassung:

 

Variablen mit @ im Namen bezeichnen eine Liste. In der Zuweisung müssen Werte an diese Listen durch Apostroph und Komma getrennt werden:

 

@user = ( 'klaus@tux.local', 'susi@tux.local', 'micha@tux.local' );

 

Die Kurzschreibweise qw() kann genutzt werden, um Listen mit Leerzeichen als Trenner, in eine solche Liste zu konvertieren – also das Werkzeug für Faule.

 

@user = qw( klaus@tux.local susi@tux.local micha@tux.local );

 

 

Variablen mit $ im Namen sind ganz normale Variablen:

 

$pid_file = "$MYHOME/amavisd.pid";

 

Sofern Variablen boolean interpretiert werden, steht „1“ für TRUE und „' '“ oder „undef“ für FALSE:

 

$insert_received_line = 1;

$virus_admin = undef;

 

amavisd.new kennt assoziative Arrays, alias „Hash-Arrays“ – eingeleitet durch geschweifte Klammern. Abhängig vom Lookup-Key werden verschiedene Werte für diesen Parameter gesetzt. Lookup-Keys sind je nach Situation Absender- oder (i.d.R.) Empfängermailadressen. Das ganze schließt mit einem Default-Wert:

 

@virus_admin_maps = ( # by-recipient maps

{'not.example.com' => '',

'.' => 'virusalert@example.com'},

$virus_admin, # the usual default

);

 

Zuguterletzt sind auch Regexp-Ausdrücke mittels „qr“ möglich:

 

$banned_filename_re = new_RE(

# block certain double extensions anywhere in the base name

qr'\.[^./]*[A-Za-z][^./]*\.(exe|vbs|pif|scr|bat|cmd|com|cpl|dll)\.?$'i,

qr'^application/x-msdownload$'i, # block these MIME types

qr'^application/x-msdos-program$'i,

qr'^application/hta$'i,

);

 

 

 

Das nachfolgende Beispiel kombiniert alle Varianten: Zuerst eine normale Liste, dann ein Hash-Array und zuguterletzt ein Regexp-Ausdruck:

 

@virus_lovers_maps = (

[ qw( me@lab.xxx.com !lab.xxx.com .xxx.com yyy.org ) ],

{ "postmaster\@$mydomain" => 1, # double quotes permit variable evaluation

'postmaster@example.com'=> 1, # in single quotes the '@' need not be quoted

'abuse@example.com'=> 1,

'some.user@' => 1, # this recipient, regardless of domain

'boss@example.com' => 0, # never, even if domain matches

'example.com' => 1, # this domain, but not its subdomains

'.example.com' => 1, # this domain, including its subdomains

},

new_RE( qr'^(helpdesk|postmaster)@example\.com$'i ),

);

 

 

 

Das ganze geht noch eine Stufe weiter. Abhängig vom Empfänger kann auch abhängig vom Sender ein Score-Wert gesetzt werden...

 

@score_sender_maps = ({ # a by-recipient hash lookup table

 

# # per-recipient personal tables (NOTE: positive: black, negative: white)

# 'user1@example.com' => [{'bla-mobile.press@example.com' => 10.0}],

# 'user3@example.com' => [{'.ebay.com' => -3.0}],

# 'user4@example.com' => [{'cleargreen@cleargreen.com' => -7.0,

# '.cleargreen.com' => -5.0}],

 

# site-wide opinions about senders (the '.' matches any recipient)

'.' => [ # the _first_ matching sender determines the score boost

 

new_RE( # regexp-type lookup table, just happens to be all soft-blacklist

[qr'^(bulkmail|offers|cheapbenefits|earnmoney|foryou)@'i => 5.0],

[qr'^(greatcasino|investments|lose_weight_today|market\.alert)@'i=> 5.0],

[qr'^(money2you|MyGreenCard|new\.tld\.registry|opt-out|opt-in)@'i=> 5.0],

[qr'^(optin|saveonlsmoking2002k|specialoffer|specialoffers)@'i => 5.0],

[qr'^(stockalert|stopsnoring|wantsome|workathome|yesitsfree)@'i => 5.0],

[qr'^(your_friend|greatoffers)@'i => 5.0],

[qr'^(inkjetplanet|marketopt|MakeMoney)\d*@'i => 5.0],

),

], # end of site-wide tables

});

Mails mit Amavis taggen?

Taggen ist häufig Ausdruck eines Mißtrauens, ggf. basierend auf schlechten Erfahrungen.

Saubere gute Filter sind so gut, daß auf Taggen wirklich verzichtet werden kann. Stattdessen lieber hartes REJECT im Annahmeprozeß. Taggen macht (m. E. n.) nur Sinn, wenn dies aus rechtlichen Gründen notwendig ist.

 

 

Amavis taggt per Default nur lokale Domains im Subject – der häufigste Fallstrick, entsprechende Probleme oft auf Mailinglisten zu finden.

 

Amavis taggt Mails im Subject bei Score-Werten > sa_tag2_level.

 

 

$sa_tag_level_deflt = 2.0; # add spam info headers if at, or above that level

$sa_tag2_level_deflt = 5.0;

$sa_kill_level_deflt = 6.31; # triggers spam evasive actions

$sa_dsn_cutoff_level = 10; # spam level beyond which a DSN is not sent

 

Wichtige Parameter:

 

$sa_spam_subject_tag = '***SPAM*** ';

 

 

 

Plan B: Verschieben der e-Mails in „Spamverdacht“-Ordner. Zum Beispiel über Mailextensions. Diese werden durch „+“ an die Mailadresse angehängt, aber vom Mailserver wie die eigentliche Mailadresse verstanden: klaus@tux.local = klaus+spam@tux.local

 

Einrichten in Amavis:

 

$recipient_delimiter = '+';

# @addr_extension_virus_maps = ('virus'); # defaults to empty

@addr_extension_spam_maps = ('spam'); # defaults to empty

# @addr_extension_banned_maps = ('banned'); # defaults to empty

# @addr_extension_bad_header_maps = ('badh'); # defaults to empty

#

# A more complex example:

# @addr_extension_virus_maps = (

# {'sub.example.com'=>'infected', '.example.com'=>'filtered'}, 'virus' );

 

Einrichten in Postfix:

 

recipient_delimiter = +

 

 

Muß dann aber vom IMAP-Server oder dem MDA (Mail Delivery Agent: procmail & Co) unterstützt und ausgewertet werden!

Schizophren? Mehr Spass mit amavisd-new Policy Banks!

 

Amavis kann in quasi jeder Situation fast jeden Parameter beliebig anders setzen – nicht nur für userbezogene sa_kill_level & Co. Mächtiges Werkzeug: Policy Banks!

 

Amavis horcht auf mehreren Ports...

 

$inet_socket_port = [10024, 10030];

 

Und was auf Port 10030 eingeliefert wird, gehört nun zur Policy-Bank „AUTH“:

 

$interface_policy{'10030'} = 'AUTH';

 

Alle in der amavisd.conf getroffenen Einstellungen lassen sich nun für alle hier eingelieferten e-Mails überschreiben:

 

$policy_bank{'AUTH'} = {

# enable admin notifications for malware originating from our users:

# virus_admin_maps => ["virusalert\@$mydomain"],

# spam_admin_maps => ["virusalert\@$mydomain"],

# be slightly more permissive on spam levels for mail from our users:

spam_kill_level_maps => 7.5,

# spam_dsn_cutoff_level_maps => 15,

bypass_banned_checks_maps => 1, # allow sending any file type or name

# final_bad_header_destiny => D_BOUNCE; # block invalid headers

};

 

 

Nun muß man nur noch Postfix & Co beibringen, auf unterschiedlichen Ports einzuliefern. Bei Postfix: master.cf!

 

 

# mail.tux.local (Unsere User)

192.168.1.10:smtp inet n - y - 70 smtpd

-o content_filter=smtp-amavis-n:[vscanner1.tux.local]:10030

 

192.168.1.11:smtp inet n - y - 15 smtpd

-o content_filter=smtp-amavis-n:vscanner.tux.local:10024

 

 

amavisd-new im Cluster

 

DNS und Mailsysten bieten mit den MX-Records einwandfreies Loadbalancing nebst Failover frei Haus.

 

a) Round-Robin über alle gleichberechtigten MX-Server („MX 10“)

b) Fail-Over an nachgelagerte MX-Server („MX 20“).

 

Und das alles einfach so – ohne Loadbalancer, ohne Aufwand!

 

Postfix kann den Virenfilter nicht nur über A-Records einbinden, sondern auch über MX-Records. Dann greifen die ganz normalen Regeln zum MX-Routing. Ist ein Filter down, wird auf andere Filter ausgewichen!

 

Tip: Meta-DNS-Namen für die Virenfilter einrichten!

 

 

filter1.tux.local. IN A 192.168.10.11

filter2.tux.local. IN A 192.168.10.12

filter3.tux.local. IN A 192.168.10.13

 

filter.tux.local IN MX 10 filter1.tux.local.

filter.tux.local IN MX 10 filter2.tux.local.

filter.tux.local IN MX 20 filter3.tux.local.

 

 

Ergo: Round-Robin über filter1 und filter2, Fallback zu filter3.

 

 

Amavis darf dann natürlich nicht nur auf localhost horchen:

 

$inet_socket_bind = '*';

 

Trotzdem darf nicht jedermann einliefern, nur berechtigte IPs:

 

@mynetworks = qw( 127.0.0.0/8 ::1 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 213.203.238.0/25 );

 

Zurückgespeist wird ganz trickreich – zurück zu der IP, von der der Request kam:

 

$forward_method = 'smtp:*:10025' ;

 

Oder noch besser: Zurück an diese IP und „Zielport = Eigener Empfangsport + 1“:

 

$forward_method = 'smtp:*:*' ;

 

 

Speed up your amavisd-new!

 

  • Der Filter ist der Flaschenhals im Mailempfang!

 

  • Pimp up your viruskiller: Möglichst in einer dämonisierten Variante einsetzen!

 

Eine Ram-Disk für /var/spool/amavis/tmp wirkt wahre Wunder! Aus /etc/sfatab:

 

none /var/spool/amavis/tmp tmpfs defaults,size=180m,mode=750,uid=65,gid=0 0 0

 

Eigentlich muß Ram-Disk so groß sein, wie „Maximale Prozeßanzahl * Mailgröße + X“. Geht aber auch so, RAM-Disk üblicherweise mit < 1 Mbyte belegt, da ausreichend kleine Mails dabei sind. Überlastete RAM-Disk liefert temporären Fehler – also was soll's.

 

 

 

 

Razor und Pyzor sind Performance-Fresser wegen langer Reaktions- und Latenzzeiten. Sind sie wirklich notwendig?

Training mit SpamAssassin

 

Über das Programm „sa-learn“ kann man Mails über einzelne Dateien, ganze Ordner oder mbox-Archive lernen. Dabei ist anzugeben, ob diese Mails „Ham“ oder „Spam“ sind.

 

Wichtig:

 

  • Training benötigt mindestens 200 Mails jeder Sorte

  • Training alleine mit SPAM-Mails bringt gar nichts – schadet sogar (false positives!)

 

Training durch Nutzer durchführen zu lassen ist möglich:

 

  • Cron-Job, der auf Dateiebene durch alle SPAM-IMAP-Folder geht und sa-learn aufruft

 

ist aber sehr heikel:

 

  • „Denn sie wissen nicht, was sie tun“ -- Nutzer/Laien trainieren Filter oft (zu) schlecht.

 

 

Man kann auch Mails einer spam-Trap direkt an sa-learn vefüttern lassen. Problem: Spammer verschicken gezielt „Ham“-Mails um Lern-Filter kaputt zu machen („filter poisening“).

 

Deshalb meine Thesen:

 

  • In aller Regel werden Filter kaputt-trainiert.

  • Training muß wirklich sorgfältig erfolgen!

  • Training muß dich kompetente Administratoren erfolgen

  • Training sollte nicht automatisch erfolgen! Nur mit manueller Kontrolle!

     

Setup einer MySQL-Unterstützung

Zuerst Apache2, PHP5, MySQL, php5-mbstring, perl-DBD-mysql und ggf. phpMyAdmin installieren – und alle sich daraus ergebenden Abhängigkeiten :-)

 

In MySQL oder phpMyAdmin einen Nutzer „amavis“ anlegen und eine gleichnamige Datenbank anlegen. Dem Nutzer Rechte auf diese Datenbank geben. Reload von MySQL ggf. nicht vergessen.

 

In /usr/share/doc/packages/amavisd-new/README_FILES/README.sql ist ein MySQL-Schema – muß man leider ausschneiden, kann man dann an mysql verfüttern:

 

mysql -u root -p amavis < /root/amavis.sql

 

Anschließend kann man sich das ganze schonmal in phpMyAdmin anschauen...

Aktivierung in amavisd.new:

 

@lookup_sql_dsn =

( ['DBI:mysql:database=amavis;host=127.0.0.1;port=3306', 'amavis', 'passwd'],

# ['DBI:mysql:database=mail;host=host2', 'username2', 'password2'],

# ["DBI:SQLite:dbname=$MYHOME/sql/mail_prefs.sqlite", '', '']

);

 

Und wenn Quarantäne-Mails ebenfalls in dieser Datenbank gespeichert werden sollen:

 

@storage_sql_dsn = @lookup_sql_dsn; # none, same, or separate database

 

Was kann man damit tun? Nun, zum Beispiel White-/Blacklisting einrichten:

 

  • Externe Mailadressen in mailaddr abbilden und eindeutige ID vergeben

  • Interne Mailadressen in users abbilden und eindeutige ID vergeben

  • Beide in wblist verknüpfen.

 

Oder man kann allen lokalen Nutzern vordefinierte Profile zuweisen:

 

  • Profil/Policy in der Tabelle policy einrichten

  • Die policy-ID dann mit der Mailadresse in der Tabelle users verknüfen

  • Rest macht amavisd-new dann automatisch...

 

 

Das Quarantäne-Verzeichnis in MySQL

 

Das Quarantäne-Verzeichnis kann vom Dateisystem auch in MySQL verlagert werden...

 

$virus_quarantine_method = $spam_quarantine_method = 'sql:';

 

Jede in quarantine gespeicherte Mail kriegt neben der mail_id noch eine secret_id, die in der Tabelle msgs verlinkt ist.

 

Das Tool amavisd-release kann Mails freigeben. Aktivierung in amavisd.conf:

 

$interface_policy{'SOCK'} = 'AM.PDP';

$policy_bank{'AM.PDP'} = {protocol=>'AM.PDP'};

 

Und dann auf der Kommandozeile:

 

atlas:/var/spool/amavis # amavisd-release 1TthMLT4dBDZ IPsXl-ucAXqS

250 2.6.0 Ok, id=rel-1TthMLT4dBDZ, from MTA([127.0.0.1]:10025): 250 Ok: queued as AC1B8783B6

atlas:/var/spool/amavis #

 

 

Vorsicht: Bug in SuSE 10.1: In /usr/sbin/amavisd-release muß in Zeile 75 der Pfad angepaßt werden. Es muß /var/spool/amavis heißen – nicht nur /var/amavis...

 

 

NIXspam in Amavis einbinden

So wird die NIXspam-Liste von Bert Ungerer/Heise in Amavis eingebaut: Eine Datei namens /etc/mail/spamassassin/myrules.cf mit folgendem Inhalt anlegen...

header LOCAL_RCVD_IN_IXM eval:check_rbl('ixmani', 'ix.dnsbl.manitu.net.')

describe LOCAL_RCVD_IN_IXM Received via a host listed in ix.dnsbl.manitu.net

tflags LOCAL_RCVD_IN_IXM net

score LOCAL_RCVD_IN_IXM 2

 

...und dann Amavis neu starten.

 

Der Name ist egal – Hauptsache die Datei liegt in /etc/mail/spamassassin und endet auf *.cf.

 

Das Scoring für die Liste ist selbst zu verantworten!

 

DKIM in Amavis einrichten

Als erstes sollte man von Amavis die Keys generieren lassen:

host:~ # amavisd genrsa /var/spool/amavis/example.com.pem

 

Bei Debian bietet sich der Pfad /var/lib/dkim/example.com.pem an.

 

Anschließend muß DKIM in der Amavis-Config aktiviert werden:

 

$enable_dkim_verification = 1; # enable DKIM signatures verification

$enable_dkim_signing = 1; # load DKIM signing code,

dkim_key('example.com', 'abc', '/var/spool/amavis/example.com.pem');

 

Ist alles richtig eingetragen, sollte Amavis alle eingetragenen Schlüssel heraussuchen und anzeigen lassen können – diese Einträge sind gleich fertig für die Cut&Paste-Übertragung in das jeweilige DNS-Zonefile formatiert:

 

host:~ # amavisd showkeys

abc._domainkey.example.com. 3600 TXT ( "v=DKIM1; p="

"MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQcNuAysGQ4YxBhgPl6u"

"JutgxhazJDOEw0zeNNbor9nPhDllMwT9WHPBCxQEpE4NvwDFmhaBh0/jdjYEl/kZ"

"11u5bsMWo/8cf4RYgrEbklc0f9HJ+pyx4eNq9BTgWn8mDFc2Y36cmz5K2tBrpPT0"

"ElR7qsLo5bIKjBAFkQIDAQAB")

 

Ist der Public-Key im DNS verfügbar gemacht worden, so kann man mit Amavis einen Testdurchlauf starten, der als Ergebnis natürlich „pass“ liefern sollte:

 

host:~ # amavisd testkeys

TESTING: abc._domainkey.example.com => pass

 

Und noch ein wichtiger Stolperstellenhinweis: Die Domains sollten sauber in der Amavis-Konfiguration auch sauber „@local_domains_maps“ aufgeführt werden, damit Amavis diese Domains als eigene/lokale erkennt und Mails dieser Absender auch sauber signiert. Aber dort sollten diese Domains sowieso stehen, ganz gleich ob man DKIM nutzt, oder nicht :-)

 

Aufgabe 1: amavisd-new an den Start bringen

 

Installieren Sie gemeinsam mit mir amavisd-new und andere nötige Pakete.

 

Als erstes geben wir ClamAV ein Signatur-Update, sonst läuft er später nicht:

 

freshclam

 

Anschließend starten wir amavisd-new (rcamavisd-new restart, bzw. /etc/init.d/amavisd-new restart) und testen mit „lsof -i :10024“ bzw. „telnet localhost 10024“ ob der Server erreichbar ist.

 

Als nächstes verschaffen wir uns gemeinsam einen ersten Überblick über /etc/amavisd.conf.

 

Anschließend richten wir Postfix ein, setzen einen Hostnamen in „myhostname“ und konfigurieren amavisd-new als content_filter bzw. smtpd_proxy_filter. Außerdem richten wir Port 10025 ein, damit amavisd-new die e-Mails nach erfolgter Filterung zurückspielen kann.

 

Versenden Sie Testmails wie in /usr/share/doc/packages/amavisd-new/test-messages/README angegeben. Analysieren sie /var/log/mail und versuchen Sie herauszulesen, was aus der e-Mail geworden ist.

 

Ggf. wurde die e-Mail zwar als Spam erkannt – aber trotzdem durchgelassen. Dann müssen wir Nachbesserungen in /etc/amavisd.conf vornehmen.

 

Zuguterletzt experimentieren wir etwas mit content_filter und smtpd_proxy_filter herum.

 

 

 

Aufgabe 2: Debugging von amavisd-new

Aktivieren Sie die ausführliche Protokollierung: $log_level = 5; # verbosity 0..5 Außerdem kann man Postfix in /etc/postfix/main.cf Debug-Modus schalten: debug_peer_list = 127.0.0.1 Anschließend Restart von Postfix & amavisd-new nicht vergessen. Testmail schicken und Logfile analysieren!

Aufgabe 3: TAG-ONLY bei bestimmten Empfänger

Richten Sie mittels „useradd -m“ einige lokale Test-Nutzer ein. Anschließend bauen wir in /etc/amavisd.conf ein paar besondere Regelungen ein, so daß Mails an diesen Benutzer nur getaggt, aber nie geblockt werden.

 

Stichwort: score_sender_maps

 

 

Aufgabe 4: Last-Test

Starten Sie mit mir einen Last-Test! Öffnen Sie in einem weiteren Fenster „top“, so daß Sie alles beobachten können.

 

Das nachfolgende (Postfix-) Kommando bombardiert dann localhost mit Testmails. Verfolgen sie die Auslastung Ihres Servers!

 

smtp-source -c -l 5000 -m 1000 -s 100 -t <USERNAME>@localhost -f root@localhost localhost:25

 

 

Aufgabe 5: Amavis im Cluster benutzen

Tun Sie sich bitte hierfür mit Ihrem Nachbarn zusammen. Richten Sie anhand eines MX-Routings ihre beiden amavisd-new-Dämomen als MX-Cluster ein. Verfolgen Sie in den Logfiles, was passiert!

 

Es geht nicht? Schauen Sie in /etc/amavisd.conf und achten Sie auf mynetworks und auf inet_socket_bind:

 

# @mynetworks = qw( 127.0.0.0/8 [::1] [FE80::]/10 [FEC0::]/10

# 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 );

$inet_socket_bind = '*';

Aufgabe 6: amavisd-new & Policy-Bank benutzen

Richten Sie gemeinsam mit mir eine Policy-Bank ein, über die Mails anders getaggt werden, bzw. die Spam-Mails bounct, anstatt sie zu rejecten.

 

 

Aufgabe 7: Nicht schwarz, nicht weiß – Greylisting!

Wir richten gemeinsam Greylisting ein!

 

 

Aufgabe 8: Training spam/ham aus Maildir-Foldern

Auch wenn Peer Heinlein es nicht mag – das Training darf nicht fehlen.

 

 

Aufgabe 9: Setup der MySQL-Unterstützung

Los geht’s...

Aufgabe 10: FuzzyOCR einrichten

Installieren Sie in YaST die Pakete ocr, ocrad, ungifsicle, perl-String-Approx, giflib-progs Laden Sie von http://fuzzyocr.own-hero.net/wiki/Downloads das aktuelle tgz von FuzzyOCR 3.5.x Kopieren Sie den Ordner FuzzyOCR nach /etc/mail/spamassassin, sowie die Dateien FuzzyOCR.cf, FuzzyOCR.pm, FuzzyOCR.scansets und FuzzyOCR.preps nach /etc/mail/spamassassin. Schauen Sie im Debug-Modus nach, ob alles funktioniert hat. Achten Sie dabei auch darauf, ob alle Hilfsprogramme zur Grafikbearbeitung gefunden wurden. spamassassin --debug FuzzyOCR < ocr-animated.eml

Aufgabe 11: Eigene Regelsätze einbinden

Installieren Sie ein Update mittels sa-update -D. Prüfen Sie die Dateien in /var/lib/spamasassin mittels spamasassin --lint -D. Wichtige Quellen:

http://wiki.apache.org/spamassassin/CustomRulesets http://www.rulesemporium.com

 

Entweder ignorieren Sie den GPG-Key (--nogpg) oder Sie laden und installieren Sie den GPG-Key von Rulesemporium:

wget http://daryl.dostech.ca/sa-update/sare/GPG.KEY ; sa-update --import GPG.KEY

 

Kopieren Sie von http://wiki.apache.org/spamassassin/SareChannels das vorgeschlagene Channel-File nach /etc/mail/spamassassin/sa-update.cf, ergänzen Sie ggf. eigene Quellen und starten Sie das Update:

sa-update --channelfile /etc/mail/spamasassin/sa-update.cf --gpgkey 856AA88A

sa-update --channelfile /etc/mail/spamasassin/sa-update-channels.dat –nogpg

 

updates.spamassassin.org

chickenpox.cf.sare.sa-update.dostech.net

70_zmi_german.cf.zmi.sa-update.dostech.net

sought.rules.yerp.org

# SARE-Regeln werden nicht mehr aktualisiert => nur einmal updaten, dann raus!

# 70_sare_stocks.cf.sare.sa-update.dostech.net

# 70_sare_adult.cf.sare.sa-update.dostech.net

# 70_sare_spoof.cf.sare.sa-update.dostech.net

# 70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net

# 70_sare_genlsubj_x30.cf.sare.sa-update.dostech.net

# 70_sare_oem.cf.sare.sa-update.dostech.net

# 70_sare_random.cf.sare.sa-update.dostech.net

# 70_sare_specific.cf.sare.sa-update.dostech.net

# 70_zmi_german.cf.zmi.sare.sa-update.dostech.net

# 70_sare_evilnum0.cf.sare.sa-update.dostech.net

# 70_sare_highrisk.cf.sare.sa-update.dostech.net

# 70_sare_header0.cf.sare.sa-update.dostech.net

# 70_sare_html0.cf.sare.sa-update.dostech.net

# 70_sare_obfu0.cf.sare.sa-update.dostech.net

# 70_sare_stocks.cf.sare.sa-update.dostech.net

# 70_sare_unsub.cf.sare.sa-update.dostech.net

# 70_sare_uri0.cf.sare.sa-update.dostech.net

# 70_sare_uri1.cf.sare.sa-update.dostech.net

# 70_sare_uri3.cf.sare.sa-update.dostech.net

# 70_sc_top200.cf.sare.sa-update.dostech.net

# 72_sare_bml_post25x.cf.sare.sa-update.dostech.net

# 99_sare_fraud_post25x.cf.sare.sa-update.dostech.net

# 88_FVGT_Bayes_Poison.cf.sare.sa-update.dostech.net

# 88_FVGT_Tripwire.cf.sare.sa-update.dostech.net

# 88_FVGT_rawbody.cf.sare.sa-update.dostech.net

# 88_FVGT_subject.cf.sare.sa-update.dostech.net

Mi Vormittag Grundlagen Mail. Header-Aufbau. Received-Zeilen. SMTP-Dialog. Reverse-Lookup. Ursachen von Spam/Botnetze. Versand-Strategien.Installation amavisd-new. Einbindung Postfix. prequeue-/postqueue-Filter. Amavisd-Grundconfig. Logfile lesen. GTUBE-Testmails.Aufgabe 1: amavisd-new an den Start bringenAufgabe 2: Debugging von amavisd-new und Postfix
Mi Nachmittag amavisd-new scharf schalten. Syntax der amavisd.conf.Einrichten von Spam-Tagging,Wichtige Filter-Regeln im Überblick, AWLVergleich zu spamc / spamd Ausklang: Filter-Strategien / Tagging?
Do Vormittag Userindividuelle Regelungen (Conf, MySQL, LDAP)Die master.cf von Postfix: Offen für Tricks!Nutzung von Policy-BanksRechtsprobleme für Postmaster Aufgabe 3: Tag-Only für bestimmte Empfänger Aufgabe 6: Policy-Banks in amavisd-new Aufgabe 9: SQL-Setup
Do Nachmittag Performance-Messung & TuningAufbau eines redundanten Filter-Clusters.Greylisting, Policyd-weightRulesDuJour / Regelupdates, SARE Aufgabe 4: Last-Test Aufgabe 5: amavisd-new im Cluster Aufgabe 7: Greylisting / policyd-weight einrichten
Fr. Vormittag Bilderkennung: FuzzyOCRDer Umgang mit dem Quarantäne-VerzeichnisBayes und Filter-TrainingAufgabe 8: Bayes-Training Aufgabe 10: Einrichten von Fuzzy-OCR
Fr. Nachmittag Zeit für restliche Fragenund weitere ThemenAusklang gegen 16 Uhr

 

 

Rechtsprobleme für Postmaster

Ablauf-Elemente:

 

  • Ursachen des Spam

  • Vortrag Rechtslage 1 (StGB)

  • Vortrag Rechtslage 2 (Datenschutz, Betriebsrat)

 

 

 

Userindividuelle Regelungen (MySQL, LDAP)

 

-Pyzor, Razor

 

-Greylisting

 

Weitere Themen:

 

Log-Level

Die Strategie der frühen Abweisung

Bilderkennung / OCR.

Policyd-Weight

XFORWARD/

AWL / autowhitelist

 

 

 

 

 

 

 

Todo:

 

-Fotokopien Buch smtp-source

 

Weitere Beiträge zum Thema

Enterprise Mail-Security mit Open-Source?

Enterprise Mail Security with Open Source?
Expertise
Akademie
Consulting
Services
SLAC
Unternehmen
Jobs
News und Presse
Referenzen
Kontakt
Impressum
Datenschutz
AGB

Tel: +49 30 40 50 51 - 0
Fax: +49 30 40 50 51 - 19