Es gibt eine Vielzahl verschiedener Mailserver. Die gängigsten im Linux Bereich sind "sendmail", "qmail" und "postfix". Nebst diesen gibt es noch "exim" und "courier". Auf Grund der Einstellungsmöglichkeiten, Verbreitung und Dokumentation ist "postfix" der sinnvollste Mailserver in der Praxis.

Der Postfix Mailserver lässt sich durch eine Reihe von anderen Anwendungen erweitern. Zum Beispiel amavisd-new, welches wiederrum auch durch eine Vielzahl von Anwendungen ergänzt werden kann um so besser Viren und Spam zu erkennen. Es ist auch problemlos möglich eigene Filter für den Postfix zu schreiben. Einige dieser externen Addons wären zum Beispiel:

  • Spam/Virenschutz
    • amavisd-new
    • spamassassin
    • clamav
    • dspam
  • Policy-Daemons
    • policyd-weight
    • postgrey
    • libspf
  • Pop/Imap
    • Courier-Imap
    • Dovecot
  • Sonstiges
    • postscreen (Bestandteil von neueren Postfix-Installationen)

Weitere finden sich hier: http://www.postfix.org/addon.html

Techniken zur Vermeidung von Spam

Im Kampf gegen UCE (Unsolicited Commercial E-Mail, zu deutsch: Unverlangte E-Mail-Werbung) haben sich die verschiedensten Techniken etabliert. Die gängigsten seien hier vorgestellt.

Greylisting

Greylisting nutzt ein Sicherheitsmerkmal welches eigentlich vor Mailverlust schützt. Wenn eine eMail aufgrund eines temporären Fehlers abgelehnt wird, wird der sendende Mailserver die eMail zeitverzögert erneut zustellen. Greylisting geht davon aus, das ein Spammer eine solche eMail _nicht_ erneut zustellen wird, weil Verbindungen nur kurz aufrecht erhalten werden können und die Resourcen für einen erneuten Versand nicht vorhanden sind. In der Praxis hat dies auch eine lange Zeit lang funktioniert - Natürlich haben sich einige Spammer angepasst und Greylisting bringt auch eigene Probleme mit sich. Unter den Postfix-Admins ist Greylisting mittlerweile immer unbeliebter, da eMails initial zeitverzögert ankommen und somit nicht gewährleistet ist, dass eine wichtige eMail sofort gelesen werden kann.

Mit der Pflege einer (automatischen) Whitelist kann dieses Problem teilweise umgangen werden. Dann gibt es aber noch das Problem der sendenden Mailserver. Ein bekannter Provider in Deutschland hat sich nach der Beschwerde einiger Kunden zu dem Thema Greylisting geäussert und gesagt "Greylisting entspricht nicht der RFC (dem Standard)" - Das Problem war, das dieser Provider eMails die temporär abgelehnt wurden teilweise erst ein bis zwei Wochen später erneut zustellte.

Entsprechend sollte Greylisting mit Bedacht eingesetzt werden. Bei der Verwendung von postscreen (siehe unten) kann auf Greylisting verzichtet werden. Wenn ein Mailserver grundsätzlich nur für eMails im Inland genutzt wird, bietet es sich möglicherweise an Greylisting für eingehende eMails aus anderen Ländern einzuschalten (So das .de, .com, .net, .info, etc. ohne Greylisting verarbeitet werden, andere TLDs wie .br .jp .us aber Greylisting erfordern).

Sender Policy Framework

Das Sender Policy Framework (kurz SPF) ist dafür gedacht das Senden von gefälschten Adressen (welche einen Großteil an Spam ausmachen) zu erschweren. Hierzu wird ein DNS Record gesetzt, welcher Informationen darüber enthält welche Computer eMails von der jeweiligen Domain versenden dürfen.

