[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Expiration does not work + solution
Trung Tran-Duc <trung.tranduc@prague.ixos.cz> writes:
> The obvious reason is nnimap uses two-digit years in the NOT SINCE search
> clause and the IMAP server does not like it. The fix is really simple and I
> think it should not break other IMAP servers
Thanks for the patch, I've applied it. RFC1730 permits 2 digit years
so if your server list "IMAP4" as the first CAPABILITY symbol it
should work (look athe the first 2-3 lines of *imap-log*), I guess
Exchange is a IMAP4rev1 server then.
> In *imap-log* I also see
> ...
> 37 UID STORE 2:14 -FLAGS (gnus-expire)
> 37 BAD protocol error: "Invalid flags set for STORE command"
> ...
>
> It looks like nnimap tries to store a user-defined flag and the server refuses
> to obey. Does nnimap gracefully fall back in this case?
Nnimap should never try to set/remove a user-defined flag unless the
server tell us we can do that. Could you search backwards in
*imap-log* for SELECT and tell us what it looks like?
The "\*" in the PERMANENTFLAGS line below signals that the server
accept user-defined flags.
268 SELECT INBOX.nnimap
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen gnus-expire gnus-save)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen gnus-expire gnus-save \*)]
* 56 EXISTS
* 0 RECENT
* OK [UNSEEN 55]
* OK [UIDVALIDITY 908992622]
268 OK [READ-WRITE] Completed
Hm. Just before that line in *imap-log*, was any of article 2-14 just
expired? There is a known bug in nnimap that make it remove flags on
articles that has been removed. I think the server is supposed to just
silently ignore thoose but perhaps it doesn't.