07.02.2013

E-Mail-Server 4: postgrey, spamassassin, clamav, postfix-filter

Nachdem sowohl [[/e-mail-server-1-ldap-debian-wheezy/|LDAP]], [[/e-mail-server-2-dovecot-debian-wheezy/|Dovecot]] und [[/e-mail-server-3-postfix-debian-wheezy/|Postfix]] eingerichtet sind kommen wir nun zu den SPAM-Filtern und Virenchecks.

Spamfilter/Virenscanner

Die Installation wird gestartet mit:

apt-get install amavisd-new clamav-daemon spamassassin razor pyzor

Gesteuert werden Spamfilter und Virenscanner über amavis, damit dieser mit clamav interagieren darf ist noch ein Benutzer anzulegen und der Gruppe amavis zuzuordnen:

adduser clamav amavis

Nun kann amavis mit clamav (und dem Spamfilter) bekannt gemacht werden. Dies geschieht über die Datei /etc/amavis/conf.d/15-content_filter_mode:

# /etc/amavis/conf.d/15-content_filter_mode

use strict;

@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);

@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

1;

Die neue Konfiguration wird über /etc/init.d/amavis restart aktiviert. Der korrekte Start kann mit lsof -i TCP:10024 überprüft werden. Das Ergebnis sollte wie folgt aussehen:

COMMAND    PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
amavisd-n 7745 amavis    5u  IPv4  29777      0t0  TCP localhost:10024 (LISTEN)
amavisd-n 7747 amavis    5u  IPv4  29777      0t0  TCP localhost:10024 (LISTEN)
amavisd-n 7748 amavis    5u  IPv4  29777      0t0  TCP localhost:10024 (LISTEN)

Der Spamfilter wird durch setzen von ENABLED=1 in /etc/default/spamassassin und den Aufruf von /etc/init.d/spamassassin restart aktiviert.

Damit amavis und somit Virenscanner und Spamfilter überhaupt aktiv werden, müssen diese noch mit Postfix verheiratet werden. Dies geschieht über /etc/postfix/main.cf bzw. /etc/postfix/master.cf.

/etc/postfix/main.cf erhält folgende Zeile:

# /etc/postfix/main.cf

content_filter=smtp-amavis:[127.0.0.1]:10024

Die Konfigurationseinstellungen in /etc/postfix/master.cf sind etwas komplexer, am Ende der Datei wird folgendes angefügt:

# /etc/postfix/master.cf

smtp-amavis     unix    -       -       -       -       2       smtp
        -o smtp_data_done_timeout=1200
        -o smtp_send_xforward_command=yes
        -o disable_dns_lookups=yes
        -o max_use=20

127.0.0.1:10025 inet    n       -       -       -       -       smtpd
        -o content_filter=
        -o local_recipient_maps=
        -o relay_recipient_maps=
        -o smtpd_restriction_classes=
        -o smtpd_delay_reject=no
        -o smtpd_client_restrictions=permit_mynetworks,reject
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o smtpd_data_restrictions=reject_unauth_pipelining
        -o smtpd_end_of_data_restrictions=
        -o mynetworks=127.0.0.0/8
        -o smtpd_error_sleep_time=0
        -o smtpd_soft_error_limit=1001
        -o smtpd_hard_error_limit=1000
        -o smtpd_client_connection_count_limit=0
        -o smtpd_client_connection_rate_limit=0
        -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks

Unterhalb der Zeile pickup fifo n - - 60 1 pickup werden folgende Zeilen hinzugefügt:

# /etc/postfix/master.cf

         -o content_filter=
         -o receive_override_options=no_header_body_checks

Nach diesen Änderungen wird postfix neu gestartet: /etc/init.d/postfix restart

Wenn die Einstellungen korrekt gesetzt sind sollte eine E-Mail folgendes Header aufweisen:

Received: from localhost (localhost [127.0.0.1])
    by ldap.21x9.org (Postfix) with ESMTP id 26E7F76BC1
    for <gpkvt@ldap.21x9.org>; Thu, 25 Aug 2011 16:52:31 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at ldap.21x9.org
Received: from ldap.21x9.org ([127.0.0.1])
    by localhost (ldap.21x9.org [127.0.0.1]) (amavisd-new, port 10024)
    with ESMTP id xYZrfPsjOUas for <gpkvt@ldap.21x9.org>;
    Thu, 25 Aug 2011 16:52:28 +0200 (CEST)
Received: from [192.168.1.23] (unknown [192.168.1.23])
    by ldap.21x9.org (Postfix) with ESMTPSA id 8D5F276B13
    for <gpkvt@ldap.21x9.org>; Thu, 25 Aug 2011 16:52:28 +0200 (CEST)

Der Spamfilter ist derzeit noch so eingestellt, dass der Spamfilter Mails nicht kennzeichnet werden. Um dies zu ändern müssen in /etc/amavis/conf.d/20-debian_defaults folgende Variablen (um)gesetzt werden:

# /etc/amavis/conf.d/20-debian_defaults

$sa_tag_level_deflt  = undef;
$sa_tag2_level_deflt = 5;
$sa_kill_level_deflt = 10;

Die entsprechenden Zeilen sind bereits vorhanden und müssen nur abgeändert werden.

Zum Übernehmen der Änderungen muss Amavis neu gestartet werden:

/etc/init.d/amavis restart

Eine erneute Testmail sollte nun folgendes im Header aufweisen:

X-Virus-Scanned: Debian amavisd-new at ldap.21x9.org
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 required=5 tests=[ALL_TRUSTED=-1,
    DKIM_ADSP_NXDOMAIN=0.8] autolearn=no

WICHTIG: In der Anfangsphase sollte der Wert $sa_kill_level_deflt recht hoch gewählt werden. In den gewünschten Mails sollte dann der Maximalwert ermittelt und der Wert entsprechend nach unten korrigiert werden. Alternativ kann man Spamassassin auch ein HAM und SPAM-Postfach übergeben aus welchem es entsprechend lernt. Dank der Filterlisten razor und pyzor sollte das aber überflüssig sein.

postgrey/greylisting

Postgrey ist derzeit nicht installiert, sollte das Spamaufkommen zu hoch steigen kann dies aber leicht nachgeholt werden. Postgrey schützt vor Spam, indem Mails von unbekannten Absendern zunächst mit einem temporären Fehler abgelehnt werden. Der einliefernde Mailserver ist dann für einen weiteren Zustellversuch verantwortlich. Je nach Einstellung des Mailservers kann es wenige Sekunden, aber auch mehrere Stunden dauern, bis ein erneuter Zustellversuch unternommen wird. Erfolgt ein zweiter Versuch innerhalb einer definierten Zeitspanne lässt postgrey die Mail passieren. Typische SPAM-Botnetze unternehmen keinen erneuten Zustellversuch.

Die Installation wird gestartet durch:

apt-get install postgrey

Ob postgrey korrekt gestartet wurde kann mit lsof -i TCP:10023 überprüft werden, es sollte folgendes ausgegeben werden:

COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
postgrey 4382 postgrey    6u  IPv4  18839      0t0  TCP localhost:10023 (LISTEN)

Nun muss postgrey noch in die postfix-Config übernommen werden, hierzu wird die Zeile smtpd_recipient_restrictions in /etc/postfix/main.cf erweitert durch:

# /etc/postfix/main.cf

check_policy_service inet:127.0.0.1:10023

Normalerweise überprüft Postfix erst nachdem die smtpd_recipient_restrictions abgearbeitet wurden ob ein Empfänger einer Mail überhaupt existiert. Damit ein externer Mailserver eine solche Mail nicht durch das Greylisting erneut zustellt sollte vor der check_policy_service Zeile noch reject_unlisted_recipient eingefügt werden, damit Mails an unbekannte Empfänger sofort verworfen werden.

Anschließend wird postfix neu gestartet: /etc/init.d/postfix restart