Bei eMail-Umleitungen über andere Domains (Insbesondere bei dem Versand aus Universitäten) kommt es bei direkter SPF-Prüfung häufig zu Problemen, da das Empfängersystem die IP des Umleitenden Systems sieht, welches meist nicht im SPF-Record genannt ist - Somit würde bei direkter SPF Prüfung die eMail abgelehnt werden, obwohl sie legitim ist.

Ein weiteres Problem sind Webformulare, welche häufig so programmiert sind, dass die Absenderadresse von der Person genutzt wird, welche das Formular ausfüllt. Da der sendende Mailserver aber gar nicht zuständig für diese Adresse ist, würde bei SPF Prüfung eine Ablehnung der eMail erfolgen.

Daher wird empfohlen, SPF nur zusammen mit Scoring-Mechanismen (Das heißt, durch SPF werden E-Mails nicht abgelehnt oder zugelassen sondern eine positivere bzw. negativere Punktzahl vergeben, je nach Punktzahl anderer "Prüfungen" wird die E-Mail dann später durchgelassen oder nicht - Hierfür kann z.B. Spamassassin genutzt werden) einzusetzen.

Weitere Informationen

DomainKeys Identified Mail

DomainKeys Identified Mail (kurz DKIM) ist wie SPF dafür gedacht, das Senden von gefälschten Adressen zu vermeiden. Wie bei SPF ist der Nebeneffekt Spam und Phishing zu vermindern. Hierbei wird asymmetrische Verschlüsselung genutzt und jede eMail um eine Signatur erweitert, welche als öffentlicher Schlüssel im DNS Record der Domain vorliegt - Stimmen diese nicht überein, kann die eMail aussortiert oder abgelehnt werden.

Weitere Informationen

Postscreen

Postscreen wurde entwickelt um sich dem Problem von Zombies zu widmen, mit Zombies sind in diesem Fall kompromitierte Computer von End-Usern gemeint. Mehr als 90% aller eMails sind Spam, und ein Großteil dieses Spams stammt vom solchen Zombies.

Solche Zombies haben nur eine begrenzte Zeit Spam zu versenden bevor die IP gesperrt wird. Um den Versand zu Beschleunigen gehen sie Kompromisse im SMTP-Protokol ein. Das SMTP Protokol funktioniert nach Hand-Shake Prinzip - Das heisst der Sender sendet, der Empfänger antwortet, der Sender sendet → Bei Zombies wird gesendet bevor er an der Reihe ist. Sie versuchen auch weiter eMails zuzustellen wenn der Empfänger die Befehle zum Beenden der Verbindung gesendet hat.

Genau hier setzt Postscreen an.

Weitere Informationen

Backup-Mailserver

Bei dem Einsatz von Backup-Mailservern gilt es eine Vielzahl von möglichen Problemen zu Bedenken wenn es um die Bekämpfung von Spam geht. Das größte Problem von Backup-Mailservern liegt in der Tatsache, dass die meisten Backup-Mailserver keine, oder nur eine viel schwächere Filterung einsetzen als der eigentliche eMail-Server. Das heisst, im Falle eines Ausfalls hortet der Backup-Mailserver unter Umständen Unmengen an Spam. Wird der Backup-MX nur zur Zwischenspeicherung genutzt und leitet alle eMails wieder an den eigentlichen Mailserver bei Erreichbarkeit, kann der eigentliche eMail-Server mit einem Übermaß an eMails bombardiert werden und unter der Last zusammenbrechen. Ein weiteres Problem ist, das viele Backup-Mailserver _immer_ erreichbar sind, dies wird von Spammern ausgenutzt, indem diese eMails direkt an die Backup-Mailserver senden statt an den eigentlichen Mailserver mit dem Wissen das auf dem Backup-Mailserver weniger oder gar nicht gefiltert wird.

Zu den grundsätzlichen Überlegungen bei der Verwendung eines Backup-Mailservers sollten also die obigen Punkte gehören.

Ein Backup-Mailserver wird auf DNS-Ebene verfügbar gemacht. Ein Beispiel:

