70 lines
		
	
	
	
		
			3 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			70 lines
		
	
	
	
		
			3 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
| f{,data}sync() usage could be optimized by batching the calls.
 | |
| 
 | |
| add some marker about message being already [remotely] trashed.
 | |
| real transactions would be certainly not particularly useful ...
 | |
| 
 | |
| make sync_chans() aware of servers, so a bad server (e.g., wrong password)
 | |
| won't cause the same error message for every attached store.
 | |
| 
 | |
| make SSL (connect) timeouts produce a bit more than "Unidentified socket error".
 | |
| 
 | |
| uidvalidity lock timeout handling would be a good idea.
 | |
| 
 | |
| add message expiration based on arrival date (message date would be too
 | |
| unreliable). MaxAge; probably mutually exclusive to MaxMessages.
 | |
| 
 | |
| add alternative treatments of expired messages. ExpiredMessageMode: Prune
 | |
| (delete messages like now), Keep (just don't sync) and Archive (move to
 | |
| separate folder - ArchiveSuffix, default .archive).
 | |
| 
 | |
| kill the concept of an INBOX, it is a relic from single-channel operation.
 | |
| if somebody needs it, he can have two stores with different Paths. the path
 | |
| can name a single (in-)box (curr. broken with maildir). an empty box name
 | |
| actually means empty, so the IMAP mailbox should use INBOX for Path (can't
 | |
| make that the default, as it would mess up the NAMESPACE).
 | |
| 
 | |
| add regexp-based mailbox path rewriting to the drivers. user would provide
 | |
| expressions for both directions. every transformation would be immediately
 | |
| verified with the inverse transform. PathDelimiter and Flatten would become
 | |
| special cases of this.
 | |
| 
 | |
| add daemon mode. primary goal: keep imap password in memory.
 | |
| also: idling mode.
 | |
| 
 | |
| parallel fetching of multiple mailboxes.
 | |
| 
 | |
| imap_set_flags(): group commands for efficiency, don't call back until
 | |
| imap_commit().
 | |
| 
 | |
| add streaming from fetching to storing.
 | |
| 
 | |
| handle custom flags (keywords).
 | |
| 
 | |
| make use of IMAP CONDSTORE extension (rfc4551; CHANGEDSINCE FETCH Modifier);
 | |
| make use of IMAP QRESYNC extension (rfc5162) to avoid SEARCH to find vanished
 | |
| messages.
 | |
| 
 | |
| use MULTIAPPEND and FETCH with multiple messages.
 | |
| 
 | |
| create dummies describing MIME structure of messages bigger than MaxSize.
 | |
| flagging the dummy would fetch the real message. possibly remove --renew.
 | |
| note that all interaction needs to happen on the slave side probably.
 | |
| 
 | |
| don't SELECT boxes unless really needed; in particular not for appending,
 | |
| and in write-only mode not before changes are made.
 | |
| problem: UIDVALIDITY change detection is delayed, significantly complicating
 | |
| matters.
 | |
| 
 | |
| possibly use ^[[1m to highlight error messages.
 | |
| 
 | |
| consider alternative approach to trashing: instead of the current trash-before-
 | |
| expunge done by mbsync, let MUAs do the trashing (as modern ones typically do).
 | |
| mbsync wouldn't do any trashing by itself, but should track the moves for
 | |
| optimization. additionally, there should be a mode to move trashed messages to
 | |
| the remote store. TrashMode Internal|External, AbsorbRemoteTrash.
 | |
| a yet different approach to trashing is treating the trash like a normal mailbox.
 | |
| however, this implies a huge working set.
 | |
| 
 | |
| consider optional use of messages-id (and X-GM-MSGID):
 | |
| - detection of message moves between folders
 | |
| - recovery from unmotivated UIDVALIDITY change, or total loss of sync state
 |