Mailserver mit Sendmail/Fetchmail/POP3/Imap und SMTP-AUTH unter NetBSD
Autor: Karsten Kruse
In dieser Anleitung will ich mich mit Sendmail und SMTP-Auth beschäftigen. SMTP-Auth ist in letzter Zeit sehr populär geworden. Dem wollen wir Tribut zollen, indem wir es benutzen. Einige ISPs bieten sogar nichts anderes mehr an, so dass man keine Wahl hat, als sich damit auseinanderzusetzen.
Glücklicherweise haben wir es mit NetBSD gar nicht schwer. Das System bietet uns dank pkgsrc einen einfachen Einstieg. Weil Maillösungen unter unixartigen Systemen typischerweise sehr flexibel sind und eine Fülle an Möglichkeiten bieten, werde ich mich auf einen sehr typischen und einfachen Fall beschränken.
Ein NetBSD-Rechner erledigt die Mail für ein privates LAN und verschickt ausgehende Mail über Sendmail nach außen an ein Mailrelay, das die weitere Auslieferung übernimmt. Eingehende Mail wird mit Fetchmail aus verschiedenen POP3- oder IMAP-Mailboxen auf unseren NetBSD-Rechner geholt. Dort können Clients im LAN die Mail dann via POP3 abholen oder mit IMAP lesen.
Hier ist ein Schema:
INTERNET LAN
+-----------------+ +---------------------------------------+
| | | |
| +------------+ | Fetchmail | +----------------+ POP3 +--------+ |
| | POP3-Konten| --------------> | | -----> | | |
| +------------+ | | | | | | |
| | | | | | | |
| | | | NetBSD-Rechner | | Client | |
| | | | | | | |
| +------------+ | SMPT-Auth | | | SMTP | | |
| | Mailrelay | <-------------- | | <----- | | |
| +------------+ | | +----------------+ +--------+ |
| | | |
+-----------------+ +---------------------------------------+
Die Anzahl der POP3-Konten und Client-Rechner ist egal, da wir alle ausgehende Mail über ein Mailrelay versenden können, unabhängig davon was wir als Absenderadresse in unserer Mail stehen haben. Damit kommen wir auch schon zu der Liste der Anforderungen, die dieser Weg stellt:
Als erstes brauchen wir ein Mailrelay. Die meisten Provider bieten ihren Kunden Mailaccounts, bei denen die Absenderadresse immer die Adresse des Mailaccounts sein muss. Ein Mailrelay arbeitet anders: hier kann man Mail mit jeglicher Absenderadresse abschicken, und das Mailrelay kümmert sich dann um die weitere Auslieferung.
Wie kommt man also an ein solches Mailrelay? Fast alle Provider bieten es an, allerdings muss man schon genau suchen oder sogar nachfragen. Wer gar kein Mailrelay hat kann sich bei einem Provider einen Account mieten.
Als Beispiele möchte ich zwei typische Fälle aufzeigen:
1. Als Kunde bei T-Online kann man z.B. gegen eine monatliche Gebühr deren Mailrelay benutzen.
2. Als Kunde von kleineren Providern, die kein Mailrelay anbieten, kann man sich z.B. für ein kleines Paket
bei einem anderen, flexibleren Provider begeistern. Als Beispiel sei hier ganz uneigennützig unser Sponsor
(http://www.bw-networx.net/) ans Herz gelegt. ;)
Die meisten Provider bieten das Mailrelay aber umsonst an.
Nachdem wir unser Mailrelay haben, fehlen noch POP3 oder IMAP-Konten für die Clients. Ich habe z.B. von meinem ISP ein Konto, eines bei dem "Umsonst-Anbieter" GMX und ein weiteres, das zu meiner Webseite gehört. Die Anzahl der POP3-Konten ist im Prinzip egal und wird nur durch die verfügbare Bandbreite beschränkt.
Natürlich brauchen wir noch einen installierten NetBSD-Rechner der Zugang zum Internet hat. Außerdem muß auf diesem Rechner pkgsrc installiert sein. Hier nochmal alles im Überblick:
Das installieren ist dank pkgsrc ein Spaziergang, für Sendmail gibt es aber etwas zu beachten: weil wir Unterstützung für die SASL- und STARTTLS-Libraries brauchen, fügen wir der Datei /etc/mk.conf folgendes hinzu:
USE_SASL=YES USE_STARTTLS=YES
NetBSDs pkgsrc wird diese Datei auswerten und die entsprechenden Funktionen in Sendmail einbauen. Jetzt können wir alle Pakete installieren, die benötigt werden. Ich gehe davon aus, das pkgsrc auf aktuellem Stand ist und in /usr/pkgsrc installiert wurde:
cd /usr/pkgsrc/mail/sendmail make install cd /usr/pkgsrc/mail/procmail make install cd /usr/pkgsrc/mail/imap-uw make install cd /usr/pkgsrc/mail/fetchmail make install
Die Programme sind installiert, und pkgsrc hat sich um Abhängigkeiten gekümmert. Was bleibt ist die Konfiguration der einzelnen Pakete:
Fangen wir mit Sendmail an, seine Konfiguration ist am schwierigsten. Wir beginnen mit dem einbinden des aus pkgsrc gebauten Sendmail in das System. NetBSD bringt von Haus aus eine Datei /etc/mailer.conf (man mailer.conf) mit, die es ermöglicht, das benutzte Mailpaket zu ändern. Im System sind z.B. die Sendmail- und die Postfix-Suite, welche man benutzt, kann man mit der Datei einstellen. Es handelt sich also um einen Mailwrapper.
Unser Glück ist es, dass der Sendmail den wir aus pkgsrc installiert haben eine fertige mailer.conf mitbringt. Wir benennen einfach die orginal /etc/mailer.conf um und legen dann einen symbolischen Link auf die neue mailer.conf:
mv /etc/mailer.conf /etc/mailer.conf_orginal ln -fs /usr/pkg/share/examples/sendmail/mailer.conf /etc/mailer.conf
Das war es schon. Das System wird ab jetzt den Sendmail aus pkgsrc benutzen. Die Konfigurationsdateien liegen, wie auch vorher schon, in /etc/mail/. Besonders wichtig sind für uns folgende Dateien:
Wir beginnen mit /etc/mail/access und tragen ans Ende der Datei ein, welche Hosts, Domains oder Netzwerkabschnitte unseren NetBSD-Rechner als Mailrelay benutzen dürfen. Üblicherweise sind das unser ganzes Netzwerk und unsere ganze Domain. Meine Domain habe ich .home genannt und sie kann mit DNS auch in meinem Netz aufgelöst werden. Außerdem trage ich noch meinen Netzwerkabschnitt als IP-Bereich ein:
# Meine Domain ist .home und relay ist erlaubt .home RELAY # Mein Netzwerk beginnt mit 192.168.1 und relay ist erlaubt 192.168 RELAY # Loopback darf immer relayen 127 RELAY
Wer keinen eigenen DNS hat, trägt seine Host/IP-Mappings in die Datei /etc/hosts ein (man hosts). Sendmail erwartet die Daten aus /etc/mail/access als Datenbank, also erstellen wir diese:
makemap hash /etc/mail/access.db < /etc/mail/access
Als nächstes erstellen wir /etc/mail/authinfo, dort tragen wir die Auth-Informationen ein, die wir benötigen um später Mail erfolgreich über das Mailrelay unseres Providers abzusetzen. Ich zeige als Beispiel meine eigene Datei, natürlich müßt ihr eure eigenen Daten einfügen:
AuthInfo:mail.bw-networx.net "U:karsten" "P:supergeheim"
AuthInfo:mail.bw-networx.net sagt, dass die folgenden Daten für das Mailrelay mail.bw-networx.net sind, "U:karsten" ist der Username mit dem ich mich anmelde und "P:supergeheim" enthält mein supergeheimes Passwort. Damit nicht jeder diese Daten lesen kann, ändern wir die Rechte der Datei, so daß nur Root sie lesen und schreiben darf. Danach erstellen wir auch daraus eine Datenbank und ändern auch deren Rechte:
chmod 600 /etc/mail/authinfo makemap hash /etc/mail/authinfo.db < /etc/mail/authinfo chmod 600 /etc/mail/authinfo.db
Weiter geht es mit der Datei /etc/mail/genericstable. Dort tragen wir die Mappings von internem Usernamen und externer Mailadresse ein. Sagen wir es gibt einen User "karsten" dessen reale Mailadresse kk@irgendwo.com ist. Nehmen wir weiter an, der Host auf dem der User eine Mail schreiben will ist ein Host, der nicht im Internet per Namen aufzulösen ist, z.B. uberhost.home. Würde der User also eine Mail schreiben, wäre der Absender karsten@uberhost.home. Keiner könnte eine Mail von diesem User beantworten, weil der Name im Internet nicht aufzulösen ist.
Also müssen wir die Absenderadresse umschreiben und dazu nehmen wir /etc/mail/genericstable. So könnte sie aussehen:
karsten: kk@irgendwo.com karl: kalle@provider.net lotta: lottchen@domain.de
Sendmail erwartet auch diese Datei als Datenbank. Das erledigt der folgende Befehl:
/usr/sbin/sendmail -bi -oA/etc/mail/genericstable
Als nächstes erstellen wir die Datei /etc/mail/virtusertable und tragen dort die Absenderadressen ein die nicht erst nach draussen gehen sollen weil es einen lokalen User gibt dem diese Adresse gehört.
Als Beispiel: Der User karl sendet eine Mail an kk@irgendwo.com. Normalerweise geht die Mail über das Gateway raus und kommt via fetchmail wieder rein weil kk@irgendwo.com ja in Wirklichkeit der lokale User karsten ist. Warum also erst rausschicken und wieder reinholen? Warum nicht gleich lokal ausliefern?
Genau das macht die /etc/mail/virtusertable.db. Um sie anzulegen tragen wir folgendes in /etc/mail/virtusertable ein:
kk@irgendwo.com karsten kalle@provider.net karl lottchen@domain.de lotta
Danach erstellen wir mit folgendem Befehl daraus eine Datenbank:
makemap hash /etc/mail/virtusertable.db < /etc/mail/virtusertable
Damit die Einträge aus virtusertable auch funktionieren müssen alle Domainnamen in die
Datei /etc/mail/local-host-names eingetragen werden:
irgendwo.com provider.net domain.de
Als letztes bleibt noch die Datei /etc/mail/sendmail.cf, die wir mit einigen M4-Macros erstellen. Dazu wechseln wir in das Verzeichnis /usr/pkg/share/sendmail/m4/ und erstellen folgende Datei als mycf.mc:
divert(-1)dnl include(`../m4/cf.m4')dnl VERSIONID(`mycf.mc von root')dnl OSTYPE(bsd4.4)dnl dnl # Ein Kommentar beginnt mit dnl und Anweisungen enden mit dnl dnl # Kommando zum Neuerstellen der sendmail.cf: dnl # cd /usr/pkg/share/sendmail/m4/ ; m4 mycf.mc > /etc/mail/sendmail.cf dnl # Um korrektes Masquerading zu ermöglichen, muß hier unser Hostname rein GENERICS_DOMAIN(uberhost.home uberhost)dnl dnl # Wir wollen die genericstable benutzen (user zu echter Mailadresse mappen) FEATURE(genericstable)dnl FEATURE(masquerade_envelope)dnl dnl # Hier tragen wir unser Mailrelay ein define(`SMART_HOST',`mail.bw-networx.net')dnl FEATURE(redirect)dnl FEATURE(nocanonify)dnl dnl # Das brauchen wir für Fetchmail FEATURE(`accept_unresolvable_domains')dnl dnl # Einige Mailclients schreiben >mailadresse< FEATURE(`accept_unqualified_senders')dnl define(`SMTP_MAILER_FLAGS',`e')dnl define(`confCON_EXPENSIVE',`True')dnl define(`confTO_QUEUEWARN', `16h')dnl define(`confDEF_CHAR_SET',`ISO-8859-1')dnl dnl # Wir wollen die access.db benutzen (Relaying) FEATURE(`access_db',`hash -T<TMPF> /etc/mail/access.db')dnl FEATURE(relay_mail_from)dnl dnl # Dies stellt sicher das eine /etc/mail/local-host-names beachtet wird FEATURE(`use_cw_file')dnl FEATURE(`virtusertable',`hash /etc/mail/virtusertable.db')dnl define(`confMAX_MESSAGE_SIZE',`10000000')dnl dnl # Dies ist für SMTP-Auth FEATURE(`authinfo',`hash /etc/mail/authinfo.db')dnl define(`confAUTH_MECHANISMS',`CRAM-MD5 DIGEST-MD5 LOGIN PLAIN')dnl dnl # Das braucht procmail define(`PROCMAIL_MAILER_PATH',`/usr/pkg/bin/procmail')dnl FEATURE(local_procmail)dnl MAILER(local)dnl MAILER(smtp)dnl MAILER(procmail)dnl
Geändert werden muß auf jeden Fall GENERICS_DOMAIN und SMART_HOST, nach Bedarf auch MAX_MESSAGE_SIZE. Danach erstellen wir aus dieser Datei mit m4 unsere /etc/mail/sendmail.conf:
cd /usr/pkg/share/sendmail/m4/ m4 mycf.mc > /etc/mail/sendmail.cf
Die Warnung "FEATURE(`relay_mail_from') may cause your system to act as open relay." können wir ignorieren weil unser Host erstens von aussen eh durch einen Paketfilter geschützt sein sollte und zweitens nur localhost und unserem internen Netzwerk in /etc/mail/access das Relayen erlaubt wird.
Natürlich gibt es noch viel mehr Möglichkeiten, doch für die meisten Fälle sollte das erstmal reichen. Was die Optionen und Features im einzelnen bedeuten und welche Möglichkeiten noch vorhanden sind, kann man in /usr/pkg/share/sendmail/README nachlesen.
Fetchmail wird benutzt, um die Mail von Mailboxen, die im Internet sind, auf den lokalen Rechner zu holen und sie den verschiedenen Usern zuzuordnen. Gesteuert wird Fetchmail durch eine Konfigurationsdatei /root/.fetchmailrc, deren Rechte sehr restriktiv eingestellt werden müssen. Der Inhalt der Datei erklärt sich fast von allein:
set postmaster "postmaster"
set daemon 300 # wir holen alle 300Sekunden Mail
set syslog # wir loggen ins syslog
set bouncemail
set properties ""
# Hier ist der erste Eintrag
poll mail.netbeat.de protocol POP3
user "tecneeq" password "geheim" to karsten
# Von gmx.net holen wir für mehrere User
poll pop.gmx.net protocol POP3
user "1827063" password "secret" to karsten
user "8118233" password "ratemal" to karl
user "1656124" password "unsichtbar" to lotta
Wenn man keine Flatrate zum Internet hat, sollte man den Eintrag "set daemon" auskommentieren. Er sagt fetchmail, daß es sich nach dem Abholen nicht beenden soll, sondern im angegeben Intervall wieder aufwacht.
Die Usereinträge sollten klar sein. Ich werde beispielhaft den ersten erklären: "poll mail.netbsd.de" gibt den Server an auf dem das Mailkonto liegt, "protokol POP3" gibt POP3 als Format an. Fetchmail unterstützt auch andere wie man in man fetchmailrc nachlesen kann. Danach kommt der Username auf dem entfernten Rechner und sein Passwort. "to karsten" schließlich sagt, daß die Mail in das Mailfach von karsten gelegt werden soll. Der User karsten kann sie sich später z.B. mit POP3 von dort abholen oder lokal lesen.
Schließlich müssen wir noch sicherstellen, daß die Rechte der Datei /root/.fetchmailrc richtig eingestellt sind, weil Fetchmail seine Arbeit sonst verweigert:
chmod 600 /root/.fetchmailrc
Fertig.
Den POP3d und den IMAPd von der Universität Washington zu konfigurieren, ist keine große Schwierigkeit. Die Installation ist so gestaltet, dass wir beides Dienste direkt benutzen können ohne besondere Einstellungen vorzunehmen. Einzig einige Einträge in /etc/inetd.conf müssen vorgenommen werden:
imap stream tcp nowait root /usr/pkg/libexec/imapd imapd #imaps stream tcp nowait root /usr/pkg/libexec/imapd imapd #pop2 stream tcp nowait root /usr/pkg/libexec/ipop2d ipop2d pop3 stream tcp nowait root /usr/pkg/libexec/ipop3d ipop3d #pop3s stream tcp nowait root /usr/pkg/libexec/ipop3d ipop3d
Hier habe ich die Rauten vor imap und pop3 schon entfernt. Nach einem Neustart von Inetd können die Dienste schon benutzt werden:
/etc/rc.d/inetd restart
Nachdem wir jetzt alles installiert haben und die grundsätzlichen Konfigurationen geschrieben haben, bleibt uns nur noch die Dienste so einzurichten, dass sie auch beim Systemstart ordentlich gestartet werden.
Für Inetd und Sendmail reichen Einträge in /etc/rc.conf. Sendmail geben wir als Argument noch das Intervall mit, in dem ausgehende Mail verschickt werden soll:
inetd=YES sendmail=YES sendmail_args="-bd -q1m"
Den Start von Fetchmail erledigen wir in /etc/rc.local:
if [ -f /usr/pkg/bin/fetchmail ]; then
/usr/pkg/bin/fetchmail --fetchmailrc /root/.fetchmailrc &
fi
Wer keine Flatrate hat, möchte Fetchmail eventuell via cron oder von einem ppp-script starten lassen.
Zum Testen starten wir erstmal Sendmail und Inetd (damit ja auch POP3d und IMAPd). Fetchmail wird erst gestartet, nachdem alles andere funktioniert:
/etc/rc.d/sendmail restart /etc/rc.d/inetd restart
In diesem Fall schreibe ich restart falls die Dienste schon gestartet waren. Wenn nicht, tut das auch nicht weh. :)
Jetzt schreiben wir eine erste Testmail mit Telnet. Auf dem NetBSD-Rechner geben wir also ein:
telnet localhost 25
Wenn alles geklappt hat, sollten wir jetzt mit Sendmail verbunden sein und folgendes lesen können:
karsten@uberhost:~> telnet localhost 25 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 uberhost.newbie-net.de ESMTP Sendmail 8.12.6; Tue, 4 Mar 2003 15:29:50 +0100 (CET)
Wir melden uns am Server mit unserem Hostnamen an:
HELO localhost
Und bekommen als Antwort:
250 uberhost.newbie-net.de Hello IDENT:karsten@localhost [127.0.0.1], pleased to meet you
Jetzt beginnen wir mit einer Testnachricht. Als erstes geben wir eine Absenderadresse ein:
MAIL FROM:testuser@test.org
Sendmail antwortet:
250 2.1.0 testuser@test.org... Sender ok
Jetzt die Zieladresse:
RCPT TO:tecneeq@gmx.net
Auch das bestätigt Sendmail:
250 2.1.5 tecneeq@gmx.net... Recipient ok
Mit DATA sagen wir Sendmail, dass jetzt die eigentliche Nachricht kommt:
DATA
Sendmail erklärt, dass wir jetzt unsere Nachricht eingeben können und dann mit einem einzelnen Punkt auf einer Zeile die Nachricht beenden müssen.
354 Enter mail, end with "." on a line by itself
Hier also unsere Eingabe:
bla,bla,bla .
Was Sendmail auch gleich bestätigt. Die Nachricht ist komplett und wird versendet.
250 2.0.0 h24EToFQ012002 Message accepted for delivery
Wir verabschieden uns:
QUIT
Sendmail beendet die Verbindung:
221 2.0.0 uberhost.newbie-net.de closing connection Connection closed by foreign host.
Wenn alles klappt, wird kurze Zeit später die Nachricht eintreffen. Diesen Test sollten wir auch von einem Clientrechner ausprobieren. Unter Windows benutzt man dazu auch einfach Telnet, welches aus einer Dos-Box gestartet wird.
Jetzt können wir Fetchmail starten. Abgeholte Mail sollte ordentlich in die Usermailboxen einsortiert werden:
/usr/pkg/bin/fetchmail --fetchmailrc /root/.fetchmailrc
Durch Anzeigen der Logdatei für Mailangelegenheiten überprüfen wir, daß alles ordentlich funktioniert:
less /var/log/maillog
Das war es schon. Alle beteiligten Programme sollten jetzt ohne Probleme laufen. Man sollte abschließend mit einem Paketfilter sicherstellen, dass die Ports 25 (smtp), 110 (pop3) und 143 (imap) nicht vom Internet aus zu erreichen sind. Die Clients einzurichten sollte nicht schwerfallen. Happy Mailing.
Kommentare, Wünsche und Anträge an Karsten Kruse tecneeq(at)tecneeq(dot)de.