Lass dich nicht verrückt machen... Im Endeffekt müsst ihr das wissen, wie ihr den Mailserver betreiben wollt.
Mal ein paar Sachen, die mir hier auffallen und wo sich mit persönlich schonmal fragen stellen würden:
-> hier wird von erhöhter Verfügbarkeit eines Mailservers (ala Office 365) in der Cloud gesprochen -> schön dass die Kiste läuft, aber wer garantiert, dass man überhaupt mit seiner INet Anbindung die gleiche oder höhere Verfügbarkeit hat um überhaupt auf den Mailserver zuzugreifen? -> was bringt es den Leute, die auf die Mails angewiesen sind, wenn das INet weg ist und man nichtmal mehr Zugriff auf seine Mails hat?
-> POP3 und Exchange -> die Empfehlung von MS bezieht sich eigentlich klar auf den Part, den Exchange die Mails via POP3 holen zu lassen. Der kann das zwar nicht direkt selbst, aber mit Zusatzdiensten geht das schon. Ihr macht das aber ja anders, wie ich das sehe. Ihr holt die Mails via POP3 via externer Kiste und schickt via SMTP zum Exchange. Damit seit ihr voll im Fluss mit den Empfehlungen von MS. Also keine direkte Panik. Mögliche Probleme mit POP3 können aber trotzdem auftreten...
-> Umstellung von POP3 auf SMTP. Hier musst du klar sauber planen. Es gehört mehr dazu, als nur den Schalter umzudrehen und zu hoffen, dass es noch alles geht
Bspw. so paar Sachen wie Reverse DNS Eintrag public, wenn ihr direkt Mails raussenden wollt. SPF Einträge, damit die Mails auch ankommen, die ihr versendet. INet Leitung/Typ -> stino ADSL Einwahl wird teils abgelehnt usw. usf. Das was der riesige Vorteil bei der POP3/Providerlösung ist, der Provider empfängt die Mails und das sollte normal auch sauber funktionieren. Wo euer Mailserver steht, ist völlig wurscht. Sinnvollerweise sollte er dann auch rausgehend den Provider als SmartHost nutzen...
Also so genau steige ich jetzt immer noch nicht durch, was mitr eigentlich empfohlen wurde... Einerseits heisst es, den Exchange ins Netz stellen, sonst verspiele ich die ganzen Vorteile (welche genau?) und andererseits wird die pop3-Lösung als gut befunden.
Wo der Mailserver steht, ist eigentlich egal. Es gibt sowohl in der Cloud als auch im eigenen Haus Vor- und Nachteile.
Bspw. kommt bei der Cloudlösung der Part mit der INet Leitung auf -> ohne INet, kein Exchange Access. Das heist dann wohl normal, nicht nur das reine Mailing ist betroffen, auch Kontakte, Termine, Kalender usw. usf. gehen nicht. Schlimm genug, wenn INet mal down ist, aber ohne diese elementaren Sachen ist das Arbeiten gleich noch schwerer
Auch steht halt der Traffic auf der Kontraseite. Je nachdem, um wie viele Daten wir hier sprechen, kommt da schon ein gewisses Maß an Bandbreite zusammen... Wenn der Spaß dann schnarchlahm ist, weil nur ne dünne Anbindung zum INet vorhanden ist, wirds auch blöd.
Die eigen gehostete Lösung benötigt aber halt auch KnowHow über das Produkt, du musst dich um Themen wie Backups usw. selbst kümmern, du musst die Kiste absichern für ungewollte Zugriffe usw. usf.
Mein größter Kritikpunkt bei der Geschichte ist übrigens das Thema Datensicherheit. Bei Mails ist es recht problemfrei, die kommen (wenn nicht intern only) so oder so übers INet, in der Masse der Fälle auch unverschlüsselt. Aber was ist mit dem Rest? Termine, Kontakte, Aufgaben usw. usf. -> alles würde in der Cloud liegen und damit für potentiel jeden frei zugänglich. Dazu kommt (Vorsicht Aluhut), heute mag der Spaß mit SSL/HTTPS noch halbwegs sicher sein, aber was ist mit morgen? Fällt die Verschlüsslung, besteht die Gefahr, dass Dritte Zugriff auf die Daten erhalten. Ganz blöd sind die nämlich auch nicht
Welche Vor-Nachteile hat denn meine jetzige Pop3-Lösung? Wir haben keinen Pop-Connector, sondern das macht unsere Linux-Firewall mit integriertem Mail-Server incl. Virenscan, Spam-Bewertung usw. - Abholung von einem catch-all-Postfach und dann aussortierung durch den Exchange, was angenommen wird und was nicht.
Nachteil ist klar der Zeitversatz. Damit kann man aber grundsätzlich leben...
Weitere Nachteile sind Themen wie möglicherweise doppelte Mails (CC/BCC)...
Ich würde aber an deiner Stelle zusehen, dass du die Mails vor dem Exchange aussortierst. Es ist irgendwie nicht Sinn der Sache das den internen Mailserver machen zu lassen
Normal sollte das Spamgateway vor dem Mailserver sitzen und alles wegdroppen, was nicht durch darf. Hinten am Mailserver sollte also nix ankommen, was dort nicht hin soll...
Vorteil einer solchen Lösung ist, wie oben schon erwähnt, du kannst die Mails vom Provider holen und rausgehende Mails über den Provider versenden. Damit kann der Mailserver Standort ungebunden betrieben werden -> auch hinter einem privat Anschluss ADSL ohne fixer IP.
Nachteil ist weiterhin noch, es ist eine zusätzliche Fehlerquelle. Sprich verschluckt sich was beim POP3 Connect, dann KANN! es vorkommen, dass die Mail verlustig geht. -> hier sollte man Risiken bewerten und abwegen.
Wenn man eine Mail an einen nicht vorhandenen Empfänger schreibt, komt übrigens eine Fehlermeldung zurück: "timeout, too many hops", "hops exceed" oder sowas ähnliches. Die Mail wird jedenfalls nicht von unserem System angenommen. Seit wir das so haben (zuvor bekam sowas alles der Admin zum manuellen verteilen), ist die SPAM-Flut schon beachtlich zurück gegangen.
Der Sinn hinter einer CatchAll Adresse ist eigentlich genau das, was ihr nicht macht
Sprich damit WILL man doch genau die Mails, die gesendet werden, ohne dass es den Empfänger gibt.
-> hier gilt es aber eben abzuwägen, wie du selbst sagst, SPAM vs. Schreibfehler bspw.
PS: gegen die Spamflut gibts übrigens bessere/andere Möglichkeiten. Schau dir SPF Einträge an (sollte man sauber setzen!), schau dir die Konfiguration eures Spamgateways an, da findet sich sicher auch was zum Konfigurieren, wer überhaupt Mails bestimmter Domains senden darf usw.
Neben dem üblichen Spam Zeug, was recht brauchbar gefiltert wird mittlerweile, sind es eher Mails mit schadcode oder ähnliches, was aktuell massiv im Umlauf ist. Wenn bspw. eine Mail von "kopierer@eure-mail-domain.tld" kommt, sollte das Spamgateway diese von vorn herrein ablehnen, da solche Mails mit der eigenen Domain schlicht nicht von public kommen können (normal zumindest nicht)
