Spamassassin mit Exim4 und Dovecot (Debian): Unterschied zwischen den Versionen

Aus MattWiki
Keine Bearbeitungszusammenfassung
 
(24 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
Beschreibung, wie SpamAssassin in einem Debian-Basierten Mailserver mit Exim4, Dovecot und Sieve genutzt werden kann.
Beschreibung, wie Spamassassin in einem Debian-Basierten Mailserver mit Exim4, Dovecot und Sieve genutzt werden kann.


Dabei wird als Exim4 nur als MTA genutzt. Als LDA kommt Dovecot zum Einsatz, welches mit Plugins um die Nutzung von Sieve-Skripten erweitert wird.
Dabei wird als Exim4 nur als MTA genutzt. Als LDA kommt Dovecot zum Einsatz, welches mit Plugins um die Nutzung von Sieve-Skripten erweitert wird.
Quellen:
https://wiki.debian.org/Exim#Spam_scanning
http://www.exim.org/exim-html-current/doc/html/spec_html/ch44.html
https://linux.die.net/man/1/spamassassin


== Installation ==  
== Installation ==  
Zeile 20: Zeile 28:
  systemctl status spamassassin.service
  systemctl status spamassassin.service


== Konfiguration ==
== Konfiguration Exim4 ==


Configfile anpassen:  
Configfile anpassen:  


Splitkonfiguration: '''/etc/exim4/conf.d/acl/40_exim4-config_check_data'''
Splitkonfiguration: ''/etc/exim4/conf.d/acl/40_exim4-config_check_data''


Ohne Split: '''/etc/exim4/exim4.conf.template'''
Ohne Split: ''/etc/exim4/exim4.conf.template'' --> Sollte hier nicht eher ''exim3.conf.localmacros'' verwendet werden?


Zeilen hinzufügen:
Folgende Zeilen dekommentieren, um die Ergebnisse von Spamassassin in den Mailheader reinzuschreiben:


  # add line when message is over threshold
  warn
  warn  spam = nobody/defer_ok
    condition = ${if <{$message_size}{120k}{1}{0}}
        add_header = X-Spam-Flag: YES     
    # ":true" to add headers/acl variables even if not spam
Folgende bestehende Zeilen dekommentieren:
    spam = nobody:true
    add_header = X-Spam_score: $spam_score
    add_header = X-Spam_bar: $spam_bar
    # # Do not enable this unless you have shorted SpamAssassin's report
    # add_header = X-Spam_report: $spam_report


  # See the exim docs and the exim wiki for more suitable examples.
Wenn Fetchmail genutzt wird, muss es so konfiguriert werden, dass Fetchmails E-Mails an den SMTP-Server weitergibt, statt diese direkt in die Mailbox zu legen.
  #
  warn
    spam = Debian-exim:true
    add_header = X-Spam_score: $spam_score\n\
              X-Spam_score_int: $spam_score_int\n\
              X-Spam_bar: $spam_bar\n\
              X-Spam_report: $spam_report
 
Wenn Fetchmail genutzt wird, muss es so konfiguriert werden, dass es E-Mails an den SMTP-Server weitergibt.


Dazu in der .fetchmailrc-Datei folgende Zeile hinzufügen:
Dazu in der .fetchmailrc-Datei folgende Zeile hinzufügen:
Zeile 50: Zeile 53:
  smtp <smtp-server-name>
  smtp <smtp-server-name>


== Dovecot zu lokalem LDA einrichten ==
== Konfiguration Dovecot ==
 
=== Dovecot als lokalen LDA einrichten ===


Quelle: http://wiki.dovecot.org/LDA/Exim
Quelle: http://wiki.dovecot.org/LDA/Exim
Zeile 95: Zeile 100:
  # transport = LOCAL_DELIVERY  
  # transport = LOCAL_DELIVERY  
  transport = dovecot_pipe
  transport = dovecot_pipe
 
Abschließend Exim neu starten:
Abschließend Exim neu starten:
   
 
  service exim4 restart
  service exim4 restart


== Dovecot-Sieve sowie Managesieve ==
=== Dovecot-Plugins Sieve sowie Managesieve ===


Installation von Sieve:
Installation von Sieve:


  # apt-get install dovecot-sieve dovecot-managesieved (dovecot-antispam?)
  # apt-get install dovecot-sieve dovecot-managesieved (dovecot-antispam?)
Die nachfolgenden Anpassungen in den Config-Files zeigen auf die Teildateien in ''/etc/dovecot/conf.d/''
Idealerweise bleiben diese Config-Files jedoch unangetastet. Die Konfiguration sollte stattdessen in einer Sammeldatei, die nicht zum Lieferumfang der Distribution gehört, gesammelt werden, z.B.: ''99-my-customzation.conf''
Sieve greift in Dovecot an mehreren Stellen ein. Diese werden konfiguriert in: ''90-sieve.conf'' bzw. entsprechend in ''99-my-customzation.conf''
plugin {
  sieve = file:~/sieve;active=~/.dovecot.sieve
   
   
Es sind zwei Lösungsansätze denkbar:
  # The default Sieve script when the user has none. This is the location of a
   
  # global sieve script file, which gets executed ONLY if user's personal Sieve
1. Verzeichnis für Sieve-Regeln erstellen
  # script doesn't exist. Be sure to pre-compile this script manually using the
  # sievec command line tool if the binary is not stored in a global location.
  # --> See sieve_before for executing scripts before the user's personal
  #    script.
  sieve_default = /var/lib/dovecot/sieve/default.sieve
 
  # Directory for :personal include scripts for the include extension. This
  # is also where the ManageSieve service stores the user's scripts.
  sieve_dir = ~/sieve
 
  # Location Sieve of scripts that need to be executed before the user's
  # personal script.
  #sieve_before = /var/lib/dovecot/sieve.d/
 
  # Identical to sieve_before, only the specified scripts are executed after the
  # user's script (only when keep is still in effect!). Multiple script
  # locations can be specified by appending an increasing number.
  sieve_after = /etc/dovecot/sieve-after
}
 
 
'''Globale Default-Sieve-Datei'''
 
Diese Default-Sieve-Datei wird verwendet, wenn keine persönliche Sieve-Datei für den User vorhanden ist. Dies ist z. B. dann der Fall, wenn Managesieve nicht genutzt werden soll.


Dies ist sinnvoll, wenn man zusätzlich Skripte durch User erstellen lassen möchte, z. B. mit Managesieve und der Roundcube-Erweiterung.
Alternativ ist dies sinnvoll, wenn der User ohne persönliche Sieve-Datei ein Standardverhalten erhalten soll, dieses aber vollständig vom User übersteuert können werden soll.


  # mkdir /etc/dovecot/sieve-after
  # mkdir /var/lib/dovecot/sieve


Neue Sieve-Regeldatei erstellen darin erstellen, z. B. ''movespam.sieve''
Datei anlegen: ''/var/lib/dovecot/sieve/default.sieve''


Inhalt:
Inhalt für Sortierung der Mails anhand des X-Spam-Flag:


  # The “require” lines include functionality to move emails
  # The “require” lines include functionality to move emails
Zeile 125: Zeile 161:
  # which just appears as “Junk” to the user underneath their inbox.
  # which just appears as “Junk” to the user underneath their inbox.
   
   
require "fileinto";
   
   
  require ["fileinto","mailbox"];
  #if header :contains "X-Spam-Flag" "YES"
#{
fileinto "Junk";
#}
   
   
  if header :contains "X-Spam-Flag" "Yes" {
   fileinto :create "Junk";
  if header :contains "X-Spam_bar" "+++++"
  stop;
{
   fileinto "Junk";
  }
  }
2. Globale Default-Sieve-Datei


Diese Default-Sieve-Datei wird verwendet, wenn keine persönliche Sieve-Datei für den User vorhanden ist. Dies ist z. B. dann der Fall, wenn Managesieve nicht genutzt werden soll.
 
'''Verzeichnis für Sieve-After-Regeln erstellen'''
 
Dies ist sinnvoll, wenn man zusätzlich Skripte durch User erstellen lassen möchte, z. B. mit Managesieve und der Roundcube-Erweiterung.
 
# mkdir /etc/dovecot/sieve-after


Alternativ ist dies sinnvoll, wenn der User ohne persönliche Sieve-Datei ein Standardverhalten erhalten soll, dieses aber vollständig vom User übersteuert können werden soll.
Neue Sieve-Regeldatei erstellen darin erstellen, z. B. ''movespam.sieve''


# mkdir /var/lib/dovecot/sieve
Inhalt der Datei siehe globale Sieve-Datei.
Datei anlegen: /var/lib/dovecot/sieve/default.sieve


require ["fileinto","mailbox"];
In beiden Fällen muss die Sieve-Regel-Datei zu einer binären Datei kompiliert werden. Das kann entweder automatisiert werden (Cron oder wie?) oder manuell angestoßen werden:
if header :contains "X-Spam-Flag" "Yes" {
  fileinto :create "Junk";
}


In beiden Fällen sollte die Sieve-Regel-Datei zu einer binären Datei kompiliert werden:
   
  sievec /etc/dovecot/sieve/spam-to-junk.sieve
  sievec /etc/dovecot/sieve/spam-to-junk.sieve
 
bzw.
bzw.


  sievec /var/lib/dovecot/sieve/default.sieve
  sievec /var/lib/dovecot/sieve/default.sieve
 
 
Sieve-Configdatei ''20-managesieve.conf'' bearbeiten und folgende Zeile einfügen, um Sieve zu aktivieren:
Sieve-Configdatei bearbeiten und folgende Zeile einfügen, um Sieve-Plugin zu aktivieren: ''20-managesieve.conf'' bzw. entsprechend ''99-my-customzation.conf''


  protocols = $protocols sieve     
  protocols = $protocols sieve     


Dovecot-Configdatei ''90-sieve.conf'' bearbeiten und folgende Zeile einfügen:


sieve = ~/.dovecot.sieve
LDA-Plugins aktivieren durch erweitern der folgenden Zeilen um Sieve in: ''15-lda.conf'' bzw. entsprechend ''99-my-customzation.conf''
sieve_dir = ~/sieve
sieve_default = /var/lib/dovecot/sieve/default.sieve    # Für Default-Skript
sieve_global_dir = /etc/dovecot/sieve
sieve_after = /etc/dovecot/sieve-after                  # Für Sieve-After-Skripte
LDA-Plugins aktivieren in ''15-lda.conf'' durch erweitern der folgenden Zeilen um Sieve:
      
      
  protocol lda {
  protocol lda {
Zeile 177: Zeile 205:
   mail_plugins = $mail_plugins sieve
   mail_plugins = $mail_plugins sieve
  }
  }
 
 
Evtl. auch "protocol lmtp" erweitern? (Findet sich in einer anderen Conf-Datei)
Evtl. auch "protocol lmtp" erweitern? (Findet sich in einer anderen Conf-Datei)
   
   
Zeile 183: Zeile 212:


  service dovecot restart
  service dovecot restart
 
Verfügbarkeit Sieve testen, Port 4190 sollte von Dovecot geöffnet sein
Verfügbarkeit Sieve testen, Port 4190 sollte von Dovecot geöffnet sein
      
      
  netstat -tulpen | grep -i dovecot   
  netstat -tulpen | grep -i dovecot   
 
Bei Problemen: http://wiki2.dovecot.org/Pigeonhole/Sieve/Troubleshooting
Bei Problemen: http://wiki2.dovecot.org/Pigeonhole/Sieve/Troubleshooting


== Dovecot Managesieve / Roundcube ==
=== Dovecot-Plugin Managesieve für Roundcube ===


Das Dovecot-Paket Managesieve ermöglicht es Usern, ihre eigenen Sieve-Regeln zu definieren, die vom Server ausgeführt werden, wenn eine neue E-Mail eingeht.
Siehe [[Roundcube als Webmail-Client (Debian)#Managesieve]]


Um userspezifische Regeln mit Managesieve in Roundcube verwalten zu können, muss das Roundcube-Plugin aktiviert werden in ''/etc/roundcube/config.inc.php'':
== Konfiguration Spamassassin ==
   
 
$config['plugins'] = array(   
=== Bayes in Spamassassin ===
  'archive',                                                                         
 
  'zipdownload',                                                                     
Kleine Einleitung zum Bayesschen Filter in SpamAssassin: https://wiki.apache.org/spamassassin/BayesInSpamAssassin
  'managesieve',                                                                     
 
);
FAQ: https://wiki.apache.org/spamassassin/BayesFaq
== SA-Learn ==


SpamAssassin-Learn einrichten:
SpamAssassin-Learn einrichten:
Zeile 226: Zeile 254:
  sa-learn --dump magic
  sa-learn --dump magic
  sa-learn --dbpath /path/to/bayesdb --dump magic
  sa-learn --dbpath /path/to/bayesdb --dump magic
=== Netzwerktests / HashSharingSysteme Razor und Pyzor ===
Was sind Netzwerktests? https://wiki.apache.org/spamassassin/UsingNetworkTests
Bei Razor und Pyzor handelt es sich um Hash-Sharing-Systeme. Was sind Hash-Sharing-Systeme? https://wiki.apache.org/spamassassin/HashSharingSystem
Wie funktioniert Razor? https://wiki.apache.org/spamassassin/UsingRazor
Wie funktioniert Pyzor? https://wiki.apache.org/spamassassin/UsingPyzor
Ein Server kann seine Spam-Informationen auch an Hash-Sharing-Systeme zurückmelden: https://wiki.apache.org/spamassassin/ReportingSpam
Installation:
# apt-get install razor pyzor
Bei Razor registrieren und Serverliste downloaden:
# razor-admin -create
# razor-admin -register
Serverliste aktualisieren:
# pyzor discover
Pyzor testen:
# pyzor ping
Das Ergebnis sollte etwa so lauten:
public.pyzor.org:24441 (200, 'OK')
Als letztes wird noch die SpamAssassin-Konfiguration '''/etc/spamassassin/local.cf''' erweitert. Unter dem Bayes-Bereich folgende Zeilen einfügen:
use_pyzor 1
pyzor_path /usr/bin/pyzor
 
use_razor2 1
razor_config /etc/razor/razor-agent.conf
Normalerweise sind in Debian die zugehörigen SpamAssassin-Plugins bereits aktiviert. Diese kan man in '''/etc/spamassassin/v310.pre''' nochmal überprüfen:
# Pyzor - perform Pyzor message checks.
<nowiki>#</nowiki>
loadplugin Mail::SpamAssassin::Plugin::Pyzor
<nowiki>#</nowiki> Razor2 - perform Razor2 message checks.
<nowiki>#</nowiki>
loadplugin Mail::SpamAssassin::Plugin::Razor2
Spamassassin neu starten:
/etc/init.d/spamassassin restart
Zum Testen der Funktionsweise von Razor und Pyzor vgl. Abschnitt '''Testen'''.
== Testen ==
Testmail senden um gesamten SMTP-Stack zu testen:
Vgl. [[Exim als SMTP-Server (Debian)#Versenden von Testmails|Exim als SMTP-Server (Debian)#Versenden von Testmails]]
Testdaten befinden sich in Debian unter '''/usr/share/doc/spamassassin/examples/'''
=== Testdurchführung Spamassassin ===
spamassassin -t < /usr/share/doc/spamassassin/examples/sample-nonspam.txt > ~/nonspam.out
spamassassin -t < /usr/share/doc/spamassassin/examples/sample-spam.txt > ~/spam.out
spamc < /usr/share/doc/spamassassin/examples/sample-nonspam.txt > ~/nonspam.out
spamc -t < /usr/share/doc/spamassassin/examples/sample-spam.txt > ~/spam.out
=== Testdurchführung Razor / Pyzor ===
spamassassin -D -t < /usr/share/doc/spamassassin/examples/sample-spam.txt 2>&1 | tee ~/sa.out
In der erstellten Datei '''sa.out''' sollte nach folgenden '''dbg: pyzor''' Ausschau gehalten werden:
cat sa.out | grep "dbg: pyzor"
Ergebnis könnte so aussehen:
Mär 30 22:02:27.032 [4039] dbg: pyzor: network tests on, attempting Pyzor
Mär 30 22:02:29.999 [4039] dbg: pyzor: pyzor is available: /usr/bin/pyzor
Mär 30 22:02:30.000 [4039] dbg: pyzor: opening pipe: /usr/bin/pyzor check < /tmp/.spamassassin4039JL3Abptmp
Mär 30 22:02:30.316 [4039] dbg: pyzor: [4041] finished: exit 1
Mär 30 22:02:30.316 [4039] dbg: pyzor: got response: public.pyzor.org:24441 (200, 'OK') 0 3
Außerdem sollte folgende Zeile enthalten sein, die auf die Nutzung von Razor und Pyzor hinweist:
check_dkim_adsp: 4 (0.2%), check_spf: 23 (1.1%), '''check_razor2: 218 (10.5%), check_pyzor: 92 (4.4%),''' tests_pri_500: 73 (3.5%)
== Troubleshooting ==
== Troubleshooting ==


Zeile 233: Zeile 331:
  # isn't finding your mails.
  # isn't finding your mails.
  mail_debug = yes
  mail_debug = yes
 
Die Logs werden nach ''/var/log/syslog'' geschrieben.
Die Logs werden nach ''/var/log/syslog'' geschrieben.


Alternativ lohnt es sich auch noch folgende Dateien zu prüfen:
Alternativ lohnt es sich auch noch folgende Dateien zu prüfen:
* /var/log/syslog
* /var/log/mail.info
* /var/log/mail.err
* /var/log/exim/maillog


== Testen ==
Testdaten befinden sich in Debian unter '''/usr/share/doc/spamassassin/examples/'''


Testdurchführung Spamassassin
[[Category:Linux]]
 
spamassassin -t < sample-nonspam.txt > nonspam.out
spamassassin -t < sample-spam.txt > spam.out
spamc < sample-nonspam.txt > nonspam.out
spamc -t < sample-spam.txt > spam.out
 
Testmail senden um gesamten SMTP-Stack zu testen:
 
Vgl. [[Exim als SMTP-Server (Debian)#Versenden von Testmails|Exim als SMTP-Server (Debian)#Versenden von Testmails]]
[[Category:Debian]]
[[Category:E-Mail]]
[[Category:E-Mail]]

Aktuelle Version vom 12. Januar 2020, 16:25 Uhr

Beschreibung, wie Spamassassin in einem Debian-Basierten Mailserver mit Exim4, Dovecot und Sieve genutzt werden kann.

Dabei wird als Exim4 nur als MTA genutzt. Als LDA kommt Dovecot zum Einsatz, welches mit Plugins um die Nutzung von Sieve-Skripten erweitert wird.

Quellen:

https://wiki.debian.org/Exim#Spam_scanning

http://www.exim.org/exim-html-current/doc/html/spec_html/ch44.html

https://linux.die.net/man/1/spamassassin

Installation

Metapaket exim4-daemon-light deinstallieren.

Metapaket exim4-daemon-heavy installieren

apt-get install exim4-daemon-heavy

SpamAssassin installieren:

apt-get install spamassassin (spamc?)

SpamAssassin aktivieren und starten

systemctl enable spamassassin.service
systemctl status spamassassin.service

Konfiguration Exim4

Configfile anpassen:

Splitkonfiguration: /etc/exim4/conf.d/acl/40_exim4-config_check_data

Ohne Split: /etc/exim4/exim4.conf.template --> Sollte hier nicht eher exim3.conf.localmacros verwendet werden?

Folgende Zeilen dekommentieren, um die Ergebnisse von Spamassassin in den Mailheader reinzuschreiben:

 warn
   condition = ${if <{$message_size}{120k}{1}{0}}
   # ":true" to add headers/acl variables even if not spam
   spam = nobody:true
   add_header = X-Spam_score: $spam_score
   add_header = X-Spam_bar: $spam_bar
   # # Do not enable this unless you have shorted SpamAssassin's report
   # add_header = X-Spam_report: $spam_report

Wenn Fetchmail genutzt wird, muss es so konfiguriert werden, dass Fetchmails E-Mails an den SMTP-Server weitergibt, statt diese direkt in die Mailbox zu legen.

Dazu in der .fetchmailrc-Datei folgende Zeile hinzufügen:

smtp <smtp-server-name>

Konfiguration Dovecot

Dovecot als lokalen LDA einrichten

Quelle: http://wiki.dovecot.org/LDA/Exim

Damit Sieve für Dovecot genutzt wird, muss Dovecot als LDA genutzt werden.

Findet die Abholung der Mails per Fetchmail statt, kann Fetchmail die Mails direkt an den Dovecot-LDA "deliver" weitergeben.

Dies kann ggf. mit Zwischenschritt über Spamasssassin bzw. spamc, welches dann die Daten per Standardausgabe an Dovecot-LDA weiter gibt, passieren.

Alternativ muss Exim angepasst werden, damit es nicht selbst als LDA fungiert, sondern die Mails an den Dovecot-LDA weiter gibt.

In dem Zuge muss die Nutzung von Procmail ggf. unterbunden werden. Procmail wird als LDA in Exim genutzt, wenn es eine Datei /etc/procmailrc gibt. Diese muss dann ggf. entfernt werden.

Am einfachsten ist es, die verteilte Konfiguration von Exim zu verwenden.

In diesem Falle wird eine neuer Transport für den Dovecot-LDA erstellt:

/etc/exim4/conf.d/transport/30_exim4-config_dovecot_pipe

Inhalt:

dovecot_pipe:
  debug_print = "T: maildrop_pipe for $local_part@$domain"
  driver = pipe

  # Use /usr/lib/dovecot/dovecot-lda  if using Debian's package.
  # You may or may not want to add -d $local_part@$domain depending on if you need a userdb lookup done.
  # command = /usr/local/libexec/dovecot/dovecot-lda -f $sender_address
  command = /usr/lib/dovecot/dovecot-lda -f $sender_address

  message_prefix =
  message_suffix =
  log_output
  delivery_date_add
  envelope_to_add
  return_path_add
  #group = mail
  #mode = 0660
  temp_errors = 64 : 69 : 70: 71 : 72 : 73 : 74 : 75 : 78

Anschließend wird der Dovecot-LDA für den lokalen Transport hinterlegt. Anpassung von: router/900_exim4-config_local_user

# transport = LOCAL_DELIVERY 
transport = dovecot_pipe

Abschließend Exim neu starten:

service exim4 restart

Dovecot-Plugins Sieve sowie Managesieve

Installation von Sieve:

# apt-get install dovecot-sieve dovecot-managesieved (dovecot-antispam?)

Die nachfolgenden Anpassungen in den Config-Files zeigen auf die Teildateien in /etc/dovecot/conf.d/

Idealerweise bleiben diese Config-Files jedoch unangetastet. Die Konfiguration sollte stattdessen in einer Sammeldatei, die nicht zum Lieferumfang der Distribution gehört, gesammelt werden, z.B.: 99-my-customzation.conf

Sieve greift in Dovecot an mehreren Stellen ein. Diese werden konfiguriert in: 90-sieve.conf bzw. entsprechend in 99-my-customzation.conf

plugin {
  sieve = file:~/sieve;active=~/.dovecot.sieve 

  # The default Sieve script when the user has none. This is the location of a
  # global sieve script file, which gets executed ONLY if user's personal Sieve
  # script doesn't exist. Be sure to pre-compile this script manually using the
  # sievec command line tool if the binary is not stored in a global location.
  # --> See sieve_before for executing scripts before the user's personal
  #     script.
  sieve_default = /var/lib/dovecot/sieve/default.sieve
  
  # Directory for :personal include scripts for the include extension. This
  # is also where the ManageSieve service stores the user's scripts.
  sieve_dir = ~/sieve
  
  # Location Sieve of scripts that need to be executed before the user's
  # personal script. 
  #sieve_before = /var/lib/dovecot/sieve.d/
  
  # Identical to sieve_before, only the specified scripts are executed after the
  # user's script (only when keep is still in effect!). Multiple script
  # locations can be specified by appending an increasing number.
  sieve_after = /etc/dovecot/sieve-after
}


Globale Default-Sieve-Datei

Diese Default-Sieve-Datei wird verwendet, wenn keine persönliche Sieve-Datei für den User vorhanden ist. Dies ist z. B. dann der Fall, wenn Managesieve nicht genutzt werden soll.

Alternativ ist dies sinnvoll, wenn der User ohne persönliche Sieve-Datei ein Standardverhalten erhalten soll, dieses aber vollständig vom User übersteuert können werden soll.

# mkdir /var/lib/dovecot/sieve

Datei anlegen: /var/lib/dovecot/sieve/default.sieve

Inhalt für Sortierung der Mails anhand des X-Spam-Flag:

# The “require” lines include functionality to move emails
# into certain folders (fileinto) and to create folders if
# they don’t exist yet (mailbox). Then if SpamAssassin marked
# a header as spam it is moved into the Junk folder
# which just appears as “Junk” to the user underneath their inbox.

require "fileinto"; 

#if header :contains "X-Spam-Flag" "YES"
#{
#  fileinto "Junk";
#}


if header :contains "X-Spam_bar" "+++++"
{
  fileinto "Junk";
}


Verzeichnis für Sieve-After-Regeln erstellen

Dies ist sinnvoll, wenn man zusätzlich Skripte durch User erstellen lassen möchte, z. B. mit Managesieve und der Roundcube-Erweiterung.

# mkdir /etc/dovecot/sieve-after

Neue Sieve-Regeldatei erstellen darin erstellen, z. B. movespam.sieve

Inhalt der Datei siehe globale Sieve-Datei.

In beiden Fällen muss die Sieve-Regel-Datei zu einer binären Datei kompiliert werden. Das kann entweder automatisiert werden (Cron oder wie?) oder manuell angestoßen werden:

sievec /etc/dovecot/sieve/spam-to-junk.sieve

bzw.

sievec /var/lib/dovecot/sieve/default.sieve


Sieve-Configdatei bearbeiten und folgende Zeile einfügen, um Sieve-Plugin zu aktivieren: 20-managesieve.conf bzw. entsprechend 99-my-customzation.conf

protocols = $protocols sieve    


LDA-Plugins aktivieren durch erweitern der folgenden Zeilen um Sieve in: 15-lda.conf bzw. entsprechend 99-my-customzation.conf

protocol lda {
  # Space separated list of plugins to load (default is global mail_plugins).
  mail_plugins = $mail_plugins sieve
}


Evtl. auch "protocol lmtp" erweitern? (Findet sich in einer anderen Conf-Datei)

Dovecot neu starten

service dovecot restart

Verfügbarkeit Sieve testen, Port 4190 sollte von Dovecot geöffnet sein

netstat -tulpen | grep -i dovecot   

Bei Problemen: http://wiki2.dovecot.org/Pigeonhole/Sieve/Troubleshooting

Dovecot-Plugin Managesieve für Roundcube

Siehe Roundcube als Webmail-Client (Debian)#Managesieve

Konfiguration Spamassassin

Bayes in Spamassassin

Kleine Einleitung zum Bayesschen Filter in SpamAssassin: https://wiki.apache.org/spamassassin/BayesInSpamAssassin

FAQ: https://wiki.apache.org/spamassassin/BayesFaq

SpamAssassin-Learn einrichten:

 sa-learn --spam <spamfolder>
 sa-learn --ham <hamfolder>

Alternativ

 sa-learn --folders=foldersfile

Wobei foldersfile folgenden Aufbau haben muss:

ham:dir:/path/to/hamfolder1
ham:dir:/path/to/hamfolder2
ham:dir:/path/to/hamfolder3
spam:dir:/path/to/spamfolder1
spam:dir:/path/to/spamfolder2
spam:dir:/path/to/spamfolder3

Statt dir kann man auch mbox verwenden. Vgl. Dokumentation https://spamassassin.apache.org/full/3.4.x/doc/sa-learn.txt

Status SA-Learn überprüfen:

sa-learn --dump magic
sa-learn --dbpath /path/to/bayesdb --dump magic

Netzwerktests / HashSharingSysteme Razor und Pyzor

Was sind Netzwerktests? https://wiki.apache.org/spamassassin/UsingNetworkTests

Bei Razor und Pyzor handelt es sich um Hash-Sharing-Systeme. Was sind Hash-Sharing-Systeme? https://wiki.apache.org/spamassassin/HashSharingSystem

Wie funktioniert Razor? https://wiki.apache.org/spamassassin/UsingRazor

Wie funktioniert Pyzor? https://wiki.apache.org/spamassassin/UsingPyzor

Ein Server kann seine Spam-Informationen auch an Hash-Sharing-Systeme zurückmelden: https://wiki.apache.org/spamassassin/ReportingSpam

Installation:

# apt-get install razor pyzor

Bei Razor registrieren und Serverliste downloaden:

# razor-admin -create
# razor-admin -register

Serverliste aktualisieren:

# pyzor discover

Pyzor testen:

# pyzor ping

Das Ergebnis sollte etwa so lauten:

public.pyzor.org:24441	(200, 'OK')

Als letztes wird noch die SpamAssassin-Konfiguration /etc/spamassassin/local.cf erweitert. Unter dem Bayes-Bereich folgende Zeilen einfügen:

use_pyzor 1
pyzor_path /usr/bin/pyzor
 
use_razor2 1
razor_config /etc/razor/razor-agent.conf

Normalerweise sind in Debian die zugehörigen SpamAssassin-Plugins bereits aktiviert. Diese kan man in /etc/spamassassin/v310.pre nochmal überprüfen:

# Pyzor - perform Pyzor message checks.
#
loadplugin Mail::SpamAssassin::Plugin::Pyzor

# Razor2 - perform Razor2 message checks.
#
loadplugin Mail::SpamAssassin::Plugin::Razor2

Spamassassin neu starten:

/etc/init.d/spamassassin restart

Zum Testen der Funktionsweise von Razor und Pyzor vgl. Abschnitt Testen.

Testen

Testmail senden um gesamten SMTP-Stack zu testen:

Vgl. Exim als SMTP-Server (Debian)#Versenden von Testmails

Testdaten befinden sich in Debian unter /usr/share/doc/spamassassin/examples/

Testdurchführung Spamassassin

spamassassin -t < /usr/share/doc/spamassassin/examples/sample-nonspam.txt > ~/nonspam.out 
spamassassin -t < /usr/share/doc/spamassassin/examples/sample-spam.txt > ~/spam.out

spamc < /usr/share/doc/spamassassin/examples/sample-nonspam.txt > ~/nonspam.out 
spamc -t < /usr/share/doc/spamassassin/examples/sample-spam.txt > ~/spam.out

Testdurchführung Razor / Pyzor

spamassassin -D -t < /usr/share/doc/spamassassin/examples/sample-spam.txt 2>&1 | tee ~/sa.out

In der erstellten Datei sa.out sollte nach folgenden dbg: pyzor Ausschau gehalten werden:

cat sa.out | grep "dbg: pyzor"

Ergebnis könnte so aussehen:

Mär 30 22:02:27.032 [4039] dbg: pyzor: network tests on, attempting Pyzor
Mär 30 22:02:29.999 [4039] dbg: pyzor: pyzor is available: /usr/bin/pyzor
Mär 30 22:02:30.000 [4039] dbg: pyzor: opening pipe: /usr/bin/pyzor check < /tmp/.spamassassin4039JL3Abptmp
Mär 30 22:02:30.316 [4039] dbg: pyzor: [4041] finished: exit 1
Mär 30 22:02:30.316 [4039] dbg: pyzor: got response: public.pyzor.org:24441 (200, 'OK') 0 3

Außerdem sollte folgende Zeile enthalten sein, die auf die Nutzung von Razor und Pyzor hinweist:

check_dkim_adsp: 4 (0.2%), check_spf: 23 (1.1%), check_razor2: 218 (10.5%), check_pyzor: 92 (4.4%), tests_pri_500: 73 (3.5%)


Troubleshooting

Erweitertes Logging kann aktiviert werden in /etc/dovecot/conf.d/10-logging.conf

# Enable mail process debugging. This can help you figure out why Dovecot
# isn't finding your mails.
mail_debug = yes

Die Logs werden nach /var/log/syslog geschrieben.

Alternativ lohnt es sich auch noch folgende Dateien zu prüfen:

  • /var/log/syslog
  • /var/log/mail.info
  • /var/log/mail.err
  • /var/log/exim/maillog