MailPlus Server Mail-Server-PLUS als Gateway für weitere Mail Anwendungen

[FricklerAtHome]

Glück Auf

Ich möchte hier meinen Use-Case mit Mail-Server-Plus zur Diskussion stellen:

Grundprinzip: Ich habe etliche reale Postfächer für verschiedene Mail-Domänen bei meinen Providern. Ich möchte die Kontrolle über den Mail-Verkehr aber nicht bei meinen Providern lassen. Ich möchte auch nicht als Mail-Server direkt aus dem Internet erreichbar sein. Ich brauche eine push-Kommunikation mittels EAS oder Ähnlichem für / mit den mobilen Clients. Das Ganze soll so wenig wie möglich Kosten, die Kosten für die Provider Mailkonten lass ich hier aussen vor.

Meine Lösung: Ich habe den MailServer PLUS ( MSP ) im Einsatz. Der bietet eine kostenlose 5 Benutzer Lizenz. Auf diesem ist eine nicht real existierende Mail-Domäne ( zb.: kings-cross.org -- für die Potter-Fans ) eingerichtet. Mails bekommt dieser MSP grundsätzlich per Fetchmail und niemals von Sendern oder Empfängern mit der Potter-Domäne. Für jede ankommende Empfänger-Adressen habe ich unter MAILÜBERMITTLUNG > DELIVERY > RELAY-HOSTLIST eine Weiterleitung der Mail an dezidierte weitere Mail-Server eingerichtet. Dabei werden auf dem MSP bereits alle Sicherheitseinstellungen vor dem Relay abgearbeitet. Die Empfänger müssen auch nicht im MSP als Benutzer oder als aktivierte Mail-Konten eingerichtet sein. Die "Benutzer-Zahl" ist hierdurch quasi egal. Die Mails werden ensprechend der Empfänger-Adresse, mit MSP Sicherheitsniveau an den weiteren Mailserver geroutet. MSP nutzt nur SMTP, alle anderen Zugriffe (IMAP, POP etc.) sind deaktiviert
Die Mail landet also beim zweiten Mailserver erfüllt nun meine oben beschriebenen Anforderungen wie EAS, oder MAPI für Outlook etc. Dieser zweite MailServer ist über alle notwendigen Ports im internen Netz erreichbar, aus dem INTERNET jedoch nur über eine PORT-Adresse via EAS mit SSL-Schutz. Das ist für alle Clients ( IOS, ANDROID etc. ) nativ nutzbar. ----- Einige werden schon merken das ich aus dem Kopano4S Thread komme ---- Kurzum ich habe mit dem zweiten "Mailserver" die fehlende Funktionalität "EAS" für den MSP nachgerüstet. Zu Lasten eines weiteren "MAIL-SERVERS", jedoch mit guter und automatisch aktualisierter Sicherheit.
Letztlich sendet der zweite Mail-Server alle ausgehenden Mails über den angegeben Relay-Server im SMP. Das macht die Konfiguration nochmal leichter.

Ergebnis: Diese Lösung läuft nun schon seit 1 1/2 Jahren bei mir produktiv (auch in der betreuten Nachbarschaft) ohne Probleme. Es fallen keine Lizenz-Kosten an. IMAP, POP oder andere Ports spielen keine Rolle, EAS funktioniert. Keine dezidierten Apps von Synology werden benötigt. Für den SSL, Zertifikatssicheren Zugriff nutze ich nur Elemente der Syno.

Wie regelt ihr das?

ielbdn
F@H

 

[synfor]

Ich möchte die Kontrolle über den Mail-Verkehr aber nicht bei meinen Providern lassen. Ich möchte auch nicht als Mail-Server direkt aus dem Internet erreichbar sein.

Das schließt sich gegenseitig aus.

Auf diesem ist eine nicht real existierende Mail-Domäne ( zb.: kings-cross.org -- für die Potter-Fans ) eingerichtet.

Das ist keine gute Idee.

 

[FricklerAtHome]

@synfor
Zur Kontrolle: Ich nutze bei verschiedenen Providern 4 real registrierte Mail-Domänen. Von denen hole ich im 3 Minuten Takt alle Mails ab. Ja das kann auch der Provider sehen, aber regelhaft sind die Postfächer max. 3 Minuten befüllt.

Deinen Einwand zur internen Domäne verstehe ich nicht. Also bei mir kommt via fetchmail eine Mail an max@beispiel.de im MSP an. MSP sagt "nicht meine Domäne", aber ich habe einen Relay-Server für die Adresse "max@beispiel.de. An diesen sendet er dann die Mail (ganz ohne Adressumschreibung etc). --- Wo liegt da der Hacken?

ielbdn
F@H

 

[synfor]

War dein Ziel nicht, deinen E-Mail-Verkehr nicht der Kontrolle deiner Provider zu überlassen? Das hast du nicht mal ansatzweise erreicht.

Was die Hacken betrifft, die befinden sich an deinen Füßen. Für die interne Domain verwendet man nicht einfach irgendeine die gerade nicht existiert bzw. in Verwendung ist (was sich jederzeit ändern kann). Wenn du aus Gründen nicht deine eigene Domain nehmen willst, gibts da was aus RFC2606 und RFC6761. Die aus diesen RFCs fallen einem nämlich weder irgendwann auf die Füße noch beißen sie einem in die Hacken.