In /etc/default/postgrey kann festgelegt werden, wie lange ein Mailserver mind. mit einem erneuten Zustellversuch warten darf, und wie lange der erste Versuch maximal zurückliegen darf. Außerdem können Absender, deren Mails regelmäßig durch das Greylisting hindurchgelassen wurden automatisch in eine Whitelist aufgenommen werden:

# /etc/default/postgrey

# postgrey startup options, created for Debian
# (c)2004 Adrian von Bidder <avbidder@fortytwo.ch>
# Distribute and/or modify at will.

# you may want to set
#   --delay=N   how long to greylist, seconds (default: 300)
#   --max-age=N delete old entries after N days (default: 30)
# see also the postgrey(8) manpage

POSTGREY_OPTS="--inet=127.0.0.1:10023 --delay=60 --max-age=120 --auto-whitelist-clients=1"

# the --greylist-text commandline argument can not be easily passed through
# POSTGREY_OPTS when it contains spaces.  So, insert your text here:
POSTGREY_TEXT="Temporarily rejected (greylisting), please try again later."

WICHTIG: Bis Debian 5.0 war der postgrey-Standardport 60000, ab Debian 6.0 wechselte er auf 10023. In älteren Anleitungen zu Postgrey findet man daher noch die veraltete Portangabe 60000.

Sollte ein Mailserver (von dem Mails gewünscht werden) sehr hohe Wiederholintervalle aufweisen, so kann er in die Whitelist (/etc/postgrey/whitelist_clients) aufgenommen werden. Derzeit gibt es (neben den Standardeinträgen) folgende Whitelisteinträge:

# /etc/postgrey/whitelist_clients

# postgrey version: 1.34, build date: 2011-05-04

# Debian-specific additions
# I *know* they run real mail queues, so greylisting only creates
# bigger load for them.
debconf.org
debian.org
spi-inc.org
/.*\.startcom\.org$/

