Bug 1911113

Summary:

uw-imapd not well suited for the roundcube webmailer

Product:

[Fedora] Fedora

Reporter:

Albert Flügel <af>

Component:

uw-imap

Assignee:

Orphan Owner <extras-orphan>

Status:

CLOSED EOL

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

low

Docs Contact:

Priority:

unspecified

Version:

CC:

fedora, jorton, rdieter

Target Milestone:

---

Target Release:

---

Hardware:

All

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

---

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2021-11-30 16:12:29 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Patch to imapd-2007f to enhance robustness for the situation, the mailbox is locked	none
spec file to build the uw-imap with the attached patch file	none
Better (in case of clock skew) patch to imapd-2007f to enhance robustness for the situation, the mailbox is locked	none

Description Albert Flügel 2020-12-27 16:08:00 UTC

Created attachment 1742305 [details]
Patch to imapd-2007f to enhance robustness for the situation, the mailbox is locked

Description of problem:
Using the roundcube webmailer (package roundcubemail.noarch) leads to error messages when deleting or moving messages from / between mailboxes.


Version-Release number of selected component (if applicable):
uw-imap-2007f-25.fc33

How reproducible:
Install iw-imap and roundcubemail, configure roundcube to use the local imapd as backand. Use the web frontend, select a mail message and immediately delete or move to a different folder

Steps to Reproduce:
1. log on to the roundcube web UI
2. select a mail message
3. immediately press the Delete button

Actual results:
A red area appears in the web UI with the text "Failed to move message to Trash !" and the message remains in the current folder

Expected results:
The message disappears from the current folder and is moved to Trash


Additional info:
Waiting a few seconds between selecting a message and pressing the delete button  (or moving the message to a different folder) avoids the problem, but this is really annoying and confusing for ingenuous users. In the maillog the following message appears: "Killed (lost mailbox lock)".
Actually this is an intended behaviour of imapd, as the authors explain in the FAQ #7.19 . I added the following section there regarding my modification,
available only for the unix/Linux variant as i have no possibility to test on other platforms:
          However, the unix version is a bit more tolerant. When the
          server detects, that a lock is set on the mailbox, it retries
          to obtain it until 15 seconds after the creation time of the
          lock, if the lock is not already that old. Only after this
          phase of retrying it sends the "kiss of death" to the competing
          process. This way the scenarios outlined above and the related
          errors probably displayed to the users are mostly avoided. A
          short concurrent access e.g. to check for new mail should not
          cause some kind of outage and confuse the users. On the other
          side, a short waiting time for the lock to be released should
          be acceptable. A particular experience was using the web mailer
          "roundcube" (please see http://roundcube.net/ ). It is closing
          imap connections by only fractions of a second after opening 
          another one yet causing this imap server to detect an existing
          lock and requesting the termination of another server instance,
          what makes roundcube assume something went wrong. Probably this
          shortly later closing of connections is actually a matter of
          deferred execution in the browser, who is the actual client of
          roundcube in turn, so this phenomenon is probably (unclear) not
          even a fault of the roundcube implementation.

Comment 1 Albert Flügel 2020-12-27 16:09:21 UTC

Created attachment 1742307 [details]
spec file to build the uw-imap with the attached patch file

Comment 2 Albert Flügel 2020-12-28 15:59:21 UTC

Created attachment 1742726 [details]
Better (in case of clock skew) patch to imapd-2007f to enhance robustness for the situation, the mailbox is locked

This way the retrying to obtain a lock on the mailbox is not sensitive to the case, that the clock jumps during waiting for the lock to be released (counting down instead of watching time(0) )

Comment 3 Fedora Admin user for bugzilla script actions 2021-02-08 12:08:29 UTC

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 4 Ben Cotton 2021-11-04 16:07:36 UTC

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 5 Albert Flügel 2021-11-05 11:07:38 UTC

I noticed, that uw-imapd has disappeared from Fedora. What a pity. Together with the decision of the thunderbird maintainers to drop support for movemail, this would force me to some remote mailbox access service or to use cyrus imapd with e.g. it's non-trivial mailbox backup options. In any case with the superfluous need to authenticate to access a local file.
Still i haven't seen another mailbox format or solution for local mailbox file access that i found really convincing.
However, thanks to the fact, that the sources iv uw-imapd cannot be destroyed, i still use it. I wait for the day, that incompatilbilities introduced in glibc and friends will kill the chance to even build it.

Comment 6 Ben Cotton 2021-11-30 16:12:29 UTC

Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.