Hosting Provider und Webmail Roundcube vs. Horde (Synchron SMTP)

[david191186]

Vorab, das wird ein etwas längerer Beitrag.
Ich erstelle gerade meinen eigenen Webmail Client mit PHP/Laravel. Dieser dient in erster Linie für mein eigenes Portfolio, und wird eventuell Opensource.
Auch wenn Roundcube absolut top ist, ich erstelle diesen Client weil ich mich dafür interessiere.
Mit Roundcube kenne ich mich gut aus, mit Horde fast gar nicht.
Ich weiß das in diesem Forum viele Mitarbeiter von Hostern arbeiten, und deren Mailserver pflegen. Deshalb ist dieses Forum der beste Platz für meine Fragen.

1. Wieso setzen die meisten deutschen Hoster auf Horde, und nicht Roundcube?
Ich kann diese Liste nicht bestätigen, aber es sieht so aus wie Horde:
- allink.
- hetzner
- web.de
- gmx.de

Diese Hoster sind natürlich nicht gerade klein.
Der Webmailer von T-online sieht aus wie Roundcube, kann das aber nicht bestätigen.

2. Wird Horde bevorzugt wegen der Kalendar Funktion? Oder sind es andere Dinge?

3. Email versenden synchron oder asynchron

Roundcube versendet standartmäßig emails synchron. Also kein Redis, oder sonstiger Queue Driver.
Horde vermutlich auch.
Roundcube speichert das Imap und Smtp Passwort in der User Session im Klartext, was auch Sinn macht, da der Imap und Smtp Server das Passwort benötigt.

Versenden die Hoster ihre Emails normal synchron oder verwenden sie Redis dafür?
Wenn ja, wie senden die Hoster das Passwort an den Queue? Das Passwort müsste dann im Klartext an den Payload übergeben werden, was fraglich ist. Natürlich könnte man den Payload verschlüsseln, ist aber nicht sehr effizent.
Oder nutzen die Hoster eventuell OAuth dafür und passen Roundcube und Horde an?

In Laravel sind Queues absolut einfach zu nutzen, aber das mit dem Passwort ist ein Problem. Sollten die Hoster ihre Webmailer ganz normal synchron nutzen, dann wäre natürlich alles einfach. Ich freue mich auf eure Antworten.

 

[danton]

Warum soll ein Webmailer noch mal eine Queue verwendet? Die Mails werden direkt per SMTP an den Ausgange-Mail-Server übergeben und der übernimmt dann die Aufgabe einer Queue beim Senden an den Ziel-Mailserver. Bei einem Mail-Programm wie Thunderbird macht eine Queue Sinn, denn da kann es auch mal sein, dass man Mails offline beantwortet - ein Webmailer ist ja always on und kann den SMTP-Server jederzeit erreichen. Da ist eine Queue nur unnötige Komplexität.
Außerdem speichert Roundcube das Passwort in der Session sehr wohl verschlüsselt in den Session-Daten in der Datenbank - der Schlüssel dafür steht in der Konfig-Datei von Roundcube im Dateisystem.

 

[david191186]

Erstmal Danke für deine Antwort.

Warum soll ein Webmailer noch mal eine Queue verwendet?

Nunja, wenn 1000 User auf dem Webserver wo Roundcube läuft, auf senden klicken, könnte das schon starke auswirkungen haben. Wenn ein Queue verwendet wird, klickt der User auf senden und die Mail landet im Queue. Wenn ein extra Queue Server exisitiert, dann wird die ganze Smtp Sache an den Queue Server abgegeben. Wenn es aber wirklich so ist, das die Hoster den Webmailer synchron verwenden, dann umso einfacher

Außerdem speichert Roundcube das Passwort in der Session sehr wohl verschlüsselt in den Session-Daten in der Datenbank - der Schlüssel dafür steht in der Konfig-Datei von Roundcube im Dateisystem.

Ja ich hatte mich falsch ausgedrückt sorry. Ich meinte für den end User ist der Payload der Session im Klartext.

 

[danton]

Nunja, wenn 1000 User auf dem Webserver wo Roundcube läuft, auf senden klicken, könnte das schon starke auswirkungen haben.