$TTL 86400
@ IN SOA dns1.example.de. hostmaster.example.de. (
2011081805 ; Datum + Seriennummer
8H ; refresh, Sekunden
2H ; retry, Sekunden
1W ; expire, Sekunden
1D ) ; minimum

NS dns1.example.de.
NS dns2.example.de.
MX 10 mx.example.de.
MX 20 bmx.example.de.

example.de. A xx.xx.xx.x

; Subdomains
dns1 A xx.xx.xx.x
dns2 A xx.xx.xx.x
mx A 1.xx.xx.x
bmx A 2.xx.xx.x

; Default
* A xx.xx.xx.x 

Bei diesem Zonefile sind zwei MX Records eingetragen. Der Mailserver mit der niedrigsten Priorität ist der Haupt-Mailserver. Alle weiteren MX Records mit höherer Priorität sind Backupmailserver. Wenn der sendende Mailserver feststellt das der Erste nicht erreichbar ist, probiert er den Zweiten.

Spezielle Setups

Mailgateway

Es ist möglich Postfix als zentralen Mailgateway zu verwenden. Dabei werden alle eMails zentral vom Mailgateway empfangen, gefiltert und an den Endpunkt weitergeleitet. Der End-Mailserver braucht die eMails dann nicht mehr auf Spam und Viren zu prüfen und sollte eMails ausschliesslich vom zentralen Mailgateway annehmen. Dieses Setup kann sich lohnen wenn viele verteilte oder virtuelle Systeme genutzt werden, welche eMails empfangen. Durch den zentralen Mailgateway können eMails besser gefiltert werden (Wenn eine eMail von Sender xyz als Spam erkannt wird, profitiert jede Domain im System) und es können Resourcen gespart werden (da nicht jede virtuelle Instanz aufwändig filtern muss).

Beispiel
transport_maps = hash:/etc/postfix/transport
relay_domains = $transport_maps
relay_transport = $transport_maps
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_destination,
reject_unlisted_recipient,
permit_mynetworks,
check_recipient_access hash:/etc/postfix/unfiltered,
check_client_access hash:/etc/postfix/client_access,
check_helo_access hash:/etc/postfix/helo_checks,
check_sender_access hash:/etc/postfix/sender_checks,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname,
permit_auth_destination,
reject
 
smtpd_data_restrictions =
reject_unauth_pipelining,
reject_multi_recipient_bounce,
permit 

Der obige Auszug aus der main.cf zeigt ein Beispiel wie ein solcher Mailgateway aufgebaut sein könnte. Dabei finden sich in der Datei /etc/postfix/transports die einzelnen Domains mit ihrem Endpunkt. Zum Beispiel:

example.de relay:[xx.xx.xx.xx] 

Das heisst, alle eMails an example.de werden nach Filterung an die IP xx.xx.xx.xx gesendet. Ist xx.xx.xx.xx nicht erreichbar, wird die Mail für den eingestellten Zeitraum gespeichert und erst bei Erreichbarkeit zugestellt.

Die Datei /etc/postfix/unfiltered kann dafür genutzt werden, bestimmte Empfänger von den weiteren Filtern auszuschliessen. Der Inhalt der Datei würde beispielsweise wie folgt aussehen:

spam@example.de OK
anotherexample.de OK 

Die Datei client_access kann genutzt werden um bestimmte Clients direkt abzulehnen oder direkt zuzulassen:

wine.codeweavers.com OK
someone@foobar.com REJECT spam forbidden 

Bei helo_checks und sender_checks funktioniert es nach demselben Prinzip:

# Somebody HELO'ing as "localhost?" Impossible, we're "localhost"
localhost REJECT You are not localhost, i'm localhost
127.0.0.1 REJECT You are not localhost, i'm localhost 

localhost.localdomain 555 Your server is wrongly configured. Please assign it a proper host and domain
name.
error@mailfrom.com 554 Spam not tolerated here 

