Beiträge von KB19

  • Das längste Thema

    Bei SQLite gehört die Datei (und der Ordner, da PFA sonst nicht läuft!) einfach postfix:postfixadmin, und in die neue Gruppe postfixadmin packe ich www-data sowie dovecot. Die Rechte kann man auf 0570 und 0460 setzen. Notfalls kann man mit ACLs arbeiten.


    Afaik greift Dovecot auf User/Pass DB nämlich mit den Rechten des übergeordneten Prozesses zu und nicht mit den Rechten des Postfachnutzers. Alles andere wäre auch fatal, weil die Zugangsdaten z.B. zu MySQL ansonsten ungeschützt wären.


    PFA und Roundcube laufen per Default, wenn über APT installiert, beide über www-data. Die FCGI-Konfiguration von PHP diesbezüglich zu ändern geht auch nicht, weil die Rechte der Systemordner sonst nicht mehr dazu passen.


    Ich teste das nachher mal kurz, ob das klappen würde.

  • Das längste Thema

    Das ist ein Henne-Ei-Problem. Der Clientsupport für SNI wird schon kommen, je mehr Dienste es unterstützen. Thunderbird und K9 können damit angeblich schon umgehen, getestet habe ich es allerdings noch nicht.

  • Das längste Thema

    Danke für Euer Feedback! :)

    Zitat von voja

    Du musst für virtuelle User auch keine Datenbank aufsetzen.

    Klar, aber welche Möglichkeit hat der User dann, sein eigenes Passwort zu ändern? Ohne den Admin zu nerven. Diesen Anspruch habe ich selbst bei einem Testsystem. Dafür müsste ich erst irgendein Script programmieren.


    Es wird wahrscheinlich auf ein klassisches Postfixadmin Setup hinauslaufen, allerdings mit einer SQLite Datenbank. Den Webserver und PHP brauche ich sowieso für Roundcube. Das sollte im Vergleich zu MySQL ähnlich sein und gleichzeitig genügend Komfort bieten. Ich muss halt die ganzen SQL-Dateien für Postfix und Dovecot eventuell anpassen. Meine Joins sind vermutlich nicht kompatibel mit SQLite… :D

    Zitat von voja

    warum dürfen sich Deine User per SSH auf den Server einloggen?

    Die Grundidee beim Testsystem war, dass jeder User einen normalen Account bekommt, seine Mails in ~/.maildir liegen und über SSH mindestens das Passwort ändern darf. Ob er mehr darüber ausführen darf, stand noch nicht 100% fest. Auf jeden Fall war es ein einfaches, schnell zu realisierendes Testsetup, mit dem ich gleich loslegen konnte. Bezüglich Mails verwerfe ich diese Idee jetzt wieder… :)


    Immerhin weiß ich jetzt, dass Postfix und Dovecot mit dem neuen Submissiond gut zusammenarbeiten und es sich lohnt, in das Vmail-Setup mit PFA zu investieren.

    Zitat von H6G

    KB19 LDAP ist dein Freund. OpenLDAP möchte dir helfen.

    Uff, das erhöht die Komplexität aber noch mehr, oder? =O

    Zitat von mainziman

    "absolut nichts falsch gemacht haben" und auf einer Blacklist landen widerspricht sich irgendwie etwas :/

    Mindestens eine der genannten Blacklists nimmt schnell ganze Subnetze auf. Die IP-Nachbarn haben nichts verbrochen und schauen erst einmal doof.


    Oder man bekommt einen neuen Server, dessen IP-Adresse wegen einer Sache von vor ~4 Jahren noch geblacklistet ist. Die Liste verweigert aber die Austragung, wenn man sich nicht kompliziert registriert oder gar Gebühren (!) im zwei-/dreistelligen Bereich zahlt.

  • Das längste Thema

    dovecot-submissiond hat einen Haken bei meinem Testsetup: Damit das funktioniert, muss ein lokaler Postfix-Port verfügbar sein, der den XCLIENT-Befehl erlaubt. Dieser Port muss deshalb selbstverständlich durch eine Firewall gefiltert werden, damit wirklich nur Dovecot darauf Zugriff hat. Das wäre mit dem Owner-Match eigentlich keine großartige Sache…


    Das Problem daran: dovecot-submissiond wird logischerweise mit den Rechten des Postfachnutzers ausgeführt. Bei einem typischen Virtual-Setup (wie auf meinen regulären Systemen), wo es nur eine einzige UID/GID für alle Mailboxen gibt und unter diesem User nichts anderes ausgeführt werden kann, würde das kein Problem sein. Das Testsystem basiert aber auf den normalen Useraccounts von Linux, ohne Datenbank und sonstigem Schnickschnack. F… X/


    Die Jackpotfrage: Wie löse ich das jetzt?

    • Den lokalen Usern die Rechte zum Login entziehen.
    • Umstellen auf rein virtuelle User mit einer Datenbank.
    • Irgendeine andere Möglichkeit, die ich übersehe.

    Vorschläge? ;(

  • Das längste Thema

    mainziman Bei Spamhaus und SORBS wäre ich halt vorsichtig. Deren Geschäftspraktiken sind alles andere als gut. Wenn man sich auf die als einziges Kriterium verlässt, sind Fehlalarme vorprogrammiert. Das wird legitime Absender, die absolut nichts falsch gemacht haben, sicher freuen…

  • Das längste Thema

    Zitat von killerbees19

    Ich teste so ein Setup derzeit, mal schauen, ob es sich lohnt.

  • Das längste Thema

    Alle paar Jahre muss man das eigene Setup mal infrage stellen und experimentieren. ;) Selbstverständlich auf einem neuen System. :)


    Wobei ich TLS 1.3 ja wieder entfernt habe, solange OpenSSL 1.1.1 nicht aus der Beta raus ist. Aber die Config ist vorbereitet und nur einen Daemon-Restart entfernt. ^^

  • Das längste Thema

    Zitat von H6G

    Dovecot hat nichts mit E-Mail senden zu tun. Dovecot ist für IMAP zuständig, damit du die Mails in deinem Client sehen kannst.

    btw: Dovecot hat mittlerweile einen Submission-Daemon. Der ist zwar nur ein halbwegs intelligenter Proxy (mit Zusatzfeatures wie BURL) für einen richtigen SMTP-Server, aber das könnte in Zukunft noch sehr interessant werden. Vor allem, weil man die Authentifizierung und den TLS-Kram für den MUA-Bereich nur mehr an einer einzigen Stelle konfigurieren muss. Postfix braucht die Userauthentifizierung somit gar nicht mehr und kann bei TLS etwas weniger streng konfiguriert werden, damit die ungepflegten Mailserver da draußen kein Problem haben.


    Ich teste so ein Setup derzeit, mal schauen, ob es sich lohnt. Praktisch wäre es auf jeden Fall, da es für eine deutlich klarere Struktur sorgt! :)

  • MySQL/MariaDB - Shared Hosting - Datenbankgröße begrenzen (Quota)

    Alternative Idee: Eigene MariaDB-Instanz je Kunde? (mit eigenem Useraccount unter Linux und z.B. Journal-Quota)


    Dank Systemd ist das mittlerweile deutlich einfacher realisierbar. Die meisten Control Panel für Kunden kommen damit aber nur schwer bis gar nicht klar. Aber prinzipiell wäre das eventuell mein Weg, wie ich es machen würde, wenn ich es hart begrenzen wollen würde. Die von Hecke29 erwähnten Probleme mit Hardlimits existieren bei so einem Setup natürlich trotzdem. Aber das könnte man durch rechtzeitige Warnungen mittels Softlimit halbwegs kompensieren. Wobei sich dann die Frage stellt, warum man das Hardlimit so kompliziert macht und nicht gleich "nur" den Zugang sperrt… ?


    Eine eigene Instanz pro Kunde hätte auch den Vorteil, dass man auf beliebige Kundenwünsche bei der Datenbankserverkonfiguration eingehen könnte. Es erhöht halt den Verwaltungs und Administrationsaufwand.

  • Das längste Thema

    Zitat von mainziman

    die Mail soll ja wenn einer dieser Listen anschlägt rejecten

    Und genau das ist das Problem. Ein einziges False-Positive und sie wird rejected. Deshalb verwendet man normalerweise mehrere RBLs mit unterschiedlicher Gewichtung. Eine RBL alleine (die man nicht ausschließlich selbst füttert) darf niemals als einziger Ablehnungsgrund herhalten!


    Postscreen wäre übrigens auch eine Möglichkeit, wenn man es ohne externe Dienste stemmen will. Dort kann man RBLs direkt konfigurieren.

  • Das längste Thema

    Das 100% A+ Rating schafft man derzeit übrigens so… (Debian Buster; TLSv1.3 ist nur als Vorbereitung drinnen)

    Code
    ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384";