Die User werden per Webmailer vermutlich mehr Mails lesen als senden und beim Lesen kannst du nicht mal eben das Abrufen in eine Queue stellen und dann kann der User ein paar MInuten später die Mail sehen, die er lesen möchte. Der Mail-Versand wird hier nicht das große Last-Thema sein.

Wenn ein Queue verwendet wird, klickt der User auf senden und die Mail landet im Queue. Wenn ein extra Queue Server exisitiert, dann wird die ganze Smtp Sache an den Queue Server abgegeben.

Ein separater Queue-Server ist IMHO noch sinnloser. Wenn ich sie an einen Queue-Server übertrage, kann sie sie auch direkt beim SMTP-Server abkippen - der sie dann in seiner Queue abarbeitet.

 

[david191186]

Die User werden per Webmailer vermutlich mehr Mails lesen als senden.

Das stimmt.

Die User werden per Webmailer vermutlich mehr Mails lesen als senden und beim Lesen kannst du nicht mal eben das Abrufen in eine Queue stellen

Genau, es macht keinen Sinn eine Imap Verbindung in den Queue zu stellen.

Ein separater Queue-Server ist IMHO noch sinnloser. Wenn ich sie an einen Queue-Server übertrage, kann sie sie auch direkt beim SMTP-Server abkippen - der sie dann in seiner Queue abarbeitet.

Ja, das sind aber zwei unterschiedliche Dinge. Egal ob ich eine SMTP Anfrage in den Queue stelle oder nicht, es wird für jede Email eine SMTP Verbindung geöffnet. Wenn 100 Mails im Queue sind, dann wird 100x eine Verbindung geöffnet und wieder geschlossen. Natürlich hat der SMTP, hinter dem Webmailer einen eigenen Queue, welcher aber nicht relevant ist. In der Laravel Communtiy werden so gut wie alle Email Dinge in die Queue verschoben, weil es egal ob die Email jetzt gesendet wird, oder in 2 Minuten.

Das beste Beispiel in eine Register Page mit Email Verfication. Wenn sich pro Minute 50 neue User registrieren, dann werden die Emails über dem Queue nach und nach an den User gesendet.

Aber eventuell hast du recht, und ich mache mir darüber zu viele Gedanken..

 

[danton]

In der Laravel Communtiy werden so gut wie alle Email Dinge in die Queue verschoben, weil es egal ob die Email jetzt gesendet wird, oder in 2 Minuten.

Das hört sich für mich danach an, als wenn die Funktion genutzt wird, weil sie da ist. Welchen Benefit bringt dir eine Queue zum Mail-Versand, die in Lavarel geschrieben ist? Die Last auf dem Host verringerst du nicht, sie wird durch die zusätzliche Aufgabe der Queue-Verwaltung eher noch erhöht.

 

[david191186]

Das hört sich für mich danach an, als wenn die Funktion genutzt wird, weil sie da ist. Welchen Benefit bringt dir eine Queue zum Mail-Versand, die in Lavarel geschrieben ist?

Nun ja, das hat nichts mit Laravel zu tun. Egal welche PHP Webseiten du dir anschaust. Wenn du dich dort registrieren musst, dann werden die verfications Emails über einen Queue versendet. Und das machen so gut wie alle Anbieter. Sollte nämlich da was schief gehen, bekommt der User es nicht mit, und das System kann über Failed Jobs die Email erneut senden.

Die Last auf dem Host verringerst du nicht, sie wird durch die zusätzliche Aufgabe der Queue-Verwaltung eher noch erhöht.

Genau die Last wird erhöht, aber es kommt drauf an welche Art von Queue du benutzt. Wenn du Database Queues nutzt, dann eher nicht. Wenn du Redis nutzt, dann wird RAM Last enorm erhöht.

Aber wie auch immer, ein Webmailer hat ein völlig anderen Usercase, als eine Registerpage. Also du glaubst, die Hoster von Webclients schicken ihre Emails von dem Mailclient nicht in die Queue?

 

[greystone]

Ich sehe das nicht als Problem an, bei einem Webmailer keine Queue zu haben. Wenn der Versand fehlschlägt, dann bleibt die Mail im Entwurfsmodus offen und der Nutzer bekommt eine direkte Rückmeldung.