# greylisting.org: Southwest Airlines (unique sender, no retry)
southwest.com
# greylisting.org: isp.belgacom.be (wierd retry pattern)
isp.belgacom.be
# greylisting.org: Ameritrade (no retry)
ameritradeinfo.com
# greylisting.org: Amazon.com (unique sender with letters)
amazon.com
# 2004-05-20: Linux kernel mailing-list (unique sender with letters)
vger.kernel.org
# 2004-06-02: karger.ch, no retry
karger.ch
# 2004-06-02: lilys.ch, (slow: 4 hours)
server-x001.hostpoint.ch
# 2004-06-09: roche.com (no retry)
gw.bas.roche.com
# 2004-06-09: newsletter (no retry)
mail.hhlaw.com
# 2004-06-09: no retry (reported by Ralph Hildebrandt)
prd051.appliedbiosystems.com
# 2004-06-17: swissre.com (no retry)
swissre.com
# 2004-06-17: dowjones.com newsletter (unique sender with letters)
returns.dowjones.com
# 2004-06-18: switch.ch (works but personnel is confused by the error)
domin.switch.ch
# 2004-06-23: accor-hotels.com (slow: 6 hours)
accor-hotels.com
# 2004-06-29: rr.com (no retry, reported by Duncan Hill)
/^ms-smtp.*\.rr\.com$/
# 2004-06-29: cox.net (no retry, reported by Duncan Hill)
/^lake.*mta.*\.cox\.net$/
# 2004-06-29: motorola.com (no retry)
mot.com
# 2004-07-01: nic.fr (address verification, reported by Arnaud Launay)
nic.fr
# 2004-07-01: verizon.net (address verification, reported by Bill Moran and Eric, adapted by Adam C. Mathews)
/^s[cv]\d+pub\.verizon\.net$/
# 2004-07-02: cs.columbia.edu (no retry)
cs.columbia.edu
# 2004-07-02: papersinvited.com (no retry)
66.216.126.174
# 2004-07-02: telekom.de (slow: 6 hours)
/^mail\d+\.telekom\.de$/
# 2004-07-04: tiscali.dk (slow: 12 hours, reported by Klaus Alexander Seistrup)
/^smtp\d+\.tiscali\.dk$/
# 2004-07-04: freshmeat.net (address verification)
freshmeat.net
# 2004-07-11: zd-swx.com (unique sender with letters, reported by Bill Landry)
zd-swx.com
# 2004-07-11: lockergnome.wc09.net (unique sender with letters, reported by Bill Landry)
lockergnome.wc09.net
# 2004-07-19: mxlogic.net (no retry, reported by Eric)
p01m168.mxlogic.net
p02m169.mxlogic.net
# 2004-09-08: intel.com (pool on different subnets) 
/^fmr\d+\.intel\.com$/
# 2004-09-17: cox-internet.com (no retry, reported by Rod Roark)
/^fe\d+\.cox-internet\.com$/
# 2004-10-11: logismata.ch (no retry)
logismata.ch
# 2004-11-25: brief.cw.reum.de (no retry, reported by Manuel Oetiker)
brief.cw.reum.de
# 2004-12-03: ingeno.ch (no retry)
qmail.ingeno.ch
# 2004-12-06: rein.ch (no retry)
mail1.thurweb.ch
# 2005-01-26: tu-ilmenau.de (no retry)
piggy.rz.tu-ilmenau.de
# 2005-04-06: polymed.ch (no retry)
mail.polymed.ch
# 2005-06-08: hu-berlin.de (slow: 6 hours, reported by Joachim Schoenberg)
rz.hu-berlin.de
# 2005-06-17: gmail.com (big pool, reported by Beat Mueller)
proxy.gmail.com
# 2005-06-23: cacert.org (address verification, reported by Martin Lohmeier)
cacert.org
# 2005-07-27: polytech.univ-mrs.fr (no retry, reported by Giovanni Mandorino)
polytech.univ-mrs.fr
# 2005-08-05: gnu.org (address verification, reported by Martin Lohmeier)
gnu.org
# 2005-08-17: ciphirelabs.com (needs fast responses, reported by Sven Mueller)
cs.ciphire.net
# 2005-11-11: lufthansa (no retry, reported by Peter Bieringer)
/^gateway\d+\.np4\.de$/
# 2005-11-23: arcor-online.net (slow: 12 hours, reported by Bernd Zeimetz)
/^mail-in-\d+\.arcor-online\.net$/
# 2005-12-29: netsolmail.com (no retry, reported by Gareth Greenaway)
netsolmail.com
# mail.likopris.si (no retry, reported by Vito Robar)
193.77.153.67
# jcsw.nato.int (several servers, no retry, reported by Vito Robar)
195.235.39
# tesla.vtszg.hr (no retry, reported by Vito Robar)
tesla.vtszg.hr
# mailgw*.iai.co.il (pool of several servers, reported by Vito Robar)
/^mailgw.*\.iai\.co\.il$/
# gw.stud-serv-mb.si (no retry, reported by Vito Robar)
gw.stud-serv-mb.si
# mail.commandtech.com (no retry, reported by Vito Robar)
216.238.112.99
# duropack.co.at (no retry, reported by Vito Robar)
193.81.20.195
# mail.esimit-tech.si (no retry, reported by Vito Robar)
193.77.126.208
# mail.resotel.be (ocasionally no retry, reported by Vito Robar)
80.200.249.216
# mail2.alliancefr.be (ocasionally no retry, reported by Vito Robar)
mail2.alliancefr.be
# webserver.turboinstitut.si (no retry, reported by Vito Robar)
webserver.turboinstitut.si
# mil.be (pool of different servers, reported by Vito Robar)
193.191.218.141
193.191.218.142
193.191.218.143
194.7.234.141
194.7.234.142
194.7.234.143
# mail*.usafisnews.org (no retry, reported by Vito Robar)
/^mail\d+\.usafisnews\.org$/
# odk.fdv.uni-lj.si (no retry, reported by Vito Robar)
/^odk.fdv.uni-lj.si$/
# rak-gentoo-1.nameserver.de (no retry, reported by Vito Robar)
rak-gentoo-1.nameserver.de
# dars.si (ocasionally no retry, reported by Vito Robar)
mx.dars.si
# cosis.si (no retry, reported by Vito Robar)
213.143.66.210
# mta?.siol.net (sometimes no or slow retry; they use intermail, reported by Vito Robar)
/^mta[12].siol.net$/
# pim-N-N.quickinspirationsmail.com (unique sender, reported by Vito Robar)
/^pim-\d+-\d+\.quickinspirationsmail\.com$/
# flymonarch (no retry, reported by Marko Djukic)
flymonarch.com
# wxs.nl (no retry, reported by Johannes Fehr)
/^p?smtp.*\.wxs\.nl$/
# ibm.com (big pool, reported by Casey Peel)
ibm.com
# messagelabs.com (big pool, reported by John Tobin)
/^mail\d+\.messagelabs\.com$/
# ptb.de (slow, reported by Joachim Schoenberg)
berlin.ptb.de
# registrarmail.net (unique sender names, reported by Simon Waters)
registrarmail.net
# google.com (big pool, reported by Matthias Dyer, Martin Toft)
google.com
# orange.fr (big pool, reported by Lo?c Le Loarer)
/^smtp\d+\.orange\.fr$/
# citigroup.com (slow retry, reported by Michael Monnerie)
/^smtp\d+.citigroup.com$/
# cruisingclub.ch (no retry)
mail.ccs-cruising.ch
# digg.com (no retry, Debian #406774)
diggstage01.digg.com
# liberal.ca (retries only during 270 seconds, Debian #406774)
smtp.liberal.ca
# pi.ws (pool + long retry, Debian #409851)
/^mail[12]\.pi\.ws$/
# rambler.ru (big pool, reported by Michael Monnerie)
rambler.ru
# free.fr (big pool, reported by Denis Sacchet)
/^smtp[0-9]+-g[0-9]+\.free\.fr$/
/^postfix[0-9]+-g[0-9]+\.free\.fr$/
# thehartford.com (pool + long retry, reported by Jacob Leifman)
/^netmail\d+\.thehartford\.com$/
# abb.com (only one retry, reported by Roman Plessl)
/^nse\d+\.abb\.com$/
# 2007-07-27: sourceforge.net (sender verification)
lists.sourceforge.net
# 2007-08-06: polytec.de (no retry, reported by Patrick McLean)
polytec.de
# 2007-09-06: qualiflow.com (no retry, reported by Alex Beckert)
/^mail\d+\.msg\.oleane\.net$/
# 2007-09-07: nrl.navy.mil (no retry, reported by Axel Beckert)
nrl.navy.mil
# 2007-10-18: aliplast.com (long retry, reported by Johannes Feigl)
mail.aliplast.com
# 2007-10-18: inode.at (long retry, reported by Johannes Feigl)
/^mx\d+\..*\.inode\.at$/
# 2008-02-01: bol.com (no retry, reported by Frank Breedijk)
/^.*?.server.arvato-systems.de$/
# 2008-06-05: registeredsite.com (no retry, reported by Fred Kilbourn)
/^(?:mail|fallback-mx)\d+.atl.registeredsite.com$/
# 2008-07-17: mahidol.ac.th (no retry, reported by Alex Beckert)
saturn.mahidol.ac.th
# 2008-07-18: ebay.com (big pool, reported by Peter Samuelson)
ebay.com
# 2008-07-22: yahoo.com (big pool, reported by Juan Alonso)
yahoo.com
# 2008-11-07: facebook (no retry, reported by Tim Freeman)
/^outmail\d+\.sctm\.tfbnw\.net$/
# 2009-02-10: server14.cyon.ch (long retry, reported by Alex Beckert)
server14.cyon.ch
# 2009-08-19: 126.com (big pool)
/^m\d+-\d+\.126\.com$/
# 2010-01-08: tifr.res.in (no retry, reported by Alex Beckert)
home.theory.tifr.res.in
# 2010-01-08: 1blu.de (long retry, reported by Alex Beckert)
ms4-1.1blu.de
# 2010-03-17: chello.at (big pool, reported by Jan-willem van Eys)
/^viefep\d+-int\.chello\.at$/
# 2010-05-31: nic.nu (long retry, reported by Ivan Sie)
mx.nic.nu
# 2010-06-10: Microsoft servers (long/no retry, reported by Roy McMorran)
bigfish.com
frontbridge.com
microsoft.com
# 2010-06-18: Google/Postini (big pool, reported by Warren Trakman)
postini.com
# 2011-02-04: evanzo-server.de (no retry, reported by Andre Hoepner)
/^mx.*\.evanzo-server\.de$/
# 2011-05-02: upcmail.net (big pool, reported by Michael Monnerie)
upcmail.net

