[Dovecot] 1.0.rc28 / v1.0 plans
I'll probably release 1.0.rc28 in a few days. Would be nice to get some testing for it first. http://dovecot.org/nightly/dovecot-latest.tar.gz contains pretty much what it's supposed to be.
I've now replied to all the mails I was planning on replying, excluding the few patches that are v1.1 material. If you think I forgot to reply to some mail, please resend it.
I think the documentation in Wiki is finally beginning to look pretty good. All the important things are done. The only things in my "would be nice TODO" list are:
- Add a new page about index files and their configuration. I'll probably do this before rc28.
- PasswordSchemes and Authentication/Mechanisms are pretty heavy reading. Could be made easier to understand. Possibly also create some mechanism-specific pages describing how to configure them in Dovecot and in clients.
- Design documents would also be nice, but not very useful for non-programmers and pretty big job to write them
I'm planning on adding the Wiki pages to doc/wiki/ in the tarball and changing:
- http://wiki.dovecot.org/* links to doc/wiki/*.txt in
dovecot-example.conf
- doc/variables.txt could be removed and links to it updated to doc/wiki/Variables.txt
- doc/auth-protocol.txt is also already in wiki. Maybe create doc/design/ and put the AuthProtocol.txt there and other design wiki pages there as well.
As for v1.0, it looks like there aren't many bug reports anymore about rc27. If there are as few for rc28, I'll release v1.0 in about a month. So unless something special happens, I'll fix only the simplest bugs after rc28 and leave the rest to v1.1/v1.0.1. Hmm. Looks like 13.4. is Friday. Perhaps that's a good day for a release. :)
Looks like I ended up adding a few more new features to rc28:
* deliver + userdb static: Verify the user's existence from passdb,
unless allow_all_users=yes
* dovecot --exec-mail: Log to configured log files instead of stderr
+ When copying/syncing a lot of mails, send "* OK Hang in there"
replies to client every 15 seconds so it doesn't just timeout the
connection.
+ Added idxview and logview utilities to examine Dovecot's index files
+ passdb passwd and shadow support blocking=yes setting now also
+ mbox: If mbox file changes unexpectedly while we're writing to it,
log an error.
+ deliver: Ignore -m "" parameter to make calling it easier.
+ deliver: Added new -n parameter to disable autocreating mailboxes.
It affects both -m parameter and Sieve plugin's fileinto action
- auth cache: If unknown user was found from cache, we didn't properly
return "unknown user" status, which could have caused problems in
deliver.
- Index view syncing fixes
- rc27 didn't compile with some non-GCC compilers
- vpopmail support didn't compile in rc27
- NFS check with chrooting broke home direcotry for the first login
- deliver: If user lookup returned "unknown user", it logged
"BUG: Unexpected input"
- convert plugin didn't convert INBOX
I've compiled for Solaris-10 with Sun's cc, and for Altlinux. Both installations are working fine.
Sergey.
Timo Sirainen wrote:
I'll probably release 1.0.rc28 in a few days. Would be nice to get some testing for it first. http://dovecot.org/nightly/dovecot-latest.tar.gz contains pretty much what it's supposed to be.
[skip...]
Timo Sirainen schrieb:
I'll probably release 1.0.rc28 in a few days. Would be nice to get some testing for it first. http://dovecot.org/nightly/dovecot-latest.tar.gz contains pretty much what it's supposed to be.
Are we now seeing prereleases to release candidates? Wow, that is really nasty. Just release rc28 when you think it's done and fix up the ends in rc29... don't make too many changes to the procedures. 8-)
Timo Sirainen wrote:
I'll probably release 1.0.rc28 in a few days. Would be nice to get some testing for it first. http://dovecot.org/nightly/dovecot-latest.tar.gz contains pretty much what it's supposed to be.
Downloaded and started testing -
- vpopmail support didn't compile in rc27
I can already confirm that this works again in 28-to-be...
FWIW, I think that the default dovecot-sample.conf should not have PAM support enabled by default (just comment it out). When I applied by local diffs to the new conf file, I missed out on that and had to immediately edit it out in order to bring up dovecot; not a big deal but the sample configuration should more or less work out of the box for an absolutely minimal configuration (and some limited definition of "work")...
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
On Fri, 2007-03-23 at 13:45 -0400, John Peacock wrote:
FWIW, I think that the default dovecot-sample.conf should not have PAM support enabled by default (just comment it out). When I applied by local diffs to the new conf file, I missed out on that and had to immediately edit it out in order to bring up dovecot; not a big deal but the sample configuration should more or less work out of the box for an absolutely minimal configuration (and some limited definition of "work")...
Many people think using PAM by default is the minimal configuration. :)
Anyway, I won't change this for v1.0 at least.
Timo Sirainen wrote:
Many people think using PAM by default is the minimal configuration. :)
But to run using PAM, dovecot has an external dependency, i.e.
http://wiki.dovecot.org/PasswordDatabase/PAM
which you don't provide as part of the tarball, though passwd support does work out of the box. That's is why I don't consider PAM to be "minimal". In any case, I just thought I'd mention it...
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Timo Sirainen wrote:
- deliver + userdb static: Verify the user's existence from passdb, unless allow_all_users=yes
- deliver: Ignore -m "" parameter to make calling it easier.
- deliver: Added new -n parameter to disable autocreating mailboxes. It affects both -m parameter and Sieve plugin's fileinto action
Is deliver supposed to work out of the box (not talking about sieve yet)? I have been testing it per the instructions here:
http://wiki.dovecot.org/LDA/Qmail
and with a message that already has the correct Return-Path: and Delivered-To: lines in the header already, the message is *not* delivered (anywhere, AFAICT), even though I get a:
deliver(vpopmail): Info: msgid=: saved mail to INBOX
message at the commandline. If I do it this way instead:
| /usr/local/libexec/dovecot/deliver -d $EXT@$USER
it works properly (i.e. it is delivered to the correct user). Is the message parsing part of deliver not functioning?
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
On Fri, 2007-03-23 at 17:03 -0400, John Peacock wrote:
Timo Sirainen wrote:
- deliver + userdb static: Verify the user's existence from passdb, unless allow_all_users=yes
- deliver: Ignore -m "" parameter to make calling it easier.
- deliver: Added new -n parameter to disable autocreating mailboxes. It affects both -m parameter and Sieve plugin's fileinto action
Is deliver supposed to work out of the box (not talking about sieve yet)? I have been testing it per the instructions here:
That describes a way to make deliver work with system users. I wasn't sure if Qmail could be set up another way, so I didn't change that. Updated it now.
and with a message that already has the correct Return-Path: and Delivered-To: lines in the header already, the message is *not* delivered (anywhere, AFAICT), even though I get a:
deliver(vpopmail): Info: msgid=: saved mail to INBOX
message at the commandline. If I do it this way instead:
I suppose it went to vpopmail user's INBOX (/var/mail/vpopmail?)
| /usr/local/libexec/dovecot/deliver -d $EXT@$USER
it works properly (i.e. it is delivered to the correct user). Is the message parsing part of deliver not functioning?
-d makes it work with virtual users. I'm not sure why it didn't show Message ID in the log line. Did your message have it? Or did preline add an empty line in the middle of the headers for some reason?
Timo Sirainen wrote:
That describes a way to make deliver work with system users. I wasn't sure if Qmail could be set up another way, so I didn't change that. Updated it now.
I'm actually using vpopmail for virtual users, so I'm just as happy to force the issue with '-d', but I wanted to make you aware that it isn't apparently able to parse the message.
I suppose it went to vpopmail user's INBOX (/var/mail/vpopmail?)
Nope, nothing there either. I can do a full scan of the drive, but I suspect it is in the ether... ;-)
-d makes it work with virtual users. I'm not sure why it didn't show Message ID in the log line. Did your message have it? Or did preline add an empty line in the middle of the headers for some reason?
This is the entire message:
================================================= Return-Path: postmaster@cowley.org Delivered To: jpeacock@rowman.com Received: (qmail 10024 invoked from network); 23 Mar 2007 16:30:05 -0400 Received: from unknown (HELO jpeacock.internal) (192.168.0.11) by entilza.rlpgbooks.com with SMTP; 23 Mar 2007 16:30:05 -0400 Date: Fri, 23 Mar 2007 16:27:06 -0400 To: jpeacock@rowman.com From: postmaster@cowley.org Subject: test Fri, 23 Mar 2007 16:27:06 -0400 X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks
This is a test mailing
=================================================
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
On Fri, 2007-03-23 at 17:21 -0400, John Peacock wrote:
Timo Sirainen wrote:
That describes a way to make deliver work with system users. I wasn't sure if Qmail could be set up another way, so I didn't change that. Updated it now.
I'm actually using vpopmail for virtual users, so I'm just as happy to force the issue with '-d', but I wanted to make you aware that it isn't apparently able to parse the message.
I don't understand why you think it's not able to parse the message. What do you think it should be parsing from it?
I suppose it went to vpopmail user's INBOX (/var/mail/vpopmail?)
Nope, nothing there either. I can do a full scan of the drive, but I suspect it is in the ether... ;-)
It logged that it was saved, so it did save it somewhere. It used "vpopmail" as the username for saving, so it most likely saved it wherever your mail_location points, but:
- %h and ~/ expands to whatever $HOME environment contained when delivered was started
- %n and %u expands to vpopmail
- %d expands to empty
Based on that logic I think you should be able to find the message.
-d makes it work with virtual users. I'm not sure why it didn't show Message ID in the log line. Did your message have it? Or did preline add an empty line in the middle of the headers for some reason?
This is the entire message:
OK, so it didn't have Message-ID header so everything seemed to work correctly. :)
Timo Sirainen wrote:
I don't understand why you think it's not able to parse the message. What do you think it should be parsing from it?
Doesn't it look for the headers and pull the Delivered-To: in order to determine where the message should be, you know, delivered to? I thought that was the whole point of adding the preline to the pipe. If I misunderstood the nature of the software, I'm sorry. Reading between the lines, it appears that deliver merely drops the mail into the executing user's mail folder (which in hindsight seems obvious) unless -d is passed to change that.
Never mind...
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
On 23/03/2007 21:21, John Peacock wrote:
This is the entire message:
================================================= Return-Path: postmaster@cowley.org Delivered To: jpeacock@rowman.com
Is this really it? There's no - in this header.
Cheers,
John.
participants (5)
-
John Peacock
-
John Robinson
-
Matthias Andree
-
sergey ivanov
-
Timo Sirainen