Re: Mailweiterleitung von Postfix an Exchange 5.5
Hallo Matthias, Matthias Houdek <linux@houdek.de> wrote ..
thobro@FachinformatikOnline.DE am Samstag, 20. September 2003 21:16:
Hallo Matthias,
Matthias Houdek <linux@houdek.de> wrote ..
thobro@FachinformatikOnline.DE am Samstag, 20. September 2003 18:26:
Hallo Liste,
ich habe ein kleines Problem. Nach einer Systemumstellung von MS auf SuSE 8.2 habe ich es leider noch nicht geschafft, das Fetchmail / Postfix die eMails an unseren Exchange 5.5-Server weiterleiten. Andersherum funktioniert es. Die User melden sich mit Ihren Desktops (Win XP + W2K) an einer zur Zeit noch NT 4.0-Domäne an und greifen mit Ihren Clients auf unseren Exchange 5.5-Server zu. eMail werden vom ExchangeServer über Postfix ins Internet geroutet.
Meine Konfiguration: SuSE 8.2 Fetchmail 6.2.1-27 Postfix 2.0.6-14
Mein Problem ist jetzt, dass ich leider die mit Fetchmail (Version 6.2.1-27) abgeholten eMails an den ExchangeServer weiterleiten will, bzw. muss. Dabei habe ich noch einige Schwierigkeiten .....
Prinzipiell gibt es zwei Möglichkeiten: 1. Postfix leitet die Mails via SMTP an den Exchange-Server 2. Postfix legt die Mails auf dem Linux in Postfächer ab und der Exchange-Server POPt den Linux.
zu 1. Am einfachsten sollte es hier mit Hilfe der Dateien /etc/postfix/canonical sowie /etc/postfix/transport klappen. In canonical werden die Zuordnungen der externen Postfächer zu den loaklen Postfächern eingetragen. Transport legt fest, ob für bestimmte Empfänger oder Domains besondere Transportwege zu nutzen sind. Hier ist für die Domain des Exchange-Servers entsprechend der Exchange-Server einzutragen. Außerdem muss ggf. dem Exchange-Server gesagt werden, dass er Mails vom Postfix anzunehmen hat.
zu 2. Das ist einfacher zu konfigurieren, aber vom Ablauf her etwas umständlich. Ich würde es nur machen, wenn der Exchange-Server ohnehin demnächst rausfliegt und dann alles nur noch über den Linux läuft. Postfix sortiert die Mails ganz normal lokal in die entsprechenden Postfächer (/var/[spool/]mail/<user>) und der Linux stellt diese Postfächer via POP-Dämon (z.B. qpopper) bereit. Der Exchange-Server muss nun nur noch gesagt bekommen, dass er die Mails nicht mehr direkt vom Provider POPen soll, sondern von dem lokalen Linux.
Leider fliegt der Exchange 5.5 nicht raus, da einige wichtige Anwendungen auf diesem laufen. Im Gegenteil, er wird inkl. Betreibssystem ge-updated. Es steht aber noch nicht fest ob auf 2000 oder 2003. Die Entscheidung kommt erst noch ....
Eine Lösung wie Du in 2.) vorgeschlagen hast, ist nicht so mein Fall, da wir eine ziemlich grosse fluktuation an MAs haben (bedingt durch Aushilfen, Studentische Hilfskräfte etc.). Das Anlegen von Usern sowohl auf Linux als auch im Exchange würde zu viel arbeit kosten ....
Bleibt also nur Lösung 1.). Was muss ich in /etc/postfix/canonical eintragen und was in /etc/postfix/transport ?
Derzeit ist mein /etc/postfix/transport leer, und /etc/postfix/canonical ebenfalls.
Schau dir mal die Doku an, sind eigentlich sehr trivial aufgebaut. Im Prinzip sind es zeilenweise Auflistungen von Zuordnungen (mailadresse extern zu mailadresse intern bzw. Ziel zu Transportart/-weg).
Ich verwende Intern wie Extern den gleichen Domänennamen .....
-- Gruß MaxX 8-)
Grüsse Thomas
thobro@FachinformatikOnline.DE am Sonntag, 21. September 2003 14:34:
Hallo Matthias,
Matthias Houdek <linux@houdek.de> wrote ..
thobro@FachinformatikOnline.DE am Samstag, 20. September 2003 21:16:
Hallo Matthias,
Leider fliegt der Exchange 5.5 nicht raus, da einige wichtige Anwendungen auf diesem laufen. Im Gegenteil, er wird inkl. Betreibssystem ge-updated. Es steht aber noch nicht fest ob auf 2000 oder 2003. Die Entscheidung kommt erst noch ....
Eine Lösung wie Du in 2.) vorgeschlagen hast, ist nicht so mein Fall, da wir eine ziemlich grosse fluktuation an MAs haben (bedingt durch Aushilfen, Studentische Hilfskräfte etc.). Das Anlegen von Usern sowohl auf Linux als auch im Exchange würde zu viel arbeit kosten ....
OK, ist klar. Ist ja auch nur als Notlösung gedacht gewesen (die noch dazu nicht gefunxt hätte, da Exchange kein POP kann).
Bleibt also nur Lösung 1.). Was muss ich in /etc/postfix/canonical eintragen und was in /etc/postfix/transport ?
Derzeit ist mein /etc/postfix/transport leer, und /etc/postfix/canonical ebenfalls.
Schau dir mal die Doku an, sind eigentlich sehr trivial aufgebaut. Im Prinzip sind es zeilenweise Auflistungen von Zuordnungen (mailadresse extern zu mailadresse intern bzw. Ziel zu Transportart/-weg).
Ich verwende Intern wie Extern den gleichen Domänennamen .....
Hm, das ist ungünstig, denn es existiert ja für den Mitarbeiter Horst unter der öffentlichen Domain <Firma>.de bereits ein Postfach horst@<firma>.de. Man kann also kein zweites Postfach unter der gleichen Domain mit dem gleichen Namen einrichten, dann wäre es nicht mehr eindeutig. Ausweg1: Alle Postfächer bekommen einen Zusatz (z.B. horst-local@<firma>.de). Das ist auch nicht das Gelbe vom Ei, denn jetzt müsste man mit entsprechenden Regeln relativ umständlich festlegen, für welche Postfächer der Provider im Internet und für welche der Exchange-Server zuständig ist. Ausweg2: Die lokale Domain wird geändert, z.B. in <firma>.local. Hier zeigt sich, wie flexibes das Netzwerk vorher geplant wurde *g*. Unter Umständen bedeutet das auch eine Menge Arbeit. Vorteil: Exchange ist für <firma>.local zuständig und somit kann die Mail eindeutig weitergeleitet werden. (Mehr dazu unten) Ausweg3 (mein Favorit): Lass die User die Mail von auswärts doch einfach vom zentralen Linux-Server abholen (POP oder auch IMAP). Und der kommuniziert je nach Bedarf 1 .. 5 Mal in der Stunde mit dem Provider-Mail-Server. zu 2.: Die canonical sähe wie folgt aus: @<firma>.de @<firma>.local und die transport so: <firma>.local smpt:<Adresse des Exchange> Ggf. auch ein anderes Protokoll (uucp, lmpt) eintragen - was weiß ich, was Exchange kann und was nicht. Eigentlich beschämend für so ein 1000,- Euro-Teil, dass es nicht mal POP beherrscht. -- Gruß MaxX 8-)
Matthias Houdek wrote:
Ggf. auch ein anderes Protokoll (uucp, lmpt) eintragen - was weiß ich, was Exchange kann und was nicht. Eigentlich beschämend für so ein 1000,- Euro-Teil, dass es nicht mal POP beherrscht.
Das Ding bietet schon einen POP-Server an, nur über sowas wie "fetchmail"-Funktionalität verfügt es nicht. Die einzige Chance damals war ETRN, dass ist ein Verbindungsaufbau über SMTP wo der Server dann die gespoolten Mails zurückschickt. Hmm "€"? Ich glaube da gab es 5.5 schon nicht mehr... -- Andreas
Am Sonntag, 21. September 2003 20:35 schrieb Matthias Houdek:
Hm, das ist ungünstig, denn es existiert ja für den Mitarbeiter Horst unter der öffentlichen Domain <Firma>.de bereits ein Postfach horst@<firma>.de. Man kann also kein zweites Postfach unter der gleichen Domain mit dem gleichen Namen einrichten, dann wäre es nicht mehr eindeutig.
Wenn man ganz genau weiß, was man macht schon. Ich habe einige Netze mit solcher Konfiguration in Betreuung. Der interne Mailserver ist so konfiguriert, daß alle Mails von intern an die externe Domain trotzdem lokal ausgeliefert wurden. Der externe Mailserver beim Provider wird per fetchmail regelmäßig abgefragt und lokal zugestellt. Für die Nutzer ist dies ideal, sie brauchten sich nicht 2 unterschiedliche Adressen merken, ob intern oder extern wurde vom Mail-Gateway entschieden. Einziger Nachteil war, daß ein Versand von intern an die externen Postfächer über das Mail-Gateway nicht möglich war. Das kann aber meistens in Kauf genommen werden, nur bei Außendienstlern könnte sowas gebraucht werden. Bei Postfix wäre über canonnical für bestimmte Nutzer eine Ausnahme von diesr Regel denkbar. Die interne DNS-Domain ist natürlich verschieden von der externen. Das System funktioniert seit Jahren ohne größere Probleme. Gruß Torsten
Torsten Huebner am Montag, 22. September 2003 08:36:
Am Sonntag, 21. September 2003 20:35 schrieb Matthias Houdek:
Hm, das ist ungünstig, denn es existiert ja für den Mitarbeiter Horst unter der öffentlichen Domain <Firma>.de bereits ein Postfach horst@<firma>.de. Man kann also kein zweites Postfach unter der gleichen Domain mit dem gleichen Namen einrichten, dann wäre es nicht mehr eindeutig.
Wenn man ganz genau weiß, was man macht schon. Ich habe einige Netze mit solcher Konfiguration in Betreuung. Der interne Mailserver ist so konfiguriert, daß alle Mails von intern an die externe Domain trotzdem lokal ausgeliefert wurden.
Ja, das ist ken Problem. Ich kann ja in transport für jede beliebige Domain (oder sogar Adresse) einen Alternativen Transportweg festlegen.
Der externe Mailserver beim Provider wird per fetchmail regelmäßig abgefragt und lokal zugestellt. Für die Nutzer ist dies ideal, sie brauchten sich nicht 2 unterschiedliche Adressen merken, ob intern oder extern wurde vom Mail-Gateway entschieden. Einziger Nachteil war, daß ein Versand von intern an die externen Postfächer über das Mail-Gateway nicht möglich war.
Das empfinde ich zumindest als ziehmlich großen Nachteil. Ich kenne viele Firmen, in denen die Mitarbeiter ihre Mails auch in anderen Filialen oder von unterwegs oder zu Hause abrufen möchten/müssen. Fetchmail holt dabei mit keep (und UIDL) ab, ein extra Script löscht regelmäßig alte Mails in den externen Postfächern. Somit bleiben die Mails für eine definierte Zeit auch von anderen Stellen aus abholbar. Wenn jetzt die Mails von lokal nicht (auch) in das externe Postfach zugestellt werden, kann der Chef z.B. keine Mail mehr an seinen Außendienst schicken. Oder der Transport muss für jede Mailadresse flexibel (je nach dem, wo der Empfänger gerade ist) angepasst werden. Na prima.
Das kann aber meistens in Kauf genommen werden, nur bei Außendienstlern könnte sowas gebraucht werden.
oder bei verschiedenen Filialen, bei Heimarbeitern, bei ... (was weiß ich)
Bei Postfix wäre über canonnical für bestimmte Nutzer eine Ausnahme von diesr Regel denkbar. Die interne DNS-Domain ist natürlich verschieden von der externen.
Das System funktioniert seit Jahren ohne größere Probleme.
Ich denke, da ist eine leicht abgewandelte lokale Domain einfacher zu händeln. Und die Leute müssen sich auch nur eine Adresse merken, nähmlich die externe. Die lokale Domain wird doch nur für die korrekte Zustellung im System gebraucht. Kein User muss die kennen. Natürlich geht so jede Post von lokal zu lokal erst einmal ins Internet, aber was soll's. In wirklich großen Firmen, wo das eventuell Ausmaße annehmen könnte, steht meist der MX der Domain sowieso direkt in der Firma. -- Gruß MaxX 8-)
participants (4)
-
Andreas Winkelmann -
Matthias Houdek -
thobro＠FachinformatikOnline.DE -
Torsten Huebner