<DKIM> [PATCH] Write IMAP keyword changes (maildir file renames) back to the server

[Igor Almeida]

Excerpts from Nicolas Sebrecht's message of May 19, 2019 11:24 am:
> On Sun, May 19, 2019 at 01:27:13AM -0300, Igor Almeida wrote:
> 
>> Yeah, I had to do some digging to find this. But the patch was mostly for
>> testing and feedback. And to remember the discussion we had a few years ago (!)
>> about eventually getting to this part.
>> 
>> For example, at some point we talked about checking PERMANENTFLAGS for
>> permission to store keywords and create new ones, but I don't understand the
>> protocol (and the code) enough to find where this would go.
> 
> I couldn't find this discussion.
> 

How do I refer to it? Message-IDs?

<1446905815-12828-1-git-send-email-igor.contato at gmail.com>
<1448046554-4534-1-git-send-email-igor.contato at gmail.com>

>> By the way, what is the plan for py3? I remember there was pull request at
>> some point.
> 
> Yes, there's been 3 attemps to port offlineimap to py3. All failed.
> 

Ouch.

>> It will break, yes.
>> If the source side is IMAP too, we enter the except block. At this point we could
>> set `flagstring` to `imaputil.flagsmaildir2imap(flags))`, which would revert
>> to the original code.
>> Also, if both servers are modern enough, there shouldn't be a need for
>> translating between their keyword representations...
> 
> I didn't check what would be the best. Why coulnd't just ignore this
> error?
> 

Yes, the except block should not fail as it does now.
I don't intend to test IMAP-IMAP sync, though.

>> Well, at least RF3501 says that `flag-keyword` (itself an `atom`) cannot have a
>> space... Anyway, to prevent a problem here, maybe when assembling the keywordmap
>> in MaildirRepository we could raise an error.
>> 
>> I don't particularly like passing the dict to this imaputil function. Maybe it
>> would be best to just add to the set after `imaputil.flagsmaildir2imap`
>> returns to `IMAPFolder.__processmessagesflags_real`.
> 
> I think that raising an error should be good enough. At least, this
> would stop the current process and avoid doing weird things.
> 

Great. I'll submit a v2 patch eventually.

BR

> 
> -- 
> Nicolas Sebrecht
> 

--
Igor Almeida