Apr 2024
1 / 24
Apr 2024
May 2024
itwo
Apr '24

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.

Absenderkonto Mails 2024-04-16_14-45
Absenderkonto Mails 2024-04-16_14-45.png757x337 46.1 KB

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?

  • created

    Apr '24

  • last reply

    May '24
  • 23

    replies

  • 1.1k

    views

  • 3

    users

  • 2

    likes

  • 9

    links

  • 6
    4
itwo
Apr '24

Welche Einstellungen genau, Postausgangserver?

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

itwo
Apr '24

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

itwo
Apr '24

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

RalfBeckerEGroupware GmbH
Apr '24

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
Apr '24

So zu sagen ein patch force :smile:

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

itwo
Apr '24
StefanU

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).

RalfBeckerEGroupware GmbH
Apr '24

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
Apr '24

“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
Apr '24

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
Apr '24

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.

RalfBeckerEGroupware GmbH
Apr '24

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
Apr '24

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.