Timo Sirainen schrieb:

On 23.3.2007, at 23.53, Robert Schetterer wrote:

...

...

+ Added idxview and logview utilities to examine Dovecot's index

files

.. RPM build errors: Installed (but unpackaged) file(s) found: /usr/lib/dovecot/idxview /usr/lib/dovecot/logview

i am not clear her , the spec worked through several versions before, did some paths changed?

No, new stuff was added. Don't know why rpm build has to fail if that happens though.. hm , i just try build 27 again, to get sure, stay tuned for results

-- Mit freundlichen Gruessen Best Regards

Robert Schetterer

https://www.schetterer.org Munich/Bavaria/Germany

Timo Sirainen wrote:

...

RPM build errors: Installed (but unpackaged) file(s) found: /usr/lib/dovecot/idxview /usr/lib/dovecot/logview

No, new stuff was added. Don't know why rpm build has to fail if that happens though..

This is normal -- the packager (Robert) needs to update his spec file to include these two new programs to the binary output RPM. This 'error' is on purpose, it's rpmbuild trying to help you notice changes that have been made.

-te

-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com

Robert Schetterer wrote:

quick grep shows idxview is complete new to 28

Read Timo's changelog, no need to grep:

"+ Added idxview and logview utilities to examine Dovecot's index files"

so now i have to think how to get out of that rpm warning

All you have to do is edit your dovecot.spec and *include* these two files. Don't overthink the situation. :)

While you're at it, pay attention to this Changelog entry:

"* Added "-example" part to doc/dovecot-sql-example.conf and doc/dovecot-ldap-example.conf. They are now also installed to $sysconfdir with "make install"."

You will also need to adjust your spec file as necessary to pull in these two new files which should be throwing errors in your RPM build process, just like the new log utilities did.

-te

-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com

Robert Schetterer schrieb:

Timo Sirainen schrieb:

...

http://dovecot.org/releases/dovecot-1.0.rc28.tar.gz http://dovecot.org/releases/dovecot-1.0.rc28.tar.gz.sig

Still a bit more fixes. My coding TODO list is again empty. Unless something special happens in the next few weeks, I'll still make rc29 with the documentation included and v1.0 will be released April 13.

• 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
• Added "-example" part to doc/dovecot-sql-example.conf and doc/dovecot-ldap-example.conf. They are now also installed to $sysconfdir with "make install".

• 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

• mbox: Using ~/ in the mail root directory caused a ~ directory to be created (instead of expanding it to home directory)
• auth cache: If unknown user was found from cache, we didn't properly return "unknown user" status, which could have caused problems in deliver.
• mbox: Fixed "UID inserted in the middle of mailbox" in some conditions with broken X-UID headers
• 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

Hi Timo, i just tried rebuild 28 to my normal spec got this errors

Conflicts: dovecot-snapshot Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/dovecot-1.0.rc28-build error: Installed (but unpackaged) file(s) found: /usr/lib/dovecot/idxview /usr/lib/dovecot/logview

RPM build errors: Installed (but unpackaged) file(s) found: /usr/lib/dovecot/idxview /usr/lib/dovecot/logview

i am not clear her , the spec worked through several versions before, did some paths changed?

Ok its solved

%{_prefix}/lib/%{pkg_name}/idxview %{_prefix}/lib/%{pkg_name}/logview

in the spec did the job

Mit freundlichen Gruessen Best Regards

Robert Schetterer

https://www.schetterer.org Munich/Bavaria/Germany

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Fri, 23 Mar 2007, Troy Engel wrote:

This is probably the best news ever. I just had one of my testers beat on this with ~4000 emails-at-once operations which have always timed out and caused us grief. While it still takes forever and a day to accomplish (I blame Thunderbird), it now at least chugs along and completes the ops with no user errors.

Yes, I think you are right. Did you checked, if Thunderbird even talks to Dovecot during the operation? In my tests when I moved >80'000 messages into Trash, Thunderbird needed about half an hour to update its internal data (meaning: removing all message headers from the internal cache file).

It copied to mails to Trash, then marked them deleted, then the connection timed out while Thunderbird updated it internal cache, then re-connected without a problem and exunged them. Overall, the process took eons, but without error.

Bye,

Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iQEVAwUBRgkXii9SORjhbDpvAQIo1wgAlb1vrTY45NvCdj6Lj9pDVoDospbptOPw iwGCZtQyteRNUws+jJXG/3jbMW83TBeNbmTv4TfnrYAjwhtiVFvcA91/m3AEewC+ wXsM9hVWRNY/Qo36CjVgis0oT9nlFrkIP3pG93o/5W5XrC4htlnc/XqogvabBtph NoYV1XUxwPOVmhKhyB53QnGYwLqAnPvLMOxOor6SBP3tgA8ZZRwibGLEf52SSQ71 FcISNQ9XU7wKTHGy8kh6TtrMCUs6AsaT0j1C7qQ3Y9ZepHGbN8K6YOxwNa2SbCKc 0siWKohkaNkem6pA4pzo7yNMDI0NEPNJyMc7d+CImz3HyH/EYqV1LA== =Q1ei -----END PGP SIGNATURE-----

On 3/29/07, Max A. sub@comtel-60.ru wrote:

...

Still a bit more fixes. My coding TODO list is again empty. Whether it is possible to add APOP and CRAM-MD5 in the checkpassword-module? Original qmail-popup is able APOP, and smtp-auth patch (http://www.fehcom.de/qmail/smtpauth.html) can use CRAM-MD5, accordingly, vckpw from vpopmail understands both these of a method. Very much would be desirable, that these two methods were in dovecot (in chackpassword-module).

I would like to see this, too. After digging through the code some, it seems that the major sticking point is that dovecot would prefer to do the CRAM-MD5 internally and therefore expects to have access to the password in plaintext and doesn't pass the timestamp on to checkpassword...

Any chance this behavior could be altered/updated in the future? It's made migration from existing mail system difficult as I don't want to give up the security of CRAM-MD5 even for the benefits of dovecot, and reworking authentication scheme is a no-go at this point.

Any help?

Thanks, Ben

Ben Schumacher wrote:

...

I would like to see this, too. After digging through the code some, it seems that the major sticking point is that dovecot would prefer to do the CRAM-MD5 internally and therefore expects to have access to the password in plaintext and doesn't pass the timestamp on to checkpassword...

There is no way to use CRAM-MD5 without having the password stored in plaintext locally; it is a design "feature" since the hash is calculated using a different server key every time.

vpopmail can store the password in plain-text.

On Wed, 2007-06-27 at 07:50 -0600, Ben Schumacher wrote:

This somewhat conflicts with dovecot's authentication system, which expects to have all the necessary authentication information internally and is not design (not willing?) to trust a checkpassword-style authentication mechanism to peform CRAM-MD5 authentication and therefore only offers PLAIN as an option to clients.

Internally Dovecot supports two methods:

1. verify plaintext password
2. lookup password in requested format

Checkpassword API doesn't fit into either of these. I could kludge a Dovecot-specific support for 2, but supporting an external "verify non-plaintext password" API would require changing the internal APIs in some way.

Also I don't think there's a standard way to tell the checkpassword script which auth method is being used? Are they all just hardcoded to one specific method or do other servers pass the method in environment or timestamp or something?