Für den Fall, dass der Mailserver einen Fehler hat und die Mail nicht gesendet werden kann, würde die Queue einen Mehrwert bieten. Aber ehrlich gesagt kann ich mich an keinen Fall erinnern, in dem ein Webmailer eine Mail nicht an den Mailserver ausliefern konnte, es sei denn, es lag eine Fehlkonfiguration vor.

Darüber hinaus ist eine Queue möglicherweise eine zusätzliche Anforderung an einen zusätzlichen Dienst, der die Software unattraktiv macht. Also z. B. im Fall von Redis. Eine DB-Queue heisst dann, dass dies wohl nicht erforderlich wäre, da eine DB (mariadb, mysql, postgres, sqlite, ...) ja ohnehin immer benötigt wird?

Insgesamt erscheint es mir so, dass hier kein Nutzen besteht, der den zusätzlichen Aufwand rechtfertigt.

----

Mir fällt gerade ein Feature ein, dass möglicherweise durch eine Queue möglich würde: Man kann E-Mails zeitverzögert versenden. Dazu bräuchte man allerdings doch wieder eine Zeitsteurungskomponente, die dass dann auch tut. Entweder ein eigener zusätzlicher Dienst oder ein cron-Script, was dann regelmässig aufgerufen wird. Nextcloud macht das z. B. mit einem cron-script. Einen zusätzlichen Dienste würde ich aus Resourcengründen eher vermeiden wollen.

Edit:

Auch cron würde ich als Kernabhängigkeit vermeiden wollen, um die Kernabhängigkeiten so gering wie möglich zu halten. Als Zusatzabhängigkeit für Extra-Features wäre das eher akzeptabel.

 

[david191186]

Für den Fall, dass der Mailserver einen Fehler hat und die Mail nicht gesendet werden kann, würde die Queue einen Mehrwert bieten.

Ja, das auf jeden Fall.

Darüber hinaus ist eine Queue möglicherweise eine zusätzliche Anforderung an einen zusätzlichen Dienst, der die Software unattraktiv macht. Also z. B. im Fall von Redis.

Naja wenn du dir die Queue Server von AWS anschaust, da kannst pro Tag Millionen Queue Jobs draufhauen. Redis ist da schon die beste Wahl, was Queues betrifft.

Eine DB-Queue heisst dann, dass dies wohl nicht erforderlich wäre, da eine DB (mariadb, mysql, postgres, sqlite, ...) ja ohnehin immer benötigt wird?

Ganz genau, wenn du Database Queues benutzt, dann hast du in der Datenbank eine Jobs Table.

id|queue|payload|attempts|reserved_at|available_at|created_at

Dazu noch eine Tabelle für Failed Jobs. Database Queues sind sehr beliebt, und können ohne Probleme in Production laufen. Wenn es aber zu viele sind, sollte man eher auf Redis setzen. Caches und Queues sind in Database = Top. Caches und Queues in Redis = Weltklasse, aber mehr Leistung.

Für beide Varianten wird ein Cronjob oder Daemons/Supervisor benötigt, der den Queue startet.

Insgesamt erscheint es mir so, dass hier kein Nutzen besteht, der den zusätzlichen Aufwand rechtfertigt.

Genau das, wollte ich mit diesen Beitrag mit euch heraus finden

 

[danton]

Für den Fall, dass der Mailserver einen Fehler hat und die Mail nicht gesendet werden kann, würde die Queue einen Mehrwert bieten.

Jein ;-) Wenn wir beim Webmailer bleiben, dann sehe ich hier eher das Problem, dass der Versender dann ja keine direkte Rückmeldung mehr bekommt, wenn der Mailserver einen Fehler hat und somit erstmal davon ausgeht, dass seine Mail ja rausgegangen ist.
Ab einer gewissen Größe wird man diesem Thema wohl auch eher mit bewährten Techniken wie redundanten SMTP-Servern mit Load-Balancer entgegenwirken (und für den Webserver mit dem Webmailer und IMAP gilt das dann natürlich auch).
Für eine Queue muss ich ja außerdem sicherstellen, dass diese abgearbeitet wird. Entweder ein zusätzlicher Queue-Manager, der dauerhaft als Programm läuft oder ein regelmäßiger Aufruf z.B. über einen Cron-Job. Ich weiß, dass solche Sachen auch in normale Webrequests mit einebaut werden - das verlängert aber diese Webrequest unnötig oder bei selten frequentierten Dienste evlt. in zu großen Abständen.
Bei einer Anwendung zum Newsletter-Versand sehe ich hingegen die Benefits eine Queue - hier werden auf einen Schlag hunderte oder tausende von Mails losgetreten. Da kann ich mit der Queue natürlich so Dingen wie Versand zu einem späteren Zeitpunkt oder gestreckter Versand über mehrere Stunden realisieren. Aber auch da muss ich irgendwas haben, was die Queue möglichst unabhängig vom Webserver abarbeitet.
Oder allgemein ausgedrückt: Abhängig vom Einsatzzweck gibt es unterschiedliche größere und kleiner Vor- wie Nachteile, die man sorgfältig gegeneinander abwägen sollte.

 

