August 2004 - dovecot

[Dovecot] [PATCH] move highest_fd calculations to ioloop-select.c
by Andrey Panin 25 Aug '04

25 Aug '04

Hello, ioloop->highest_fd is used by ioloop-select.c only, so its handling can be moved out of generic ioloop code. Attached patch (agains -test35) does exactly this. Please consider applying. Best regards. -- Andrey Panin | Linux and UNIX system administrator pazke(a)donpac.ru | PGP key: wwwkeys.pgp.net

1 0

[Dovecot] Re: ssl_ca_file
by jan＠weitan.org 24 Aug '04

24 Aug '04

> I am using 0.99.10.7-1 on Debian, and I'm having some trouble with SSL. I > purchased a certificate from Thawte and I can't figure out how to tell > dovecot about the CA cert. Adding ssl_ca_file to my configuration produces > "Unknown setting: ssl_ca_file" on dovecot startup. > > Postfix has a smtpd_tls_CAfile argument and that part is working fine. > > Is this a Debian-specific problem or is ssl_ca_file newer than 0.99.10.7? I guess ssl_ca_file is newer than 0.99. I have the same settings (debian -sarge) and i am using ssl_cert_file and ssl_key_file to get the certificate working. I checked ssl_ca_file and i got the same error, nevertheless it's in the recent dovecot.conf file from 1.x.testing, therefore it should be newer than 0.99.

1 0

[Dovecot] Unknown setting: ssl_ca_file
by Jacob Elder 24 Aug '04

24 Aug '04

I am using 0.99.10.7-1 on Debian, and I'm having some trouble with SSL. I purchased a certificate from Thawte and I can't figure out how to tell dovecot about the CA cert. Adding ssl_ca_file to my configuration produces "Unknown setting: ssl_ca_file" on dovecot startup. Postfix has a smtpd_tls_CAfile argument and that part is working fine. Is this a Debian-specific problem or is ssl_ca_file newer than 0.99.10.7? -- Jacob Elder

1 0

[Dovecot] Underquoted macros in aclocal (was: MIME structure intermittently lost)
by Kenneth Porter 24 Aug '04

24 Aug '04

--On Monday, August 23, 2004 6:50 PM +0900 Jim Tittsler <jt(a)OnJapan.net> wrote: > You can get dovecot-0.99.10.9-1.FC3.2.src.rpm from the > Fedora Core development tree. (Seems to be working well for us.) I just built this and it has a lot of complaints about underquoted macros in aclocal. Red Hat refers developers to this reference: <http://sources.redhat.com/automake/automake.html#Extending%20aclocal>

1 0

[Dovecot] 1.0-test35
by Timo Sirainen 23 Aug '04

23 Aug '04

http://dovecot.org/test/ Test33/34 weren't usable for very long. Test35 fixes several problems in them.

1 0

[Dovecot] Newbie: dovecot not running.
by Simon Waters 23 Aug '04

23 Aug '04

Okay, sure it must be trivial.... I have old Redhat box, want a quick and dirty IMAP server, thought good time to try out dovecot (I'd rather it had Debian on too ;). Downloaded and compiled from source - no options to configure. Auth data is in /etc/passwd and /etc/shadow (as well as NIS). vi /usr/local/etc/dovecot.conf as expected. Disable ssl in conf. Basically email is in mbox format in /var/spool/mail/%u Should go somewhere ~%u/mail is fine, as would be ~%u/Mail (I don't care at the moment). created a user "dovecot..." to run as and edited conf file. If I run /usr/local/sbin/dovecot it terminates without errors, the fork is completing I think, and the main program returns as expect. Running imap-auth from xinetd gets me a greeting banner, but then the connection is closed. Trying to run "imap" directly just dies in a blizarrd of "dot locking" errors and the like, where it seems to ignore the locking directives (should I set an env or some such?), but I think that it is basically running (it creates indexes in ~/mail/...mumble) but complains about the dotlocking, and then spews an internal error (which it claims is logged to server log?). I'm off to try auth_verbose, but any tips or hints appreciated. I'm assuming /usr/local/sbin/dovecot is what was called "master" given it is in the master src directory. Simon

1 1

[Dovecot] 1.0-test33
by Timo Sirainen 23 Aug '04

23 Aug '04

http://dovecot.org/test/ I think I found and fixed the last bug that was giving me problems. Now that Dovecot has been successfully working for a few hours, time for a new test release :) This release has major changes, so there might still be some bugs left. Be careful. If you're upgrading from previous 1.0-test release, you must delete all existing dovecot.index.log files or you will get errors. So, the changes are: - All network sockets are nonblocking now and all the waiting is done in a single event loop. This required tons of changes all over the code. - Transaction log file doesn't use locks for reading anymore - Some mbox fixes - search text was broken

2 2

