dovecot - Dec 2010 - Incorrect W value after filesystem corruption

Dec 14 00:15:54 vm dovecot: IMAP(####@####): Maildir filename has wrong
W value:
/var/vmail/#####/####/cur/#########.M###########.??.????.??.??,S=4951,W=5057:2,RSa

Dear Dovecot elite,

This morning I woke up to find my mail server hard disk controller had
gone crazy and decided to corrupt my file system. After over eight
passes with the fsck and a new machine I have mostly recovered but this
being a personal server the backups were a half-job. So for speed I
recovered the mail directly off the bad file system. Most of the data
was fine but a few files were corrupt and as a result I have found
Dovecot to be a real pain when it comes to handling a wrong W value. I
am having to separately look at the mail.log and just systematically
remove the W value as a quick work-around. But it seems to me that it
would be much easier to have this done by Dovecot when it realises it
has this wrong value, especially as Dovecot seems to drop the connection
of that user after encountering this problem.

Can I suggest as an improvement this scenario is handled better? I saw
one posting which said "this should never happen" but clearly it can
and
I think there could be better handing of it perhaps?

Regards,

Bob

=============
I am configured as vmail with MySQL back-end, postfix, policyd-weight
and mailscanner.

# 1.2.15: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.26-2-amd64 x86_64 Debian 5.0.7 ext3
base_dir: /var/run/dovecot/
log_timestamp: %Y-%m-%d %H:%M:%S
protocols: imaps pop3s
ssl_cert_file: xxx
ssl_key_file: xxx
login_dir: /var/run/dovecot//login
login_executable(default): /usr/lib/dovecot/imap-login
login_executable(imap): /usr/lib/dovecot/imap-login
login_executable(pop3): /usr/lib/dovecot/pop3-login
mail_max_userip_connections(default): 30
mail_max_userip_connections(imap): 30
mail_max_userip_connections(pop3): 10
first_valid_uid: 150
last_valid_uid: 150
mail_privileged_group: mail
mail_location: maildir:/var/vmail/%d/%u
mbox_write_locks: fcntl dotlock
mail_executable(default): /usr/lib/dovecot/imap
mail_executable(imap): /usr/lib/dovecot/imap
mail_executable(pop3): /usr/lib/dovecot/pop3
mail_plugin_dir(default): /usr/lib/dovecot/modules/imap
mail_plugin_dir(imap): /usr/lib/dovecot/modules/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3
lda:
  postmaster_address: postmaster at orbit.me.uk
  sendmail_path: /usr/lib/sendmail
  auth_socket_path: /var/run/dovecot/auth-master
  mail_plugins: sieve
auth default:
  user: nobody
  passdb:
    driver: sql
    args: /etc/dovecot/dovecot-sql.conf
  userdb:
    driver: sql
    args: /etc/dovecot/dovecot-sql.conf
  socket:
    type: listen
    client:
      path: /var/spool/postfix/private/auth
      mode: 432
      user: postfix
      group: postfix
    master:
      path: /var/run/dovecot/auth-master
      mode: 432
      user: vmail
      group: mail
plugin:
  trash: /etc/dovecot/dovecot-trash.conf
  sieve: /var/vmail/%d/%u/.sieve
  sieve_global_path: /var/vmail/globalsieverc

On Tue, 2010-12-14 at 00:52 +0000, Bob wrote:
> Dec 14 00:15:54 vm dovecot: IMAP(####@####): Maildir filename has wrong
> W value:
>
/var/vmail/#####/####/cur/#########.M###########.??.????.??.??,S=4951,W=5057:2,RSa
..
> Can I suggest as an improvement this scenario is handled better? I saw
> one posting which said "this should never happen" but clearly it
can and
> I think there could be better handing of it perhaps?
After filesystem corruption the W= value is correct, but the message
body is broken. Is it really ok to just change the W value rather than
log about it to get admin to replace the file with a working one from
backup? You clearly want the former, but I don't know if it's a good
idea.

Also if mails are compressed and you accidentally try to access them
without zlib plugin (e.g. first time via doveadm), you'll get these
errors. If Dovecot started changing the W values then, it would break
working mails due to a misconfiguration.

All this is especially problematic because changing the W value changes
the base filename, which causes the message to get a new UID number. So
the change will be noticeable to clients (and maybe users).

So I'm not all that sure what would be a good way to handle this. Maybe
with v2.0 some doveadm command could verify that these are valid and fix
if not (doveadm force-rebuild maybe).