Empfehlung einfacher IMAP server

h^2

h^2

hat ne Keule +1
Hallo zusammen,

ich möchte das E-Mail-Archiv aus mehreren accounts in einen lokalen IMAP server umziehen.

Meine requirements:
  • einfacher setup
  • kein externes user-management, sondern einfache Methode genau einen account zu betreiben
  • keine Sendemöglichkeit/SMTP benötigt
  • 20-30GiB sollten kein Problem sein.
  • wahrscheinlich irrelevant, aber der Server wird nur per LAN erreichbar sein

Was würdet ihr da empfehlen?

Danke & Gruß
Hannes
 
Ich nehme auch fuer "einfache" setups dovecot. Die config laesst sich auf ein paar Zeilen eindampfen (diese ultra zersplitterte config directory struktur braucht man NICHT)..

Warum? Weil in den 872349 Protokoll-Schweinereien und speziell auch mailbox-Storage viel zu viel Fallstricke haben fuer ein "ich hab da was in 20 Zeilen (python/node/ruby/go/...) gehackt und nenne es SimpleIMAPd" im Einsatz.

Fuer das beschriebene ist dann eine dovecot.conf (hier auf OpenBSD) grob:
Code: 
mail_location = sdbox:~/Mail
mbox_write_locks = fcntl
namespace inbox {
  inbox = yes
}
passdb {
  driver = bsdauth
}
protocols = imap
ssl_cert = </etc/ssl/blabla.fullchain.pem
ssl_key = # hidden, use -P to show it
userdb {
  driver = passwd
}
 
Das mit dovecot unterschreibe ich auch mal.
Ich weiß, es gibt im Netz dicke, mehrseitige Tutorials dafür...wenn man sich aber zunächst nur aufs minimale wie empfohlen fokussiert, klappt das gut.

Falls man etwas mehr Anregung braucht oder es dann doch ausgebaut werden soll (damit hab ich mir alles zusammengefriemelt :) ):

FreeBSD mail server: IMAP using Dovecot - davd.io

davd.io is a blog featuring various topics related to web development and server operation
www.davd.io

How To Run Your Own Mail Server

A guide to self-hosting your email on FreeBSD using Postfix, Dovecot, Rspamd, and LDAP.
www.c0ffee.net www.c0ffee.net
www.purplehat.org

FreeBSD-Postfix-MySQL-SpamAssassin-Maia-Virtual Setup

Last updated: Mar 16, 2022FreeBSD Version: 13.0-RELEASE-p7 First, I would like to thank DrkShdw, Worth, and Fr0zen from ##FreeBSD on FreeNode for their time and ideas when it came down to me writin…
www.purplehat.org
 
OK, das ging schneller als gedacht. Habe erstmal ohne SSL eingerichtet, weils eh nur intern läuft, das mache ich dann später.

Login von Thunderbird klappt und testweise Mail dort ablegen auch. Ich habe mail_location = maildir:~/Maildir gesetzt, spricht da was gegen oder ist das das richtige Format, wenn da 20GB+ drin landen?

Wenn ich das richtig verstehe speichert Maildir jede Mail im Plaintext in einer einzelnen Datei, richtig? Das finde ich einerseits nice, weil es Backups erleichert, aber das werden ja dann auch richtig viele sehr kleine Files.

Ich würde zfs compression=zstd setzen. Gibt es anderes Tuning was ihr empfehlen würdet? recordsize betrifft ja nur die maximale Record-Größe. Die minimale ist wahrscheinlich 4k, oder? Da wird es sicher viele Mails geben die kleiner sind, erst recht komprimiert.. wie macht ihr das sonst?
 
zstd ist sicher sinnvoll, recordsize würd ich default lassen, hast du ja selbst erkannt wieso. Selbst mit mehreren Millionen Files in einem MailDir hatte ich noch keine Probleme.
Früher gab es tuning Tipps, vorallem für manche Linuxfilesysteme, mit ZFS sollte das aber alles obsolet sein.
 
Hm, aber was bringt die Compression, wenn die durchschnittliche E-Mail eh kleiner als 4K ist? Ich glaube eher, dass ich da viel Platz verschwende. Jetzt ärgere ich mich ein bisschen, dass ich nicht ashift=9 genommen habe, was meine Platten eigentlich auch können.

edit: dazu kommt noch, dass es encrypted ist, was den Platzbedarf bei kleinen Dateien ja nochmal erhöht.
 
Huch, seit ich kein Mod mehr bin, kann ich alte Beiträge nicht bearbeiten, naja. Was mir noch einfiel:

Ich muss nur einmal im Jahr in das Mail-Archiv schreiben (wenn das vorletzte Jahr reinwandert), ansonsten wird es quasi read-only betrieben. Ich weiß nicht ob das für oder gegen bestimmte Setups spricht.
 
Also ich habe in meinem Posteingang sogut wie keine EMails unter 4K. Denke auf jedenfall das zstd etwas bringt. Overhead der encryption dürfte jetzt auch nicht wirklich merkbar sein, aber ich weiß ehrlich gesagt nicht wie intern die Blockgrößen für aes-gcm gemacht wird. Aber Pro Block sollten 128Bit für den GCM Tag dazu kommen.
 
