“doveadm mailbox” command fails with UTF-8 mailboxes
Hello,
I’ve got a strange misconfiguration where the following command:
doveadm -f pager mailbox status -u spamutf8 'messages vsize guid' INBOX 'INBOX.*'
… fails with error code 68, saying that it can’t find one of the mailboxes. (It lists the user’s other mailboxes.) The name of the mailbox in question is saved to disk in UTF-8 rather than mUTF-7, but strace shows that doveadm is stat()ing the mUTF-7 path; the failure of that stat() is, assumedly, what causes doveadm to report the error status.
I’ve tried to paw through the source code to see what might be causing this but haven’t made much headway. Can someone here point out where the misconfiguration might be that is causing doveadm to stat() the mUTF-7 path rather than UTF-8? Or perhaps offer any tips as to how I might diagnose what’s going on? What causes doveadm to stat() one path or the other?
Thank you!
-Felipe Gasper Mississauga, ON
On 12 March 2019 21:20 Felipe Gasper via dovecot <dovecot@dovecot.org> wrote:
Hello,
I’ve got a strange misconfiguration where the following command:
doveadm -f pager mailbox status -u spamutf8 'messages vsize guid' INBOX 'INBOX.*'
… fails with error code 68, saying that it can’t find one of the mailboxes. (It lists the user’s other mailboxes.) The name of the mailbox in question is saved to disk in UTF-8 rather than mUTF-7, but strace shows that doveadm is stat()ing the mUTF-7 path; the failure of that stat() is, assumedly, what causes doveadm to report the error status.
I’ve tried to paw through the source code to see what might be causing this but haven’t made much headway. Can someone here point out where the misconfiguration might be that is causing doveadm to stat() the mUTF-7 path rather than UTF-8? Or perhaps offer any tips as to how I might diagnose what’s going on? What causes doveadm to stat() one path or the other?
Thank you!
-Felipe Gasper Mississauga, ON
Mailbox should be stored on disk using mutf7, not UTF-8.
Aki
On Mar 12, 2019, at 3:28 PM, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
On 12 March 2019 21:20 Felipe Gasper via dovecot <dovecot@dovecot.org> wrote:
Hello,
I’ve got a strange misconfiguration where the following command:
doveadm -f pager mailbox status -u spamutf8 'messages vsize guid' INBOX 'INBOX.*'
… fails with error code 68, saying that it can’t find one of the mailboxes. (It lists the user’s other mailboxes.) The name of the mailbox in question is saved to disk in UTF-8 rather than mUTF-7, but strace shows that doveadm is stat()ing the mUTF-7 path; the failure of that stat() is, assumedly, what causes doveadm to report the error status.
I’ve tried to paw through the source code to see what might be causing this but haven’t made much headway. Can someone here point out where the misconfiguration might be that is causing doveadm to stat() the mUTF-7 path rather than UTF-8? Or perhaps offer any tips as to how I might diagnose what’s going on? What causes doveadm to stat() one path or the other?
Thank you!
-Felipe Gasper Mississauga, ON
Mailbox should be stored on disk using mutf7, not UTF-8.
Aki
Hm. I have other users where the command above works, and the mailbox is stored on-disk with a UTF-8 name, and the stat() call is indeed referencing the UTF-8 name.
Is there nothing in Dovecot that allows for a variance?
-FG
On 12 March 2019 21:37 Felipe Gasper via dovecot <dovecot@dovecot.org> wrote:
On Mar 12, 2019, at 3:28 PM, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
On 12 March 2019 21:20 Felipe Gasper via dovecot <dovecot@dovecot.org> wrote:
Hello,
I’ve got a strange misconfiguration where the following command:
doveadm -f pager mailbox status -u spamutf8 'messages vsize guid' INBOX 'INBOX.*'
… fails with error code 68, saying that it can’t find one of the mailboxes. (It lists the user’s other mailboxes.) The name of the mailbox in question is saved to disk in UTF-8 rather than mUTF-7, but strace shows that doveadm is stat()ing the mUTF-7 path; the failure of that stat() is, assumedly, what causes doveadm to report the error status.
I’ve tried to paw through the source code to see what might be causing this but haven’t made much headway. Can someone here point out where the misconfiguration might be that is causing doveadm to stat() the mUTF-7 path rather than UTF-8? Or perhaps offer any tips as to how I might diagnose what’s going on? What causes doveadm to stat() one path or the other?
Thank you!
-Felipe Gasper Mississauga, ON
Mailbox should be stored on disk using mutf7, not UTF-8.
Aki
Hm. I have other users where the command above works, and the mailbox is stored on-disk with a UTF-8 name, and the stat() call is indeed referencing the UTF-8 name.
Is there nothing in Dovecot that allows for a variance?
-FG
Would you be able to provide examples?
Aki
A tool to determine the encoding of a file is 'file -bi <filename>' This command is not perfect though.
On 3/12/19 2:20 PM, Felipe Gasper via dovecot wrote:
Hello,
I’ve got a strange misconfiguration where the following command:
doveadm -f pager mailbox status -u spamutf8 'messages vsize guid' INBOX 'INBOX.*'
… fails with error code 68, saying that it can’t find one of the mailboxes. (It lists the user’s other mailboxes.) The name of the mailbox in question is saved to disk in UTF-8 rather than mUTF-7, but strace shows that doveadm is stat()ing the mUTF-7 path; the failure of that stat() is, assumedly, what causes doveadm to report the error status.
I’ve tried to paw through the source code to see what might be causing this but haven’t made much headway. Can someone here point out where the misconfiguration might be that is causing doveadm to stat() the mUTF-7 path rather than UTF-8? Or perhaps offer any tips as to how I might diagnose what’s going on? What causes doveadm to stat() one path or the other?
Thank you!
-Felipe Gasper Mississauga, ON
On 12 Mar 2019, at 21.20, Felipe Gasper via dovecot <dovecot@dovecot.org> wrote:
Hello,
I’ve got a strange misconfiguration where the following command:
doveadm -f pager mailbox status -u spamutf8 'messages vsize guid' INBOX 'INBOX.*'
… fails with error code 68, saying that it can’t find one of the mailboxes. (It lists the user’s other mailboxes.) The name of the mailbox in question is saved to disk in UTF-8 rather than mUTF-7, but strace shows that doveadm is stat()ing the mUTF-7 path; the failure of that stat() is, assumedly, what causes doveadm to report the error status.
I’ve tried to paw through the source code to see what might be causing this but haven’t made much headway. Can someone here point out where the misconfiguration might be that is causing doveadm to stat() the mUTF-7 path rather than UTF-8? Or perhaps offer any tips as to how I might diagnose what’s going on? What causes doveadm to stat() one path or the other?
What's your doveconf -n? Using UTF-8 on filesystem requires using "UTF-8" option in mail_location. Do you have it set? https://wiki2.dovecot.org/MailLocation
On Mar 12, 2019, at 5:23 PM, Timo Sirainen via dovecot <dovecot@dovecot.org> wrote:
On 12 Mar 2019, at 21.20, Felipe Gasper via dovecot <dovecot@dovecot.org> wrote:
Hello,
I’ve got a strange misconfiguration where the following command:
doveadm -f pager mailbox status -u spamutf8 'messages vsize guid' INBOX 'INBOX.*'
… fails with error code 68, saying that it can’t find one of the mailboxes. (It lists the user’s other mailboxes.) The name of the mailbox in question is saved to disk in UTF-8 rather than mUTF-7, but strace shows that doveadm is stat()ing the mUTF-7 path; the failure of that stat() is, assumedly, what causes doveadm to report the error status.
I’ve tried to paw through the source code to see what might be causing this but haven’t made much headway. Can someone here point out where the misconfiguration might be that is causing doveadm to stat() the mUTF-7 path rather than UTF-8? Or perhaps offer any tips as to how I might diagnose what’s going on? What causes doveadm to stat() one path or the other?
What's your doveconf -n? Using UTF-8 on filesystem requires using "UTF-8" option in mail_location. Do you have it set? https://wiki2.dovecot.org/MailLocation
It turns out we had a missing a cache expiration when a user switches to UTF-8 filenames. So that’s why doveadm was looking for the mUTF-7 filename.
Now that we tracked that down, this appears to be working as it should.
Thank you, everyone!
-FG
On 2019-03-12 17:23, Timo Sirainen via dovecot wrote
Sorry, this might be off-topic, but while reading up on the link you sent, I've noticed the following sentence:
Use only absolute paths. Even if relative paths would appear to work, they might just as well break some day.
Yet, all examples in the documentation use ~ which is a relative path.
Also, using an absolute path is impossible, if your users are located in different parent home directories. e.g.: /home2/<uname> /home3/<uname> /home4/<uname> /var/users/<uname>
So how am I supposed to use an absolue path in such a case? (If I wanted to have the maildir in their home directories and not in a central location?)
Cheers, K. C.
-- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
/* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
On 13 Mar 2019, at 1.07, Helmut K. C. Tessarek <tessarek@evermeet.cx> wrote:
On 2019-03-12 17:23, Timo Sirainen via dovecot wrote
Sorry, this might be off-topic, but while reading up on the link you sent, I've noticed the following sentence:
Use only absolute paths. Even if relative paths would appear to work, they might just as well break some day.
Yet, all examples in the documentation use ~ which is a relative path.
Well, I suppose it depends on definitions.. But I'm not calling ~/ relative paths, because it expands to an absolute path. The problem is using paths like "mail/" where it depends on the current chdir.
On 2019-03-12 19:17, Timo Sirainen wrote:
Well, I suppose it depends on definitions.. But I'm not calling ~/ relative paths, because it expands to an absolute path. The problem is using paths like "mail/" where it depends on the current chdir.
Thank you for clearing this up.
IMO the ~ is still a relative path until it has been expanded to an absolute path. Depending on the framework/API/code, expansion might not even work. A path mail/ could also be expanded to an absolute path, so I don't see a difference there. It's just that the output of getcwd might not be as predictable, that's all.
But I agree, it's a matter of definition. In that case, I'd kindly ask you to state in the documentation that ~ is not considered a relative path.
If one wants to get very pedantic, ~ is neither an absolute, nor a relative path. But I'm not here to be a smartass.
Thanks again for clearing this up for me.
Cheers, K. C.
-- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
/* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */
participants (5)
-
Aki Tuomi
-
Bob Gustafson
-
Felipe Gasper
-
Helmut K. C. Tessarek
-
Timo Sirainen