ssl_dhparam /etc/nginx/dhparam-4096.pem;
ssl_ecdh_curve secp384r1;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_session_timeout 1d;

    Die Cipherliste ist von Mozilla, wobei alle 128 Bit Cipher entfernt wurden.

    Nicht vergessen, die DH-Datei mit 4096 Bit zu generieren!


    Jetzt fehlt nur noch eine Bestnote bei securityheaders.com :D

  • Eigene Nameserver + email

    Zitat von AD1

    Auf dem Vserver liegen aber mehrere Webspaces für mehrere Domains, alles unter einer IP, findet er denn die richtige Domain?

    Das hat mit DNS wenig zu tun und würde sich bei einem eigenen Nameserver nicht anders verhalten.


    Dafür gibt es bei HTTP den Host-Header und bei HTTPS auch noch SNI. Der Webserver gibt dann anhand der vHost-Konfiguration die richtige Seite aus.


    Darf man fragen, ob das ein unmanaged (v)Server ist? Administrierst Du den selbst?

  • Eigene Nameserver + email

    Solange der MX-Record auf den Webspace zeigt, sollte das klappen. Nicht vergessen, dass der TXT-Record (SPF) dazu passt, falls über den anderen Server ebenfalls Mails verschickt werden sollen!


    Aber wieso gleich eigene Nameserver? Reicht es nicht, wenn Du die A/AAAA-Records auf den (v)Server zeigen lässt?