We've seen two issues come up with Dovecot LDA, both of which have
caused us problems:
1) If the user's home directory does not exist, or is not owned by them,
deliver fails and causes the mail message to bounce back to the
originator. In our environment this happens when our user is moved
to another server (where we move their files, but for up to 24 hours
afterwards, continue to re-mail their /var/mail INBOX). This no
longer works because the user has no home directory, causing deliver
to fail with "Permission denied" when attempting to create their
home directory for the purposes of creating INBOX index files.
2) If the user is over quota (in their home directory), deliver fails
with a temporary error, causing requeues until the user is back
under quota (which in our environment could be a long time, days).
Since we've never had quotas on the user's INBOX (in /var/mail),
this is a problem for us.
I'd propose for both of these cases that deliver issue WARNING messages
to its logs, and simply not create index files for the INBOX. If the
INBOX index files already exist, and the user is over quota in /home,
neither deliver nor any other Dovecot process should attempt to update
them, and instead issue WARNING messages. This allows the e-mail to be
delivered instead of requeued, or worse yet, rejected. Index files are
supposed to make things perform better, not worse, in ALL cases. :)
--
Steven F. Siirila Office: Lind Hall, Room 130B
Internet Services E-mail: sfs at umn.edu
Office of Information Technology Voice: (612) 626-0244
University of Minnesota Fax: (612) 626-7593
On Fri, 2007-03-23 at 13:08 -0500, Steven F Siirila wrote:> We've seen two issues come up with Dovecot LDA, both of which have > caused us problems: > > 1) If the user's home directory does not exist, or is not owned by them, > deliver fails and causes the mail message to bounce back to the > originator. In our environment this happens when our user is moved > to another server (where we move their files, but for up to 24 hours > afterwards, continue to re-mail their /var/mail INBOX). This no > longer works because the user has no home directory, causing deliver > to fail with "Permission denied" when attempting to create their > home directory for the purposes of creating INBOX index files.Happened with mbox, but not with maildir. Changed to return temporary failure: http://dovecot.org/list/dovecot-cvs/2007-March/008357.html> 2) If the user is over quota (in their home directory), deliver fails > with a temporary error, causing requeues until the user is back > under quota (which in our environment could be a long time, days). > Since we've never had quotas on the user's INBOX (in /var/mail), > this is a problem for us...> I'd propose for both of these cases that deliver issue WARNING messages > to its logs, and simply not create index files for the INBOX. If the > INBOX index files already exist, and the user is over quota in /home, > neither deliver nor any other Dovecot process should attempt to update > them, and instead issue WARNING messages. This allows the e-mail to be > delivered instead of requeued, or worse yet, rejected. Index files are > supposed to make things perform better, not worse, in ALL cases. :)For the 1) case.. No. At least not anytime soon. The mail root directory is used for other things than index files as well, and I don't want to add lots of special case checks to make it work in a INBOX-only environment. For 2) case, it should work like that since rc27. What version are you using? -------------- 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/20070326/0943c78d/attachment.bin>
On Mon, Mar 26, 2007 at 03:23:12AM +0300, Timo Sirainen wrote:> On Fri, 2007-03-23 at 13:08 -0500, Steven F Siirila wrote: > > We've seen two issues come up with Dovecot LDA, both of which have > > caused us problems: > > > > 1) If the user's home directory does not exist, or is not owned by them, > > deliver fails and causes the mail message to bounce back to the > > originator. In our environment this happens when our user is moved > > to another server (where we move their files, but for up to 24 hours > > afterwards, continue to re-mail their /var/mail INBOX). This no > > longer works because the user has no home directory, causing deliver > > to fail with "Permission denied" when attempting to create their > > home directory for the purposes of creating INBOX index files. > > Happened with mbox, but not with maildir. Changed to return temporary > failure: http://dovecot.org/list/dovecot-cvs/2007-March/008357.html > > > 2) If the user is over quota (in their home directory), deliver fails > > with a temporary error, causing requeues until the user is back > > under quota (which in our environment could be a long time, days). > > Since we've never had quotas on the user's INBOX (in /var/mail), > > this is a problem for us. > .. > > I'd propose for both of these cases that deliver issue WARNING messages > > to its logs, and simply not create index files for the INBOX. If the > > INBOX index files already exist, and the user is over quota in /home, > > neither deliver nor any other Dovecot process should attempt to update > > them, and instead issue WARNING messages. This allows the e-mail to be > > delivered instead of requeued, or worse yet, rejected. Index files are > > supposed to make things perform better, not worse, in ALL cases. :) > > For the 1) case.. No. At least not anytime soon. The mail root directory > is used for other things than index files as well, and I don't want to > add lots of special case checks to make it work in a INBOX-only > environment. > > For 2) case, it should work like that since rc27. What version are you > using?We are using rc24 on one server, rc27 on another. Are you saying that it should deliver e-mail to my INBOX (in rc27) even if my home is over quota? I will need to double-check, but I thought this was not the case in either rc24 or rc27, and that it was requeuing instead. -- Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs at umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593