[tapg] Fragen zum Aufbau des neuen Mailservers

[Takashi Linzbichler]

Hi allseits,

On Tuesday 17 September 2013 18:48:32 Jogi Hofmüller wrote:
> Ich bemühe nach einigen Jahren wieder einmal diese Liste, die wir ja
> eigentlich sträflich vernachlässigten.  Wie im $Subject schon
> angekündigt, widmen wir uns endlich wieder dem Aufbau eines neuen
> Mailservers (POP3/IMAP), denn wir haben bald keinen Spielraum mehr im
> Mailspool (obwohl wir in unregelmäßigen Abständen tote Mailboxen löschen
> und die Benutzer+innen auffordern, doch bitte ihre Spam-, Trash- und was
> weiß ich für Folder aufzuräumen.
> 
> Um was ich hier bitte, sind Erfahrungen, Meinungen und Argumente zu
> folgenden Dingen:

OK, ich pack' einmal die virtuelle Tube aus und gebe meinen Senf dazu...
 
> * Software:  dovecote, cryus, ?
> 
> Derzeitiger Stand der Dinge:  cyrus21.  Der erlaubt Zugriff auf Mails
> ausschließlich via POP/IMAP.  Wie wichtig und oder sinnvoll erscheint
> die Anforderung, Mails auch direkt im Filesystem verwalten zu können?

Hm, kann da nur eine ganz persönliche Erfahrung abrufen, ich bin irgendwann 
von Cyrus (1.irgendwas) abgegangen, weil ich das Teil als rel. mühsam zu 
administrieren empfand und v.a. der Umstieg auf Ver. 2.x in 2 Versuchen 2x 
überhaupt nicht vernünftig klappen wollte...

Landete bei Dovecot, war echt angetan von dem Teil, simpel, funktionierte 
einfach ohne viel Tamtam. Dachte auch, dass die Möglichkeit, Mails direkt im 
FS zu bearbeiten, ein im Notfall gut brauchbares feature darstellt. Soweit so 
gut, ich hatte nie Probleme mit Dovecot, bin dann irgendwann aber auf Citadel 
als 'rundum sorglos Paket für alles' gelandet (also eher der featuritis 
wegen). Was mir allerdings bei diesem Umstieg schon aufgefallen ist, war die 
Tatsache, dass Citadel (speichert Mails in einer Berkeley-DB) beim Zugriff auf 
den gleichen Mailbestand (ca. 11k Nachrichten)_deutlich_ schneller war als 
Dovecot, also die Speicher-/Indizier-Methodik von letzterem einer 'echten' 
Datanebank doch deutlich überlegen ist. Das würde im Rückschluss für mich doch 
eher in Richtung Cyrus deuten...

Ich glaub' übrigens die überwiegende Mehrzahl der User hat wenig Ambitionen, 
im FS Mailfiles zu editieren ;-)

> * Filesystem: btrfs, ext4, ?
> 
> Derzeitiger Stand der Dinge:  ext3.  Fein wäre ein Filesystem, das
> Kompression unterstützt, da sich das im Mailspool echt auszahlen würde.

Dann bleibt dir eh nicht allzuviel Auswahl, wenn du die ganz exotischen Dinge 
außer Acht lässt. btrfs komprimiert transparent, ext4 gar nicht. Für ZFS 
müsstest du auf etwas zurückgreifen, das aus Lizenzgründen niemals im Linux- 
(Vanilla-?) Kernel auftauchen wird, ergo entweder Drittanbieter oder FreeBSD 
(denke Debian/GNU kFreeBSD ist noch nicht production-ready). Allerdings frage 
ich mich gerade, ob die Kompression wirklich viel bringt, btrfs macht das IMHO 
auf File- nicht auf Block-Ebene. Und ich nehme einmal an, dass nicht die 
Nachrichtentexte per se massig Speicherplatz belegen, sondern die Attachments. 
Und die sind meistens eh schon komprimiert (heutzutage selbst Office-Dateien 
;-) ). Klar, den statistischen 1.333333-Faktor an Base64-Overhead könnte man 
(abhängig davon, wie das jew. System die MIME-Teile speichert) u.u. 
reduzieren. Wie auch immer, ich denke, die Anzahl der benötigten Blöcke im FS 
wird sich nicht allzusehr verringern, die Anzahl der benötigten Inodes gar 
nicht...

Somit würde ich die 'Krot schlucken' und doch bei ext4 bleiben (bin da 
bekanntermaßen aber auch eher konservativ/vorsichtig/ängstlich). Ich glaube, 
bis zum nächsten Upgrade wird das locker reichen und bis dahin wird 
wahrscheinlich selbst Debian btrfs als Std-FS verwenden :-)

> Meine aktuelle Idee ist, diesen Service *nicht* zu virtualisieren, da
> der Virtualisierungsserver schon ziemlich am Limit ist, und uns nicht
> den nötigen Spielraum in Puncto Speicherkapazität lässt.  Außerdem denke
> ich darüber nach, sämtlich Maildienste, die Interaktion unserer
> Benutzer+innen erforden, auf dieser Maschine zu konzentrieren:
> POP/IMAP, SMTP-Submission, Webmail.

Selbst wenn es auf einer eigenen Maschine läuft würde ich, des einfacheren 
potentiellen Umzugs wegen, einen Hypervisor darunterlegen...

just my $0.01,

	-ta