Kleine und große Linux AHAs
Beiträge getaggt mit MS Exchange Linux Mail Migration
[Update] Und heute im Ü-Ei: Advanced Disclaimer für Postfix
10. Mrz
In meinem Artikel zum Advanced Disclaimer für Postfix mit Hilfe von altermime haben sich ein paar kleine Fehler eingeschlichen. Ich habe die Fehler nun korrigiert und den Artikel (den Script Teil) überarbeitet.
Fehler 1:
Die Empfängeraddresse wurde nicht richtig bestimmt
REC_DOMAIN=${2##*@}
muss heißen
REC_DOMAIN=${4##*@}
Fehler 2:
Durch diesen Fehler kann es passieren, dass Mails teilweise ganz abgeschnitten ankommen, bzw. auch teilweise “nur” der Anhang fehlt. Das ganze ist darauf zurückzuführen, dass sich in der Mail – wenigstens dann wenn sie von altermime bearbeitet wurde – eine Zeile mit lediglich einem Punkt befindet. Dies wird von Postfix bei der Rückgabe als “ende” interpretiert. Daher muss der sendmail Aufruf innerhalb des Scripts angepasst werden (3x).
Aus
$SENDMAIL "$@" <in.$$
wird also
$SENDMAIL -i "$@" <in.$$
(1 votes, average: 1,00 out of 5)
Loading ...
MailMig Teil11: Damit jeder einen Migrationshintergrund bekommt – so wirds gemacht
01. Feb
Tja, also in wie fern meine Artikelreihe verständlich ist kann ich leider nicht sagen. Ich habe versucht das ganze – recht komplexe – Projekt hier immer wieder ein wenig zu dokumentieren. Ihr könnt mich auch gerne kontaktieren, wenn Ihr vor einer gleichen Aufgabe steht.
Auf jeden Fall wird hier nun einer der finalen Schritte dokumentiert.
Viel probiert, nun passt das
Viel haben wir probiert, viel gescriptet – nun ist es soweit. In unserem – realen – Projekt ist mittlerweile die komplette IT-Abteilung umgezogen und “gewöhnt” sich an das neue System. Die überwiegend gestellten Fragen zielen dabei auf Dinge, die einfach nur anders funktionieren als vorher. Das nutzen wir dann um eine Wiki Seite mit Howto’s zu pflegen. Diese Wiki Seite ist per Autoconfig als Startseite für Thunderbird hinterlegt. Der Vorteil am Wiki ist dabei einmal mehr, dass jeder etwas zur Vollständigkeit beitragen kann. So wird die Dokumentationslast quasi verteilt 
FAQs
Was sind die am meisten gestellten Fragen zur Zeit?
- Wo ändere ich meine SIgnatur? Durch die verwendung der Autoconfig, muss die Signatur in Group-Office geändert werden. Das ist nicht direkt ersichtlich, da nicht jeder von der Autoconfig weiß
- Einrichtung des Abwesenheitsassistenten: Dieser wird ebenfalls in Group-Office eingerichtet. Vorher – in Outlook – ging das über den Client.
Soweit sind das wirklich die häufigsten Fragen. Vielen gefällt Thunderbird um einiges besser als Outlook.
Migrationshintergrundbeschleunigung
Wie werden die Benutzer denn nun umgezogen / migriert??
(No Ratings Yet) Loading ... MailMig Teil 10: Der aktuelle “Flow”
26. Jan
Es ist ja oft recht interessant Datenflüsse zu “visualisieren” da man anhand eines Bildes auch komplexere Zusammenhänge leichter erkennen kann. So hab ich mir gedacht mache ich das auch mit unserem Mailprojekt. Dort gibt es mittlerweile mehr verpflechtungen als man denkt. Aber seht selbst:
Ich finde solche Darstellungen immer recht interessant
(No Ratings Yet) Loading ... MailMig Teil 9: Simsalabim, dreimal blauer Donnervogel – Thunderbird autoconfig II
10. Jan
In MailMig Teil 6 (MailMig Teil 6: Hokus Pokus Fidibus – Thunderbird Konfiguration wie von Zauberhand) hatte ich beschrieben, wie man Thunderbird quasi automatisch konfigurieren kann. Das ganze funktioniert über eine Konfigurationsdatei die sich auf einem Server befindet. Sie ist dynamisch und dadurch für jeden Benutzer “einzigartig”.
In Teil 6 wurden damit diverse Grundeinstellungen, Mailkonten, Signaturen und Addressbücher konfiguriert. Mittlerweile hat GroupOffice gelernt seinen Kalender per CalDav zur Verfügung zu stellen – diese Erweiterung wurde von uns ( der Firma für die ich arbeite) in Auftrag gegeben um Thunderbird an den GroupOffice Kalender anbinden zu können. Das ganze funktioniert in Verbindung mit Lightning wirklich prima.
Tja, was wird jetzt wohl kommen? Klar, wie binde ich auch den Kalender per Autoconfig in Thunderbird ein!!
Erweiterung des Scripts
Um das ganze zu bewerkstelligen muss zuerst einmal das Script auf dem Webserver erweitert werden. Das ganze sieht so aus:
// Benutzer duerfen keine Updates einspielen
lockPref("app.update.enabled", false);
pref("extensions.update.enabled", false);
lockPref("browser.search.update", false);
# Calendar(s), get them, create config
$cal_query_url = "https://<groupoffice mailserver>/groupoffice/getcalurl.php?username=$db_username";
use LWP::Simple;
$response = get $cal_query_url;
# check if the response is correct (a https link)
if ( $response =~ /^https:/ ) {
# create calendar registry number
# so, we need for each user even the same uid for the calendar on every connect
# for that, we create a uid out of the username by creating the hex code of it and fill up with 0s
(my $reg_uid = $db_username) =~ s/(.|\n)/sprintf("%02lx", ord $1)/eg;
$reg_uid=sprintf( "%036s", $reg_uid);
# Color for the private calendar
$cal_color="#FFA500";
# Name for the calendar
$calendar_name = "Groupoffice";
# print out the config
print qq#
// Private Calendar
lockPref("calendar.registry.$reg_uid.calendar-main-default", true);
lockPref("calendar.registry.$reg_uid.calendar-main-in-composite", true);
defaultPref("calendar.registry.$reg_uid.color", "$cal_color");
lockPref("calendar.registry.$reg_uid.imip.identity.key", "id1");
lockPref("calendar.registry.$reg_uid.name", "$calendar_name");
lockPref("calendar.registry.$reg_uid.type", "caldav");
lockPref("calendar.registry.$reg_uid.uri", "$response");
#;
$i++;
}
# DONE with calendar
print qq#
} catch(e) {
displayError("ARGL 
", e);
}#;
$dbh->disconnect();
close LOG;
Achtung! HIer ist auch ein Teil vor und nach der Erweiterung abgebildet!
Besonderes
An sich ist die Erweiterung recht simpel und bedarf keiner großen Erklärung. Trotzdem gibt es den ein oder anderen Punkt zu eräutern:
- $cal_color = die Farbe des Kalenders in Thunderbird
- $reg_uid = das ist eine UID für den Kalender. Diese muss für den jeweiligen Benutzer / Kalender immer gleich sein, da sie auch die Referenz für Terminanfragen oder ähnliches darstellt. Die IDs die ich bisher gesehen habe waren immer in Hexadezimal und 32 Zeichen lang. Daher habe ich den Benutzernamen genommen, diesen in Hex umgewandelt und vorne mit Nullen aufgefüllt. Dem entsprechend ist die ID nun konform und wird für jeden Benutzer immer gleich vergeben.
getcal.php Script
Von Merijin Schering (Intermesh) habe ich ein Script bekommen, welches mir die URL zum Kalender aus GroupOffice zurück gibt. Die URLs sind anders nicht wirklich herauszufinden, da sie eine Nummer enthalten die nirgends in der Datenbank zu finden ist (könnt Ihr ja je nach dem auch selbst sehen). Das Script kann hier heruntergeladen werden und wird dann in /usr/share/groupoffice abgelegt.
(No Ratings Yet) Loading ... MailMig Teil8: Caldav in Group-Office verfügbar
04. Dez
Seit dieser Woche ist die neue Version von Group-Office (3.6.5) verfügbar.
Darin enthalten ist das Caldav Modul, mit dem wir die Verbindung von Thunderbird (inkl. Lightning) zu Group-Office herstellen. Das Modul wurde mit uns entwickelt und getestet. Wäre gut wenn möglichst viele das ganze nun auch testen um letzte Fehler zu finden.
(No Ratings Yet) Loading ... MailMig Teil 7: Thunderbird ohne Status der Einladungen, oder doch?
22. Nov
Das war echt geil. Wir haben jetzt bestimmt eine ganze Woche nach dem Problem gesucht, warum bei Einladungen mit Thunderbird der Organisator den Status der Einladungen nicht sieht. Also ob “die eingeladenen” zu- oder abgesagt haben. Das ganze sollte dann aussehen wie
Leider wurde bei unseren Tests nie das Icon (hier grün) angezeigt. Ein leeres Nichts.
Da der Caldav Server in unserem Auftrag in Group-Office implementiert wird, sind wir die ganze Zeit davon ausgegangen, dass es an dem Server liegt. Also mit Merijin (von Intermesh/Group-Office) Mails hin und her geschickt. Er kam zu dem Schluss, dass es ein Problem mit Thunderbird sein muss – bei Ihm wurden die Icons auch nicht angezeigt.
Richtung Lösung
Da ich mir das irgendwie nicht vorstellen konnte, hab ich heute einen Caldav Server (DaviCal) in einer virtuellen Maschine installiert und das ganze damit getestet. Auch nichts. Dann hab ich mir die .ics Dateien angesehen. In den Dateien waren die Einträge drin (accepted, declined, …). Auch die Dateien im Caldav Server von Group-Office waren Ok. Also doch TB?
Bevor man einen Bug meldet …
… sollte man immer erst in den vorhandenen Bugs suchen. Das hab ich gemacht. Und was hab ich gefunden? Diesen Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=604757 .
Die Lösung
Ubuntu blendet – anscheinend per Default – Menüicons aus. Das macht Menüs im normalen Leben übersichtlicher. ABER: Ist diese Option aktiviert, so werden auch diese Icons im Thunderbird nicht mehr angezeigt. Sprich: Ist diese Option aktiviert, so kann man den Status von Einladungen nicht mehr sehen.
Man muss sich also entscheiden – wer es braucht .
Abhilfe schafft:
gconftool-2 --type Boolean --set /desktop/gnome/interface/menus_have_icons Truebzw.
gconftool-2 --type Boolean --set /desktop/gnome/interface/menus_have_icons Falseum es wieder rückgängig zu machen.
(No Ratings Yet) Loading ... MailMig Teil 6: Hokus Pokus Fidibus – Thunderbird Konfiguration wie von Zauberhand
28. Okt
Wie im letzten Artikel angekündigt hier nun ein paar Tipps, wie man Thunderbird in größeren Umgebungen automatisch konfigurieren kann. In unserem Beispiel im Zusammenspiel mit Group-Office, allerdings ist das recht flexibel.
Die Lösung für ISPs
Was schon recht bekannt ist, ist die automatische Konfiguration der Server für ein Konto entsprechend der Domain. Das ganze ist beschrieben im MDC. Das ist jedoch nur eine Unterstützung, da dieses Verfahren lediglich – anhand der Domain aus der Email Adresse – die Server (Name, Ports, SSL…) für den Email Empfang bzw. Versandt bestimmt.
Die Lösung für den Mittelstand
Weniger bekannt ist die Möglichkeit, die komplette Konfiguration beim Start, beispielsweise per http, zur Verfügung zu stellen. Wir haben damit bisher folgendes realisiert:
- Mailkonto komplett konfiguriert, inkl. einheitlicher Signatur, speziellen Ordnern (…)
- LDAP Addressbuch fertig konfiguriert
- vorgegebene Startseite
- vorgegebene Schriftarten
- Proxy Konfiguration
- automatische Updates disabled
Man bedenke, dass all diese Einstellungen komplett automatisch geschehen ohne zutun des Anwenders oder Admins.
(1 votes, average: 5,00 out of 5) Loading ... MailMig Teil 5: Für die einen so, für die anderen mit Donnervogel
26. Okt
In unserem Projekt war von vornherein klar, dass wir ein Zweiklassen System zur Zeit haben und auch weiterhin haben werden. Die einen, die ihren Mailaccount haben um damit Mails zu bekommen die “an alle” versendet werden (Bekanntmachungen, Mitteilungen, …) und ansonsten vielleicht 5 eMails in der Woche schreiben. Die anderen, die eben den ganzen Tag mit dem Medium eMail zu tun haben und dem entsprechend viele Mails haben. Einfach gesagt: Standard User und Power User.
Für die Standard User wird Group-Office das Tor zu eMail und Company Collaboration sein. In unserem Fall haben die meisten Standard User auch keinen festen Platz, sondern müssen sich mal von da und mal von dort anmelden können. Dafür ist Webmail eh am einfachsten. Auf die Standard User möchte ich jetzt auch gar nicht weiter eingehen, da Group-Office in späteren Artikeln bestimmt noch behandelt werden wird.
Heute geht es um die Power User. Warum überhaupt zwei verschiedene Systeme anbieten? Naja, da gibt es Argumente wie die Möglichkeit zum Sortieren des Posteingangs (oder anderer Ordner). Möchte man beispielsweise einen Ordner nach den Absendern gruppieren, so wird das mit einem Webmail Client sehr schwierig da dafür die kompletten Daten des Ordners in die Berechnung der Anzeige einfließen müssten. Group-Office – und auch die meisten anderen – arbeitet als IMAP Client mit direktem Zugriff auf den Mailserver und kann dabei nicht viel an Cache nutzen.
Ein weiteres Beispiel ist die Anzeige (Liste) der Mails. Group-Office zeigt per Default 20 eMails in der Liste an. Man kann diesen Wert auf bis auf 50 erhöhen – dann ist Schluss. Das macht aus Sicht der Webmail Anwendung auch Sinn, um die Performance zu erhalten. Nun ist es allerdings so, dass manche Anwender ihren Ordner einfach mal so überfliegen möchten, weil sie “irgendeine eMail suchen die vor ein paar Tagen gekommen ist”. Man möchte die Liste einfach durch scrollen. Mir ist schon klar, dass man dafür auch Suchfunktionen innerhalb des Webmail Systems nutzen könnte Schlecht ist das auch bei Mitarbeitern die morgens so um die 70 eMails oder Montags sogar > 100 eMails haben. Sie müssten sich durch mehrere Seiten klicken um sich einen Überblick zu verschaffen – das ist auch aus meiner Sicht nachvollziehbar 
Das sind nur ein paar Beispiele dafür, dass es notwendig ist einen FatClient anzubieten. Der wohl schwerwiegendste Grund dürfte allerdings die Gewohnheit sein. Die Mitarbeiter haben sich über viele Jahre an einen FatClient (in dem Fall Outlook) gewöhnt. Nun möchten wir das ganze System ändern. Eine große Aufgabe liegt darin, den Mitarbeitern das ganze schmackhaft zu machen – mit möglichst wenig Änderungen an Bedienung und Verfahrensweisen. Auch das ist ein Grund, warum man den FatClient nicht einfach “wegmigrieren” kann.
Die Qual der Wahl? Naja.
Nun, welchen eMail Client kann man nehmen? Gibt es viele Alternativen? Aus meiner Sicht nicht wirklich. Ein Client, der auf Windows als auch auf Linux läuft. Ein Client der recht bekannt ist und aktiv entwickelt wird. Ein Client der erweiterbar ist.
Wie aus der Überschrift zu entnehmen ist haben wir uns auf Thunderbird als FatClient festgelegt. Gibt es andere, wirkliche, Alternativen? Ich kenne keine und bin bisher auch mit Thunderbird ganz zufrieden. Es gab zwar so einige Stolperstellen, aber im Großen und Ganzen bin ich zufrieden – mittlerweile.
Ist Thunderbird “Ready for the Enterprise”?
Das ist mit die interessanteste Frage in dem Spiel. Kann Thunderbird im Unternehmen eingesetzt werden? Naja, generell spricht ja nichts dagegen – wieso auch. Welche Anforderungen hat ein Unternehmen denn?
Also prinzipiell benötigt ein Unternehmen an sich auch nicht viel mehr als der Privatmann zu Hause (ganz ganz grob ausgedrückt):
- eMail (IMAP, SSL)
- Kalender (Free & Busy, Shared)
- Adressbuch / -bücher (LDAP, Lokal)
Diese Anforderungen sind wirklich nur der Standard – es geht hier nicht um Firmen die mit dem Mailclient Workflow abbilden oder anderes. Aber stellen wir uns das mal vor… So wie jeder Thunderbird kennt würde dann auf jedem Arbeitsplatzrechner Thunderbird installiert, die Plugins heruntergeladen und installiert, alles manuell konfiguriert. Dieses Szenario x Anzahl Poweruser. Und die Updates nimmt man direkt aus dem Internet, oder? Klar.
Damit sind wir bei den Anforderungen der Unternehmen:
- zentrale Installation (komplettes Package incl. Plugins/Extensions)
- zentrale Steuerung von Updates
- zentrale Administration der Clients (Konfiguration, Konfigurationsupdates)
Aber kann Thunderbird das? Yes, he can. Allerdings war es echt schwierig an die nötigen Informationen zu kommen.
Weiter geht es im nächsten Artikel – bald auf dieser IP Adresse.
(2 votes, average: 3,00 out of 5) Loading ... Und heute im Ü-Ei: Advanced Disclaimer für Postfix
08. Sep
Ob ein Disclaimer sinnvoll ist oder nicht, das kann ich noch nicht einmal genau sagen. In dem Buch von Peer Heinlein ist zu lesen, dass er keine Rechtskraft hat. Er hat in seinem Postfix Buch auch nichts über einen Disclaimer geschrieben. Trotzdem ist es so, dass es sich in den Firmen irgendwie durchgesetzt hat dass man sowas haben muss.
Die Qual der Wahl
Sucht man im Internet nach einem Programm für Postfix um einen Disclaimer in Mails einzufügen, so wird man im Prinzip nur einen Treffer erhalten: altermime. Altermime übergibt man einfach ausgedrückt zwei Dateien. Eine einfache Textdatei und eine HTML Datei. Diese beiden werden von altermime jeweils am Ende des Text, bzw. des HTML Blocks in die eMail eingefügt.
Ganz toll, aber
Um altermime herum wird quasi ein Wrapper Script gebaut, welches die Parameter zusammensetzt und ein paar Checks im vorhinein macht. Dieses Script kann in der Basisversion einfach nur immer einen Disclaimer einfügen.
Nun ist man ja verwöhnt und Manager sehr kreativ. Was nun, wenn ich verschiedene Domains auf einem Server betreibe? Ich benötige dann auch verschiedene Disclaimer. Was nun, wenn ich nur für ausgehende eMails Disclaimer möchte? (dafür gibt es ein paar Beispiele im Internet). Und was, wenn ich für einen oder bestimmte Benutzer vielleicht gar keinen Disclaimer einfügen darf?
So geht das
Ich habe kurzerhand das Script ein wenig erweitert. Die Basis bildet dabei natürlich das Standard Script. Auf die eigentliche Installation gehe ich nicht ein, ich zeige Euch hier nur das erweiterte Wrapper Script.
Funktionen:
- Disclaimer per Domain
- Default Disclaimer (für alle, für die es keinen Domain Disclaimer gibt)
- Disclaimer nur für ausgehende Domains (bzw. für alle, die nicht im Script hinterlegt sind)
- Disclaimer kann für einzelne Mailboxen (Sender eMailadressen) ausgeschaltet werden
Hier nun das Script:
#!/bin/bash
#
# Advanced Disclaimer
# - Disclaimer per Domain
# - Default Disclaimer
# - Disclaimer for outbound [y|n]
# - disable Disclaimer for named sender addresses
#
# For each Domain there "should/could" be two files in
# $DISCLAIMERS_PATH named like the Domain in .txt and .html
# ex: localdomain.com.txt and localdomain.com.html
#
# Files for the default Domain Parameter must exist.
#
# Uses altermime
#
# THIS SCRIPT NEEDS Bash > 4 to work !!!
# - Thanks to Olaf
#
# Ronny Becker, 09.2010 - 05.2011
#
#
# to configure
# Domains that are not required to have disclaimer
EXCLUDE_REC_DOMAINS="-localdomain.com-"
# Users that should not have a disclaimer
EXCLUDE_SENDER="nodisclaimer@localdomain.com"
# default disclaimer
# (in DISCLAIMERS_PATH as $DEFAULT_DISCLAIMER.txt and $DEFAULT_DISCLAIMER.html)
DEFAULT_DISCLAIMER="localdomain.com"
# --
DISCLAIMERS_PATH="/etc/postfix/disclaimerfiles"
INSPECT_DIR=/var/spool/altermime
SENDMAIL=/usr/sbin/sendmail
# Exit codes from
EX_TEMPFAIL=75
EX_UNAVAILABLE=69
# Clean up when done or when aborting.
trap "rm -f in.$" 0 1 2 3 15
# Start processing.
# get recipients domain
REC_DOMAIN=${4##*@}
# get senders domain
S_DOMAIN=${2##*@}
# checks
cd $INSPECT_DIR || { echo $INSPECT_DIR does not exist; exit $EX_TEMPFAIL; }
# save temp file
cat >in.$$ || { echo Cannot save mail to file; exit $EX_TEMPFAIL; }
# check if mail matches exclude domains or (send-)users, then send without
if [[ $EXCLUDE_REC_DOMAINS =~ -${REC_DOMAIN}- ]] || [[ $EXCLUDE_SENDER =~ $2 ]]; then
$SENDMAIL -i "$@"
Achtung Zeichensatz!
Die .html Datei sollte dem HTML Standard entsprechen. Das bedeutet, dass Umlaute im HTML Format in der Datei stehen.
Die Textdatei muss in der Codierung vorliegen, in der auch die eMails verschickt werden. So ist auf vielen Linux Systemen (Server) der Standard Zeichensatz UTF-8. Mails werden allerdings meist in ISO-8859-8/15 verschickt. So muss man also darauf achten, dass der Disclaimer in der Textversion im ISO Format vorliegt.
Doppelte Disclaimer?
Nein. Altermime ist so intelligent, dass er erkennt wenn der Disclaimer bereits eingefügt ist. Dadurch kann man dann auch die beliebten Frage & Antwort Spielchen per Mail betreiben, ohne 20x den Disclaimer durch die Welt zu schicken.
(No Ratings Yet) Loading ... MailMig Teil 4: Der Plan zum Paralleluniversum
06. Sep
Einen Mailserver in einem produktiven Umfeld zu migrieren bedeutet auch, dafür zu sorgen dass es möglichst wenig Ausfall / Downtime gibt. Am einfachsten kann man das mit Hilfe einer Parallelinstallation erreichen. Wir möchten also sowas:
Eigentlich ganz einfach, oder? Naja.
Routing
Zu beachten ist das “Mail routing”. Wie werden Mails zwischen dem einen und anderen Mailserver verschickt? Beide Mailserver – wenn man sie gerade frisch installiert hat – halten sich ja erst einmal für den Chef der Domain. Damit ist jede Mailbox, die nicht auf dem lokalen Mailserver vorhanden ist, quasi nicht vorhanden. Aber dieses Szenario besteht, wenn man bereits einige Mailboxen auf den “neuen” Mailserver migriert hat und der größte Teil noch auf dem “alten” arbeitet. Wobei die Größe der Teilmengen dabei natürlich egal ist. Ob nun zwei Mailboxen auf einem anderen Mailserver sind oder das Verhältnis 50:50 – das macht vom Mail routing her keinen Unterschied.
Man muss sicherstellen, dass alle Mailboxen allen Mailservern bekannt sind – und wo. So können prinzipiell beide Mailserver entscheiden ob eine eMail abgewiesen oder zugestellt wird.
Exchange
Da der Exchange Server der aktuelle Master ist, soll er doch – eigentlich ganz einfach – die eMail von bereits umgezogenen Benutzern an den neuen Mailserver weiterleiten. Tja, da waren sie wieder meine drei Probleme. Vielleicht geht das auch irgendwie anders, aber ich habe nur folgende Möglichkeit gefunden:
Damit ein Exchange Server eine Mail zu einem externen Account weiterleitet, muss man einen sogenannten “Kontakt” im Verzeichnis erstellen. Dieser Kontakt besitzt eine externe eMailadresse. Dann kann man über den Account des Benutzers “Exchange erweitert | Zustelloptionen | Weiterleitung” den Namen des neu angelegten Kontaktes angeben – fertig. Die Mails werden dann also über einen lokalen Kontakt nach extern weitergeleitet. Ich hätte mir durchaus vorstellen können eine externe Adresse direkt bei “Weiterleitung” eintragen zu können.
Warum überhaupt extern? Naja, für den Exchange Server ist der neue Mailserver ein externer Server.
Achtung! Stolperfallen!
Der Exchange den ich hier zu verarzten habe, hatte bei dieser Aktion dann noch eine Überraschung für mich übrig. Der Exchange arbeitet so, dass er quasi die Namen vor der Domain abgleicht und wenn er dafür einen Treffer hat, dann wird die Mail zugestellt. Soll heißen: landet die Mail linux-aha@foo.bar auf dem Server und es gibt eine Mailbox mit Namen linux-aha, dann wird sie dem Benutzer linux-aha zugestellt. Landet eine Mail mit linux-aha@dieseDomaingibtesgarnicht.dot auf dem Server, dann wird sie ebenfalls zugestellt. Er achtet wirklich nur auf den User Teil der Adresse. Man darf also als externe Migrationsadresse nicht einfach die Adresse des Benutzers mit einer anderen Domain nehmen, sondern muss sie auch ein wenig ändern. Ich habe einfach eine “2″ an jede Adresse an gehangen.
Die zweite Stolperfalle ist eigentlich nur ein Hinweis. Es gibt einen Haken “Nachricht an Empfänger und alternativen Empfänger übermitteln”. Eigentlich bedeutet dieser nur, dass Mails nicht nur weitergeleitet, sondern auch in der lokalen Mailbox gespeichert werden. Leider hat dieser Haken zur Folge, dass manche (ich habe kein Muster gefunden) eMail doppelt auf dem neuen Mailserver zugestellt werden. Warum auch immer.
Zusammengefasst
Um das routing auf der Exchange Seite zu realisieren habe ich also folgendes gemacht:
- eine Migraionsdomain im DNS anlegen (migr.DOMAIN.de), sie zeigt auf den neuen Mailserver
- für jede Mailbox, die auf den neuen Server umzieht, einen Kontakt anlegen – ich habe diese xmigr<USERNAME> genannt
- die Mailadresse des Kontakts zeigt auf <MAILADRESSE>2@migr.DOMAIN.de (die 2 ist kein Tippfehler -> siehe Stolperfalle)
- in den Benutzereinstellungen -> Exchange erweitert -> Zustelloptionen -> Weiterleitung den Namen des Kontakts eintragen
Damit schickt der Exchange Server die Mails für die konfigurierten Accounts an migr.DOMAIN.de. Da sollte dann der neue lauschen.
Postfix
Auf der Postfix Seite ist es ein wenig – … – naja, sagen wir mal logischer Postfix ist installiert mit der eigentlichen Domain. Fühlt sich also dafür zuständig. Nun bekommt er Mails für @migr.DOMAIN.de. Damit er diese nicht abweist, muss er die Migrations Domains kennen. Diese werden in der main.cf hinter den Verweisen auf die Datenbank eingetragen:
virtual_mailbox_domains = proxy:mysql:$config_directory/mysql_virtual_domains_maps.cf,migr.linux-aha.de
Die eMails an @migr.linux-aha.de müssen nun beim Empfang auf @linux-aha.de umgeschrieben werden. Das passiert in der recipient_canonical_map. Darin befindet sich für jede eMailadresse eine Konfigurationszeile, in der die @migr.DOMAIN.de in @DOMAIN.de umgeschrieben wird.
ronny.becker2@migr.linux-aha.de ronny.becker@linux-aha.de
Damit werden die Adressen umgeschrieben und der Mailserver fühlt sich auch wieder zuständig.
Der zweite Schritt ist, dem neuen Mailserver die auf dem Exchange bekannten Mailadressen bekannt zu machen. Das geht auch recht einfach mit Hilfe der “transport” Datei. In der transport muss für jede Mailbox die sich noch auf dem Exchange befindet ein Eintrag gemacht werden aus dem hervorgeht, wo Postfix diese Mailbox findet. Also:
sacha.nowak@linux-aha.de smtp:exchange.linux-aha.de
Mit jedem Umzug muss der passende Eintrag aus der transport gelöscht werden. Um diese Daten zu erstellen bietet sich die Datenbank an, die ich im letzten Artikel beschrieben habe. Diese ist leicht zu aktualisieren und man kann stets aktuelle recipient maps, bzw. transport Dateien erstellen (mit ein wenig scripten und SQL).
Zusammengefasst
Die Anpassungen in Postfix sind also recht übersichtlich. Die beiden Datenbanken pflegen und gut ist. Notwendig ist das ganze nur während der Migration und mit der Datenbank aus dem letzten Artikel als Lieferant der Inhalte, ist es auch recht einfach die Dateien neu zu erstellen.
(No Ratings Yet) Loading ...