Bei den empfangenden Systemen würde man dann in der smtpd_recipient_restrictions eine Regel:

check_client_access cidr:/etc/postfix/allowed_gateway, reject 

Anlegen - Wodurch nur eMails vom Gateway erlaubt und alle weiteren rejected werden. CIDR ist eine spezielle Lookup-Tabelle in Postfix welche die Angabe von IP-Ranges ermöglicht.

Filterung mit eigenen Restriction Classes

Es ist möglich eigene Restriction-Classes anzulegen, so lässt sich beispielsweise eine Restriction-Class für Greylisting und eine für DNSBL anlegen, und daraus lässt sich dann zum Beispiel eine Restriction-Class welche Greylisting und DNSBL Checks beinhaltet anlegen.

Somit ist es möglich pro eMail Adresse und/oder Domain unterschiedlich zu filtern.

# kleiner shortcut zu den query files
query = sqlite:$config_directory/query
 
smtpd_restriction_classes = z-swl,z-dnswlAll,z-dnswlLo,z-dnswlMed,
z-dnswlHi,z-dnswlBLesp,z-zen,z-brbl,z-sem,z-ahbl,z-njabl,
z-spamcop,z-sorbs,z-trbl,z-common,z-helo,z-noSender,z-unlist,
z-semBscat,z-bscatOrg,z-bscat,z-dblC,z-dblH,z-dblS,
z-noPtr,z-noFCrDns,z-unkHelo,z-warnDefer,
# RC00 RC01 RC10 RC20 RC29 RC30 RC40 RC50
# RC00-reject, RC01-nuts,RC10-aggressive,RC20-moderate,
# RC29-whn,RC30-conservative,RC40-weak,RC50-open

### Composite classes
#
RC00 = reject

# Die nächsten fünf Regeln in absteigender Ordnung von
# Filter-Agressivität, sind jene, die dem Nutzer als
# Wahlmöglichkeit angeboten werden können. Die Nutzung
# von "open" und "weak" sind dabei nicht empfohlen.

# RC01-nuts: Nicht benutzen! Wird legitime eMail blocken
RC01 = z-common,z-noFCrDns,z-unkHelo,z-dblC,z-dblH,z-dblS,z-brbl,
z-sem,z-ahbl,z-njabl,z-trbl,z-sorbs,z-spamcop,z-bscat,
z-dnswlBLesp

# RC10-aggressive: Wenn starke Filterung wichtiger ist, als
# der seltene Verlust von legitimer Mail
# than occasionally missing a legitimate email
RC10 = z-common,z-noFCrDns,warn_if_reject,z-unkHelo,
z-dblC,z-dblH,z-dblS,z-swl,z-dnswlHi,z-brbl,z-sem,
z-dnswlMed,z-ahbl,z-njabl,
z-dnswlAll,z-trbl,z-sorbs,z-spamcop,z-bscat

# RC20-moderate
RC20 = z-common,z-noPtr,z-dblS,z-dblH,z-dblC,
z-swl,z-dnswlLo,z-brbl,z-sem,z-ahbl,z-njabl,z-bscat

# RC30-conservative: Wenn lieber mehr Spam durchgestellt werden
# soll, als den Verlust von legitimen eMails zu riskieren
RC30 = z-common,warn_if_reject,z-noPtr,
z-dblC,z-dblH,z-dblS,z-swl,z-dnswlAll,z-brbl,z-sem,z-ahbl,
z-njabl,warn_if_reject,z-bscat

# RC40-weak: tut fast nichts gegen spam.
RC40 = z-common
# Unkommentieren um eine Übersicht zu bekommen was alles hätte
# geblockt werden können (in den maillogs)
# warn_if_reject,z-noPtr,warn_if_reject,z-dblC,
# warn_if_reject,z-dblH,warn_if_reject,z-dblS,
# warn_if_reject,z-brbl,warn_if_reject,z-sem,
# warn_if_reject,z-ahbl,warn_if_reject,z-njabl,
# warn_if_reject,z-bscat