Es ist auch möglich bestimmte (Empfänger-)Mailadressen vom Greylisting auszunehmen. Dies geschieht über die Datei /etc/postgrey/whitelist_recipients:

# /etc/postgrey/whitelist_recipients

postmaster@
abuse@

Weitere Anti-SPAM-Maßnahmen können Header-Checks oder die Einbindung von Spamlisten (z.B. spamhaus.org) sein((http://www.debian-administration.org/articles/168)).

Logfiles

Sowohl Dovecot als auch Postfix teilen sich ein gemeinsames Logfile /var/log/mail.*. In der Regel reicht es aus, sich /var/log/mail.info anzusehen. In /var/log/mail.err werden ausschließlich Fehlermeldungen gesammelt, die aber auch in /var/log/mail.info zu finden sind und oftmals ist der Kontext bei der Fehlersuche hilfreich.

Bei Problemen kann es hilfreich sein alle Mailserverdienste einmal neu zu starten und dabei das Logfile (tail -f /var/log/mail.info) im Auge zu behalten:

/etc/init.d/postfix restart
/etc/init.d/dovecot restart
/etc/init.d/postgrey restart
/etc/init.d/amavis restart
/etc/init.d/clamav-daemon restart
/etc/init.d/spamassassin restart

Auch empfangene E-Mails selbst können sehr aufschlussreich sein, z.B. wenn der Mailempfang stark verzögert wird, oder ein Kunde einen Bounce erhält und weiterleitet.

Received: from localhost (localhost [127.0.0.1])
    by ldap.21x9.org (Postfix) with ESMTP id 42F1476B0B
    for <gpkvt@ldap.21x9.org>; Fri, 26 Aug 2011 13:55:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at ldap.21x9.org
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level: 
X-Spam-Status: No, score=-0.2 required=5 tests=[ALL_TRUSTED=-1,
    DKIM_ADSP_NXDOMAIN=0.8] autolearn=no
Received: from ldap.21x9.org ([127.0.0.1])
    by localhost (ldap.21x9.org [127.0.0.1]) (amavisd-new, port 10024)
    with ESMTP id s1pSRz-BcPdj for <gpkvt@ldap.21x9.org>;
    Fri, 26 Aug 2011 13:55:31 +0200 (CEST)
Received: from [192.168.1.42] (unknown [192.168.1.42])
    by ldap.21x9.org (Postfix) with ESMTPSA id CD47476B0A
    for <denis.witt@ldap.21x9.org>; Fri, 26 Aug 2011 13:55:30 +0200 (CEST)

Wichtig ist den Mailheader von unten nach oben zu lesen. Bei diesem Beispiel wurde die Mail vom Rechner mit der IP 192.168.1.42 an den SMTP-Server ldap.21x9.org eingeliefert. Anschließend wurde die Mail vom SMTP-Server an Amavis weitergeleitet und es erfolgte der Spam- und Virencheck. Anschließend wurde die Nachricht in ein lokales Postfach einsortiert.

Der Received-Headerabschnitt kann durchaus sehr lang werden, wenn mehrere Mailserver an Versand/Empfang beteiligt sind. So ist es möglich den kompletten Weg einer Mail durch das Internet (und interne Netze) nachzuvollziehen. Die Angaben können auch sehr hilfreich sein um eine postgrey-Whitelist anzulegen, falls ein Mailserver sehr lange Wiederholintervalle gesetzt hat.

Tests

Um zu überprüfen, ob der Spamfilter korrekt funktioniert reicht es aus eine Mail mit folgendem Inhalt zu versenden:

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

Daraufhin sollte der Spamfilter, je nach Konfiguration entweder eine Mail mit folgendem Inhalt zurücksenden:

A message from <gpkvt@ldap.21x9.org> to:
-> test@ldap.21x9.org

was considered unsolicited bulk e-mail (UBE).

Our internal reference code for your message is 08116-01/k2HigvqkQGJ1

The message carried your return address, so it was either a genuine mail
from you, or a sender address was faked and your e-mail address abused
by third party, in which case we apologize for undesired notification.

We do try to minimize backscatter for more prominent cases of UBE and
for infected mail, but for less obvious cases of UBE some balance
between losing genuine mail and sending undesired backscatter is sought,
and there can be some collateral damage on both sides.

First upstream SMTP client IP address: [192.168.1.42] 
According to a 'Received:' trace, the message originated at: [192.168.1.42],
  [192.168.1.42] unknown [192.168.1.42]

Return-Path: <gpkvt@ldap.21x9.org>
From: Denis Witt <gpkvt@ldap.21x9.org>
Message-ID: <4E566C7D.2020708@ldap.21x9.org>
Subject: test

Delivery of the email was stopped!

Oder aber folgender Logfileeintrag (/var/log/mail.log) entstehen:

Jun 26 11:03:53 pdc amavis[9242]: (09242-17) Blocked SPAM, [217.11.61.100] [217.11.61.100] <root@example.de> -> <gpkvt@example.de>, quarantine: A/spam-AzRT6ktii1L3.gz, Message-ID: <20120626090318.A5D222D04185@mx1.example.de>, mail_id: AzRT6ktii1L3, Hits: 1000, size: 746, 11821 ms

Neben dem Spam- und Virenscanner werden außerdem bestimmte Dateitypen geblockt. Dies kann z.B. mit einer EXE als Dateianhang getestet werden. Folgende Mail sollte die Folge sein:

No viruses were found.

Banned name: application/x-ms-dos-executable,.empty,Screensaver.exe
Content type: Banned
Internal reference code for the message is 08116-02/sccgLIuv6Pm5

First upstream SMTP client IP address: [192.168.1.23] 
According to a 'Received:' trace, the message originated at: [192.168.1.23],
  [192.168.1.23] unknown [192.168.1.23]

Return-Path: <fkochem@ldap.21x9.org>
From: fabian kochem <fkochem@ldap.21x9.org>
Message-ID: <4E566CA2.5080605@ldap.21x9.org>
Subject: Test
The message has been quarantined as: s/banned-sccgLIuv6Pm5

The message WAS NOT relayed to:
<gpkvt@ldap.21x9.org>:
   554 5.7.0 Reject, id=08116-02 - BANNED: application/x-ms-dos-executable,.empty,Screensaver.exe

Um den Virenscanner zu testen ist eine Mail mit folgendem Inhalt (als Dateianhang, gerne auch als ZIP-Datei) praktisch:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Resultat sollte folgendes sein:

A virus was found: Eicar-Test-Signature

Scanner detecting a virus: ClamAV-clamd

Content type: Virus
Internal reference code for the message is 08116-03/Y7ztyO-Q1+fE

First upstream SMTP client IP address: [192.168.1.42] 
According to a 'Received:' trace, the message originated at: [192.168.1.42],
  [192.168.1.42] unknown [192.168.1.42]

Return-Path: <gpkvt@ldap.21x9.org>
From: Denis Witt <gpkvt@ldap.21x9.org>
Message-ID: <4E566DF7.2030908@ldap.21x9.org>
Subject: test
The message has been quarantined as: Y/virus-Y7ztyO-Q1+fE

The message WAS NOT relayed to:
<fkochem@ldap.21x9.org>:
   250 2.7.0 Ok, discarded, id=08116-03 - INFECTED: Eicar-Test-Signature

Virus scanner output:
  p002: Eicar-Test-Signature FOUND

Die Mails werden hierbei nicht sofort gelöscht, sondern im Verzeichnis /var/lib/amavis/virusmails gespeichert (sowohl SPAM- als auch Virusmails). Sie können von dort einfach in das entsprechende Empfängerpostfach verschoben werden, sollten sie dennoch zugestellt werden. Zuvor müssen die Nachrichten ggf. mit gunzip entpackt werden. Anhand der Dateinamen (z.B. spam-Nq9fd5lGtsFT.gz, virus-Y7ztyO-Q1+fE oder banned-sccgLIuv6Pm5) kann man leicht erkennen, warum eine Mail in der Quarantäne gelandet ist.

Whitelist

Leider gibt es immer wieder Kundenserver mit falscher/nicht ausreichender Konfiguration. Oft fehlt z.B. der korrekte Reverse DNS-Eintrag was unseren Mailserver veranlasst die Kommunikation zu beenden. Per Whitelist ist es aber möglich die entsprechenden Server von der Prüfung auszunehmen.

Hierbei ist es wichtig alle Server-IPs zu erfassen. In der Regel lässt sich eine entsprechende Liste über die Abfrage der MX-Server erstellen:

dig MX example.com

Der Output sollte folgendes enthalten:

;; ANSWER SECTION:
example.com.            7386    IN  MX  10 mail1.example.com.
example.com.            7386    IN  MX  20 mail2.example.com.

Mittels ping lässt sich nun die IP-Adresse ermitteln:

ping -c 1 mail1.example.com
PING mail1.example.com (1.2.3.4) 56(84) bytes of data.
64 bytes from 1.2.3.4: icmp_req=1 ttl=242 time=36.5 ms
...
ping -c 1 mail2.example.com
PING mail2.example.com (2.3.4.5) 56(84) bytes of data.
64 bytes from 2.3.4.5: icmp_req=1 ttl=242 time=36.5 ms

Die beiden IPs werden nun in die Whitelist eingetragen:

# /etc/postfix/client_whitelist

1.2.3.4 OK
2.3.4.5 OK

Nun muss die Whitelist aktiviert werden:

postmap /etc/postfix/client_whitelist
postfix reload

Der Befehl postmap erstellt hierbei die eigentliche Whitelist (client_whitelist.db) und das reload aktiviert die Änderungen.

Damit die Whitelist überhaupt Verwendung findet ist einmalig die Postfix-Config selbst anzupassen. Hierzu wird der Parameter check_client_access in die smtpd_recipient_restrictions aufgenommen:

# /etc/postfix/main.cf

smtpd_recipient_restrictions = 
     check_client_access hash:/etc/postfix/client_whitelist

Hierbei ist die Reihenfolge entscheidend. Fügt man den Check erst hinter einen anderen Check ein, so wird dieser wie gewohnt durchgeführt und erst die nachfolgenden Checks werden übersprungen. Um einen rDNS-Check zu umgehen muss der Eintrag der Whitelist also zwingend vor reject_invalid_hostname liegen. Es ist möglich check_client_access mehrfach zu verwenden, so können verschiedene Whitelists genutzt werden, die nur einzelne Checks überspringen.

Header Checks

Die oben genannte Whitelist lässt sich nur auf IP-Adressen anwenden. Will man andere Daten nutzen um Mails an- oder abzulehnen kann PCRE mit header_checks genutzt werden.

Hierzu wird folgende Zeile in /etc/postfix/main.cf eingefügt:

# /etc/postfix/main.cf

header_checks = pcre:/etc/postfix/header_checks

Anschließend wird die Datei mit Regeln befüllt:

# /etc/postfix/header_checks

/^To:.*noreply\@/           REJECT  noreply means no reply, please write to info@21x9.org instead, thanks.
/^To:.*no-reply\@/          REJECT  no-reply means no reply, please write to info@21x9.org instead, thanks.
/^From: <info@example\.com>/    REJECT

Im ersten Teil wird der reguläre Ausdruck eingefügt. Anschließend kommt die Aktion welche bei einem Match ausgeführt wird. Optional kann noch eine eigene Meldung angegeben werden, welche der Mailserver als Fehlermeldung an den Client zurückliefert.

Tags: imported