Eduard Pertíñez writes:
Hi,
I reported this problem to Mozilla Thunderbird and they have been very kind
to analyze it.
https://bugzilla.mozilla.org/show_bug.cgi?id=1892385
But it seeems the problem is with Courier MTA and the way you have to create
folder based shared folders.
Problem:
When moving a message that has been flagged (important, todo, favorite, ...)
to a shared folder, the message loose the flags.
I bet the problem is that the user's structure is not created until the user
refreshes its shared folder view, so the flags cannot be moved to this user
folder yet.
This is absolutely correct, and this is exactly how IMAP is required to
work, as specified in RFC 3501.
But that is only a guess.
Anyway, you have all info about the problem in the bugzilla link I just sent
you.
I would appreciate if you take a look at the problem.
I did not dig deep into that bug entry's logs, but what's described are
symptoms of a common IMAP bug. Let's use a concrete command as an example:
2024-09-23 07:44:14.957642 UTC - [Parent 1995790: IMAP]: I/IMAP
7f220e70d600:bredax.com:S-INBOX:CreateNewLineFromSocket: 51 OK [COPYUID
1229508979 53158 706] COPY completed.
The client received a COPY response, indicating that a message was copied to
another folder.
I do know that Thunderbird uses multiple IMAP connections. I suspect that
Thunderbird has another connection, that has the destination folder opened
and assumes that it can fiddle with the copied message there. I didn't dig
through all of the logs pasted into that bug, but I suspect that this is the
case here.
And that's wrong. This is a protocol violation. People might be surprised to
learn that the copied message doesn't really exist yet, even though it's
been physically created by a COPY. It's sitting in a black hole, waiting for
the IMAP client to pull it across the blue event horizon. The IMAP client
must refresh the folder in order for the message to officially exist in our
shared universe.
Until the IMAP client receives an untagged EXISTS message, indicating more
messages in the currently selected folder, there are no new messages in the
folder, as far as this IMAP session is concerned.
Now, once the IMAP client does get the EXISTS message it will definitely
discover that there's a new message in the folder, that just happens to have
a UID that the COPYUID message returned. But until the IMAP client is
notified, by the server, that there's a new message in the folder, it cannot
be referenced by any IMAP command.
One might ask – why is the server not returning an error message, if the
client sends a command referencing a non-existent message?
This is a very good question.
And the answer is that invalid message references was historically a very
common IMAP client bug, and IMAP clients will vomit all over themselves if
the server sent an error in response to a reference to a nonexistent
message. It was decided (I have no records when, but it was at least ten
years ago, before the entire source was imported into git) to simply ignore
this, and do nothing.
RFC 3501:
==========================================================================
7.3.1. EXISTS Response
Contents: none
The EXISTS response reports the number of messages in the mailbox.
==========================================================================
That's it. The End. Full stop. Finis. Nowhere else in RFC 3501 is there any
other description of any other way that the IMAP client is served notice
that there are new messages in the currently open folder. The IMAP client
must do one of several actions that refresh the folder, and generate an
untagged EXISTS message.
If the most recent EXISTS message told the IMAP client that there are 10
messages in the folder, there are still ten messages in this folder, even if
another IMAP connection COPYed a new message into this folder. There are
going to be just 10 messages in the folder until it gets another EXISTS (or
until it gets an EXPUNGE but that's immaterial for the purpose of this
discussion). That's just how IMAP works.
The fact that the server executed a COPY to this folder in another IMAP
connection does not change the fact that the folder still has 10 messages,
as far as /this/ IMAP connection is concerned.
I find nothing in RFC 3501's specification of a COPY that indicates that the
state of the existing messages in the folder has changed, as a result of a
COPY in another IMAP connection.
_______________________________________________
Courier-imap mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