AVM musste diese Lektion auch schon lernen. Da betraf es die TLD box, die irgendwann vergeben wurde.

 

[FricklerAtHome]

@synfor

Ich glaube jetzt verstehe ich deine Einwände. Wie bei den Hacken habe ich mich wohl nicht ganz selbsterklärend ausgedrückt:

Also ich habe 4 unterschiedliche Mail-Domänen bei verschiedenen externen Hostern. Von denen hole ich im 3 Minuten Takt alle neuen Mails ab und lösche sie auch mit dem Abholen ( pop mittels Fetchmail ).
Diese leite ich in meinem internen Netzwerk zunächst an den SMP. Dieser verwaltet für sich aber nur eine Domäne mit der TLD "xxxx.local" und kann dafür mit der üblichen TLD "xyz.de" nichts anfangen. ("Local" sollte als TLD durch entsprechende RFC geschützt sein,oder?) SMP kann "Fremde" Mails relayen. Und das ist bei mir so eingerichet das die Mails an entsprechende MAIL Server, die nur in meinem internen Netzwerk erreichbar sind und auch nur intern betrieben werden, erfolgt. Ich nutze KOPANO und GROMMUNIO. Sowohl Kopano und Grommunio nutzen wieder die ursprünglichen Domänen.
Alle Mail-User können ihre Mails nicht selbstständig beim Hoster abholen. Um an ihre Mails zu kommen müssen sie wenn sie im Internet sind strikt Active-Sync (EAS), oder ein entsprechendes WEB-Interface nutzen. POP oder IMAP stehen nur im internen Netz zur Verfügung. Bis auf die 3 fetchmail-Minuten liegen alle Mails und Archive nur auf meiner Hardware in meinem internen Netz. Auch nur im internen Netz steht die native Nutzung von Outlook zur Verfügung. Wer Outlook auch von "Draussen" braucht, nutzt halt das selbstgehostete VPN.
Für ssl/tls nutze ich let's encrypt. Die sind auf Domänen / Sub-Domänen gemappt die vollständig unabhängig von den Mail Domänen sind. Hier nutze ich den Relay-Proxy der Syno.
Der Versand aus KOPANO und Grommunio erfolgt wieder an den SMP im Internen Netz und dann von diesem erst in die weite Welt. Unsere Clients können nicht selbständig am SMP vorbei per SMTP versenden.

ist das jetzt klarer?

ielbdN
F@H

 

[synfor]

Mir war das von Anfang an klar. Wie im letzten Beitrag von mir erwähnt, haben deine Mailprovider nach wie vor die Kontrolle über deinen Mailverkehr und zwar an der Front. Das war deiner Aussage nach eigentlich etwas, was du nicht wolltest. Wenn du die Kontrolle nicht bei deinen Mailprovidern lassen willst, musst du die außen vor lassen und zwar komplett.

Meinen Einwand bezüglich der verwendeten Maildomain deines Servers hast du ja anscheinend inzwischen verstanden.

 

[FricklerAtHome]

@synfor
Die ".local" Domain nutze ich immer für solche Zwecke. Hatte zu Anfang mit dem Potter nur ein falsches Beispiel gewählt.
Ja du hast recht. Wenn ich den Provider wirklich draussen vor haben möchte, dann darf ich ihn auch nicht benutzen bzw. beteiligen.
Den Aufwand dies vollständig selbst auf meiner Hardware zu hosten, bzw. einen entsprechenden dezidierten Server auch wieder bei einem Provider zu betreiben ist mir seit längerer Zeit dann doch zu hoch. Ich habe mich mit dem nun beschrieben Konstrukt der Hoster arragiert und nutze ihn als "first line of defence" und vertraue für die 3 Minuten und bei den eingesetzten Protokollen / Logs auf sein Privatsphären und Datenschutz Versprechen. --- Ist natürlich nicht die reine Lehre! Das für unsere Zwecke anzulegende Schutzrisiko ist aber auch nicht mehr so hoch, da Kinder, Ehefrau und die betreute Nachbarschaft von Twitter, Facebook, WhatsUp etc. eh nicht lassen können. Alles rein private Nutzung.

Danke das du mit den pingeligen Nachfragen ;-) mich noch zu weiteren Erklärungen verlockt hast. Mein Ansinnen wird nun für die Mitlesenden im Forum hoffentlich klarer. Ich wollte hier eine Lösung aufzeigen, die für einige eventuell eine Anregung ist. Besonders die Kopano-Fraktion im Zarafa Thread steht vor einigen Aufgaben. Bei Kopano muss man sich weiterhin einen aktuellen Anti-Spam / Anti-Viren Schutz selber frickeln. Mit dem MSP als Gateway schaltet man einen aktuellen Schutz davor.

ieLbdN
F@H

 

[synfor]

Selbst für Beispiele in Anleitungen und in der Dokumentation hat RFC2606 und Co. etwas: example\.(com|net|org|edu)