mdecimus
commented
2 months ago The fileinto command is case sensitive, you probably created another INBOX folder at the root level.
Closed esclear closed 2 months ago
mdecimus
commented
2 months ago The fileinto command is case sensitive, you probably created another INBOX folder at the root level.
esclear
commented
2 months ago I don't see one. Wouldn't there need to be a mention of INBOX in a different casing then?
In the IMAP session, I used identical casings in both selects/fetches, so I'm not sure how capitalization would play into this?
mdecimus
commented
2 months ago To confirm this you can try exporting your account and check the JSON file containing the mailbox structure.
esclear
commented
2 months ago Thanks!
Indeed, there is also an Inbox mailbox in the mailbox.json file.
I suspect that this is the default one generated by Stalwart.
Still, I did not expect this to make a difference, since RFC 3501 stipulates that the INBOX mailbox name is case-insensitive — and, even if it appears as part of a path, I'd expect the INBOX part to be treated case-insensitively.
But apart from that, in this situation, the Sieve script, my MUA, and the IMAP session all referenced the path in INBOX.
So I'm not sure how the existence of Inbox would lead to the (re)creation of a folder in INBOX?
esclear
commented
2 months ago Okay, thinking a bit further about this, I have a suspicion:
Inbox folder, at least as far as mailboxes.json is concerned.INBOX folder server-side after the import.INBOX as Inbox, also as part of paths.INBOX maildir.Inbox.However, INBOX doesn't seem to always take precedence, since the folders under Inbox, which don't exist under INBOX are still found, including their contents. 🤔
Would Stalwart (looking for INBOX/Foo in IMAP) use Inbox/Foo, if INBOX exists, but INBOX/Foo doesn't?
Yeah, so this is unexpected. 😅
Personally, I'd treat the INBOX part as case-insensitive in Sieve as well.
Sec 4.1 of RFC 5228 doesn't say that it has to be treated case-sensitive (although quoted strings are case-sensitive).
In my opinion, doing this mapping would be sensible, as it'd have saved me from this problem and likely others as well.
From my interpretation of the fileinto action, that would also be permitted by the standard (either as part of the "delivery to an implementation-defined mailbox", or in the same vein as the reencoding).
I am not sure, how other servers handle this. What do you think?
mdecimus
commented
2 months ago I've just changed the way folders are searched so Inbox is case insensitive.
What happened?
I migrated my old mailserver (postfix + dovecot) to Stalwart and am currently on v0.9.2. For the migration, I transferred all of my emails and the folder structure using the
imapsynctool. I set up a fresh Thunderbird profile and downloaded all messages and all were there.Afterwards, I also set up my old sieve script, which moves messages into folders, based on the envelope-to address (and basing the folder name on the address
:detail).fileintouses the:createflag, as sometimes the folders need to be created ad-hoc.I received some messages and noticed that Thunderbird was behaving strangely; the folders where they should end up disappeared from my mailbox. From some manual debugging (see below), it appears to me that existing folders are being replaced (and that the old messages are lost).
How can we reproduce the problem?
foo@<your-domain>and within it the folderINBOX/Foo-Stuff/Barand put messages in there using IMAP (e.g. using Thunderbird or imapsync). I put two messages in mine.Set up the following Sieve script for this mailbox:
INBOX/Foo-Stuff/Bar, e.g. using IMAP directly:)
) f1 OK FETCH completed
g2 SELECT "INBOX/Foo-Stuff/Bar"
) f2 OK FETCH completed
Code of Conduct