Guten Morgen,
“A mail operation failed in the background: IMAP error reported by server.” seit Versionswechsel beim löschen von Mails, Mails bleiben erhalten. Löschen von Mails mit Tb/Ev funktioniert weiterhin
Das “für alle” definierte Mailkonto ist vom Typ “Dovecot” und im Hintergrund läuft auch ein Dovecot.
Logs geben erstmal noch nichts her.
Hmm, das allg. das Löschen von Mail nicht mehr geht, habe ich bisher nicht gehört.
Was genau machst Du, um wie viele Mails gehts es, und in welchem Folder?
Generell kannst Du schauen ob es auf der JavaScript Konsole im Browser Fehler gibt, oder im EGroupware PHP error-log /etc/egroupware-docker/egroupware-logs.sh während Du versuchst eine Mail zu löschen.
Der Netzwerktab des Browsers protokolliert auch die Zugriffe auf den EGroupware Server.
Ralf
Sind Mails aus Inbox oder Unterordner, einzeln oder mehrere.
Im Browser kein Javascript Fehler. Websocket beinhaltet nur die o.g. Meldung
mit der .sh kann ich leider nicht dienen, nutze nur den stack.
Dovecot ist -noch- ein 2.3.19, muss gerade schauen, wie ich dessen logging hochschraube um zu schauen, was da ankommt
Hi bzubi.
Kannst du das bitte weiter erklären? Wie sieht deine EGroupware-Umgebung aus?
Stefan
After upgrading to EGroupware 26.9.20260928, we are experiencing an error when sending emails through an external Aruba SMTP server.
Even after disabling certificate validation, we still receive the following error in the EGroupware container logs:
Horde_Imap_Client_Exception_ServerResponse: You do not have adequate permissions to carry out this operation. (17): Permission denied
The EGroupware web interface also reports the following error:
You do not have adequate permissions to carry out this operation.
We have verified that the permissions are correct. It seems that there may be an issue with the mapping of the mail server folders, which cannot be modified from EGroupware.
There were no such problems in the previous version of EGroupware.
We have also performed the following tests:
Sending emails through the provider's webmail works correctly.
Sending emails using mail clients such as Thunderbird and Outlook works correctly.
The problem only occurs when sending emails through EGroupware.
We are also experiencing the same error with Timeshift, which I have attached for reference.
Could you please investigate whether this might be related to a change in the mail folder mapping or IMAP/SMTP handling introduced in version 26.9.20260928?
If the issue cannot be resolved, could you please provide instructions on how to roll back EGroupware to the previous version without affecting or modifying the existing data?
My mail server is dovecot 2.32
Thank you in advance for your support.
[quote=“StefanU, post:4, topic:80066, full:true”]
Hi bzubi.
bzubi:
Ich nutze das direkt als Docker Compose Stack, nicht über Distribution/Installationsskripte
Die hier: egroupware/doc/docker/docker-compose.yml at master · EGroupware/egroupware · GitHub
ohne rocketchat (gab hier schon parallel), ohne mongodb, ohne collabora, ohne watchtower
hab jetzt gesehen, dass die .sh macht auch “nur” ein docker logs für den nginx container.
auf Dovecotseite sehe ich nur, dass eGW Login/INBOX/Prefetch macht, aber kein Löschen - im Vergleich zu Evolution seh ich copy from INBOX → INBOX/Trash usw.
unrelated(?) dazu sehe beim nginx
CreateObject(mail_compose) file /usr/share/egroupware/mail/inc/class.mail_compose.inc.php not found
bei mail.mail_compose.ajax_saveAsDraft. - die gibts auch nicht.
Hab ich einen Versionsmix? Konsistenz prüfen möglich?
Im Browser-Netzwerkdump sieht man beim Löschen einen POST auf /mail/jmap.php mit Email/set.
UID 87129 soll von INBOX nach Trash:
update: {“87129”:{“mailboxIds”:{“VHJhc2g=”:true}}}, mailboxId:“SU5CT1g=”
Die JMAP-Response ist HTTP 200 und meldet sogar:
updated: {“87129”:null}, notUpdated: {}
Erst danach kommt über WebSocket:
A mail operation failed in the background: IMAP error reported by server.
Hi giuseppe.
Please create a separate thread for your issue.
This thread is about deleting emails.
Stefan
Ja genau. Ist nur ein Hilfsscript um es einfacher zu machen.
Wenn du den Container von uns verwendest, dann an der Stelle schon mal nicht.
Caching auf verschiedenen Ebenen könnte ein Problem sein.
Du solltest mindestens mal einen anderen Browser verwenden.
Die Tage bin ich da auch wieder drauf reingefallen…
Das ist dann eher was für @RalfBecker
Stefan
Rawlog Mitschnitt bei Dovecot, ich nehme das vorherige zurück und behaupte das Gegenteil
EGw sendet beim Löschen:
UID MOVE 87134 Trash
Dvecot antwortet:
NO Client tried to access nonexistent namespace. (Mailbox name should probably be prefixed with: INBOX/)
Der Server meldet vorher:
NAMESPACE ((“INBOX/” “/”)) ((“shared/” “/”)) NIL
ich glaube, der sollte INBOX/Trash verwenden, statt Trash.
Hab für das verwendete “für alle” Konto bei den Ordneroption das “INBOX/Trash” explizit gesetzt,
Mails löschen funktioniert wieder.
Das war mal wieder ein Vormittag… 
Geht das auch ohne dass da etwas eingestellt ist?
Ich habe da immer etwas drin stehen, musste aber auch noch nie etwas explizit einstellen. Ist beim Einrichten alles vorbelegt.
War das denn bei dir gar nicht gefüllt?
Stefan
Sind special folder, sollten eigentlich selbst erkannt werden - hat ja auch mit der vorherigen version super geklappt. ich hab die immer leer gelassen und waren auch leer.
Funktioniert ja auch mit der aktuellen EGw Version weiterhin bei z.b. Drafts / Entwürfe - wird richtig unter INBOX/Drafts abgelegt.
Ja, in dem Handling liegt vermutlich das Problem.
Schon recht alt…
Aber ob das dieses Problem auslöst?
Vielleicht hat @RalfBecker da noch weitere Erkenntnisse.
Stefan
Also, ich baue gerade wieder ein, das wenn kein Trash Folder im Mail Account gesetzt ist, wir eine zusätzliche Abfrage auf den als Trash markierten spezial-use Folder machen.
Generell macht es aber Sinn den fest einzustellen.
Ralf
