offlineimap and dovecot-antispam: APPEND issues
d.s at daniel.shahaf.name
Wed Jan 11 17:14:41 GMT 2012
chris coleman wrote on Wed, Jan 11, 2012 at 08:22:56 -0800:
> I don't recall the reason we're moving messages from one mailbox to
> another with APPEND+DELETE instead of COPY+DELETE.
Because the sync algorithm works on a folder-by-folder basis and not
At least, that's what Sebastian tells me.
> 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.
> Sebastian and Nicholas should have a better idea why APPEND+DELETE
> instead of COPY+DELETE.
> Micah wrote:
> I've recently implemented the dovecot-antispam plugin and was dismayed
> to find that it has a particularly bad failure situation that only
> occurs for Offlineimap users... of which I am one. This seems
> unfortunate, and should be resolved. So I'm writing here to see what can
> be done about this, and CC'ing the dovecot-antispam maintainer in the
> process. Hopefully a good dialoge about the problem and potential ways
> forward will result.
> The summary of the problem is that offlineimap operates in a particular
> way with regard to APPEND operations that make it impossible for the
> dovecot-antispam plugin to detect certain spam training situations.
> The problem is when training filters. When a user is looking through
> their Spam folder, and finds a message that was incorrectly tagged as
> spam and decides to move it out of their Spam folder. The way
> offlineimap handles this situation is that when it runs it does an
> APPEND+DELETE, and this results in a situation that makes the
> dovecot-antispam plugin not be able to detect that this is happening and
> thus will not train the message as not-spam (ham). If the user does this
> move in a webmail client, or other mail client, things work fine.
> The dovecot-antispam man page has this warning to say about APPEND
> operations, which is what offlineimap does:
> ALLOWING APPENDS?
> You should be careful with allowing APPENDs to SPAM folders. The
> reason for possibly allowing it is to allow not-SPAM --> SPAM
> transitions to work with offlineimap. However, because with
> APPEND the plugin cannot know the source of the message, multiple
> bad scenarios can happen:
> 1. SPAM --> SPAM transitions cannot be recognised and are trained
> 2. the same holds for Trash --> SPAM transitions
> Additionally, because we cannot recognise SPAM --> not-SPAM
> transitions, training good messages will never work with APPEND.
> I'm hoping that this is enough information for offlineimap developers to
> understand what the issue is, but if not I've CC'd the dovecot-antispam
> developer if further clarification is needed.
> OfflineIMAP-project mailing list
> OfflineIMAP-project at lists.alioth.debian.org
> OfflineIMAP homepage: http://software.complete.org/offlineimap
More information about the OfflineIMAP-project