# RC50-open: Tut nichts gegen spam - Könnte aber dafür sorgen das der
# Server ein open-relay ist
RC50 = permit

# RC29-whn: Eine spezielle Klasse für eine einzige Domain definiert.
RC29 = z-common,z-noPtr,z-dblS,z-dblH,z-dblC,z-swl,z-dnswlAll,
z-brbl,z-sem,z-ahbl,z-njabl,z-bscat

### Component classes
### Die meisten tun nur eine Sache, rufen vereinzelt aber eine andere
### Restriction Class auf.
z-ahbl = reject_rbl_client,dnsbl.ahbl.org
z-brbl = reject_rbl_client,b.barracudacentral.org
z-bscat = check_sender_access,$query/access-bscat.query
z-bscatOrg = reject_rbl_client,ips.backscatterers.org
z-common = z-helo,z-unlist,z-noSender,z-zen
z-dblC = reject_rhsbl_client,dbl.spamhaus.org
z-dblH = reject_rhsbl_helo,dbl.spamhaus.org
z-dblS = reject_rhsbl_sender,dbl.spamhaus.org
z-dnswlAll = permit_dnswl_client,list.dnswl.org
### ! nutzt dnswl's code für ESP als Blacklist !
z-dnswlBLesp = reject_dnsbl_client,list.dnswl.org=127.[0..255].15.0
### ! Nicht zuhause probieren !
z-dnswlHi = permit_dnswl_client,list.dnswl.org=127.[0..255].[0..255].[3..255]
z-dnswlLo = permit_dnswl_client,list.dnswl.org=127.[0..255].[0..255].[1..255]
z-dnswlMed = permit_dnswl_client,list.dnswl.org=127.[0..255].[0..255].[2..255]
z-helo = check_helo_access,pcre:$config_directory/helo_checks,
z-njabl = reject_rbl_client,dnsbl.njabl.org
z-noFCrDns = reject_unknown_client_hostname
z-noPtr = reject_unknown_reverse_client_hostname
z-noSender = reject_unknown_sender_domain,
z-sem = reject_rbl_client,bl.spameatingmonkey.net
z-semBscat = reject_rbl_client,backscatter.spameatingmonkey.net
z-sorbs = reject_rbl_client,dnsbl.sorbs.net
z-spamcop = reject_rbl_client,bl.spamcop.net
z-swl = permit_dnswl_client,swl.spamhaus.org
z-trbl = reject_rbl_client,spamtrap.trblspam.com
z-unkHelo = reject_unknown_helo_hostname
z-unlist = reject_unlisted_recipient
z-warnDefer = check_client_access,static:warn,defer_if_reject
z-zen = reject_rbl_client,zen.spamhaus.org 

Dies soll nur einen Ausblick auf die Möglichkeiten geben; Nun kann mittels Lookup-Tabellen eine Zuordnung zwischen Filtern und Domains oder Adressen hergestellt werden. Der obige Auszug funktioniert nicht ohne weiteren Code. Eine komplette Anleitung auf Englisch zu genau diesem Beispiel mittels Sqlite findet sich hier:

Weitere Möglichkeiten finden sich auch in der Postfix-Dokumentation:

Access/Lookup-Tabellen in der Praxis

Postfix hat mehrere Lookup-Tabellen. Die gängigsten sind:

  • cidr - Eine Tabelle in welcher Classless Inter-Domain Routing (CIDR) pattern genutzt werden, also zum Beispiel: 127.0.0.0/8
  • hash - Die gängigste Lookup Tabelle
  • mysql - MySQL Datenbank
  • pcre - Für Regular Expressions
  • sqlite - SQlite Datenbank

Weitere interessante:

  • cdb - Lese-Optimierte Datenbank. Kann nicht verändert werden; muss bei Änderungen neu angelegt werden.
  • proxy - Zugriffs-Informationen via Postfix proxymap(8) service (Wird häufig vor mysql: genutzt um keine Probleme mit zuvielen Zugriffen zu erzeugen)
  • pgsql - PostgreSQL Datenbank
  • memcache - Memcache

Eine komplette Übersicht findet sich hier: http://www.postfix.org/DATABASE_README.html

Normalerweise, bei der Verwendung von Lookup-Tabellen, werden Einträge in der Form:

WAS AKTION [Nachricht] 

erstellt. Das heisst:

example.de (was) REJECT (ablehnen) spam not tolerated (nachricht)
example.de (was) OK (erlauben) 

WAS kann hierbei sein:

  • user@domain (matched email addressen)
  • domain.tld (matched domains)
  • .domain.tld (matched subdomains)
  • user@ (matched nur den part vor der domain)
  • net.work.addr.ess (matched eine IP)
  • net.work.addr (matched einen kompletten IP Bereich)
  • net.work (matched einen kompletten IP Bereich)
  • net (matched einen kompletten IP Bereich)

AKTION kann sein:

  • 4NN text (Versuche es später erneut)
  • 5NN text (Nicht erneut versuchen)
  • REJECT (Mail ablehnen)
  • DEFER (Mail ablehnen)
  • OK (Mail erlauben)

Es gibt noch weitere Aktionen wie BCC, DISCARD und FILTER. Mit FILTER wäre es möglich eMails von oder an eine bestimmte Adresse an Postgrey zu übergeben. Es ist auch möglich Restriction Classes anzugeben. Wird also eine Restriction Class für Greylisting angelegt mit dem namen "greylisting" ginge:

user@domain.tld greylisting 

Eine komplette Übersicht findet sich hier: http://www.postfix.org/access.5.html

Jede Lookup Tabelle hat hierbei noch weitere oder andere Möglichkeiten und Einschränkungen. Es bietet sich daher an die einzelnen Dokumente vor der Verwendung zu begutachten:

Andere Anwendungen

fetchmail

Fetchmail wird genutzt um eMails von anderen Providern / Hosts abzurufen. Somit ist es beispielsweise möglich die eMails von einem Mailprovider abzurufen, diese vom lokalen Mailserver filtern zu lassen und sie dann dem lokalen Nutzer zur Verfügung zu stellen.

Ein Beispiel für die /etc/fetchmailrc:

set postmaster "root"
set bouncemail
set no spambounce
properties ""
set syslog
set daemon 300

poll imap.somehost.de with proto IMAP user 'benutzername' there with password
'passwort' is 'jean' here ssl 

Die Zeile "poll imap.somehost.de with proto IMAP" bedeutet, dass eMails von imap.somehost.de mit dem Protokol IMAP abgeholt werden sollen. "user .. there" ist der Benutzername bei imap.somehost.de "with passwort .." ist das Passwort bei imap.somehost.de "is .. here" beinhaltet den Benutzer auf dem eigenen System. Am Ende werden noch Optionen angegeben - Beispielsweise ssl.

procmail / maildrop / sieve

Procmail wird zur Filterung von eMails gegeben. Allerdings ist das Einbinden von Procmail bei der Verwendung von Virtual und Maillinglisten häufig problembehaftet, weshalb manche Administratoren auf maildrop zurückgreifen. Während procmail und maildrop im MTA (mail transport agent → postfix) genutzt werden, wird Sieve im MDA (mail delivery agent → courier/dovecot) genutzt. Anders als procmail kann Sieve keine externen Programme nutzen.

Beispiel für procmail Regel

:0
        * ^Subject: \[Bug [0-9]+\]
        .bugs/ 

Diese Regel sorgt dafür, dass eMails bei denen der Betreff gematched wird, in den Ordner .bugs verschoben werden. Es handelt sich hierbei also um server-seitige Filterung/Sortierung.

:0
* >1024000
/dev/null 

Dieses Regel würde alle eMails die größer als 1 MB sind nach /dev/null verschieben, und somit löschen.

:0fw
* <1024000
| /usr/bin/spamc 

Mit dieser Regel werden alle eMails die kleiner als 1 MB sind an Spamassassin zur Prüfung auf Spam gegeben.

Beispiel für maildrop Regel


    if (/^X-Advertisement:.*/ || /^X-Mailer:.*(Advanced Mass)/ || /^X-Spam-Status: YES / || /^Message-ID:*<>/:h){
        exception {
            to $DEFAULT/.Trash/
        }
    }

Alle eMails die in den Headern X-Advertisenment, X-Mailer: …(Advanced Mass), etc haben, werden in den Mülleimer (Ordner Trash) verschoben.


`test -f vacation.msg && exit 1 || exit 0`
if ($RETURNCODE==1)
{
    {
        if (!/^List-Unsubscribe:.*/:h )
        {
            if (!/^X-Spam-Flag: YES/:h )
            {
                RESPOND="$MAILDIR/$USER.autorespond.msg"
                RESPONDDB="$MAILDIR/$USER.autorespond.db"

                # The following must be one contiguous line
                cc "| mailbot -t $RESPOND -d $RESPONDDB -D 1 \
                -A 'From: $RECIPIENT' -s 'Auto Response: from $RECIPIENT' \
                /usr/sbin/sendmail -t -f ''"
            }
        }
    }
}

Dieses Beispiel prüft zunächst ob es die Datei vacation.msg gibt (Hier wird also vorausgesetzt das "local" und nicht "virtual" von Postfix zur Zustellung genutzt wird - Es existieren also echte User für die eMails), wenn ja, wird geprüft ob es sich um eine eMail von einer Maillinglist oder um Spam handelt (anhand der Mail-Header) wenn nicht, wird die Datei autorespond.msg herangezogen und ein Auto-Resonse versendet. (Beispiel entnommen von http://en.gentoo-wiki.com/wiki/Maildrop)

Beispiel für sieve Regel

if header :contains "from" ["ebay.de", "ebay.com"]
  { fileinto "INBOX.ebay"; }

Wenn im Header "FROM" ebay.de oder ebay.com vorkommt, soll die eMail in den Ordner ebay verschoben werden.

if size :over 10M { reject;}

Wenn die eMail größer als 10 MB ist, soll sie abgelehnt werden.

if header :contains "subject" "viagra" { discard; }

Wenn im eMail Betreff viagra auftaucht, soll die eMail verworfen werden (Anders als bei Reject, gibt es also keine Rückmeldung an den Sender - Wodurch Backscatter ausgeschlossen wird)

Nützliche Informationen / Links

 

Hotline
 
Hotline des Rechenzentrums

Fragen? Rufen Sie uns an!
Montag - Freitag 10:00 - 19:00 Uhr

+49 69 - 900 180 - 0

 
Aktionen & News
 

Dedizierte Supermicro Xeon Server - ab 70,00 Euro

Angebote

 

Zweiter Standort
 
Hotline des Rechenzentrums

Erfahren Sie mehr über unseren zweiten Standort in der Hanauer Landstrasse in Frankfurt am Main.

mehr erfahren

Zertifizierungen
 
TüV geprüftes Rechenzentrum
ISO 27001 zertifiziertes Rechenzentrum
ISO 9001 zertifiziertes Rechenzentrum


Knowledge Base
 

Hilfreiche Artikel zum Thema Netzwerk, Server & IT.

mehr erfahren


Galerie
 

Sehen Sie sich in einem virtuellen Rundgang in unserem Rechenzentrum um:

Niederspannungshauptverteilung Unterbrechungsfreie Strom Versorgung
Kaltwassererzeuger Bereitstellung individueller SAT-Dienstleistungen


100% Ökostrom
 
100% Öko-Strom