Exim4 und mehrere Smarthost Howto
Ausgehend von der Diskussion vor einigen Tagen habe ich mich nun mal
etwas eingehender mit der Konfiguration von Exim für verschiedene
Smarthosts (source-based-routing) beschäftigt.
Die folgende Konfiguration versucht, möglichst nahe an der
Debian-Standard Konfig zu bleiben und verwendet daher nur einen
angepassten Router.
Die Konfiguration kann von http://www.m-taube.de/exim.tgz geladen werden.
Ich habe die Konfiguration an einer frischen Debian-Installation
(Debian GNU/Linux 7.3.0 _Wheezy) sowohl für exim4-daemon-heavy als auch
für exim4-daemon-light mit verschiedenen mail-providern (gmx, web.de,
t-online) getestet.
Bei meinen Tests sind Probleme meist aus Fehlern in der externen
Konfiguration aufgetreten (beim Anliefern der Mail an Exim wird kein
richtiges envelope-from gesetzt, wechselnder rdns beim Smarthost), die
ich nicht alle in dem Beispiel abgefangen habe - ggf. ist noch weitere
Konfigurationsarbeit angesagt. Hinweise siehe unten.
Installationsanleitung für ein frisches Debian-System:
dpkg-reconfigure exim4-config
Hierbei den Versand entweder auf Smarthost oder Internet-Mail
einstellen. Dies ist der fallback, falls für eine Adresse kein passender
smarthost definiert ist.
Ebenfalls muss "Einstellungen auf kleine Dateien aufteilen" angewählt sein.
nun mein Beispielpaket laden und entpacken:
wget http://www.m-taube.de/exim.tgz
tar xvfz exim.tgz
cp 170_exim4_config_smarthost_list /etc/exim4/conf.d/router/
nun müssen passwd.client und sender.smarthost auf die eigenen
Mailprovider angepasst werden. Ich habe zwei Beispieldateien
mitgeliefert, aber evtl. existiert schon eine passwd.client
auf dem System:
cp passwd.client /etc/exim4/
cp sender.smarthost /etc/exim4/
Nach getaner Anpassung:
update-exim4.conf
service exim4 restart
Für Tests habe ich ein kleines Perlscript erstellt,
welches für eine Liste von Mailadresse eine Testmail
von allen an alle verschickt. Für das Script sind zwei
Bibliotheken erforderlich:
aptitude install libmime-lite-perl libgetopt-simple-perl
Mit
./mailtest.pl beispiel@gmx.de beispiel@web.de beispiel@t-online.de
würde jetzt jeweils zwischen diesen Mailadressen Mails verschickt
werden, und zwar einmal per smtp auf localhost und einmal direkt von der
Kommandozeile. Mittels -s oder -c als Option könnte der Versandtyp
vorgewählt werden.
Kommen wir nun zu den erkannten Problemen:
1. envelope-From
Eigentlich sollte das Routing auf Basis des envelope-from passieren. Nur
wird dieses manchmal nicht richtig gesetzt, entweder weil die Mail per
script direkt auf der Kommandozeile eingeworfen wird oder der MUA
falsch konfiguriert ist.
In meiner Lösung habe ich nun hierfür einen zweiten Router erstellt, der
- falls ein Routing auf Basis des envelope-from nicht möglich ist - ein
Routing auf Basis des From im Mailheader probiert. Dann muss man aber
auch das ausgehende envelope-from richtig setzen, ich habe es durch
Definition von REMOTE_SMTP_RETURN_PATH gemacht. Das schlägt fehl, falls
dieses schon via debconf gesetzt ist, allerdings wäre die alternative
Lösung ein eigener Transport gewesen. In meiner Lösung nutze ich den
Standard transport remote_smtp_smarthost. Falls dies nicht der richtige
Debian-Weg ist bitte einen Hinweis.
2. smtp-server pools
Der Debian-exim standard Transport remote_smtp_smarthost setzt das
Passwort aus passwd.client auf Basis des RDNS des Servers und nicht des
übergebenen Servernamens.
Nun nutzt beispielsweise t-online den Server "securesmtp.t-online.de",
der allerdings ein RDNS "sfwdallmx.t-online.de" meldet. Ich habe für
meine Tests das Passwort für beide Servernamen gesetzt. Was man nun mit
einem Pool machen soll, der zufällig irgendeinen Servernamen meldet weis
ich nicht. Ich habe jedenfalls erstmal nicht am standard Transport
remote_smtp_smarthost ändern wollen.
3. Routing von Bounce-Messages
Es muss durch eine geeignete Konfiguration sichergestellt werden, dass
Bounce-Messages richtig geroutet werden. Falls der Smarthost eine Mail
nicht annimmt, versucht der exim die ja zurückzuschicken. Diese Mails
tragen als Ziel aber die (externe) Absenderadresse der ursprünglichen
Mail. Es sollte sichergestellt sein, dass diese auf dem lokalen Rechner
terminieren (z.B. mit redirect), da die ja nicht über den Smarthost
rausgehen können (was der ursprüngliche Fehler war).
Ansonsten bleiben die als frozen im spool hängen.
4. Sonderfälle der Authentifizierung
Heiko hatte ja ein Beispiel angegeben, mit dem man auch Sonderfälle
(spezieller Port, spezielle Auth) setzen kann. Ich habe dies hier nicht
übernommen, sondern setze auf den Standard Transport auf, der mit dem
Debian-exim mitgeliefert wird. Falls der Provider damit nicht
funktioniert, muss man evtl. anpassen - bei meinen Tests hat es
zwar auch so geklappt, aber ich kann schließlich nicht alle Provider
testen.
mfg
Matthias
Reply to: