malformed PERMANENTFLAGS status when syncing specific folders
mailbox synchronizer
Brought to you by:
ossi
Hello. I am newbie when it comes to using command line interfaces with email so forgive my ignorance.
I have set up isync on my macOS machine. My email provider is fastmail, however when attempting to sync mail via imap, I get following error:
IMAP error: malformed PERMANENTFLAGS status
IMAP error: bogus FETCH response
I assume that this might not be related to isync at all and it can be with my email provider. However I was hoping that you could point me at some direction. This is my .mbsyncrc file:
IMAPAccount personal
Host imap.fastmail.com
User username@fastmail.com
Pass password
SSLType IMAPS
SSLVersions TLSv1.2
Port 993
CertificateFile /usr/local/etc/openssl@1.1/cert.pem
IMAPStore personal-remote
Account personal
MaildirStore personal-local
SubFolders Verbatim
Path ~/mail/personal/
Inbox ~/mail/personal/INBOX
Channel personal
CopyArrivalDate yes
Far :personal-remote:
Near :personal-local:
Patterns "*"
Sync All
Create Both
Expunge None
SyncState *
I am using version 1.4.0.
It seems to get stuck at specific folders, some of them get synced and I can see them on my local machine.
please re-run with the -Dn option and attach the log. it's sufficient if you do this for a single affected folder.
@ossi hope this helps:
Also not sure if this is related, I actually wanted to file this as a possible bug as well but some of my emails that I have synced seemed to have mangled my name in "Sent" folder. The format of the "FROM" field is specified like this: "FirstName LastName firstnamelastname@email.com".
However my name actually contains accented characters so the downloaded files actually contain something like this:
=?utf-8?b?T25kxZllaiBTeW7DocSNZWs=?= <firstnamelastname@email.com>. Which is not great as my email viewer is not able to render this correctly.As I mentioned, not sure if that can relate to the problem above, some possible encoding issue.
from https://tools.ietf.org/html/rfc3501#section-9:
which means that the unquoted closing brackets in the keywords are illegal.
by extension this means that closing brackets in keywords are illegal altogether, as the above syntax has no provisions for quoting. that's certainly just an omission of the spec, but still.
i think i can work around this somewhat easily, but technically speaking that server is broken and you should report it to them.
the encoding problem is unrelated. the protocol doesn't change or even care for the mail contents in any way. check if the outgoing messages are compliant with https://tools.ietf.org/html/rfc5322.
Great! I will be checking new release.
I've actually found out it's one of my email clients that does this. Raw emails downloaded via web interface of my email provider have the same weird header value so you're right, not definitely and issue with isync.
Thanks again for help.
@ossi One more thing. I've tried pulling
1.4branch, read the instructions for installation. I wanted to check out if it works with your changes.However did something change between
1.4.0and what is currently in that branch as far as configuration goes?I've got error saying that
SSLTypeandSSLVersionsis not supported withinIMAPAccountsection.fairly safe bet: openssl was not found. make sure you have the -dev package installed.
By that package do you mean
openssl-dev? I'm on macOS so I tried searching foropenssl-dev/openssl-develbut no luck. The requirements inREADMEfile specify open ssl as optional but do not mention the dev package.This is the output:
When running
./configureI getSo I guess that is potential culprit?
Last edit: comatory 2021-02-15
OK got it and confirm your fix does indeed work. I managed to compile on my macOS system by doing following
brew install openssl && brew link openssl --forcePATH, do that, linkopenssl --forceagain and reload terminal session.cp /usr/local/opt/openssl@1.1/lib/pkgconfig/*.pc /usr/local/lib/pkgconfig/. I found it hereREADMEto recompile and install again.Last edit: comatory 2021-02-15