Kalendereinladung über default SMTP anstatt Benutzer SMTP

itwo 2024-04-16 12:54:08 UTC #1

EGw 23.1.20240304

Wenn wir eine Kalendereinladung per EMail erhalten und ich stimme zu geht die Mail als Absender “Default SMTP”* raus anstatt dem SMTP Konto des Anwenders.

Ich habe jetzt schon alle möglichen Einstellungen durch geschaut, kann aber nichts finden.
Der SMTP Server der Benutzer funktioniert ausgezeichnet, er kann “normale” Mails versenden (im Postfix Log kontrolliert).

Irgend jemand eine Idee wo das verstellt sein könnte?

SMTP-only Mail-Konto für Benachrichtigungen

StefanU 2024-04-16 13:54:25 UTC #2

Hi Samuel.

Zeig bitte noch deine Einstellungen des Mail-Kontos.

Stefan

itwo 2024-04-16 16:03:24 UTC #3

Welche Einstellungen genau, Postausgangserver?

Edit:
Könnte es ein Problem sein das mein SMTP Benutzer != meiner EMailadresse ist?

RalfBecker 2024-04-17 13:18:53 UTC #4

Versuch mal den folgenden Patch:

Ralf

itwo 2024-04-17 16:58:54 UTC #5

Er möchte den Patch auf der aktuellen 23.1.2040304 nicht anwenden:

root@egw:~# curl https://github.com/EGroupware/egroupware/commit/54e5365e0b94bae00d22111c39c7113c65f0c661.patch | docker exec -i egroupware patch -p1 -d /usr/share/egroupware-sources
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2720 100 2720 0 0 9329 0 --:–:-- --:–:-- --:–:-- 9347
patching file notifications/inc/class.notifications_email.inc.php
Hunk #2 FAILED at 78.
1 out of 3 hunks FAILED – saving rejects to file notifications/inc/class.notifications_email.inc.php.rej

RalfBecker 2024-04-17 17:13:01 UTC #6

Da fehlt noch der “fix some PHP Warnings” commit, musst Du zuerst anwenden:

Ralf

itwo 2024-04-17 17:33:12 UTC #7

Irgendwie steckt da etwas der Wurm drin, ist der diff zu groß?

root@egw:~# curl https://github.com/EGroupware/egroupware/commit/018083dc0e8a68e53fcc0aa5b8fea7f79cad5296.patch | docker exec -i egroupware patch -p1 -d /usr/share/egroupware-sources
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2480 100 2480 0 0 9937 0 --:–:-- --:–:-- --:–:-- 9959
patching file api/src/Storage/Tracking.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 out of 2 hunks ignored – saving rejects to file api/src/Storage/Tracking.php.rej
patching file notifications/inc/class.notifications_email.inc.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored – saving rejects to file notifications/inc/class.notifications_email.inc.php.rej
patching file notifications/inc/class.notifications_popup.inc.php
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
1 out of 1 hunk ignored – saving rejects to file notifications/inc/class.notifications_popup.inc.php.rej

RalfBecker 2024-04-17 18:15:32 UTC #8

Vermutlich ist es einfacher das ganze notifications/inc/class.notifications_email.inc.php File in den Container zu kopieren, statt zu patchen:

curl https://raw.githubusercontent.com/EGroupware/egroupware/23.1/notifications/inc/class.notifications_email.inc.php > /tmp/class.notifications_email.inc.php
docker cp /tmp/class.notifications.inc.php egroupware:/usr/share/egroupware/notifications/inc/
docker exec egroupware kill -s usr2 1

Nach restart des Containers oder Reboot der Kiste, ist das wie der Patch wieder draußen, damit es restart-fest wird musst Du bei dem docker cp /usr/share/egroupware mit /usr/share/egroupware-sources ersetzen.

Ralf

itwo 2024-04-17 18:31:18 UTC #9

So zu sagen ein patch force

@StefanU kannst Du mir nochmal eine Einladung zum testen schicken?

StefanU 2024-04-17 18:34:12 UTC #10

Done.
Stefan

itwo 2024-04-17 19:09:39 UTC #11

Ist nichts angekommen.

StefanU 2024-04-17 19:22:14 UTC #12

Arghhh…
Hatte extern nicht benachrichtigt.

StefanU 2024-04-17 19:24:13 UTC #13

itwo 2024-04-17 19:27:00 UTC #14

Ja ich sehe schon, das war nicht die Lösung.
Auch ein Neustart vom Container hat nichts geändert (ja ich hatte egroupware-source auch gepatched).

RalfBecker 2024-04-17 20:37:56 UTC #15

Noch mal ganz auf Anfang: Du hast doch in der App Config das “noreply@…” SMPT Konto für Benachrichtigungen ausgewählt.

Du solltest das auf “automatisch” lassen.

Falls Du “automatisch” nicht auswählen kannst, führe mal das folgende SQL aus:

DELETE FROM egw_config WHERE config_name='async_identity' and config_app='notifications'

Danach musst Du den Cache löschen, und die App Konfiguration der Benachrichtigungen nicht mehr speichern. Da ist ein Typo in dem XML File, das dafür sorgt, dass “automatisch” nicht auswählbar ist:

Ralf

itwo 2024-04-18 08:28:27 UTC #16

“automatisch” konnte ich nicht auswählen, hab daher den Key in der DB gelöscht und den Cache geleert:

MariaDB [egroupware]> SELECT * FROM egw_config WHERE config_name='async_identity' and config_app='notifications';
Empty set (0.000 sec)

In der WebGUI steht noch das noreply@ Konto, deshalb nicht mehr speichern vermute ich.

Ursprünglich ist es so zu dem noreply@ Konto gekommen:

itwo 2024-04-19 08:10:42 UTC #17

Genau das war das Problem, vielen Dank @RalfBecker.
Das ganze Problem ist damals mit dem “‘1’ist NICHT erlaubt (‘)!” entstanden.

Danke @StefanU für die vielen Testeinladungen!

itwo 2024-04-19 09:27:47 UTC #18

Leider entsteht daraus ein neues Problem, EGw bringt eine rote Meldung sobald ein Alarm für den Kalendereintrag verschickt werden soll:

Fehler beim Benachrichtigen von user user@example.com
Alarm for TESTTERMIN at 19.04.2024, 11:20 in
notifications_popup failed: , notifications_email failed: Server is not accepting SMTP connections.

In der Mailserver Log sieht man das EGw nicht meinen SMTP Benutzer verwendet, sondern die EMail einfach so beim Mailserver abliefern möchte -> Client host rejected: Access denied

@RalfBecker könnte das mit dem Patch zusammen hängen?
Ist das ggf. ein Bug der daraus entsteht?

Edit: User und EMailadresse stimmen und wurden hier nur maskiert.

RalfBecker 2024-04-19 13:12:08 UTC #19

Kannst Du doch einfach mal ausprobieren:

cd /etc/egroupware-docker
docker-compose up -d --force-recreate

Danach sind alle Patches weg, aber die in der DB gelöschte Zeile sorgt immer noch dafür, das due “automatisch” verwendest.

Ralf

itwo 2024-04-19 13:35:54 UTC #20

Ich würde das gerne probieren, damit verliere ich auch einige Patches mit den PDFs Body only Mails und so langsam habe ich den Überblick verloren wann ich was gepatched habe.

Vielleicht ist es besser wenn ich als erstes das nächste Release abwarte und dann das ganze Thema noch einmal untersuche.