Alternative Logins für Mailboxen

ct_rprauchner

Hallo,

bin gerade beim Evaluieren von Mailcow.
Ziel ist es einen bestehenden Mailserver (Postfix, dovecot, amavis, roundcube) zu migrieren.
Am alten System werden für POP/IMAP Logins Benutzernamen ≠ E-Mail Adressen verwendet. (zB. Mailadresse: test@test.com; Benutzername: userxyz)

Jetzt meine Frage:
Ich möchte natürlich im neuen Setup den Benutzernamen=Mailadresse haben, das Login soll aber trotzdem noch mit dem alten Benutzernamen möglich sein, damit nicht jeder Client neu eingerichtet werden muss. (Es geht um ca. 2,5k Mailboxen und ca. 200 Domains)
Gibt’s eine Möglichkeit alternative Logins festzulegen?
Ist Mailcow überhaupt für meine Use-Case geeignet?

Vielen Dank.

Ganzjahresgriller

ct_rprauchner Also ich finde ja Mailcow klasse, für meinen Usecase, aber ob Du mit 2,5k Mailboxen und 200 Domains damit glücklich wirst, bzw. Deine User wage ich zu bezweifeln

esackbauer

In Mailcow MUSS man sich immer mit email-adresse als username anmelden.
Sobald 2FA oder SSO aktiviert ist muss man sich mit einem App Passwort bei den Clients anmelden (das man über die Mailcow GUI vergibt). Am WebGUI gehts halt nur mit email adresse und klassischem Login passwort.
Verwendet man ein SSO wie z.b. Authentik, dann gehts auch mit Usernamen, aber eben nur fürs WebGUI.
Clients verwenden IMMER die interne Authentifizierung von mailcow.

esackbauer

Warum nicht? Mit der API kann man ja vieles automatisieren.
Und seine User verwenden jetzt ja POP3 und IMAP schon, insofern ist mailcow komfortabler 😉

Ganzjahresgriller

Wie ich schon sagte es kommt immer auf den Usecase an. Bei meinem Arbeitgeber haben wir 8 k Mailboxen und auch etwa 200 Domains, alle User nutzen Outlook, die meisten iPhones mit ActiveSync und fast alle Features die M365 anbietet. Und auch wenn ich MS nicht mag, aber das ist größtenteils schon sehr elegant gemacht. Und nachdem das eine US Amerikanische Firma ist spielt Datenschutz keine Rolle. Da würde ich mit Mailcow erst gar nicht anfangen wollen.

ct_rprauchner

Danke für euer Feedback!
@esackbauer : Im Endausbau möchte ich natürlich alles über die API automatisieren. Was sind eure Erfahrungen bez. RAM und CPU? (ich habe auf jeden Fall Leistungsreserven)

Dann muss ich mich wohl irgendwie mit der Dovecot authentifizierung auseinandersetzen und hier ev. einen Workaround finden, damit ich nicht alle Kunden anweisen muss ihr Konto neu zu verbinden.

@Ganzjahresgriller Danke auf für deinen Input! Der Usecase in meinem Fall ist, dass ich das für einen ISP mache. Bei einem Internetpaket sind zB x POP/IMAP Postfächer dabei.
Webmail/UI Login ist eher unkritisch, da sie sich im aktuellen Webmail auch bereits mit der Mailadresse anmelden können.
Mir geht’s hauptsächlich um die unzähligen POP/IMAP Clients.

Wenn jemanden noch was einfällt bez. Dovecot Authentifizierung für meinen Migrations-use case bin ich natürlich dankbar, bis dahin werde ich mal ein bisschen Testen. 🙂

Ganzjahresgriller

Ok, dann könnte das ja sehr gut passen

ct_rprauchner

Prinzipiell gefällts mir ja sehr gut, die einzige Hürde ist noch die POP/IMAP/SMTP auth für Posfix und Dovecot.
Aber ich werde mich da mal eingraben sobald es die Zeit zu lässt.

Danke auf jeden Fall an alle!

ct_rprauchner

Update für alle:
Habs hinbekommen, dass POP/MAP/SMTP Login sowohl mit Maildresse als auch mit “altem” Usernamen funktionieren.

Lösung kurz umrissen:
-Zusätzliche Tabelle in der DB für das mapping der Usernamen inkl. eigener DB-User für lookups nur in dieser Tabelle.
-Konfigfile für Postfix angelegt für smtpd_sender_login_maps. (Modifikationen in der main.cf habe ich in der extra.cf gemacht)
-Dovecot passdb lookup (passwd-verify.lua) geändert mit db-lookup für usermapping
-user_query in dovecot-dict-sql-userdb.conf wird per hook angepasst (sollte somit update-fest sein)

Eine Frage hab ich noch bezüglich Update-Resistenz meiner Modifikationen:
-Kann es irgendwann passieren, dass durch ein Update die ganze DB weggeschmissen und neu aufgebaut wird? (und ich somit meine benutzerdefinierte tabelle und den extra user mit eingeschränkten rechten verliere?)
-wird die passwd-verify.lua bei Updates überschrieben? (sollte ich die besser auch über einen hook bearbeiten?)
-werden extra config files unter postfix/sql durch updates verworfen? (anpassungen für main.cf sind schon in der extra.cf)

wie gesagt hab ich die Lösung nur für POP/IMAP/SMTP benötigt. Das Sogo login soll eh nur mit der mailadresse funktionieren.

Vielen Dank bereits im Voraus für die Beantwortung meiner Fragen! 🙂

Sollte jemand genauer Infos benötigen gerne Fragen.

esackbauer

ct_rprauchner Kann es irgendwann passieren, dass durch ein Update die ganze DB weggeschmissen und neu aufgebaut wird?

Kann passieren z.b. bei einer Migration auf neue DB/Version. Am besten auf eine mailcow-externe DB auslagern.

ct_rprauchner wird die passwd-verify.lua bei Updates überschrieben?

Ja, bzw. möglich

ct_rprauchner werden extra config files unter postfix/sql durch updates verworfen?

Nein.

ct_rprauchner

esackbauer Danke für die schnelle Rückmeldung.
Werd mich noch um die DB und passwd-verify.lua kümmern um das etwas update-resistenter zu machen.

Ich möchte die “alten” user auch nicht ewig mitschleifen. Ich denke die werden über die Jahre eh aussterben, da jeder mal ein neues Handy/PC etc. braucht und das Konto neu einrichten muss.
Irgendwann werd ich die Modifikationen dann löschen und beim Standard bleiben, sofern alle Tests durchgelaufen sind und das System produktiv ist.

ct_rprauchner

Eigene DB für’s mapping ist erstellt und queries entsprechend angepasst.
custom passwd-verify.lua ist erstellt und passdb{} block in der extra.conf eingebunden.

Jetzt gehts in die Testing-Phase und API anbindung…

Danke an alle!