[david191186]

Bei einer Anwendung zum Newsletter-Versand sehe ich hingegen die Benefits eine Queue - hier werden auf einen Schlag hunderte oder tausende von Mails losgetreten.

Das Gleiche hatte ich vorhin auch im Kopf. Ihr habt mich überzeugt. Ich lasse das mit dem Queue. Besten Dank erstmal.

Habt ihr noch eine Meinung zu meiner anderen Frage?

1. Wieso setzen die meisten deutschen Hoster auf Horde, und nicht Roundcube?
Ich kann diese Liste nicht bestätigen, aber es sieht so aus wie Horde:
- allink.
- hetzner
- web.de
- gmx.de

Diese Hoster sind natürlich nicht gerade klein.
Der Webmailer von T-online sieht aus wie Roundcube, kann das aber nicht bestätigen.

 

[danton]

Erstmal ist die Frage, ob die Hoster wirklich Horde nutzen oder sich nicht einfach nur beim Design daran orientiert haben. Ansonsten ist Horde ein Framework, dass viele Funktionen bereitstellt, die man für eine Groupware braucht, selbst wenn man ein eigenes Frontend verwendet. Zudem ist Horde mit pear sehr einfach auf einem aktuellen Stand zu halten, was aber eher ein Benefit für kleinere Installationen sein dürfte. Ansonsten gibt es Horde schon viele Jahre und die Installationen bei den Providern sind dann auch gerne mal historisch gewachsen. Da ist dann ein Wechsel auf eine andere Plattform nicht mal eben gemacht, besonders wenn man noch eigene Anpassungen vorgenommen hat.
Ich habe vor gut einem Jahr von Horde auf Roundcube gewechselt, weil es zu dem Zeitpunkt danach aussah, als wenn Horde ziemlich brach liegt (PHP8 war da bei Horde ein Problem) - mittlerweile scheint sich bei dem Projekt wieder was zu tun. Aus User-Sicht gefällt mir Roundcube sogar besser als Horde, aber aus Adminsicht kämpfe ich immer ein wenig mit Updates - das war bei Horde echt geschmeidig.

 

[david191186]

Da ist dann ein Wechsel auf eine andere Plattform nicht mal eben gemacht, besonders wenn man noch eigene Anpassungen vorgenommen hat.

Ja das ist immer ein großer Punkt, das denke ich auch.

Ich habe vor gut einem Jahr von Horde auf Roundcube gewechselt, weil es zu dem Zeitpunkt danach aussah,

Roundcube ist einfach mega. Ich nutze es auch schon viele Jahre. Also die Weboberfläche von Horde gefällt mir absolut nicht, dieser Kalendar ist nicht nutzbar in meinen Augen.

Aus User-Sicht gefällt mir Roundcube sogar besser als Horde, aber aus Adminsicht kämpfe ich immer ein wenig mit Updates - das war bei Horde echt geschmeidig.

GIT? Ich habe mir immer die letze Version runtergeladen und dann einen Branch erstellt. Z.b. 1.6.1. Wenn dann ein Update raus kam habe ich 1.6.2 runter geladen, und wieder einen neuen Branch erstellt mit dem Namen 1.6.2. Wenn danach was schief geht, einfach Branch wechseln

 

[Sonyo]

1. Wieso setzen die meisten deutschen Hoster auf Horde, und nicht Roundcube?
Ich kann diese Liste nicht bestätigen, aber es sieht so aus wie Horde:
- allink.
- hetzner
- web.de
- gmx.de

