Re: [Dovecot] IMAP Fetch fails with BAD instead of NO
Hi Thanks, I guess I can handle the BAD response in my application via javamail by just catching the exception. I think in dovecot it sends back the BAD, but also closes the connection ? Is that the expected behavior on a BAD fetch, to close the IMAP connection? Exchange also sends back a NO , but I'll take that as a bug too :) Thanks Reinier On 9/30/07, Timo Sirainen [EMAIL PROTECTED] wrote: On Thu, 2007-09-27 at 10:18 -0400, Reinier Bezuidenhout wrote: AXXX FETCH 14 (UID) AXXX BAD Error in IMAP command FETCH: Invalid messageset This has been discussed in imap-protocol mailing list a few times, and BAD is the correct reply here. For example UW-IMAP is the reference IMAP server implementation and it gives: x fetch 100 uid x BAD Bogus sequence in FETCH: Sequence out of range Looks like Cyrus replies with NO for some reason. I'd say it's a bug in Cyrus instead. Actually it's been said that FETCH should never return NO, and it was a mistake to add that to the spec in the first place.
[Dovecot] IMAP Fetch fails with BAD instead of NO
Hi, I'm running version 1.0.3 of dovecot using IMAP and using javamail to access the mail. The application I'm using (when stress testing the system by doing simultaious creation of email and deleting emails, it sometimes get into the state where the application (via javamail) ask for the UID of a message that has been expunged and deleted (no longer exists). Dovecot returns with the following error: AXXX FETCH 14 (UID) AXXX BAD Error in IMAP command FETCH: Invalid messageset This can easily be reproduced by using telnet to 143 and giving the command by hand. When I read through the source code, there were obvious comments that states the dovecot will not return NO on fetch errors, only BAD. So I assume it is done on purpose. My question is that in RFC 3501 for fetch it says: (section 6.4.5) Result: OK - fetch completed NO - fetch error: can't fetch that data BAD - command unknown or arguments invalid No I guess a UID that is out of range could be considered arguments invalid, but shouldn't it be a soft error with NO as a result where can't fetch that data is more appropriate according the the RFC. The command isn't syntactically BAD, the requested data just does not exists. The same command tested against another IMAP server returns AXXX NO message not available Not that they are necessarily correct, but it just begs the question. Thanks Reinier Running on FreeBSD 6.x (x86) devmail# dovecot -n # 1.0.3: /usr/local/etc/dovecot.conf protocols: imap pop3 ssl_disable: yes disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login valid_chroot_dirs: /var/mail verbose_proctitle: yes first_valid_uid: 3000 last_valid_uid: 5000 first_valid_gid: 0 mail_extra_groups: mail mail_location: mbox:~/mail/:INBOX=/var/mail/%u mail_debug: yes maildir_copy_with_hardlinks: yes mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 imap_client_workarounds(default): delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(imap): delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(pop3): outlook-idle pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh auth default: verbose: yes passdb: driver: ldap args: /usr/local/etc/dovecot-ldap.conf userdb: driver: ldap args: /usr/local/etc/dovecot-ldap-user.conf userdb: driver: prefetch devmail#