[Dovecot] MIME structure intermittently lost
by Kenneth Porter 23 Aug '04

23 Aug '04

I'm using Dovecot-0.99.10.5-0.FC2 on Fedora Core 2 on the server, and Mulberry 3.1.6 over Win2kSP4 on the client. Intermittently messages with multiple parts show up as a single text part. I'm not sure if it's Mulberry or Dovecot. I just turned on IMAP logging and restarted Mulberry and a message with two text/plain parts that wasn't showing the 2nd part is now displaying it correctly. I hate heisenbugs!

3 3

RE: [Dovecot] Unusual behaviour
by Mark Lidstone 23 Aug '04

23 Aug '04

Ahh! Now you've explained it, it makes a lot of sense. Many thanks, Mark Lidstone IT and Network Support Administrator BMT SeaTech Ltd Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton. SO14 3TJ. UK Tel: +44 (0)23 8063 5122 Fax: +44 (0)23 8063 5144 E-Mail: mailto:mark.lidstone@bmtseatech.co.uk Website: www.bmtseatech.co.uk ======================================================================== == Confidentiality Notice and Disclaimer: The contents of this e-mail and any attachments are intended only for the use of the e-mail addressee(s) shown. If you are not that person, or one of those persons, you are not allowed to take any action based upon it or to copy it, forward, distribute or disclose the contents of it and you should please delete it from your system. BMT SeaTech Limited does not accept liability for any errors or omissions in the context of this e-mail or its attachments which arise as a result of Internet transmission, nor accept liability for statements which are those of the author and not clearly made on behalf of BMT SeaTech Limited. ======================================================================== == -----Original Message----- From: Timo Sirainen [mailto:tss@iki.fi] Sent: 23 August 2004 09:07 To: Mark Lidstone Cc: dovecot(a)dovecot.org Subject: RE: [Dovecot] Unusual behaviour On Mon, 2004-08-23 at 08:48 +0100, Mark Lidstone wrote: > Is it supposed to give the current time and date in the error message. > I've no problem with it giving an "internal error" message to the > client, but I am a little confused about the time being in there. > That's all I'm asking about. Client should never see any "real" error messages to make sure no extra information about the system gets leaked. So any time something unexpected happens, Dovecot gives the "internal error" message to user while writing the real error to log file. The timestamp is there to help sysadmin find the real error message from log files when user gives a copy&pasted internal error message. Instead of timestamp I guess there could be also some unique identifier which could be grepped from logs but I think timestamp is better. And about the original problem of giving "internal error" when Dovecot process didn't have access to some maildir.. Maybe it could have replied "Permission denied" to client in that case. It already does in several cases, but I guess the problem here was that it was trying to create the missing dirs but couldn't. I'll look over all these permission issues properly when creating real shared folder support.

1 0

RE: [Dovecot] Unusual behaviour
by Mark Lidstone 23 Aug '04

23 Aug '04

OK, last try. Is it supposed to give the current time and date in the error message. I've no problem with it giving an "internal error" message to the client, but I am a little confused about the time being in there. That's all I'm asking about. Mark Lidstone IT and Network Support Administrator BMT SeaTech Ltd Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton. SO14 3TJ. UK Tel: +44 (0)23 8063 5122 Fax: +44 (0)23 8063 5144 E-Mail: mailto:mark.lidstone@bmtseatech.co.uk Website: www.bmtseatech.co.uk ======================================================================== == Confidentiality Notice and Disclaimer: The contents of this e-mail and any attachments are intended only for the use of the e-mail addressee(s) shown. If you are not that person, or one of those persons, you are not allowed to take any action based upon it or to copy it, forward, distribute or disclose the contents of it and you should please delete it from your system. BMT SeaTech Limited does not accept liability for any errors or omissions in the context of this e-mail or its attachments which arise as a result of Internet transmission, nor accept liability for statements which are those of the author and not clearly made on behalf of BMT SeaTech Limited. ======================================================================== == -----Original Message----- From: Andrew Boothman [mailto:andrew@mux.org.uk] Sent: 20 August 2004 18:09 To: Dovecot list Subject: Re: [Dovecot] Unusual behaviour Mark Lidstone wrote: > I thought that Dovecot was supposed to handle that kind of thing? > Reading from the website: > > "Any kind of crash is considered as bug and will be fixed - even if > it happens only by deliberately poking the index files." > > I've done it in the past by just creating the bare folders - they > appear in the IMAP folder list then when they're used Dovecot seems to > create the sub folders anyway. > > The issue I'm asking about here is, should the error message say > "Internal Error [date time]" rather than something useful? Did Dovecot actually crash? Did it log a more sensible error message to syslog? I think Dovecot quite often reports an "internal error" to the client but then writes a more sensible error message to syslog. Which is probably no bad thing as you may well not want clients to see detailed error messages - there's nothing they can do about it anyway. Andrew

2 1