dovecot - Sep 2007 - 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#

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070930/6b15f4ac/attachment-0002.bin>

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 <tss at iki.fi> 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.
>
>
>