h^2 schrieb:
Hm, aber was bringt die Compression, wenn die durchschnittliche E-Mail eh kleiner als 4K ist? Ich glaube eher, dass ich da viel Platz verschwende. Jetzt ärgere ich mich ein bisschen, dass ich nicht ashift=9 genommen habe, was meine Platten eigentlich auch können.
Zum Vergrößern anklicken....
Code: 
NAME                 PROPERTY              VALUE                     SOURCE
zroot/jails/postfix  type                  filesystem                -
zroot/jails/postfix  creation              Tue Aug 30 18:59 2022     -
zroot/jails/postfix  used                  1.39G                     -
zroot/jails/postfix  available             101G                      -
zroot/jails/postfix  referenced            740M                      -
zroot/jails/postfix  compressratio         3.20x                     -
zroot/jails/postfix  mounted               yes                       -
zroot/jails/postfix  quota                 none                      default
zroot/jails/postfix  reservation           none                      default
zroot/jails/postfix  recordsize            1M                        inherited from zroot
zroot/jails/postfix  mountpoint            /zroot/jails/postfix      inherited from zroot
zroot/jails/postfix  sharenfs              off                       default
zroot/jails/postfix  checksum              on                        default
zroot/jails/postfix  compression           zstd-19                   received
zroot/jails/postfix  atime                 off                       inherited from zroot
zroot/jails/postfix  devices               on                        default
zroot/jails/postfix  exec                  on                        default
zroot/jails/postfix  setuid                on                        default
zroot/jails/postfix  readonly              off                       default
zroot/jails/postfix  jailed                off                       default
zroot/jails/postfix  snapdir               hidden                    default
zroot/jails/postfix  aclmode               discard                   default
zroot/jails/postfix  aclinherit            restricted                default
zroot/jails/postfix  createtxg             538                       -
zroot/jails/postfix  canmount              on                        default
zroot/jails/postfix  xattr                 on                        default
zroot/jails/postfix  copies                1                         default
zroot/jails/postfix  version               5                         -
zroot/jails/postfix  utf8only              off                       -
zroot/jails/postfix  normalization         none                      -
zroot/jails/postfix  casesensitivity       sensitive                 -
zroot/jails/postfix  vscan                 off                       default
zroot/jails/postfix  nbmand                off                       default
zroot/jails/postfix  sharesmb              off                       default
zroot/jails/postfix  refquota              none                      default
zroot/jails/postfix  refreservation        none                      default
zroot/jails/postfix  guid                  14486435355472889329      -
zroot/jails/postfix  primarycache          all                       default
zroot/jails/postfix  secondarycache        all                       default
zroot/jails/postfix  usedbysnapshots       688M                      -
zroot/jails/postfix  usedbydataset         740M                      -
zroot/jails/postfix  usedbychildren        0B                        -
zroot/jails/postfix  usedbyrefreservation  0B                        -
zroot/jails/postfix  logbias               latency                   default
zroot/jails/postfix  objsetid              429                       -
zroot/jails/postfix  dedup                 off                       default
zroot/jails/postfix  mlslabel              none                      default
zroot/jails/postfix  sync                  standard                  default
zroot/jails/postfix  dnodesize             legacy                    default
zroot/jails/postfix  refcompressratio      2.54x                     -
zroot/jails/postfix  written               12.1M                     -
zroot/jails/postfix  logicalused           4.23G                     -
zroot/jails/postfix  logicalreferenced     1.74G                     -

Je größer die recordsize, desto besser kann die Kompression schöpfen. ;)
 
Gerade mit ZFS lohnt sich mdbox, da ein Snapshot für einen konsistenten Zustand der mdbox sorgt und somit auch das Backup kein Problem mehr darstellt. Bleiben die Vorteile von mdbox gegenüber maildir.
 
Glaube ich würde für 20GB nicht groß basteln, das ist bei größeren Installationen doch heutzutage nicht mal mehr nen halber user ;)
 
CommanderZed schrieb:
Glaube ich würde für 20GB nicht groß basteln, das ist bei größeren Installationen doch heutzutage nicht mal mehr nen halber user ;)
Zum Vergrößern anklicken....
Das stimmt natürlich. Beide Methoden würde ich als rock solid bezeichnen. Maildir kann man halt einfach so sichern, aber man hat halt die vielen Dateien. Wenn man ZFS benutzt und über einen Snapshot sichert, dann egalisiert sich der Vorteil. Hat man Benutzer wie meine Frau, die seit Jahren alle Dateien in ihrer Inbox belässt, dann macht sich schon ein massiver Geschwindigkeitsunterschied bemerkbar. In der Konfiguration muss man nur eine Zeile ändern und mit doveadm kann man jederzeit zwischen den verschiedenen Formaten wechseln. Also evtl. einfach mal ausprobieren.
 
