Alt, tot, überholt, schlecht, nicht nachmachen 🙂
Dieses soll eine kleine Beschreibung über die Gründe, die eigentliche Installation
und Einrichtung meines privaten Mailservers werden. Also kein HowTo!
Sollte jemand Fragen oder Anregungen haben, freue ich mich natürlich
über jede E-Mail.
Solltest du Fragen stellen achte bitte darauf deine Frage so genau wie irgend
möglich zu stellen. Beschreibe kurz dein Problem, haue mich nicht mit log und
configs zu und habe etwas Geduld. Ich bekomme nicht nur eine E-Mail am Tag. Darum
werde ich ganz sicher nur auf unfreundliche und ungenaue Fragen antworten. KEINER
hat ein Recht drauf von mir Support zu bekommen!!
Nun, die Situation bei mir schaut ca. so aus: Meine Familie, der Nachbar und ich
selbst sitzen zusammen im Netzwerk. Zu dem kommt immer mal wieder Besuch zu uns.
Da wir auch etwas mehr Platz als der normale Durchschnitt haben, finden auch oft
irgendwelche LANs usw. bei uns stat. Zu dem hängt noch eine Firma und ein
geschlossenes WLAN mit drin.
Da ist ein Problem mit der Sicherheit natürlich vorprogrammiert und den überblick
kann man da so einfach auch nicht mehr behalten. Das Netzwerk ist daher in mehrere Bereiche,
mit unterschiedlichen Rechten aufgeteilt worden. Das Netzwerk ist zum Internet hin
durch eine Firewall, Proxy und MTA abgeschirmt. Zu Proxy und Firewall sind andere
Projektbeschreibungen zu finden.
Die Hauptgründe für die Einrichtung des MTA sind also folgende:
– Zentraler Check der E-Mails auf Viren
– Zentraler Check der E-Mails auf Spam
– Einfachere Einschränkung der Bandbreite (damit eine E-Mail nicht die Internetverbindung lahmlegt.
– Keine zusätzliche Software auf den Clients
– Interner schneller E-Mail Verkehr, auch mit sehr grossen Daten
Alle E-Mails von externen Usern werden über Fetchmail vom Postfach des jeweiligen
Providers abgeholt. Werden dann sofort vom AntivirMailgate auf Viren überprüft
und müssen dann einen genauen Check durch Spamassassin über sich ergehen lassen.
Ist die E-Mail virenverseucht, bekommt der Postmaster (also ich) eine genaue Information
über den Virus, den Absender und den Empfänger der E-Mail. Der Absender und der
eigentliche Empfänger bekommt eine kurze Nachricht darüber, dass die E-Mail nicht
weitervermittelt wurde und mit welchem Virus diese E-Mail verseucht war. Sollte die E-Mail
als Spam klassifiziert werden wird vor den Betreff der E-Mail das Wort *****SPAM*****
geschrieben, ein kleiner Bericht angefertigt und diesem dann die eigentliche E-Mail
angehängt. Das ganze wird im Postfach des Empfängers abgelegt. So kann dieser
über seinen E-Mail Client die vermeintlichen Spam E-Mails entsprechend seiner Wünsche
weiter sortieren oder gar löschen. Da die vermeintliche Spam E-Mail dem Bericht
angehängt wird, hat er aber immer die Möglichkeit die E-Mail noch einmal zu
begutachten. Es könnte sich ja auch im eine wirkliche E-Mail handeln. Ist die E-Mail
aber virenfrei und kein Spam wird sie einfach im Postfach des Users abgelegt.
Alle E-Mails von den internen Clients durchlaufen die gleiche Routine bis zu einer
bestimmten Stelle. Ist die E-Mail für einen User bestimmt, der auch auf dem Mailserver
existiert, so wird die E-Mail direkt in dessen Postfach abgelegt und muss nicht erst durchs
Internet wandern. Somit ist auch bei 15 MB (1und1) nicht schon Schluss, sondern er wird an
den maximal möglichen Angaben des MTA gemessen.
Sollte die E-Mail für einen User ausserhalb des MTA bestimmt sein, wird sie an den MTA
des ISP weitergeleitet.
So nun aber zur Konfiguration des Ganzen. Konfigurationspunkte, welche ich aus privaten
oder sicherheitstechnischen Gründen lieber nicht öffentlich preisgeben
möchte, habe ich etwas umgeschrieben oder unter den Tisch fallen lassen.
Fangen wir mit der Konfiguration von Fetchmail an. Ich habe mir unter /etc/ eine
Datei mit dem Namen fetchmail.conf angelegt. Diese Datei sollte nach Möglichkeit
nur vom User root und dem User zu lesen sein, der für den Fetchmaildienst verantwortlich
ist. Denn in dieser Datei stehen die Zugangsdaten zu allen E-Mailpostfächern des ISP bzw.
E-Maildienstanbieters im Klartext. Durch einiges herumprobieren habe ich herausgefunden, dass
es bei einer ADSL-Leitung ganz sinnvoll ist alle 320 Sekunden nach neuen E-Mails in den
Postfächern des ISP zu schauen. Zwar blockiert sich Fetchmail nicht selbst, da wenn
Fetchmail gerade mit dem E-Mailchecken beschäftigt ist startet es sich nicht einfach
noch einmal parallel neu aber wenn man die Zeit unter 320 Sekunden setzt kommt es vor dass
der ISP meint es seien jetzt mal zu viele Anmeldungen in zu kurzer Zeit auf das Postfach
und dieses dann einfach mal für ein paar Minuten oder gar Stunden sperrt. Nimmt man
über 320 Sekunden muss man einfach zu lange auf E-Mails warten, da man ja auch wieder
die Zeit mitberechnen muss, die Fetchmail fürs abrufen der E-Mails braucht!
Ich starte fetchmail per init script im runlevel 3 mit dem Befehl:
fetchmail -d 320 -f /etc/fetchmail.conf
Die Option d startet fetchmail als Deamon im Hintergrund und zwar alle 320 Sekunden
(dafür die 320). Mit der Option f gebe ich fetchmail die zu nutzende Konfigurationsdatei an.
Die Konfigurationsdatei kann man in mehreren Arten formatieren. Ich habe mich für die
unten angezeigte Art entschieden. Da ich E-Mails von verschiedenen Servern abholen muss
und es so am übersichtlichsten finde. Es muss aber jeder für sich entscheiden
welche ihm besser gefällt. Ich beschränke mich hier aber auf die von mir genutzte Art.
############ /etc/fetchmail.conf # Anfang ############
set postmaster "postmaster"
set bouncemail
set no spambounce
set properties ""
poll pop.gmx.net with proto POP3
user 'info@gmx.net' there with password 'eienei' is 'peter1' here options fetchall
user 'info@gmx.li' there with password 'sksieneu' is 'klaus' here options fetchall
poll pop.1und1.com with proto POP3
user 'pt3732737' there with password 'safadsfg' is 'maus' here options fetchall
user 'pt302020' there with password 'aerfe' is 'peter1' here options fetchall
poll pop.t-online.de with proto POP3
user '000835444444444444400001' there with password '23424364' is 'bilder' here options keep
user '000835888888888001' there with password '334524364' is 'hund' here options keep
############ /etc/fetchmail.conf # Ende ############
Wie man sehen kann stehen in den ersten 4 Zeilen ein paar, selbsterklärende Angeben
für Fetchmail. Das Wort poll sagt Fetchmail: „Achtung, aber hier bezieht sich alles
auf den nachfolgenden Server!“ im ersten Fall also auf pop.gmx.net. With proto POP3 gibt
Fechtmail dann noch das zu nutzende Protokoll für die übertragung an. Bei mir in allen
Fällen pop3. in der nächsten Zeile werden Fetchmail nun die Daten für die einzelnen,
auf diesem Server zu überprüfenden, Postfächer übergeben. Hinter user folgt in
Hochkomma der Username für das Postfach beim ISP. there with password braucht normalerweise
auch schon keine genaue Beschreibung mehr. Hier wird in Hochkomma halt das zugehörige Passwort
für das Postfach angegeben. Direkt dahinter taucht is auf. Hinter is wird in Hochkomma nun der
Unix-Username des Benutzers auf dem lokalen MTA angegeben, in wessen Postfach die abgerufenen
E-Mails einsortiert werden. Der Punkt options fetchall weist Fetchmail an alle E-Mails erst vom
Server herunterzuladen und dann dort zu löschen. Es gibt natürlich auch die Möglichkeit
dieser dort liegen zu lassen und nur die Kopien herunterzuladen. Dafür ist die Option keep
zu setzten, was in den letzten beiden Zeilen der Konfigurationsdatei zu sehen ist. Einem
lokalen User kann natürlich auch mehr als ein externes Postfach zugeordnet werden. Dieses
ist in Zeile 7 und 12 zu sehen. Die Konfigurationsdatei sollte sich ohne grosses Denken
sofort verständlich lesen lassen. Fetchmail lässt sich auch dazu überreden die
E-Mails verschlüsselt vom ISP abzuholen. Genaue Informationen gibt es bei mir oder
am besten mit dem Befehl: man fetchmail
Um die E-Mails nun auf dem lokalen System zu bewegen und auch an Spamassassin weiterzugeben,
nutze ich das Programm Procmail. Diese benötigt eine eigene Konfigurationsdatei. Diese
habe ich in /etc/ angelegt und procmailrc genannt.
############ /etc/procmailrc# Anfang ############
PATH=$HOME/bin:/usr/bin:/usr/local/bin:
####################
# AntiSpam Section #
####################
:0 hbfw
| /usr/bin/spamassassin -P
############ /etc/procmailrc # Ende ############
Der Aufbau ist so simpel und kurz… Da spare ich mir jede Erklärung. Sollten noch
Fragen da sein: Googeln oder Mailen.
Beim Programm Spamassassin wird es schon wieder interessanter. Es braucht natürlich
auch eine Konfigurationsdatei. Diese ist bei mir unter: /etc/mail/spamassassin zu finden
und nennt sich local.cf
############ /etc/spamassasin/local.cf # Anfang ############
# How many hits before a message is considered spam.
required_hits 5.0
rewrite_header Subject *****SPAM*****
# Encapsulate spam in an attachment
report_safe 1
# Use terse version of the spam report
use_terse_report 0
# Enable the Bayes system
use_bayes 1
# Enable Bayes auto-learning
auto_learn 1
# Enable or disable network checks
skip_rbl_checks 0
use_razor2 1
use_dcc 1
use_pyzor 1
# Mail using languages used in these country codes will not be marked
# as being possibly spam in a foreign language.
ok_languages all
# Mail using locales used in these country codes will not be marked
# as being possibly spam in a foreign language.
ok_locales all
############ /etc/spamassasin/local.cf # Ende ############
Auch hier sind die Angaben selbsterklärende und schon in der Konfigurationsdatei
beschrieben. Hier taucht erst der Parameter auf, dann eine 0 für deaktiviert, eine
1 für aktiviert oder eine genauerer Angabe zum Parameter. Wenn eine E-Mail mehr als
5.0 Punkte bekommt wird sie als Spam klassifiziert. Spamassassin ist in der Lage
selbstständig zu lernen. Bis es das Filtern von Spam richtig beherrscht sollte man
den Wert vielleicht auf 4.0 oder 4.5 setzten. Hier sollte man ein bischen mit den Werten
herumprobieren.
Jetzt werden die E-Mails also schon mal auf Spam überprüft und sie werden auch
zwischen MTA, in meinem Fall Postfix, usw. herumgereicht. Die E-Mails sollen nun noch auf
Viren getestet werden. Dies sollte aber so passieren, dass keine E-Mail sich am Virenscanner
vorbei schleichen kann. Ich nutze das AntivirMailgate dafür. Dieses stellt einen eigenen
SMPT-Server und lauscht, anstelle von Postfix, auf dem TCP Port 25. Mit den passenden Regeln
in der Firewall (Firewallprojekt) müssen nun alle E-Mails im ganzen Netzwerk hier durch.
Damit das AntivirMailgate auch wirklich so arbeiten muss man natürlich noch ein paar Sachen umstellen..
Im Ordner /etc/ liegt die Datei services. Dort sollte man folgende beiden Einträge hinzufügen:
antivir 10024/tcp #Port for avgated
smtp-backdoor 10025/tcp #Port for postfix backdoor
Jetzt können einige Programme das ganze auch etwas übersichtlicher in den logs usw.
aufschlüsseln und wir können mit der Konfiguration des Mailgates fortfahren. Im
Ordner /etc/ sollte die Konfigurationsdatei avmailgate.conf liegen. In dieser müssen
nun diese beiden Einträge eingegeben werden, bzw. die Kommentarzeichen angepasst werden.
ListenAddress localhost port antivir
ForwardTo SMTP: localhost port smtp-backdoor
Der erste Eintrag gibt dem Mailgate an auf dem gerade in den services angegebenen Port zu arbeiten.
Zeile zwei sagt dem Mailgate wohin er die E-Mails nach dem Testen weitergeben soll. Wie man sieht
taucht hier wieder smtp-backdoor auf. Will man sich den Eintrag in /etc/services sparen kann man hier
natürlich dann auch die Ports eintragen. Das ganze kann ich aber nicht empfehlen.
Nun sind noch zwei kleine änderungen an Postfix zu machen. Im Ordner /etc/postfix/ gibt es
die Datei master.cf
In dieser sind folgende änderungen zu machen:
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (50)
smtp inet n n - - smtpd
localhost:smtp-backdoor inet n ; n - - smtpd -o content_filter =
Mit diesen änderungen sagt man Postfix das es selbst die Finger von den ankommenden E-Mails
lassen soll. Dieses soll ja unser Mailgate erledigen 🙂 Es sollte aber darauf geachtet werden dass,
das erste Zeichen in der Tabelle kein Leerzeichen und kein Tab ist. Sonst gibt es einen Fehler und
man suchst sich Stundenlang tot (ja, es ist mir passiert!).
Zum Schluss nun nur noch folgendes in die Datei main.cf im Ordner /etc/postfix/ packen:
#AntiVir Einbindung
content_filter = smtp:127.0.0.1:10024
Jetzt läuft dann auch schon unsere Virenprüfung. Wie man jetzt genau das Programm Antivir
und welche Zusatzoptionen man nun noch beim Mailgate macht, ist wieder so eine Sache mit dem Probieren.
Ich gebe natürlich auch gerne dabei noch eine Hilfestellung. Nur sollte man es selbst
schon einmal ausprobiert haben.
Was fehlt nun noch? Genau die Konfiguration des MTA (Postfix). Sonst geht ja schon alles…
Du solltest sicher gehen das du sasl libs usw. installiert hast. Sonst kommt am Ende die Meldung das
der Service nicht zur Verfügung steht (sobald du versuchst eine E-Mail an deinen ISP weiter zu
schicken). Genau so wichtig ist auch ein installierter popd, welcher auf Port 110 lauscht. Sonst
ist es Essig mit dem Abrufen der E-Mails vom Server.. Hier habe ich in den Anfängen auch
schon mal etwas länger grübeln dürfen.
Ich will alle E-Mails für externe User über den Mailserver von 1und1 schicken. Der ist
über den DNS-Namen smtp.1und1.com zu erreichen. Um E-Mails über den verschicken zu
können muss ich mich dort anmelden. Daher brauche ich dort einen Usernamen und ein Kennwort,
diese habe ich ja automatisch, sobald ich dort eine E-Mail Adresse besitze. Ich habe also im
Ordner /etc/postfix die Datei sasl_passwd angelegt. Die Datei hat folgenden Inhalt:
############ /etc/postfix/sasl_passwd # Anfang ############
smtp.1und1.com pt3333333-3:3333333
############ /etc/postfix/sasl_passwd # Ende ############
In diese Datei kommt zuerst der Server um den es sich handelt. Er muss genau so geschrieben
werden wie später der relay host in der postfix Konfiguration. Hier also smtp.1und1.com! Nun folgt
eine Leerzeile und dann pt3333333-3 dieses ist der Username für die Anmeldung am Mailserver des ISP.
Direkt dahinter kommt ein „:“! Dieses gibt an dass hier der Username endet und das zugehörige Passwort
beginnt. In unserem Fall 3333333! Plöp… Das war es auch schon. Man sollte nie vergessen aus diesen
Dateien, auch access und alias.. bla, eine Datenbank zu erstellen. Sonst ist man schon wieder seinen Fehler
am suchen! Das geht mit postmap /pfad/Dateiname
Im gleichen Ordner finden wir nun die Datei access. In dieser sollte man erst mal alle Einträge
auskommentieren. Nur dieser darf drinbleiben:
127 RELAY
Das sagt Postfix nun folgendes: Nur E-Mails die von einer IP Adresse kommen welche mit 127 beginnt werden
überhaupt angenommen und weiterverarbeiten. Da die 127..bla für die localhost Geschichte gedacht
ist werden jetzt erst mal nur E-Mails vom eigenen Host angenommen und verarbeitet. Ich habe bei mir
mehrere Netze aber alle beginnen mit 192.168.! Daher schaut meine Datei am Ende so aus:
127 RELAY
192.168 RELAY
Hat man nur ein Netz, sagen wir mal 192.168.50.0, dann sollte man das natürlich auch so angeben.
Damit haben wir schon mal sichergestellt, dass keine scheiss Spamer unseren schönen Server als
„offenen relay host“ nutzen können. SEHR WICHTIG!! Gut, speichern und raus.. Was haben wir
vergessen? Genau postmap :-)…
Jetzt schauen wir uns im gleichen Ordner mal die Datei aliases an. In dieser sollte schon so einiges
an Usernamen stehen. Las diese bitte auch erst mal so, es sei denn du weisst was du tust! Der Aufbau ist
aber ganz simpel. Links steht der Aliasname und rechts der wirkliche Username im lokalen System. Möchte
ich also das alle E-Mails die an peter-hat-es-dicke@mailserver.de gesendet werden, dem lokalen User
peter1 zugeteilt werden dann trage ich folgendes ein:
peter-hat-esdick: peter1
Das Spielchen kann ich mit so vielen User- und Aliasnamen machen wie ich Lust und Zeit habe.
Da gibt es nun aber noch eine interessante Datei mit namen canonical! In dieser steht meist nur
auskommentierter Krims. Der Sinn der Datei ist aber folgender. Ist mein Username auf dem lokalen
System hanz, meine E-Mail Adresse aber wurst und ich schicke z.B.: über die Konsole eine E-Mail
ab. So wird als Absender folgendes angegeben:
hanz@mailserver.de
Tja, die Adresse gibt es nicht oder gehört nicht mir. Ist so also schon mal scheisse. Wenn
ich aber nun in die Datei cononical folgendes eintrage:
hanz wurst@mamama.de
Wird immer, sofern nicht anders vom Mailclient oder ähnlich angegeben, mein Absender auf
wurst@mamama.de gesetzt. Toll nicht?
So, alles schön gespeichert und auch jeweils an postmap gedacht? Sehr gut! Dann schauen wir uns
mal die Datei main.cf an. Ja, die ist schön voll 🙂 Wir sausen daher mal direkt ans Ende der
Datei. Hier tippern wir nun folgendes ein:
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relayhost = smtp.1und1.com
smtp_sasl_security_options = noanonymous
smtp_always_send_ehlo = yes
message_size_limit = 1024000000
mailbox_size_limit = 1024000000
myhostname = mailserver.de
smtpd_banner = $myhostname ESMTP (S-wie-Sicker)
Dann schauen wir zuerst die ganze Datei durch ob wir nicht damit gerade doppelte
Einträge gemacht haben. Interessant hierbei ist natürlich nur der Teil links
vor dem „=“! Sollten wir doppelte haben, kommentieren wir diese oben aus. Jetzt ganz
schnell wieder runter ans Ende!
smtp_sasl_auth_enable sagt Postfix das wir uns am Mailserver vom ISP anmelden müssen,
smtp_sasl_password_maps sagt Postfix mit welchen Zugangsdaten das ganze passieren soll und
relayhost sagt welcher Host überhaupt der Mailserver unseres ISPs(oder sonst wer) ist.
smtpd_banner verändere ich nur, damit nicht jeder sofort sehen kann, mit welchem SMTP-Server
er sich gerade bei mir unterhält. So hat ein Angreifer es etwas schwerer Sicherheitslöcher
zu nutzen. Da er ja erst mal keine Ahnung hat welche es in diesem System gerade gibt.
mailbox_size_limit gibt die maximale Grösse der Usermailboxen auf dem lokalen System an.
message_size_limit die maximale Grösse der E-Mails, die ein lokaler User verschicken kann.
message_size_limit sollte sinnvollerweise nie grösser als mailbox_size_limit sein.
Tja, das war es dann auch schon.
–==Ende==–
… Nachdem nun Yahoo die Eier hatte einfach mal ihre DMARC Policy „scharf“ (reject) zu schalten und sich so viel Schimpfe von aller Welt dafür eingesammelt hat und beschuldigt wurde die Mailinglisten „kaputt“ zu machen…. Tja, da zieht AOL nun in gewisser Weise nach: 