http://dovecot.org/releases/dovecot-1.0.rc30.tar.gz http://dovecot.org/releases/dovecot-1.0.rc30.tar.gz.sig
So, this is it. Unless you can find a new and important bug within a week, this release is the same as v1.0. I'll only update the version number and NEWS file.
Changes since rc29:
* PAM: Lowercase the PAM service name when calling with "args = *".
Linux PAM did this internally already, but at least BSD didn't.
If your PAM file used to be in /etc/pam.d/IMAP or POP3 file you'll
need to lowercase it now.
+ Send list of CA names to client when using
ssl_verify_client_cert=yes.
- IMAP: If message body started with line feed, it wasn't counted
in BODY and BODYSTRUCTURE replies' line count field.
- deliver didn't load plugins before chrooting<quote who="Timo Sirainen">
http://dovecot.org/releases/dovecot-1.0.rc30.tar.gz http://dovecot.org/releases/dovecot-1.0.rc30.tar.gz.sig
So, this is it. Unless you can find a new and important bug within a week, this release is the same as v1.0. I'll only update the version number and NEWS file.
Yeah!!!!
-- Kind Regards,
Gavin Henry. Managing Director.
T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry@suretecsystems.com
Open Source. Open Solutions(tm).
Timo Sirainen wrote:
Changes since rc29:
- PAM: Lowercase the PAM service name when calling with "args = *". Linux PAM did this internally already, but at least BSD didn't. If your PAM file used to be in /etc/pam.d/IMAP or POP3 file you'll need to lowercase it now.
- Send list of CA names to client when using ssl_verify_client_cert=yes.
- IMAP: If message body started with line feed, it wasn't counted in BODY and BODYSTRUCTURE replies' line count field.
- deliver didn't load plugins before chrooting
Timo, in rc30, deliver is not creating user directories properly. It looks like it goes straight to creating the maildir, without creating the home directory first if it doesn't exist. It also seems to be doing this before chrooting, as the following errors occur even after manually creating the home directory (with proper permissions):
Apr 6 10:26:23 node7 postfix/qmgr[21815]: D2242D39A5: from=<>, size=556, nrcpt=1 (queue active) Apr 6 10:26:23 node7 deliver(user@example.com): mkdir(/cur) failed: Permission denied Apr 6 10:26:23 node7 deliver(user@example.com): mkdir(/cur) failed: Permission denied Apr 6 10:26:23 node7 postfix/pipe[26800]: D2242D39A5: to=<user@example.com>, relay=dovecot, delay=232, delays=232/0/0/0.01, dsn=4.3.0, status=deferred (temporary failure)
Also, the convert plugin seems to assume the home dir exists when it tries to create it's lock file. However, manually creating the home dir does allow convert to continue successfully.
Apr 6 10:42:15 node7 dovecot: POP3(user@example.com): open(/var/mailstore/af/4f/510590/.temp.node7.neonova.net.26842.6454b11667006c6f) failed: No such file or directory Apr 6 10:42:15 node7 dovecot: child 26842 (pop3) returned error 89
The 510590 directory did not exist in both of these examples, and I'm using %h as the mail location (but adding a subdir to that didn't make a difference).
On 6.4.2007, at 17.55, Justin McAleer wrote:
Timo, in rc30, deliver is not creating user directories properly.
It looks like it goes straight to creating the maildir, without
creating the home directory first if it doesn't exist. It also
seems to be doing this before chrooting, as the following errors
occur even after manually creating the home directory (with proper
permissions):Apr 6 10:26:23 node7 postfix/qmgr[21815]: D2242D39A5: from=<>,
size=556, nrcpt=1 (queue active) Apr 6 10:26:23 node7 deliver(user@example.com): mkdir(/cur)
failed: Permission denied
Looks like deliver doesn't chroot at all if you did chrooting by
using /./ in the home directory. Since deliver doesn't work that
great chrooted anyway (can't send bounces by running sendmail), maybe
this is a good thing.
Also, the convert plugin seems to assume the home dir exists when
it tries to create it's lock file. However, manually creating the
home dir does allow convert to continue successfully.
This happens only if it the source storage creation succeeds. So
you're moving user's home directory also?
Anyway, I don't think I'll be changing any of this code in v1.0
branch. But the subscription name changing .. yea, I'll fix that for
v1.0. Guess I'll still have to put out rc31 :(
Timo Sirainen wrote:
On 6.4.2007, at 17.55, Justin McAleer wrote:
Timo, in rc30, deliver is not creating user directories properly. It looks like it goes straight to creating the maildir, without creating the home directory first if it doesn't exist. It also seems to be doing this before chrooting, as the following errors occur even after manually creating the home directory (with proper permissions):
Apr 6 10:26:23 node7 postfix/qmgr[21815]: D2242D39A5: from=<>, size=556, nrcpt=1 (queue active) Apr 6 10:26:23 node7 deliver(user@example.com): mkdir(/cur) failed: Permission denied
Looks like deliver doesn't chroot at all if you did chrooting by using /./ in the home directory. Since deliver doesn't work that great chrooted anyway (can't send bounces by running sendmail), maybe this is a good thing.
For the record, I was not using /./ in the home directory. For this user the home directory (and maildir) is /var/mailstore/af/4f/510590. While that may be a good thing, that deliver fails to create a user's maildir is a big problem for me, as I will have to actively provision maildirs for all new accounts before they can receive mail (or be converted)... so for the record, can I no longer count on dovecot to create user directories that don't exist?
Also, the convert plugin seems to assume the home dir exists when it tries to create it's lock file. However, manually creating the home dir does allow convert to continue successfully.
This happens only if it the source storage creation succeeds. So you're moving user's home directory also?
All I'm dealing with here is mail. I'm converting from CommuniGate mailboxes to dovecot, so the whole concept of a home directory is just a technicality. In fact, I was initially just setting users' home to '' and using the mail_location setting to generate the path. The only reason I went back to setting home is because convert seems to create it's lock file in the home dir (so lock creation was failing trying to open /.temp...). Here is what I'm feeding to convert:
convert_mail = mbox:/var/mailstore/%d/%1n.sub/%1.1n.sub/%n.macnt:INBOX=/var/mailstore/%d/%1n.sub/%1.1n.sub/%n.macnt/INBOX.mbox
And an example of the user's home/maildir:
/var/mailstore/af/4f/510590 mail_location = maildir:%h:INDEX=/var/indexes/%2Mi/%2.2Mi/%i
The index location here would be /var/indexes/af/4f/510590 (local disk).
One of the source hacks I've made for the CommuniGate format was setting a mask of *.mbox rather than just * when calling the mail_storage_mailbox_list_init functions... I didn't think that could cause a problem like this though. I also strip off the .mbox extension, and any occurance of .folder in the dest_name string in mailbox_name_convert(). All of that works perfectly so far in my testing, though, as long as the user's home directory already exists :)
Anyway, I don't think I'll be changing any of this code in v1.0 branch. But the subscription name changing .. yea, I'll fix that for v1.0. Guess I'll still have to put out rc31 :(
-- Justin McAleer Director of Development Neonova Network Services
On 6.4.2007, at 21.14, Justin McAleer wrote:
Timo Sirainen wrote:
On 6.4.2007, at 17.55, Justin McAleer wrote:
Timo, in rc30, deliver is not creating user directories properly.
It looks like it goes straight to creating the maildir, without
creating the home directory first if it doesn't exist. It also
seems to be doing this before chrooting, as the following errors
occur even after manually creating the home directory (with
proper permissions):Apr 6 10:26:23 node7 postfix/qmgr[21815]: D2242D39A5: from=<>,
size=556, nrcpt=1 (queue active) Apr 6 10:26:23 node7 deliver(user@example.com): mkdir(/cur)
failed: Permission deniedLooks like deliver doesn't chroot at all if you did chrooting by
using /./ in the home directory. Since deliver doesn't work that
great chrooted anyway (can't send bounces by running sendmail),
maybe this is a good thing.For the record, I was not using /./ in the home directory. For this
user the home directory (and maildir) is /var/mailstore/af/4f/ 510590. While that may be a good thing, that deliver fails to
create a user's maildir is a big problem for me, as I will have to
actively provision maildirs for all new accounts before they can
receive mail (or be converted)... so for the record, can I no
longer count on dovecot to create user directories that don't exist?
Umm. So are you even trying to use the chrooting? Deliver doesn't try
to do that by default. So if it's trying to create /cur directory, it
sees the mail directory as /.
Also, the convert plugin seems to assume the home dir exists when
it tries to create it's lock file. However, manually creating the
home dir does allow convert to continue successfully.This happens only if it the source storage creation succeeds. So
you're moving user's home directory also?All I'm dealing with here is mail. I'm converting from CommuniGate
mailboxes to dovecot, so the whole concept of a home directory is
just a technicality. In fact, I was initially just setting users'
home to '' and using the mail_location setting to generate the
path. The only reason I went back to setting home is because
convert seems to create it's lock file in the home dir (so lock
creation was failing trying to open /.temp...). Here is what I'm
feeding to convert:
Yea, it does. Maybe you could set the home directory to be the
CommuniGate's directory? In any case I don't really like the idea of
convert plugin creating home directory.
An alternative is for you to create the home directory yourself
before Dovecot runs: http://wiki.dovecot.org/PostLoginScripting
Timo Sirainen wrote:
http://dovecot.org/releases/dovecot-1.0.rc30.tar.gz http://dovecot.org/releases/dovecot-1.0.rc30.tar.gz.sig
So, this is it. Unless you can find a new and important bug within a week, this release is the same as v1.0. I'll only update the version number and NEWS file.
Changes since rc29:
- PAM: Lowercase the PAM service name when calling with "args = *". Linux PAM did this internally already, but at least BSD didn't. If your PAM file used to be in /etc/pam.d/IMAP or POP3 file you'll need to lowercase it now.
- Send list of CA names to client when using ssl_verify_client_cert=yes.
- IMAP: If message body started with line feed, it wasn't counted in BODY and BODYSTRUCTURE replies' line count field.
- deliver didn't load plugins before chrooting
One other thing about the convert plugin, sorry. Unless I'm mistaken, the mailbox_list_copy_subscriptions function should call mailbox_name_convert before adding the new folders to the subscriptions file. That's not being done currently, so if any renaming takes place the user gets subscribed to non-existant or even invalid folders. I simply did this, though it is some code duplication:
228a242
const char *dest_name;
234c248,250 < if (mail_storage_set_subscribed(dest_storage, list->name,
dest_name = mailbox_name_convert(dest_storage,
source_storage,
list->name);> if (mail_storage_set_subscribed(dest_storage, dest_name,
On April 6, 2007 12:45:07 PM +0300 Timo Sirainen <tss@iki.fi> wrote:
http://dovecot.org/releases/dovecot-1.0.rc30.tar.gz http://dovecot.org/releases/dovecot-1.0.rc30.tar.gz.sig
So, this is it. Unless you can find a new and important bug within a week, this release is the same as v1.0. I'll only update the version number and NEWS file.
Yay! Another really-real-this-time release candidate! ;-)
participants (5)
-
Frank Cusack
-
Gavin Henry
-
Johnny Chadda
-
Justin McAleer
-
Timo Sirainen