Also ich sollte mich schon arg irren aber web.de und gmx nutzen was eigen entwickeltes. wie das bei allink aussieht weiss ich nicht, da ist zwar ne gewisse Grundähnlichkeit aber es ist halt ein webmailclient.

Generell sieht man Horde Installationen außerhalb von Unis relativ selten. Und ich finde das auch ziemlich gruslig (subjektives empfinden)

Wenn du da wirklich was auf Laravel Basis entwickelst bin ich durchaus interessiert. Das Angebot ist ja immer kleiner geworden in den letzten Jahren. Nachdem auch noch b1gmail weggefallen ist wird es echt dünn.

Email versenden synchron oder asynchron

Definitiv asynchron, Laravel hat da ja schon mi Bordmitteln schöne Möglichkeiten. Insbesondere die Möglichkeit das dann über verschiedene Worker zu senden um Last und eventuelles BlacklistRisiko zu verteilen macht viel Sinn.

Das Passwort müsste dann im Klartext an den Payload übergeben werden, was fraglich ist. .....
....In Laravel sind Queues absolut einfach zu nutzen, aber das mit dem Passwort ist ein Problem.

Inwiefern ist das ein Problem? oder dachtest du daran das wirklich jedesmal per SMTP Verbindung über die jeweiligen Postfächer rauszuschicken? Ich würde das eher mit php Bordmitteln schicken.



Generell ein spannendes Thema, auch weil ich mit den vorhanden Lösungen nicht restlos glücklich bin (Roundcube ist aber definitiv das beste derzeit)

 

[david191186]

Also ich sollte mich schon arg irren aber web.de und gmx nutzen was eigen entwickeltes. wie das bei allink aussieht weiss ich nicht, da ist zwar ne gewisse Grundähnlichkeit aber es ist halt ein webmailclient.

Also bei Allinkl und Hetzner, erkennt man es an der Kalendar funktion. Aber ich kann auch nur vermuten und nicht bestätigen, das es Horde ist.

Das Angebot ist ja immer kleiner geworden in den letzten Jahren. Nachdem auch noch b1gmail weggefallen ist wird es echt dünn.

Jap, das liegt unter anderem daran, das PHP IMAP nicht gerade einfach ist. Das einzelne raus lutschen der Parts ist relativ kompliziert, wenn man das noch nie gemacht hat. Wirklich gute Packages dafür gibt es auch nicht, deshalb hatte ich das schon vor vielen Jahren selbst geschrieben.

Definitiv asynchron, Laravel hat da ja schon mi Bordmitteln schöne Möglichkeiten. Insbesondere die Möglichkeit das dann über verschiedene Worker zu senden um Last und eventuelles BlacklistRisiko zu verteilen macht viel Sinn.

Nunja, die Argumente von den anderen Stimmen schon, ein Queue wäre eigentlich wirklich nicht nötig. Was meinst du BlacklistRisiko?

Inwiefern ist das ein Problem? oder dachtest du daran das wirklich jedesmal per SMTP Verbindung über die jeweiligen Postfächer rauszuschicken? Ich würde das eher mit php Bordmitteln schicken.

Wenn du die Email über einen Queue senden möchtest, dann kannst du keine User Session benutzen, weil der Queue keine Session benutzen kann. Stattdessen muss das Password über den App_Key verschlüsselt werden, und legt dieses in der Datenbank ab. Auf diese Weise kann der Queue auf das Password zugreifen und entschlüsseln.

Wenn du keinen Queue benutzt, wird das Passwort im Klartext in der Session gespeichert, aber auch verschlüsselt. Also der Payload. Dafür setzt man in der .env "SESSION_ENCRYPTION auf true". Für beide Varianten wird der APP_KEY genutzt um zu verschlüsseln.

Aber prinzipiell ist beides inordnung.

Generell ein spannendes Thema, auch weil ich mit den vorhanden Lösungen nicht restlos glücklich bin (Roundcube ist aber definitiv das beste derzeit)

Ohja, Roundcube ist echt mega gut. Ich finde Roundcube kann zuviel, es sind zu viele Einstellungen.

Ich habe auch vor ein paar Tagen einen neuen Thread aufgemacht, wegen den Ideen sammeln. Schau da mal rein.