Nachdem auf der Mailingliste die Frage nach einem E-Mail-Dienst aufgetaucht ist und dies im Moment zu einem der wichtigsten Kommunikationswege in unserem Netzwerk zählt, sollen hier Ideen zur Realisierung eines solchen Dienstes gesammelt werden.
E-Mail-Dienst
Anforderungen
- Autokonfiguration für Clients wie Thunderbird
- Webmail?
Umsetzungsvorschläge
Variante 1
Test 
eines dezentralen Mail-Systems
Die Grundprinzipien dieses Vorschlags sind
- dezentral
- ausfallsicher (funktioniert auch nur intern bzw. bei Ausfall mehrerer Server)
- Wartung erfolgt möglichst lokal
Vorraussetzung für den Betrieb des Systems sind
- DNS-Server
- ? netzweite Blacklist
Router
Die Mail-Speicherung und User-Verwaltung wird über das ganze Netzwerk verteilt. Dazu kann für jeden Standort ein MX-Host im DNS konfiguriert werden, der die lokale Mail-Zustellung übernimmt. In der einfachsten Variante kann dazu auch der Router selbst dienen z.B. mit:
popa3d (mit maildir-Patch)
vllt. mit einem einfachen Webinterface zur Konfiguration & Mail-Anzeige
Kompiliert macht alles zusammen ca. 50KB (komprimiert) auf der JFFS2 Partition aus (von max getestet). Falls es höhere Anforderungen an die Zuverlässigkeit oder die Flexibilität bzw. den Speicherplatz der Mailspeicherung gibt, empfiehlt sich der Einbau einer SD-Karte in den Router (sehr elegant mit TL-WR741ND mit SPI oder USB), ein Alix-Board oder gleich ein eigenständiger Server. Für die externe Abholung könnte zusätzlich ein POP3-Relay (z.B. Perdition, nginx) in ähnlicher Weise wie der Ext-Http-proxy fungieren.
Mail Exchanger
Für die Mail-Zustellung werden im Netzwerk etwas "fähigere" (=mehr Hauptspeicher, Rechenleistung) Geräte (z.B. alle Alix-Boards die sich langweilen) verteilt, die lediglich die Zustellung innerhalb des Netzes übernehmen. Die Last-Verteilung kann z.B. über Round-Robin-DNS erfolgen. Für ausgehende Nachrichten leiten diese die Mails an die SMTP-Server an den Netzgrenzen weiter.
Mit XMail (als virtuelle Maschine getestet) würde die Konfiguration auf zwei Einträge jeweils für lokale Domains (<standort>.domain) und alle anderen im custdomains-Verzeichnis beschränkt sein. Zusätzlich ist noch ein Überlastungsschutz, für übermäßig häufige Anfragen sinnvoll. Dazu können die MXe Eintragungen in eine netzweite Blacklist vornehmen. (z.B. für Spambot-infizierte Rechner)
Relays
Die SMTP-Server an den Netzgrenzen verwenden Spam-Filter (vllt. auch mit Virenscanner) für ein- und ausgehende E-Mails (um nicht auf Blacklists zu landen) und haben dazu genug Speicherplatz und Rechenleistung. Eingehende Nachrichten können z.B. an die internen mailrelays weitergereicht werden. Hierzu muß das Relay von außen alle Nachrichten an domain (mit Prüfung des Empfängers) und *.domain akzeptieren. Zusätzlich können auch Alias-Adressen am Relay angelegt werden, die auf <standort>.domain-Adressen weitergeleitet werden.
Damit wird an den Netzgrenzen nur die Filterung und Alias-Verwaltung durchgeführt, an möglichst vielen Orten im Netzwerk die Weiterleitung und am Zielort die Speicherung, User-Verwaltung und "Abholung" über POP3.
-- max 2012-04-12 11:28:16
Variante 2
Einrichtung eines konventionellen Mail-Servers
Dazu müßte auf einem Server die gesamte Benutzerverwaltung, Speicherung und Filterung übernommen werden. Der klare Vorteil ist in diesem Fall die zentrale Administration, die aber gleichzeitig auch den Hauptnachteil darstellt (es braucht einen/mehrere Administratoren). Ein weiterer Nachteil ist der erforderliche Speicherplatz für die Postfächer. Weiters würde ein Ausfall dieses Servers das gesamte Mail-System lahm legen. Ein weiterer Vorteil ist für User die gewohnte Verwendung im Hinblick auf Free-Mail-Dienste. (Verwendung als Webmail, kein Mail-Client notwendig)
-- max 2012-04-12 11:28:16