<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div>I can foresee a time, maybe soon, when the OLI algorithm might naturally add the capability of working globally - especially on IMAP servers that support modern features that would make global sync relatively simple to implement.</div><div><br></div><div>One feature that would help achieve this is an IMAP server that implements the 2010 IETF draft proposal of the single MOVE command, which allows message to be moved from one folder to another, on the same IMAP server. One command instead of about 4, and zero upload/download of the moved messages. This would perform about 1000x faster than today's upload/download method, and greatly reduce the chances of a race condition/deadlock with other connected IMAP clients.<br></div><div><br></div><div><div>Basic algorithm: between runs, retain the unique keys of all
the messages in all of the local and remote mailboxes. The next time you run, use this key information to detect changes in the mailbox contents on both sides. For all messages that have moved, simply do a mass MOVE or a COPY - from one mailbox to another - hundreds of messages can be moved/copied at once. A few seconds to run this, instead of hundreds of seconds.</div><div><br></div></div><div>Also - if IMAP servers were to support something like snapshots (or equivalent), this would help tremendously to reduce the occurrence of runtime errors, due to other clients changing the mailbox state, message state, and flags, during the run of OLI.</div><div><span><br></span></div><div><span><br></span></div><div><span><br></span></div><div><span><br></span></div><div>Daniel wrote:</div><div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "><div style="font-size: 12pt; font-family: 'times new roman',
'new york', times, serif; ">
chris coleman wrote on Wed, Jan 11, 2012 at 08:22:56 -0800:<br>> I don't recall the reason we're moving messages from one mailbox to<br>> another with APPEND+DELETE instead of COPY+DELETE. <br>> <br><br>Because the sync algorithm works on a folder-by-folder basis and not<br>globally.<br><br>At least, that's what Sebastian tells me.<br><br>> Might've originally been an attempt to preserve the UID of the message<br>> when going from one mailbox to another - but UID is lost across<br>> mailboxes so it can't actually be that. <br>> <br>> Sebastian and Nicholas should have a better idea why APPEND+DELETE<br>> instead of COPY+DELETE.<br>> <br>> Chris<br>> <br>> <br>> <br>> Micah wrote:<br>> <br>> Hello,<br>> <br>> I've recently implemented the dovecot-antispam plugin and was dismayed<br>> to find that it has a particularly bad failure situation that only<br>> occurs for Offlineimap
users... of which I am one. This seems<br>> unfortunate, and should be resolved. So I'm writing here to see what can<br>> be done about this, and CC'ing the dovecot-antispam maintainer in the<br>> process. Hopefully a good dialoge about the problem and potential ways<br>> forward will result.<br>> <br>> The summary of the problem is that offlineimap operates in a particular<br>> way with regard to APPEND operations that make it impossible for the<br>> dovecot-antispam plugin to detect certain spam training situations. <br>> <br>> The problem is when training filters. When a user is looking through<br>> their Spam folder, and finds a message that was incorrectly tagged as<br>> spam and decides to move it out of their Spam folder. The way<br>> offlineimap handles this situation is that when it runs it does an<br>> APPEND+DELETE, and this results in a situation that makes the<br>> dovecot-antispam plugin not be
able to detect that this is happening and<br>> thus will not train the message as not-spam (ham). If the user does this<br>> move in a webmail client, or other mail client, things work fine.<br>> <br>> The dovecot-antispam man page has this warning to say about APPEND<br>> operations, which is what offlineimap does:<br>> <br>> ALLOWING APPENDS?<br>> <br>> You should be careful with allowing APPENDs to SPAM folders. The<br>> reason for possibly allowing it is to allow not-SPAM --> SPAM<br>> transitions to work with offlineimap. However, because with<br>> APPEND the plugin cannot know the source of the message, multiple<br>> bad scenarios can happen:<br>> <br>> 1. SPAM --> SPAM transitions cannot be recognised and are trained<br>> <br>>
2. the same holds for Trash --> SPAM transitions<br>> <br>> Additionally, because we cannot recognise SPAM --> not-SPAM<br>> transitions, training good messages will never work with APPEND.<br>> <br>> I'm hoping that this is enough information for offlineimap developers to<br>> understand what the issue is, but if not I've CC'd the dovecot-antispam<br>> developer if further clarification is needed.<br>> <br>> micah<br>> <br>> -<br><br> </div> </div> </div></body></html>