At 1247082407 time_t, Timo Sirainen wrote: > "let the bug"? The idea is anyway that you return > home=/var/mail/vmail/danjou.info/jd and set > > mail_location = maildir:%h > > That makes much more sense to me. I've considered making it an error to > return relative home dirs from userdb, but that might break some setups > that are actually working right..
Like mine. I don't think this is *bad* since it's, AFAIK, Dovecot only use in homedir to expand %h. Or do I miss another point? > Well, I guess there's some confusion about what a home dir is.. With > Dovecot the home dir is always what userdb returns as the home dir. > Dovecot doesn't care about /etc/passwd at all, unless your userdb is > passwd. So Dovecot doesn't know/care that deliver is run as "mail" user, > it doesn't care what /etc/passwd contains for the mail user. Okay, sorry for the confusion. I don't know why I though it was doing some chdir() in a part of mail_location, which has no sense. > > where as mail_location is /var/mail/vmail/%h. > > And almost all the mails (except the couples of ones I mentionned) are > > delivered and still delivered currently. > > It's probably the large mails that cause the problem. Dovecot writes > them to a temporary file under home directory. OK, that would explains everything actually, depending on what you call home directory. :-) If it's the user's home, it really has no sense since nowhere it returns something with /var/spool/postfix. Well, anyway, I changed my setup to return absolute path and it seems to work, the mails got delivered. I really suggest you[1] rather try to reproduce and fix the bug, or really disallow relative path in home directory since it's seems partly-broken, or maybe only for large file (your theory :). [1] Yeah, I know, it's easy to say... :-) Cheers, -- Julien Danjou // ᐰ <[email protected]> http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // I'm no superman.
signature.asc
Description: Digital signature
