<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>I don't recall the reason we're moving messages from one mailbox to another with APPEND+DELETE instead of COPY+DELETE. </span></div><div><span><br></span></div><div><span>Might've originally been an attempt to preserve the UID of the message when going from one mailbox to another - but UID is lost across mailboxes so it can't actually be that. </span></div><div><span><br></span></div><div><span>Sebastian and Nicholas should have a better idea why APPEND+DELETE instead of COPY+DELETE.</span></div><div><span><br></span></div><div><span>Chris</span></div><div><span><br></span></div><div><span><br></span></div><div><span><br></span></div><div>Micah 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; ">
<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>