dovecot - Oct 2007 - Upgrade from 1.0.1 -> 1.0.5 failed (rc 75)

Hi,

I'm using a mixture of Exim, Dovecot and Deliver.  Exim receives the 
mail and validates the user against our database, then pipes the e-mail 
to deliver which puts it in the right mailbox.

We were running Exim 4.67 and Dovecot 1.0.1, and today I did an in-place 
upgrade to Dovecot 1.0.5 and Exim 4.68.
However, now Exim is failing deliveries saying deliver returned code 
75.  If I examine the dovecot log file, I'm getting errors like:

deliver(andy.shellam-lists at mailnetwork.co.uk): Oct 21 17:19:49 Fatal: 
chroot(/users/mail/andy.shellam-lists at mailnetwork.co.uk) failed: 
Operation not permitted

All mailboxes are owned by user "dovecot-mail" and group
"localservice",
with user and group having full permissions, and other having no access 
(0770).
None of the config files (Exim nor Dovecot's) have changed, nor have 
permissions on the mailbox paths, and Dovecot can still access the 
mailboxes through IMAP just fine.

If I delete the dovecot log-file and force a mail delivery, the log gets 
re-created with mode 0644 and owner dovecot-auth:localservice, which 
confirms the user running dovecot is the same group, so why doesn't it 
have permissions?

I've read on another message that return code 75 is EX_TEMPFAIL, what 
does this mean?
My sendmail_path is the correct path to Exim, verified by killing Exim 
and copying and pasting the command to start it back up again.

Any advice would be appreciated, as I may have to restore back to 1.0.1.

Thanks,

Andy

dovecot -n:

# 1.0.5: /usr/local/dovecot/etc/dovecot.conf
base_dir: /var/run/dovecot/
log_path: /mndata/logs/dovecot.current.log
protocols: imap
ssl_disable: yes
disable_plaintext_auth: no
login_dir: /var/run/dovecot/login
login_executable: /usr/local/dovecot/libexec/dovecot/imap-login
login_user: dovecot-login
login_greeting: SystemVDM2 ready.
login_processes_count: 5
valid_chroot_dirs: /mndata/mail
mail_chroot: /mndata/mail
first_valid_uid: 1013
last_valid_uid: 1013
first_valid_gid: 1002
last_valid_gid: 1002
mail_extra_groups: localservice
mailbox_idle_check_interval: 60
maildir_copy_with_hardlinks: yes
namespace:
  type: private
  separator: .
  prefix: INBOX.
  inbox: yes
auth default:
  mechanisms: plain login
  default_realm: mailnetwork.co.uk
  user: dovecot-auth
  username_translation: +@
  username_format: %Lu
  passdb:
    driver: sql
    args: /usr/local/dovecot/etc/dovecot-sql.conf
  userdb:
    driver: sql
    args: /usr/local/dovecot/etc/dovecot-sql.conf
  socket:
    type: listen
    master:
      path: /var/run/dovecot/auth-master
      mode: 432
      user: dovecot-auth
      group: localservice

On Sun, 21 Oct 2007, Andy Shellam (Mailing Lists) wrote:
> deliver(andy.shellam-lists at mailnetwork.co.uk): Oct 21 17:19:49 Fatal: 
> chroot(/users/mail/andy.shellam-lists at mailnetwork.co.uk) failed:
Operation
> not permitted
Only programs running as UID 0 (root) are allowed to use the chroot system 
call.  Does your use of chroot() for deliver represent something new in 
your config, or if not, in the way Dovecot interprets your config?

-- Asheesh.

--
 	A reverend wanted to telephone another reverend.  He told the operator,
"This is a parson to parson call."

On Sun, 2007-10-21 at 17:44 +0100, Andy Shellam (Mailing Lists)
wrote:
> deliver(andy.shellam-lists at mailnetwork.co.uk): Oct 21 17:19:49 Fatal: 
> chroot(/users/mail/andy.shellam-lists at mailnetwork.co.uk) failed: 
> Operation not permitted
Earlier deliver versions ignored chroot setting, which was a bug. So you
have two choices:

1) Make deliver setuid-root so it can chroot. See "Multiple UIDs"
section in http://wiki.dovecot.org/LDA

2) Disable chrooting with deliver. I think you can do this by updating
the protocol lda section:

protocol lda {
  ..
  mail_chroot }

-------------- 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/20071021/22a811fe/attachment-0002.bin>