Da es sich um ein Archiv handeln soll, weiß ich nicht ob das mit dem Backup überhaupt relevant ist (im Archiv ändert man ja eigentlich nichts mehr).

Aber: Auch bei Maildir sollte man einen Snapshot vor dem Backup machen - Es zerschießt zwar nicht das Backup, aber es können z.b. Mails doppelt im Backup vorkommen.

Für mdbox müsste soweit ich weiß der Mailserver gestoppt - dann ein Snapshot - Mailserver start gemacht werden. Soweit ich weiß ist der Index-Rewrite (z.b. beim verschieben) keine atomare Operation. Das hat mdbox für mich immer disqualifiziert. Vielleicht hat sich da aber auch mitlerweile was geändert.
 
medV2 schrieb:
Für mdbox müsste soweit ich weiß der Mailserver gestoppt - dann ein Snapshot - Mailserver start gemacht werden. Soweit ich weiß ist der Index-Rewrite (z.b. beim verschieben) keine atomare Operation. Das hat mdbox für mich immer disqualifiziert. Vielleicht hat sich da aber auch mitlerweile was geändert.
Zum Vergrößern anklicken....
Hast Du da zufällig eine Quelle. Ich meine gelesen zu haben, dass ein Snapshot reicht, um die Konsistenz sicher zu stellen. Aber natürlich finde ich die Stelle auch gerade nicht wieder.:grumble: Sollte der Index-Rewrite wirklich nicht atomar sein, so wäre das in der Tat auch für mich ein K.O. Kriterium.
 
jmt schrieb:
Hast Du da zufällig eine Quelle. Ich meine gelesen zu haben, dass ein Snapshot reicht, um die Konsistenz sicher zu stellen.
Zum Vergrößern anklicken....
Das Dateisystem kann nur die Konsistenz für das Dateisystem sicherstellen. Aber es weiß nichts über den Zustand des Programms, das auf es schreibt.
Wenn Du also den Snapshot inmitten einer Schreiboperation machst, dann ist der Zustand der Daten natürlich nicht konsistent.
 
Man kann allerdings bspw. die mailjail (egal ob mit oder ohne postfix) stoppen, snapshotten und wieder starten, damit die Konsistenz bestehen bleibt. Wenn das nicht gerade ne Kiste von vorgestern ist, sollte das keine 30 Sekunden benötigen.
Bei E-Mails ist das eher nicht schlimm, die sind ja eh zeitverzögert und das 'Problem' hätte man auch in länger, wenn man die jail updatet.
 
mr44er schrieb:
Man kann allerdings bspw. die mailjail (egal ob mit oder ohne postfix) stoppen, snapshotten und wieder starten, damit die Konsistenz bestehen bleibt.
Zum Vergrößern anklicken....
Ja genau. Das muss man dann aber auch tun. Genau darum rankte ja die Diskussion, ob das nötig ist oder nicht, wenn ich das richtig verstanden hab. Und ich würde sicherheitshalber das Programm immer temporär stoppen (oder anderwertig in einen "synchronen Zustand" versetzen).
 
jmt schrieb:
Hast Du da zufällig eine Quelle. Ich meine gelesen zu haben, dass ein Snapshot reicht, um die Konsistenz sicher zu stellen. Aber natürlich finde ich die Stelle auch gerade nicht wieder.:grumble: Sollte der Index-Rewrite wirklich nicht atomar sein, so wäre das in der Tat auch für mich ein K.O. Kriterium.
Zum Vergrößern anklicken....


Leider nicht, kann gut sein, dass ich das auch nur aus einem Forum/Reddit aufgeschnappt habe.

Prinzipiell ist es schon möglich, dass diese Writes atomar stattfinden - indem eben mit einem Log oder so gearbeitet wird. Aber hab weder zum einen noch zum anderen was gefunden.

Aber ist das für dich relevant? Ein Archiv stelle ich mir so vor, dass da nichts mehr geschrieben wird. Oder verstehe ich deinen Anwendungsfall falsch? Ich persönlich würde für 20GB auf jedenfall beim Standard (maildir) bleiben. Bei so wenig Daten ist weder die Geschwindigkeit noch die Speichereffizienz von Maildir ein Problem.

mr44er schrieb:
Man kann allerdings bspw. die mailjail (egal ob mit oder ohne postfix) stoppen, snapshotten und wieder starten, damit die Konsistenz bestehen bleibt. Wenn das nicht gerade ne Kiste von vorgestern ist, sollte das keine 30 Sekunden benötigen.
Bei E-Mails ist das eher nicht schlimm, die sind ja eh zeitverzögert und das 'Problem' hätte man auch in länger, wenn man die jail updatet.
Zum Vergrößern anklicken....

Ein Backup mache ich aber jeden Tag oder jede Woche, ein Restart aufgrund von Updates ist alle paar Monate nötig.
 
Ja, die Gedanke bzgl. der Größe habe ich mir auch gemacht und dovecot auf maildir umgestellt. Es handelt sich bei mir nicht um ein Archiv, sondern um den für zu Hause produktiv eingesetzten Mailserver. Der hat gerade mal 8GB Mails.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben