From cras@irccrew.org  Tue Jul 23 19:39:23 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 23 Jul 2002 19:39:23 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 434B423848
	for <dovecot@procontrol.fi>; Tue, 23 Jul 2002 19:39:23 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 175FA4C0A0; Tue, 23 Jul 2002 19:39:23 +0300 (EEST)
Date: Tue, 23 Jul 2002 19:39:23 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] first test mail
Message-ID: <20020723193923.J22431@irccrew.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 1
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-IMAPbase: 1096038620 0000010517
X-UID: 1                                                  
Status: O

lets see if it works


From cras@irccrew.org  Mon Jul 29 02:17:12 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 29 Jul 2002 02:17:12 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 8D21723848
	for <dovecot@procontrol.fi>; Mon, 29 Jul 2002 02:17:12 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 8BAD24C0A0; Mon, 29 Jul 2002 02:17:11 +0300 (EEST)
Date: Mon, 29 Jul 2002 02:17:11 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Dovecot 0.93 released
Message-ID: <20020729021711.W22431@irccrew.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 2
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 2                                                  
Status: O

First alpha quality release, everything critical is now implemented. From
now on it's mostly stabilization and optimization. Features that can't break
existing code could still be added, especially SSL and authentication stuff.


From cras@irccrew.org  Wed Jul 31 22:48:41 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 31 Jul 2002 22:48:41 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id F141123829
	for <dovecot@procontrol.fi>; Wed, 31 Jul 2002 22:48:40 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 42ED44C0A0; Wed, 31 Jul 2002 22:48:40 +0300 (EEST)
Date: Wed, 31 Jul 2002 22:48:39 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] v0.95 released
Message-ID: <20020731224839.H22431@irccrew.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 3
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 3                                                  
Status: O

v0.95 2002-07-31  Timo Sirainen <tss@iki.fi>

	+ Initial SSL support using GNU TLS, tested with v0.5.1.
	  TLS support is still missing.
	+ Digest-MD5 authentication method
	+ passwd-file authentication backend
	+ Code cleanups
	- Found several bugs from mempool and ioloop code, now we should
	  be stable? :)
	- A few corrections for long header field handling


From return@trafficmagnet.com  Mon Aug  5 19:26:52 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 05 Aug 2002 19:26:52 +0300 (EEST)
Return-Path: <return@trafficmagnet.com>
Delivered-To: dovecot@procontrol.fi
Received: from ns5.trafficmagnet.net (unknown [211.157.101.52])
	by danu.procontrol.fi (Postfix) with ESMTP id 48C2C23831
	for <dovecot@procontrol.fi>; Mon,  5 Aug 2002 19:26:51 +0300 (EEST)
Received: from 181-Dispatcher ([211.101.236.181])
	by ns5.trafficmagnet.net (8.11.6/8.11.6) with SMTP id g765MXt31378
	for <dovecot@procontrol.fi>; Tue, 6 Aug 2002 00:22:34 -0500
Message-Id: <200208060522.g765MXt31378@ns5.trafficmagnet.net>
From: Sarah Williams <return@trafficmagnet.com>
To: "dovecot@procontrol.fi" <dovecot@procontrol.fi>
Subject: [dovecot] DOVECOT.PROCONTROL.FI
Date: Tue, 6 Aug 2002 0:29:18 +0800
X-Mailer: CSMTPConnection v2.17
MIME-Version: 1.0
Content-Type: multipart/related; boundary="956bff02-8aec-485e-a58c-40fda617ecbe"
Content-Transfer-Encoding: quoted-printable
Reply-To: Sarah Williams <Sarah_williams@trafficmagnet.com>
X-archive-position: 4
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: return@trafficmagnet.com
Precedence: bulk
X-list: dovecot
X-UID: 4                                                  
Status: O
Content-Length: 2421

This is a multi-part message in MIME format
--956bff02-8aec-485e-a58c-40fda617ecbe
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<!-- Ap --> 
<TITLE></TITLE>
<STYLE TYPE=3D"text/css">
<!--
TD { font-family: verdana, arial, helvetica; font-size: 11px; color: #000000 =
}
-->
</STYLE>
</HEAD>
<BODY BGCOLOR=3D"#FFFFFF">
<TABLE WIDTH=3D"600" BORDER=3D"0" CELLSPACING=3D"0" CELLPADDING=3D"0">
<TR>
	<TD>Hi<BR>
	<BR>
	I visited <A HREF=3D=
"http://www.trafficmagnet.com/signup/index.html">DOVECOT.PROCONTROL.FI</A>, =
and 
	noticed that you're not listed on some search engines! I think we can offer 
=

	you a service which can help you increase traffic and the number of visitors =

	to your website.<BR>
	<BR>
	I would like to introduce you to <A HREF=3D=
"http://www.trafficmagnet.com/signup/index.html">TrafficMagnet.com</A>. We =
offer a unique technology 
	that will submit your website to over 300,000 search engines and directories =

	every month.<BR>
	<BR> 
	<TABLE WIDTH=3D"398" BORDER=3D"0" CELLSPACING=3D"0" CELLPADDING=3D"0" =
ALIGN=3D"center">
	<TR>
		<TD><A HREF=3D"http://www.trafficmagnet.com/signup/index.html"><IMG SRC=3D=
"http://www.trafficmagnet.com/img/img_tm.gif" WIDTH=3D"137" HEIGHT=3D"136" =
BORDER=3D"0"></A>&nbsp;</TD>
		<TD><A HREF=3D"http://www.trafficmagnet.com/signup/index.html"><IMG SRC=3D=
"http://image10.trafficmagnet.net/imagenew/SMART173/002/337/aso.jpg" WIDTH=3D=
"197" HEIGHT=3D"141" BORDER=3D"1"></A></TD>
		<TD VALIGN=3D"bottom"><A HREF=3D=
"http://www.trafficmagnet.com/signup/index.html"><IMG SRC=3D=
"http://www.trafficmagnet.com/img/img_signup.gif" WIDTH=3D"62" HEIGHT=3D"136" =
BORDER=3D"0"></A></TD>
	</TR>
	</TABLE>
	<BR>
	You'll be surprised by the low cost, and by how effective this website =
promotion 
	method can be. <BR>
	<BR>
	To find out more about TrafficMagnet and the cost for submitting your =
website 
	to over 300,000 search engines and directories, visit <A HREF=3D=
"http://www.trafficmagnet.com/signup/index.html">www.TrafficMagnet.com</A>. 
	<BR>
	<BR>
	I would love to hear from you. <BR>
	<BR><BR>
	Best Regards,<BR><BR>
	Sarah Williams <BR>
	Sales and Marketing <BR>
	E-mail: sarah_williams@trafficmagnet.com <BR>
	<A HREF=3D=
"http://www.trafficmagnet.com/signup/index.html">http://www.TrafficMagnet.com=
</A> 
    </TD>
</TR>
</TABLE>
</BODY>
</HTML>
--956bff02-8aec-485e-a58c-40fda617ecbe--

From reply@seekercenter.net  Tue Aug  6 13:01:17 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 06 Aug 2002 13:01:17 +0300 (EEST)
Return-Path: <reply@seekercenter.net>
Delivered-To: dovecot@procontrol.fi
Received: from XXXXXX (unknown [211.101.236.162])
	by danu.procontrol.fi (Postfix) with ESMTP id C6D0823832
	for <dovecot@procontrol.fi>; Tue,  6 Aug 2002 13:01:15 +0300 (EEST)
From: "Vanessa Lintner" <reply@seekercenter.net>
Subject: [dovecot] I have visited DOVECOT.PROCONTROL.FI and noticed that ...
To: dovecot@procontrol.fi
Content-Type: text/html;
Reply-To: "Vanessa Lintner" <vanessa@seekercenter.net>
Date: Tue, 6 Aug 2002 18:05:01 +0800
X-Priority: 3
X-Library: Business Promotion
Message-Id: <20020806100115.C6D0823832@danu.procontrol.fi>
X-archive-position: 5
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: reply@seekercenter.net
Precedence: bulk
X-list: dovecot
X-UID: 5                                                  
Status: O
Content-Length: 5137

<html>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">
.stbtm {
	BACKGROUND-COLOR:#cecbde; BORDER-BOTTOM: #665b8e 1px solid; BORDER-LEFT: #ffffff 1px solid; BORDER-RIGHT: #665b8e 1px solid; BORDER-TOP: #ffffff 1px solid; COLOR: #000000; FONT-SIZE: 12pt; HEIGHT: 26px; WIDTH: 120px; clip:        rect(   )}
.stedit {
	 background-color:#484C68; white-space: nowrap; border: #000000; BORDER-BOTTOM: #ffffff 1px solid; BORDER-LEFT: #ffffff 1px solid; BORDER-RIGHT: #ffffff 1px solid; BORDER-TOP: #ffffff 1px solid; FONT-SIZE: 10pt; color: #CCCCCC; font-weight: bold}

</style>
</head>
<BODY leftMargin=0 onload="" topMargin=0 marginheight="0" marginwidth="0" bgcolor="#FFFFFF">
  
<table width="778" border="0" cellspacing="0" cellpadding="0">
  <tr>
      
    <td height="233" width="21">&nbsp;</td>
      
    <td height="233" colspan="3" width="757"> 
      <table width="621" border="0" cellspacing="0" cellpadding="0" align="left">
        <tr> 
            
          <td width="373" height="64"> 
            <table width="373" border="0" cellspacing="0" cellpadding="0" background="http://image.seekercenter.net/letter_bg.jpg" height="327">
                <tr> 
                  
                <td><p> 
                  <font face=Arial size=2>
                  </font> <font face=Arial size=2><font face="Verdana, Arial, Helvetica, sans-serif" color="#000000">Hello,<br>
                  <br>
                  I have visited <a href='http://dovecot.procontrol.fi'>dovecot.procontrol.fi</a> and noticed that your website is not listed on some search engines.
                  I am sure that through our service the number of people who visit your website will definitely increase. <a target=_blank href="http://www.seekercenter.net/index.php">SeekerCenter</a> 
                  is a unique technology that instantly submits your website 
                  to over 500,000 search engines and directories  
                  -- a really low-cost and effective way to advertise your site. 
                  For more details please go to <a target=_blank href="http://www.seekercenter.net/index.php">SeekerCenter.net</a>.<br>
                  <br>
                  Give your website maximum exposure today!<BR>
                  Looking forward to hearing from you.<br>
                  <BR>
                  <table border=0 width=100%><TR><TD width=50%>
                  <font face="Verdana, Arial, Helvetica, sans-serif" size=2 color="#000000">Best 
                  Regards,<br>
                  Vanessa Lintner<br>
                  Sales &amp; Marketing <br>
                  <a target=_blank href="http://www.seekercenter.net/index.php">www.SeekerCenter.net</a></font></font></font>
                  <TD><td width=50%>
                   <div align="center" valign=middle>
                   <form target=_blank action=http://www.seekercenter.net method=POST>
                          <input type="submit" name="Submit" value="Signup Now!!!" class="stbtm">
                   </form>
                        </div>
                  </TD>
                  </TR>
                  </table>
                  </td>
                </tr>
              </table>
            </td>
            
          <td width="242" height="64" valign="bottom"> 
            <table width="257" border="0" cellspacing="0" cellpadding="0">
              
                <tr>
                  <td colspan="3" height="2"></td>
                </tr>
                <tr> 
                  <td colspan="3" height="3"> 
                    
                  <p><img src="http://image.seekercenter.net/letter_top01.jpg" width="326" height="15"></p>
                    </td>
                </tr>
                <tr> 
                  <td colspan="3"><img src="http://image.seekercenter.net/letter_right01.jpg" width="31" height="185"><A target=_blank Href ="http://dovecot.procontrol.fi"><IMG Src =http://image4.seekercenter.net/image1622/6/37/img228.jpg Border=0 width="256" height="184"></A><img src="http://image.seekercenter.net/letter_left01.jpg" width="14" height="185"></td>
                </tr>
                
              <tr> 
                <td colspan="3" height="80" background="http://image.seekercenter.net/letter_bottom01.jpg"> 
                  <table width="326" border="0" cellspacing="0" cellpadding="0" height="80">
                    <tr>
                      <td width="36" height="43">&nbsp;</td>
                      <td width="157" height="43">&nbsp;</td>
                      <td width="134" height="43">&nbsp;</td>
                    </tr>
                    <tr>
                      <td width="36" height="2">&nbsp;</td>
                      <td width="157" height="2">&nbsp;</td>
                      <td width="134" height="2">&nbsp;</td>
                    </tr>
                  </table>
                  
                </td>
                </tr>
                <tr> </tr>
              </table>
            </td>
          </tr>
        </table>
      </td>
    </tr>
  </table>
  </body>
</html>

From cras@irccrew.org  Tue Aug  6 13:34:34 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 06 Aug 2002 13:34:34 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 1EC3C23831
	for <dovecot@procontrol.fi>; Tue,  6 Aug 2002 13:34:34 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id E37C74C0A0; Tue,  6 Aug 2002 13:34:33 +0300 (EEST)
Date: Tue, 6 Aug 2002 13:34:33 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] spam / updates
Message-ID: <20020806133433.T22431@irccrew.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 6
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 6                                                  
Status: O

I guess I underestimated the spammers :) This list is subscribers-only now.

As for dovecot, I've been cleaning the code and probably will continue with
that some time. I was also thinking about moving the authentication code
into separate (SASL) library which could then be plugged into other
software, such as postfix.


From darix@linux.taugt.net  Tue Aug  6 20:54:39 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 06 Aug 2002 20:54:39 +0300 (EEST)
Return-Path: <darix@linux.taugt.net>
Delivered-To: dovecot@procontrol.fi
Received: from linux.taugt.net (wh5035.stw.uni-rostock.de [139.30.105.35])
	by danu.procontrol.fi (Postfix) with ESMTP id 99FC923829
	for <dovecot@procontrol.fi>; Tue,  6 Aug 2002 20:54:39 +0300 (EEST)
Received: by linux.taugt.net (none of your biz, from userid 500)
	id 28A8D29F49; Tue,  6 Aug 2002 19:54:41 +0200 (CEST)
Date: Tue, 6 Aug 2002 19:54:41 +0200
From: Marcus Rueckert <rueckert@informatik.uni-rostock.de>
To: dovecot mailing list <dovecot@procontrol.fi>
Subject: [dovecot] mbox support
Message-ID: <20020806175441.GA7148@linux.taugt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.4i
X-archive-position: 7
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: rueckert@informatik.uni-rostock.de
Precedence: bulk
X-list: dovecot
X-UID: 7                                                  
Status: O

hi

could you explain the following sentence from the readme.txt:
"mbox support is available but currently it relies a little bit on good
luck, ..."

what kind of luck do i need?
why do you think the mbox support isnt this reliable?

Marcus Rckert

-- 
irssi - the client of the smart and beautiful people

From marcelo@carpa.ciagri.usp.br  Wed Aug  7 02:39:26 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 07 Aug 2002 02:39:26 +0300 (EEST)
Return-Path: <marcelo@carpa.ciagri.usp.br>
Delivered-To: dovecot@procontrol.fi
Received: from carpa.ciagri.usp.br (carpa.ciagri.usp.br [143.107.209.25])
	by danu.procontrol.fi (Postfix) with SMTP id 42D5323829
	for <dovecot@procontrol.fi>; Wed,  7 Aug 2002 02:39:25 +0300 (EEST)
Received: (qmail 32442 invoked by uid 1000); 6 Aug 2002 23:40:54 -0000
From: marcelo@carpa.ciagri.usp.br
Date: Tue, 6 Aug 2002 20:40:54 -0300
To: dovecot@procontrol.fi
Subject: [dovecot] starting
Message-ID: <20020806234054.GA30820@carpa.ciagri.usp.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-archive-position: 8
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: marcelo@carpa.ciagri.usp.br
Precedence: bulk
X-list: dovecot
X-UID: 8                                                  
Status: O


Hi. Sorry for the basic question but... how do I
start the server?  From inetd or in standalone mode
(which binary)?

Thanks

From cras@irccrew.org  Wed Aug  7 06:54:12 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 07 Aug 2002 06:54:12 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id EA9D623829
	for <dovecot@procontrol.fi>; Wed,  7 Aug 2002 06:54:11 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id D125E4C0A0; Wed,  7 Aug 2002 06:54:11 +0300 (EEST)
Date: Wed, 7 Aug 2002 06:54:11 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot mailing list <dovecot@procontrol.fi>
Subject: [dovecot] Re: mbox support
Message-ID: <20020807065411.A16470@irccrew.org>
References: <20020806175441.GA7148@linux.taugt.net>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20020806175441.GA7148@linux.taugt.net>; from rueckert@informatik.uni-rostock.de on Tue, Aug 06, 2002 at 07:54:41PM +0200
Content-Type: text/plain; charset=us-ascii
X-archive-position: 9
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 9                                                  
Status: O

On Tue, Aug 06, 2002 at 07:54:41PM +0200, Marcus Rueckert wrote:
> could you explain the following sentence from the readme.txt:
> "mbox support is available but currently it relies a little bit on good
> luck, ..."
> 
> what kind of luck do i need?
> why do you think the mbox support isnt this reliable?

mbox files are locked only while they're being modified. If only dovecot was
accessing the mailbox I guess there wouldn't be any problem since it
properly locks the index files as well. But if any other MUA was just
modifying the mbox file (deleting messages) while dovecot was reading it,
it's possible that you end up having data from some random message. Storing
MD5 sum of all messages and making sure they match would fix this.


From cras@irccrew.org  Wed Aug  7 06:58:27 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 07 Aug 2002 06:58:27 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id B90D723829
	for <dovecot@procontrol.fi>; Wed,  7 Aug 2002 06:58:27 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 443C64C0A0; Wed,  7 Aug 2002 06:58:24 +0300 (EEST)
Date: Wed, 7 Aug 2002 06:58:24 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: starting
Message-ID: <20020807065824.C16470@irccrew.org>
References: <20020806234054.GA30820@carpa.ciagri.usp.br>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20020806234054.GA30820@carpa.ciagri.usp.br>; from marcelo@carpa.ciagri.usp.br on Tue, Aug 06, 2002 at 08:40:54PM -0300
Content-Type: text/plain; charset=us-ascii
X-archive-position: 10
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 10                                                  
Status: O

On Tue, Aug 06, 2002 at 08:40:54PM -0300, marcelo@carpa.ciagri.usp.br wrote:

> Hi. Sorry for the basic question but... how do I
> start the server?  From inetd or in standalone mode
> (which binary)?

Run imap-master


From cras@irccrew.org  Wed Aug  7 06:59:01 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 07 Aug 2002 06:59:01 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 05B9423829
	for <dovecot@procontrol.fi>; Wed,  7 Aug 2002 06:59:01 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id E84874C0A0; Wed,  7 Aug 2002 06:59:00 +0300 (EEST)
Date: Wed, 7 Aug 2002 06:59:00 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: starting
Message-ID: <20020807065900.D16470@irccrew.org>
References: <20020806234054.GA30820@carpa.ciagri.usp.br>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20020806234054.GA30820@carpa.ciagri.usp.br>; from marcelo@carpa.ciagri.usp.br on Tue, Aug 06, 2002 at 08:40:54PM -0300
Content-Type: text/plain; charset=us-ascii
X-archive-position: 11
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 11                                                  
Status: O

On Tue, Aug 06, 2002 at 08:40:54PM -0300, marcelo@carpa.ciagri.usp.br wrote:

> Hi. Sorry for the basic question but... how do I
> start the server?  From inetd or in standalone mode
> (which binary)?

Oh, and standalone :) Maybe I should support inetd too later.


From marcelo@carpa.ciagri.usp.br  Thu Aug  8 02:18:19 2002
Received: with ECARTIS (v1.0.0; list dovecot); Thu, 08 Aug 2002 02:18:19 +0300 (EEST)
Return-Path: <marcelo@carpa.ciagri.usp.br>
Delivered-To: dovecot@procontrol.fi
Received: from carpa.ciagri.usp.br (carpa.ciagri.usp.br [143.107.209.25])
	by danu.procontrol.fi (Postfix) with SMTP id 348EE23829
	for <dovecot@procontrol.fi>; Thu,  8 Aug 2002 02:18:18 +0300 (EEST)
Received: (qmail 18910 invoked by uid 1000); 7 Aug 2002 23:19:56 -0000
From: marcelo@carpa.ciagri.usp.br
Date: Wed, 7 Aug 2002 20:19:56 -0300
To: dovecot@procontrol.fi
Subject: [dovecot] SELECT
Message-ID: <20020807231956.GA11240@carpa.ciagri.usp.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-archive-position: 12
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: marcelo@carpa.ciagri.usp.br
Precedence: bulk
X-list: dovecot
X-UID: 12                                                  
Status: O
Content-Length: 1024



Hi, all.

Thanks Timo for answering my previous post. It's starting
fine now :)

I must be doing something wrong again but I can't connect from
any imap client. If I telnet to the server I get:

$ telnet carpa 11143
Trying 143.107.209.25...
Connected to carpa.ciagri.usp.br.
Escape character is '^]'.
* OK dovecot ready.
a001 login marcelo #####
a001 OK Logged in.
a002 select INBOX
a002 NO Broken INBOX: Permission denied
a003 select ""
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft \Recent)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft)] Flags
permitted.
* 246 EXISTS
* 246 RECENT
* OK [UNSEEN 1] First unseen.
* OK [UIDVALIDITY 1028760751] UIDs valid
a003 OK [READ-WRITE] Select completed.
a004 close
a004 OK Close completed.
a005 logout
* BYE Logging out
a005 OK Logout completed.
Connection closed by foreign host.

"INBOX" seems not be a valid mailbox name to Dovecot but
it works with others servers (courier, at least).

The server uses Maildirs and runs qmail and courier (by now).

Thanks.

From cras@irccrew.org  Thu Aug  8 07:13:04 2002
Received: with ECARTIS (v1.0.0; list dovecot); Thu, 08 Aug 2002 07:13:04 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 65BF823831
	for <dovecot@procontrol.fi>; Thu,  8 Aug 2002 07:13:04 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 3BB134C0A0; Thu,  8 Aug 2002 07:13:03 +0300 (EEST)
Date: Thu, 8 Aug 2002 07:13:03 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: SELECT
Message-ID: <20020808071303.F16470@irccrew.org>
References: <20020807231956.GA11240@carpa.ciagri.usp.br>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20020807231956.GA11240@carpa.ciagri.usp.br>; from marcelo@carpa.ciagri.usp.br on Wed, Aug 07, 2002 at 08:19:56PM -0300
Content-Type: text/plain; charset=us-ascii
X-archive-position: 13
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 13                                                  
Status: O

On Wed, Aug 07, 2002 at 08:19:56PM -0300, marcelo@carpa.ciagri.usp.br wrote:

> a002 NO Broken INBOX: Permission denied

You use normal passwd/shadow/pam authentication? Where does the home
directory point to, to your real home dir under which Maildir/ is? Anyway,
one of the following failed (under Maildir/):

 mkdir .INBOX
 ln -s ../cur .INBOX/cur
 ln -s ../new .INBOX/new
 ln -s ../tmp .INBOX/tmp

Next release will tell exactly which of them failed :)

> a003 select ""

I don't think this should be allowed :)


From marcelo@carpa.ciagri.usp.br  Thu Aug  8 16:11:45 2002
Received: with ECARTIS (v1.0.0; list dovecot); Thu, 08 Aug 2002 16:11:45 +0300 (EEST)
Return-Path: <marcelo@carpa.ciagri.usp.br>
Delivered-To: dovecot@procontrol.fi
Received: from carpa.ciagri.usp.br (carpa.ciagri.usp.br [143.107.209.25])
	by danu.procontrol.fi (Postfix) with SMTP id 88CF423831
	for <dovecot@procontrol.fi>; Thu,  8 Aug 2002 16:11:44 +0300 (EEST)
Received: (qmail 9606 invoked by uid 1000); 8 Aug 2002 13:13:30 -0000
From: marcelo@carpa.ciagri.usp.br
Date: Thu, 8 Aug 2002 10:13:30 -0300
To: dovecot@procontrol.fi
Subject: [dovecot] Re: SELECT
Message-ID: <20020808131329.GA30775@carpa.ciagri.usp.br>
References: <20020807231956.GA11240@carpa.ciagri.usp.br> <20020808071303.F16470@irccrew.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020808071303.F16470@irccrew.org>
User-Agent: Mutt/1.3.28i
X-archive-position: 14
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: marcelo@carpa.ciagri.usp.br
Precedence: bulk
X-list: dovecot
X-UID: 14                                                  
Status: O

On Thu, Aug 08, 2002 at 07:13:03AM +0300, Timo Sirainen wrote:
> On Wed, Aug 07, 2002 at 08:19:56PM -0300, marcelo@carpa.ciagri.usp.br wrote:
> 
> > a002 NO Broken INBOX: Permission denied
> 
> You use normal passwd/shadow/pam authentication?

Well, in dovecot.conf I have:

auth = default
auth_methods = plain
auth_userinfo = shadow
auth_user = root

> Where does the home
> directory point to, to your real home dir under which Maildir/ is?

Maildir is in the real users' home (/home/user/Maildir)

> Anyway,
> one of the following failed (under Maildir/):
> 
>  mkdir .INBOX
>  ln -s ../cur .INBOX/cur
>  ln -s ../new .INBOX/new
>  ln -s ../tmp .INBOX/tmp
> 
> Next release will tell exactly which of them failed :)
> 

Shouldn't it be:

mkdir .INBOX
ln -s cur .INBOX/
ln -s new .INBOX/
ln -s tmp .INBOX/
?

Anyway, "mkdir .INBOX" succeeds but it is created with
perms 070 and trying to create the links inside it
causes the permission errors.


From cras@irccrew.org  Thu Aug  8 18:04:54 2002
Received: with ECARTIS (v1.0.0; list dovecot); Thu, 08 Aug 2002 18:04:54 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id C053623831
	for <dovecot@procontrol.fi>; Thu,  8 Aug 2002 18:04:54 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 6E2674C0A0; Thu,  8 Aug 2002 18:04:53 +0300 (EEST)
Date: Thu, 8 Aug 2002 18:04:53 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: SELECT
Message-ID: <20020808180453.J16470@irccrew.org>
References: <20020807231956.GA11240@carpa.ciagri.usp.br> <20020808071303.F16470@irccrew.org> <20020808131329.GA30775@carpa.ciagri.usp.br>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20020808131329.GA30775@carpa.ciagri.usp.br>; from marcelo@carpa.ciagri.usp.br on Thu, Aug 08, 2002 at 10:13:30AM -0300
Content-Type: text/plain; charset=us-ascii
X-archive-position: 15
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 15                                                  
Status: O

On Thu, Aug 08, 2002 at 10:13:30AM -0300, marcelo@carpa.ciagri.usp.br wrote:

> Shouldn't it be:
> 
> mkdir .INBOX
> ln -s cur .INBOX/
> ln -s new .INBOX/
> ln -s tmp .INBOX/
> ?

No, if that was done the symlinks would point to themselves. ln -s behaviour
looks a bit weird if you're not doing it from the destination directory :)

> Anyway, "mkdir .INBOX" succeeds but it is created with
> perms 070 and trying to create the links inside it
> causes the permission errors.

Ah, and this was because I was stupid and set the default umask to 0700
instead of 0077 :) You could fix this by uncommenting the umask-line in
dovecot.conf.

btw. 0.95 also has problems with bad network connections or large mailboxes,
I'll probably release 0.96 soon which fixes it.


From cras@irccrew.org  Thu Aug  8 19:00:00 2002
Received: with ECARTIS (v1.0.0; list dovecot); Thu, 08 Aug 2002 19:00:00 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 5A8E723829
	for <dovecot@procontrol.fi>; Thu,  8 Aug 2002 19:00:00 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 36C274C0A0; Thu,  8 Aug 2002 19:00:00 +0300 (EEST)
Date: Thu, 8 Aug 2002 19:00:00 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] v0.96 released
Message-ID: <20020808190000.K16470@irccrew.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 16
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 16                                                  
Status: O
Content-Length: 1072

This release was actually tested with reading my inbox (500+ messages, mbox,
Solaris 8) using Outlook and Evolution

v0.96 2002-08-08  Timo Sirainen <tss@iki.fi>

	* Changed to LGPL v2.1 license

	+ STARTTLS support and optional disabling of plaintext authentication
	  (LOGINDISABLED capability)
	+ Support for custom message flags, each folder can have 26 different.
	+ New configuration file options: imap_listen, max_logging_users,
	  max_imap_processes
	+ You can specify config file location to imap-master with -c <path>
	+ All IMAP processes can now write to specified log file instead of
	  syslog. Either do this by setting IMAP_LOGFILE environment, or
	  give -l <path> parameter to imap-master.
	+ Some cleanups to remove warnings with BSDs
	+ Changed all %s .. strerror(errno) -> %m
	+ Rewritten memory pool code
	- imap-master didn't close all the fds for executed processes
	- iobuffer code was buggy and caused the connection to terminate
	  sometimes
	- make install overwrote the existing dovecot.conf file, so it's now
	  named as dovecot-example.conf


From marcelo@carpa.ciagri.usp.br  Thu Aug  8 22:33:47 2002
Received: with ECARTIS (v1.0.0; list dovecot); Thu, 08 Aug 2002 22:33:47 +0300 (EEST)
Return-Path: <marcelo@carpa.ciagri.usp.br>
Delivered-To: dovecot@procontrol.fi
Received: from carpa.ciagri.usp.br (carpa.ciagri.usp.br [143.107.209.25])
	by danu.procontrol.fi (Postfix) with SMTP id 18B9C23829
	for <dovecot@procontrol.fi>; Thu,  8 Aug 2002 22:33:45 +0300 (EEST)
Received: (qmail 23496 invoked by uid 1000); 8 Aug 2002 19:35:33 -0000
From: marcelo@carpa.ciagri.usp.br
Date: Thu, 8 Aug 2002 16:35:33 -0300
To: dovecot@procontrol.fi
Subject: [dovecot] Disk quotas (was: SELECT)
Message-ID: <20020808193533.GA28619@carpa.ciagri.usp.br>
References: <20020807231956.GA11240@carpa.ciagri.usp.br> <20020808071303.F16470@irccrew.org> <20020808131329.GA30775@carpa.ciagri.usp.br> <20020808180453.J16470@irccrew.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020808180453.J16470@irccrew.org>
User-Agent: Mutt/1.3.28i
X-archive-position: 17
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: marcelo@carpa.ciagri.usp.br
Precedence: bulk
X-list: dovecot
X-UID: 17                                                  
Status: O
Content-Length: 1136

On Thu, Aug 08, 2002 at 06:04:53PM +0300, Timo Sirainen wrote:

> > Anyway, "mkdir .INBOX" succeeds but it is created with
> > perms 070 and trying to create the links inside it
> > causes the permission errors.
> 
> Ah, and this was because I was stupid and set the default umask to 0700
> instead of 0077 :) You could fix this by uncommenting the umask-line in
> dovecot.conf.

Hey, it works! :)

> 
> btw. 0.95 also has problems with bad network connections or large mailboxes,
> I'll probably release 0.96 soon which fixes it.
> 

Yes, confirmed. Using 0.96 my inbox shows up with all my ~200 messages now.

Now, one last question (for a while):  would be possible/desirable make
Dovecot work when an user is with her disk quota completely full (hard
quota)?  The main reason I'm looking for an alternative imap server is that
neither WU-Imapd nor Courier work "properly" (from an user point of view) in
that situation (the user can not login or delete her messages to clean up
the mailbox). If Dovecot could handle this problem (creating its scratch
files in /tmp, perhaps) it'd be big plus, IMHO.

Thanks for the great support :)

From cras@irccrew.org  Fri Aug  9 07:03:02 2002
Received: with ECARTIS (v1.0.0; list dovecot); Fri, 09 Aug 2002 07:03:02 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id A2CE123829
	for <dovecot@procontrol.fi>; Fri,  9 Aug 2002 07:03:02 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 30A774C0A0; Fri,  9 Aug 2002 07:03:01 +0300 (EEST)
Date: Fri, 9 Aug 2002 07:03:01 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Disk quotas (was: SELECT)
Message-ID: <20020809070301.L16470@irccrew.org>
References: <20020807231956.GA11240@carpa.ciagri.usp.br> <20020808071303.F16470@irccrew.org> <20020808131329.GA30775@carpa.ciagri.usp.br> <20020808180453.J16470@irccrew.org> <20020808193533.GA28619@carpa.ciagri.usp.br>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20020808193533.GA28619@carpa.ciagri.usp.br>; from marcelo@carpa.ciagri.usp.br on Thu, Aug 08, 2002 at 04:35:33PM -0300
Content-Type: text/plain; charset=us-ascii
X-archive-position: 18
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 18                                                  
Status: O
Content-Length: 1031

On Thu, Aug 08, 2002 at 04:35:33PM -0300, marcelo@carpa.ciagri.usp.br wrote:

> Now, one last question (for a while):  would be possible/desirable make
> Dovecot work when an user is with her disk quota completely full (hard
> quota)?  The main reason I'm looking for an alternative imap server is that
> neither WU-Imapd nor Courier work "properly" (from an user point of view) in
> that situation (the user can not login or delete her messages to clean up
> the mailbox). If Dovecot could handle this problem (creating its scratch
> files in /tmp, perhaps) it'd be big plus, IMHO.

Well, that is a bit difficult to handle.. It's mostly the index files that
dovecot has to create/grow. I think I should support keeping them only in
memory when disk quota is exceeded.

But what about clients, I think some of them just copy the mail to trash
folder instead of deleting the mail? But maybe with
maildir_copy_with_hardlinks=yes that'd be possible even with quota full.

I guess I'll have to install quota support and start fixing.


From marcelo@carpa.ciagri.usp.br  Sun Aug 11 22:05:26 2002
Received: with ECARTIS (v1.0.0; list dovecot); Fri, 09 Aug 2002 22:05:26 +0300 (EEST)
Return-Path: <marcelo@carpa.ciagri.usp.br>
Delivered-To: dovecot@procontrol.fi
Received: from carpa.ciagri.usp.br (carpa.ciagri.usp.br [143.107.209.25])
	by danu.procontrol.fi (Postfix) with SMTP id 41E5B23831
	for <dovecot@procontrol.fi>; Fri,  9 Aug 2002 22:03:46 +0300 (EEST)
Received: (qmail 27100 invoked by uid 1000); 9 Aug 2002 19:03:39 -0000
From: marcelo@carpa.ciagri.usp.br
Date: Sat, 10 Aug 2002 16:03:39 -0300
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Disk quotas
Message-ID: <20020809190339.GA2063@carpa.ciagri.usp.br>
References: <20020807231956.GA11240@carpa.ciagri.usp.br> <20020808071303.F16470@irccrew.org> <20020808131329.GA30775@carpa.ciagri.usp.br> <20020808180453.J16470@irccrew.org> <20020808193533.GA28619@carpa.ciagri.usp.br> <20020809070301.L16470@irccrew.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020809070301.L16470@irccrew.org>
User-Agent: Mutt/1.3.28i
X-archive-position: 19
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: marcelo@carpa.ciagri.usp.br
Precedence: bulk
X-list: dovecot
X-UID: 19                                                  
Status: O

On Fri, Aug 09, 2002 at 07:03:01AM +0300, Timo Sirainen wrote:

> 
> Well, that is a bit difficult to handle.. It's mostly the index files that
> dovecot has to create/grow. I think I should support keeping them only in
> memory when disk quota is exceeded.
> 

I see...

> But what about clients, I think some of them just copy the mail to trash
> folder instead of deleting the mail? But maybe with
> maildir_copy_with_hardlinks=yes that'd be possible even with quota full.
> 

When a user or his imap client asks for a "write" operation (like saving in
Trash) I think it's fair for an imap server just fail the operation and
return an error (he's overquota :).

But using "good" clients that offer the option to just delete the messages
(not copy/move them) it would be nice if they could have the chance to at
least login and delete the spam.

> I guess I'll have to install quota support and start fixing.
> 

I'm by no means a decent C programmer but if I could help somehow, just ask.

Thanks,
Marcelo.

From ev@kernel.ping-viini.org  Mon Aug 12 01:09:37 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 12 Aug 2002 01:09:37 +0300 (EEST)
Return-Path: <ev@kernel.ping-viini.org>
Delivered-To: dovecot@procontrol.fi
Received: from ping-viini.at.home.telekarelia.fi (ping-viini.at.home.telekarelia.fi [195.197.199.46])
	by danu.procontrol.fi (Postfix) with SMTP id C8B3423833
	for <dovecot@procontrol.fi>; Mon, 12 Aug 2002 01:09:37 +0300 (EEST)
Received: (qmail 17429 invoked from network); 11 Aug 2002 21:32:33 -0000
Received: from unknown (HELO eero) (192.168.0.2)
  by 0 with SMTP; 11 Aug 2002 21:32:33 -0000
Message-ID: <006701c24183$c7f10d60$0200a8c0@eero>
From: "Eero Volotinen" <ev@kernel.ping-viini.org>
To: <dovecot@procontrol.fi>
Subject: [dovecot] vpopmail authentication support
Date: Mon, 12 Aug 2002 01:09:37 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-archive-position: 20
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: ev@kernel.ping-viini.org
Precedence: bulk
X-list: dovecot
X-UID: 20                                                  
Status: O

is nice feature to get soon if possible?


--
Eero


From cras@irccrew.org  Thu Aug 22 16:25:52 2002
Received: with ECARTIS (v1.0.0; list dovecot); Thu, 22 Aug 2002 16:25:52 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 926902386D
	for <dovecot@procontrol.fi>; Thu, 22 Aug 2002 16:25:52 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id C96234C0A0; Thu, 22 Aug 2002 16:25:51 +0300 (EEST)
Date: Thu, 22 Aug 2002 16:25:51 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] status update / cvs repository
Message-ID: <20020822132551.GD12341@irccrew.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 21
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 21                                                  
Status: O

Past few weeks went mostly while rewriting small part of code. It really
wouldn't have needed to take that long, but I always got really tired after
just looking at that code for a few seconds :)

Anyway, now messages are parsed in 256kB blocks (maybe I should make it
configurable), so large messages don't eat all memory anymore. Maildir
support seems to work with the new code, though I haven't tested it too well
yet. mbox is currently broken.

If you want to test it, dovecot's CVS is available with rsync. I don't think
I'll bother setting up pserver since that CVS has also other sources that
aren't public.

With rsync you'd do it something like:

# initialize new cvs repository (do it just once)
cvs -d ~/cvs init

# update cvs repository
rsync -avz --delete dovecot.procontrol.fi::dovecotcvs ~/cvs/dovecot

# checkout the sources from your cvs repository
cd ~/src
cvs -d ~/cvs checkout dovecot


From cras@irccrew.org  Mon Aug 26 18:23:16 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 26 Aug 2002 18:23:16 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id AB6572386D
	for <dovecot@procontrol.fi>; Mon, 26 Aug 2002 18:23:16 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id ADE354C0A0; Mon, 26 Aug 2002 18:23:12 +0300 (EEST)
Date: Mon, 26 Aug 2002 18:23:12 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: vpopmail authentication support
Message-ID: <20020826152312.GI7103@irccrew.org>
References: <006701c24183$c7f10d60$0200a8c0@eero>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <006701c24183$c7f10d60$0200a8c0@eero>
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 22
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 22                                                  
Status: O

On Mon, Aug 12, 2002 at 01:09:37AM +0300, Eero Volotinen wrote:
> is nice feature to get soon if possible?

OK, I finally remembered to put this in TODO :) I also looked at vpopmail
before but it had at least one very weird thing which I thought about asking
about it's authors (gid field actually contains just flags).


From cras@irccrew.org  Thu Aug 29 03:17:57 2002
Received: with ECARTIS (v1.0.0; list dovecot); Thu, 29 Aug 2002 03:17:57 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 56E0223831
	for <dovecot@procontrol.fi>; Thu, 29 Aug 2002 03:17:57 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id A9A3B4C0A0; Thu, 29 Aug 2002 03:17:56 +0300 (EEST)
Date: Thu, 29 Aug 2002 03:17:56 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] v0.97 released
Message-ID: <20020829001756.GU7103@irccrew.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 23
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 23                                                  
Status: O
Content-Length: 2242

This is a major cleanup release. My near future goal is to make it
impossible to crash Dovecot no matter what you did. This release also adds
support for files larger than 2GB with Linux and Solaris. Also mbox support
seems to work quite well now, except EXPUNGE and STORE are still not
implemented.

The "impossible to crash" should already be quite true, at least when it
comes to index files. You can try to corrupt indexes in any way you want,
and Dovecot should not crash. There's one exception to this: modifying the
files while dovecot is reading them may crash it, this is too difficult to
fix as long as shared memory maps are used, and I don't see much point in it
anyway. I mostly want dovecot to survive corrupted files, not intentional
crashing :)

This release is the first I'd almost like to call beta-quality. But not
quite. It still lacks testing and several features, but it's very close :)

Changelog:

v0.97 2002-08-29  Timo Sirainen <tss@iki.fi>

	+ Large mails are handled in 256kB blocks, so mail size no longer
	  has hardly any effect on memory usage
	+ 64bit file offsets are used if supported by system. This means
	  Dovecot is fully capable of handling >2G mails in those systems.
	  With 32bit offsets >2G mails may not behave too well, but should
	  not crash either.
	+ I fixed lots of potential integer overflows. This should make us
	  fully crash-free no matter what happens (index file corruption
	  mostly). I didn't verify everything too carefully yet, so more
	  auditing is still needed before we fully reach that goal.
	+ Implemented several missing tasks / optimizations to index handling.
	  It should now stay fast after longer usage periods.
	+ New configuration file options: log_path, log_timestamp, imaps_listen
	+ "Critical errors" are now hidden from users, ie. any error message
	  that is not a direct reply to user error is written into log file
	  and user gets only "Internal error [timestamp]".
	+ Nonblocking SSL handshaking
	+ Lots of code cleanups
	- Lots of mbox fixes, it seems to be somewhat reliable now
	- Year in Date-field was parsed wrong
	- Appending mail to mbox didn't work right
	- Always verify that mailbox names are valid (especially they shouldn't
	  contain "../")


From svrmarty@gmx.net  Sat Sep 14 23:50:41 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 14 Sep 2002 23:50:41 +0300 (EEST)
Return-Path: <svrmarty@gmx.net>
Delivered-To: dovecot@procontrol.fi
Received: from svrmarty.gnome.at (unknown [213.225.45.83])
	by danu.procontrol.fi (Postfix) with ESMTP id 0964B23831
	for <dovecot@procontrol.fi>; Sat, 14 Sep 2002 23:50:40 +0300 (EEST)
Received: from silent (silent.svrmarty.gnome.at [192.168.1.8])
	by svrmarty.gnome.at (8.12.3/8.12.3/Debian -4) with SMTP id g8EM00he027169
	for <dovecot@procontrol.fi>; Sun, 15 Sep 2002 00:00:01 +0200
Message-ID: <059101c25c30$da8c2b40$0801a8c0@svrmarty.gnome.at>
From: "SvR Marty" <svrmarty@gmx.net>
To: <dovecot@procontrol.fi>
Subject: [dovecot] Problems with it
Date: Sat, 14 Sep 2002 22:54:00 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-archive-position: 24
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: svrmarty@gmx.net
Precedence: bulk
X-list: dovecot
X-UID: 24                                                  
Status: O

i've install it, used the example config and started

tryed to access my mailbox via Outlook Express

here's the syslog:

Sep 14 22:42:17 p133 imap-login: Logged in. [192.168.1.8]
Sep 15 00:42:17 p133 imap(svrmarty): MAIL environment missing and
autodetection failed (home /home/svrmarty)
Sep 15 00:42:17 p133 imap-master: child 20960 (imap) returned error 98
Sep 14 22:42:19 p133 imap-login: Logged in. [192.168.1.8]
Sep 15 00:42:19 p133 imap(svrmarty): MAIL environment missing and
autodetection failed (home /home/svrmarty)
Sep 15 00:42:19 p133 imap-master: child 20961 (imap) returned error 98

it fails and i don't see any message


From cras@irccrew.org  Sun Sep 15 00:50:10 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sun, 15 Sep 2002 00:50:10 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 75F9423837
	for <dovecot@procontrol.fi>; Sun, 15 Sep 2002 00:50:10 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 4AA2C4C0A5; Sun, 15 Sep 2002 00:50:09 +0300 (EEST)
Date: Sun, 15 Sep 2002 00:50:08 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Problems with it
Message-ID: <20020914215008.GU9842@irccrew.org>
References: <059101c25c30$da8c2b40$0801a8c0@svrmarty.gnome.at>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <059101c25c30$da8c2b40$0801a8c0@svrmarty.gnome.at>
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 25
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 25                                                  
Status: O

On Sat, Sep 14, 2002 at 10:54:00PM +0200, SvR Marty wrote:

> Sep 15 00:42:17 p133 imap(svrmarty): MAIL environment missing and
> autodetection failed (home /home/svrmarty)

Are you using mbox or maildir? It looks only for ~/Maildir with maildir.
With mbox it looks for ~/Mail and ~/mail directories, and they must contain
either "inbox" or "mbox" file.

If your mail is in /var/mail, that's not supported yet, and I'm not sure if
it will be. You could create symlink from it to ~/mail though.


From svrmarty@gmx.net  Sun Sep 15 15:46:31 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sun, 15 Sep 2002 15:46:31 +0300 (EEST)
Return-Path: <svrmarty@gmx.net>
Delivered-To: dovecot@procontrol.fi
Received: from svrmarty.gnome.at (unknown [213.225.45.83])
	by danu.procontrol.fi (Postfix) with ESMTP id B6BA023831
	for <dovecot@procontrol.fi>; Sun, 15 Sep 2002 15:46:28 +0300 (EEST)
Received: from silent (silent.svrmarty.gnome.at [192.168.1.8])
	by svrmarty.gnome.at (8.12.3/8.12.3/Debian -4) with SMTP id g8FDuEhe013158
	for <dovecot@procontrol.fi>; Sun, 15 Sep 2002 15:56:15 +0200
Message-ID: <009601c25cb6$b1e567c0$0801a8c0@svrmarty.gnome.at>
From: "SvR Marty" <svrmarty@gmx.net>
To: <dovecot@procontrol.fi>
References: <059101c25c30$da8c2b40$0801a8c0@svrmarty.gnome.at> <20020914215008.GU9842@irccrew.org>
Subject: [dovecot] Re: Problems with it
Date: Sun, 15 Sep 2002 14:52:03 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-archive-position: 26
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: svrmarty@gmx.net
Precedence: bulk
X-list: dovecot
X-UID: 26                                                  
Status: O
Content-Length: 1045

i can't find a good howto doc.

can you put ls -laR of the special folders into a mail an send it ?

i don't know how this should work

seems i'm using maildir
Internal error [2002-09-15 16:42:35]
Sep 15 16:42:35 p133 imap(svrmarty): Can't open index data
/home/svrmarty/Maildir/.INBOX/.imap.index.data: No such file or directory

dunno what to do

----- Original Message -----
From: "Timo Sirainen" <tss@iki.fi>
To: <dovecot@procontrol.fi>
Sent: Saturday, September 14, 2002 11:50 PM
Subject: [dovecot] Re: Problems with it


> On Sat, Sep 14, 2002 at 10:54:00PM +0200, SvR Marty wrote:
>
> > Sep 15 00:42:17 p133 imap(svrmarty): MAIL environment missing and
> > autodetection failed (home /home/svrmarty)
>
> Are you using mbox or maildir? It looks only for ~/Maildir with maildir.
> With mbox it looks for ~/Mail and ~/mail directories, and they must
contain
> either "inbox" or "mbox" file.
>
> If your mail is in /var/mail, that's not supported yet, and I'm not sure
if
> it will be. You could create symlink from it to ~/mail though.
>
>


From cras@irccrew.org  Mon Sep 16 07:41:59 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 16 Sep 2002 07:41:59 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id A05B423831
	for <dovecot@procontrol.fi>; Mon, 16 Sep 2002 07:41:59 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 4D5EF4C0A5; Mon, 16 Sep 2002 07:41:56 +0300 (EEST)
Date: Mon, 16 Sep 2002 07:41:56 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Problems with it
Message-ID: <20020916044155.GY9842@irccrew.org>
References: <059101c25c30$da8c2b40$0801a8c0@svrmarty.gnome.at> <20020914215008.GU9842@irccrew.org> <009601c25cb6$b1e567c0$0801a8c0@svrmarty.gnome.at>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <009601c25cb6$b1e567c0$0801a8c0@svrmarty.gnome.at>
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 27
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 27                                                  
Status: O

On Sun, Sep 15, 2002 at 02:52:03PM +0200, SvR Marty wrote:
> seems i'm using maildir
> Internal error [2002-09-15 16:42:35]
> Sep 15 16:42:35 p133 imap(svrmarty): Can't open index data
> /home/svrmarty/Maildir/.INBOX/.imap.index.data: No such file or directory

Looks like some bug .. rm -f /home/svrmarty/Maildir/.INBOX/.imap.index*
might help.

Anyway, the 0.97 version isn't very usable. I think I'll release new version
today or tomorrow, which has had quite a lot of testing. I'll just have to
see if all those changes I did last weekend broke everything or fixed the
last few problems :)


From cras@irccrew.org  Fri Sep 20 14:30:45 2002
Received: with ECARTIS (v1.0.0; list dovecot); Fri, 20 Sep 2002 14:30:45 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 8FDD82383F
	for <dovecot@procontrol.fi>; Fri, 20 Sep 2002 14:30:45 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 63BF44C0A5; Fri, 20 Sep 2002 14:30:45 +0300 (EEST)
Date: Fri, 20 Sep 2002 14:30:45 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] vpopmail authentication
Message-ID: <20020920113045.GC8225@irccrew.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 28
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 28                                                  
Status: O

CVS has now support for vpopmail authentication. .c file compiles, but I'm
not sure if I did the other checks properly and if it actually works :)

If someone here is using it, could you test it? At least to see if configure
detects it and if it compiles/links.

BTW. I think maildir support is now working quite well, 0.98 isn't far away.


From cras@irccrew.org  Fri Sep 20 15:19:11 2002
Received: with ECARTIS (v1.0.0; list dovecot); Fri, 20 Sep 2002 15:19:11 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 202B223831
	for <dovecot@procontrol.fi>; Fri, 20 Sep 2002 15:19:11 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id F03784C0A5; Fri, 20 Sep 2002 15:19:10 +0300 (EEST)
Date: Fri, 20 Sep 2002 15:19:10 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: vpopmail authentication
Message-ID: <20020920121910.GA27866@irccrew.org>
References: <20020920113045.GC8225@irccrew.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20020920113045.GC8225@irccrew.org>
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 29
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 29                                                  
Status: O

On Fri, Sep 20, 2002 at 02:30:45PM +0300, Timo Sirainen wrote:
> CVS has now support for vpopmail authentication. .c file compiles, but I'm
> not sure if I did the other checks properly and if it actually works :)

Yes, it works.


From tss@iki.fi  Mon Sep 23 20:42:43 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 23 Sep 2002 20:42:44 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id D7B9D2383F
	for <dovecot@procontrol.fi>; Mon, 23 Sep 2002 20:42:43 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 9D32C5E01F4F; Mon, 23 Sep 2002 20:42:43 +0300 (EEST)
Subject: [dovecot] 0.98 released
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 
Date: 23 Sep 2002 20:42:43 +0300
Message-Id: <1032802963.15743.2.camel@hurina>
Mime-Version: 1.0
X-archive-position: 30
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 30                                                  
Status: O
Content-Length: 1061

0.98 released. This release includes LOTS of bugfixes after almost 4
weeks of actual use. We've mostly tested with Outlook 2000, Outlook
Express 6 and Evolution 1.0.8. I haven't heard of a single bug in
maildir for several days, and mbox worked quite well first time today :)

New features include vpopmail authentication, ability to run properly
when there's no disk space left to allow user to delete mail, and full
support for mbox.

v0.98 2002-09-23  Timo Sirainen <tss@iki.fi>

+ mbox support is finally working. There's still some reliability
  fixes left but overall it should be quite usable.
+ vpopmail authentication support
+ We should be able to deal with "out of diskspace/quota" conditions
  properly, by keeping the indexes in memory and allowing user to
  delete mails to get more space.
+ Several speed enhancements
+ New configuration file option: overwrite_incompatible_index to force
  using ".imap.index" file, overwriting it if it isn't compatible
- Handle invalid message headers reliably
- Tons of bugfixes and code cleanups everywhere


From tss@iki.fi  Tue Sep 24 20:04:30 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 24 Sep 2002 20:04:30 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 6B45C23831
	for <dovecot@procontrol.fi>; Tue, 24 Sep 2002 20:04:30 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 2AD7C5E01F42; Tue, 24 Sep 2002 20:04:30 +0300 (EEST)
Subject: [dovecot] 0.98.1 released
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 
Date: 24 Sep 2002 20:04:30 +0300
Message-Id: <1032887070.27868.0.camel@hurina>
Mime-Version: 1.0
X-archive-position: 31
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 31                                                  
Status: O

Guess I should have waited one more day before releasing 0.98 :) This
fixes a few mbox problems and should finally make it safe to use. Also
fixes a bug of not allowing to save mail larger than 8kB.


From tss@iki.fi  Mon Sep 30 23:53:10 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 30 Sep 2002 23:53:10 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 6FE262383F
	for <dovecot@procontrol.fi>; Mon, 30 Sep 2002 23:53:10 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 69C545E03E5C; Mon, 30 Sep 2002 23:53:09 +0300 (EEST)
Subject: [dovecot] 0.98.2 released
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1033419189.14835.2.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 30 Sep 2002 23:53:09 +0300
X-archive-position: 32
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 32                                                  
Status: O
Content-Length: 1080

Lets see if I fixed all the nasty bugs now.

v0.98.2 2002-09-30  Timo Sirainen <tss@iki.fi>

	+ --with-file-offset-size=32 can now be used to select 32bit file
	  offsets. Using them should be a bit faster and take a bit less
	  disk and memory (also needed to compile Dovecot successfully with
	  TinyCC).
	+ maildir_copy_with_hardlinks option works now
	+ Check new mail and notify about it to client also after
	  commands which don't allow full syncing (FETCH, STORE, SEARCH).
	  Also always send RECENT after EXISTS notify.
	+ If we're out of disk space while opening mailbox, notify about it
	  with ALERT.
	- STORE and SEARCH didn't handle properly message sequence numbers
	  when some in the middle were externally deleted
	- SEARCH: Only first search condition was checked.
	- mbox: Message flags given to APPEND were ignored.
	- mbox: index was corrupted when changing flags for multipart MIME
	  messages
	- Out of disk space-handling wasn't working properly with .customflags
	  file
	- if auth processes were killed, login processes weren't reconnecting
	  to them


From tss@iki.fi  Tue Oct  1 00:28:31 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 01 Oct 2002 00:28:31 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 3D1E123831
	for <dovecot@procontrol.fi>; Tue,  1 Oct 2002 00:28:31 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id D03AB5E03E5C; Tue,  1 Oct 2002 00:28:30 +0300 (EEST)
Subject: [dovecot] 0.98.3 released.
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1033421310.19032.0.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 01 Oct 2002 00:28:30 +0300
X-archive-position: 33
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 33                                                  
Status: O

v0.98.3 2002-10-01  Timo Sirainen <tss@iki.fi>

	* Sorry, just noticed a very stupid bug which caused evolution 1.2
	  beta to crash. I always thought it was just evolution's fault :)
	- Several fields in BODY / BODYSTRUCTURE replies weren't quoted


From tss@iki.fi  Sun Oct  6 00:39:51 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sun, 06 Oct 2002 00:39:51 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 14CF32382D
	for <dovecot@procontrol.fi>; Sun,  6 Oct 2002 00:39:51 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id BDD015E03E5C; Sun,  6 Oct 2002 00:39:50 +0300 (EEST)
Subject: [dovecot] 0.98.4 released
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1033853990.9860.17.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 06 Oct 2002 00:39:50 +0300
X-archive-position: 34
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 34                                                  
Status: O

v0.99 will be next, having the new great binary tree code which should
make huge mailboxes possible. With smaller mailboxes I think it still
makes it better than the old code, even while it is slower in some cases
(hash lookups are faster than btree search in optimal cases).

v0.98.4 2002-10-06  Timo Sirainen <tss@iki.fi>

	* Just a final release before replacing hash file with a binary tree.

	- When fetching messages larger than 256k, sometimes Dovecot missed
	  to send CR causing corrupted data at end of message and possibly
	  complete failure depending on IMAP client.
	- Fetching BODY or BODYSTRUCTURE for message having content-type of
	  message/rfc822 didn't correctly add () around the envelope data.
	- Several fixes to make it compile with HP/UX ANSI C compiler.
	  Also fixed several warnings it showed up.


From tss@iki.fi  Tue Oct  8 00:43:16 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 08 Oct 2002 00:43:16 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 786252382B
	for <dovecot@procontrol.fi>; Tue,  8 Oct 2002 00:43:16 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id E5EDA5E015A0; Tue,  8 Oct 2002 00:43:15 +0300 (EEST)
Subject: [dovecot] Benchmarks
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1034026995.782.15.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 08 Oct 2002 00:43:15 +0300
X-archive-position: 35
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 35                                                  
Status: O

Just tried Dovecot with 85k mails from Linux kernel mailing list, total
of 357MB. I mostly wanted to see if the new binary tree file works well.
And it does :) Nothing gets slowed down after deleting messages all
around the mailbox.

I tried several things with Dovecot, UW-IMAPd and Courier. You'll see
that Dovecot is faster in everything else except raw I/O which is a bit
strange, have to look why.

I think the most important thing anyway is the time spent opening
mailbox. Clients are doing "STATUS mailbox (UNSEEN)" very often and that
has to be fast. With Dovecot it's so small that I didn't even bother
adding it to the benchmarks, with UW-IMAPd it's 16 seconds, with courier
2 seconds.

Full results can be found at
http://dovecot.procontrol.fi/dovecot-benchmark.txt


From tss@iki.fi  Tue Oct  8 03:33:27 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 08 Oct 2002 03:33:27 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 1C9832382D
	for <dovecot@procontrol.fi>; Tue,  8 Oct 2002 03:33:27 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 469EE5E015A0; Tue,  8 Oct 2002 03:33:26 +0300 (EEST)
Subject: [dovecot] Re: Benchmarks - updated for Cyrus
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <1034026995.782.15.camel@hurina>
References: <1034026995.782.15.camel@hurina>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1034037205.770.6.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 08 Oct 2002 03:33:26 +0300
X-archive-position: 36
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 36                                                  
Status: O

On Tue, 2002-10-08 at 00:43, Timo Sirainen wrote:
> Full results can be found at
> http://dovecot.procontrol.fi/dovecot-benchmark.txt

Updated to contain Cyrus benchmarks as well. Cyrus' BODY and ENVELOPE
fetches are equilevant to Dovecot's "BODY and ENVELOPE cached"
benchmarks.

So, we slightly beat Cyrus in many things, EXPUNGE most notably. BODY[]
fetching is slower probably because of our I/O problems, and possibly
also because we didn't store messages with CR+LFs (in which case we
would use sendfile(), and that should be _fast_).

We're also slow with message flag changes because maildir requires
rename()ing the mail files, we could later add optimization not to do it
but rely on flags specified in index file.


From tss@iki.fi  Tue Oct  8 06:23:31 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 08 Oct 2002 06:23:31 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 6DFF12382B
	for <dovecot@procontrol.fi>; Tue,  8 Oct 2002 06:23:31 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 466A25E015A0; Tue,  8 Oct 2002 06:23:31 +0300 (EEST)
Subject: [dovecot] Re: Benchmarks - updated for Cyrus
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <1034037205.770.6.camel@hurina>
References: <1034026995.782.15.camel@hurina> <1034037205.770.6.camel@hurina>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1034047411.780.5.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 08 Oct 2002 06:23:31 +0300
X-archive-position: 37
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 37                                                  
Status: O

On Tue, 2002-10-08 at 03:33, Timo Sirainen wrote:

> So, we slightly beat Cyrus in many things, EXPUNGE most notably. BODY[]
> fetching is slower probably because of our I/O problems, and possibly
> also because we didn't store messages with CR+LFs (in which case we
> would use sendfile(), and that should be _fast_).

Actually, after trying again a few more times (rebooting between),
Cyrus' BODY[] got much slower. Updated the benchmark once more, now
added Dovecot with CR+LF and Dovecot with 32bit file offsets (default is
64bit).



From tss@iki.fi  Thu Oct 10 04:40:09 2002
Received: with ECARTIS (v1.0.0; list dovecot); Thu, 10 Oct 2002 04:40:09 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 745FB2382B
	for <dovecot@procontrol.fi>; Thu, 10 Oct 2002 04:40:09 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id F269E5E03E5C; Thu, 10 Oct 2002 04:40:08 +0300 (EEST)
Subject: [dovecot] Re: Benchmarks - updated for Cyrus
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <1034047411.780.5.camel@hurina>
References: <1034026995.782.15.camel@hurina> <1034037205.770.6.camel@hurina>
	 <1034047411.780.5.camel@hurina>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1034214008.770.7.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 10 Oct 2002 04:40:08 +0300
X-archive-position: 38
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 38                                                  
Status: O

On Tue, 2002-10-08 at 06:23, Timo Sirainen wrote:
> Actually, after trying again a few more times (rebooting between),
> Cyrus' BODY[] got much slower. Updated the benchmark once more, now
> added Dovecot with CR+LF and Dovecot with 32bit file offsets (default is
> 64bit).

After 3 hours of tweaking which didn't make much difference, I finally
tried if filesystem had any effect on the speed. It had. A lot. Using
the same mail files as Cyrus, I got the time going from 2:32 down to
1:41. Cyrus used 2:25 to do the same, meaning we easily beat Cyrus.

Now, uw-imapd is still faster with mbox handling..


From faulerhund@faulerhund.net  Sat Oct 12 18:26:54 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 12 Oct 2002 18:26:55 +0300 (EEST)
Return-Path: <faulerhund@faulerhund.net>
Delivered-To: dovecot@procontrol.fi
Received: from moutvdom.kundenserver.de (moutvdom.kundenserver.de [195.20.224.200])
	by danu.procontrol.fi (Postfix) with ESMTP id D6D972382D
	for <dovecot@procontrol.fi>; Sat, 12 Oct 2002 18:26:54 +0300 (EEST)
Received: from [195.20.224.206] (helo=mrvdomng.kundenserver.de)
	by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1)
	id 180OAI-0001FX-00
	for dovecot@procontrol.fi; Sat, 12 Oct 2002 17:26:54 +0200
Received: from [217.84.28.114] (helo=mobilo)
	by mrvdomng.kundenserver.de with smtp (Exim 3.35 #1)
	id 180OAH-0002wH-00
	for dovecot@procontrol.fi; Sat, 12 Oct 2002 17:26:53 +0200
Message-ID: <000e01c27203$e947a450$1964a8c0@mobilo>
From: "Korbinian Riedhammer" <faulerhund@faulerhund.net>
To: <dovecot@procontrol.fi>
Subject: [dovecot] auth problem
Date: Sat, 12 Oct 2002 17:27:43 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-archive-position: 39
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: faulerhund@faulerhund.net
Precedence: bulk
X-list: dovecot
X-UID: 39                                                  
Status: O

hi, im facing this problem:
Fatal: can't listen in UNIX socket /var/rin/dovecot/login/
/usr/lib/dovecot/imap-login: No such file or directory
Errror: child xxxxx (auth) returned error 98

any idea?

- bini


From sean@tcob1.net  Sat Oct 12 19:18:50 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 12 Oct 2002 19:18:50 +0300 (EEST)
Return-Path: <sean@tcob1.net>
Delivered-To: dovecot@procontrol.fi
Received: from s2.uklinux.net (smtp2.uklinux.net [80.84.64.30])
	by danu.procontrol.fi (Postfix) with ESMTP id 17E9D2382B
	for <dovecot@procontrol.fi>; Sat, 12 Oct 2002 19:18:50 +0300 (EEST)
Received: from tcob1.net (y-airlock008.esatclear.ie [213.202.165.8])
	(authenticated)
	by s2.uklinux.net (8.11.6/8.11.6) with ESMTP id g9CGIm916110
	for <dovecot@procontrol.fi>; Sat, 12 Oct 2002 17:18:48 +0100
Envelope-To: <dovecot@procontrol.fi>
Received: from [192.168.0.1] (helo=tcob1.net.tcob1.net ident=sean)
	by tcob1.net with asmtp (Exim 4.10)
	id 180OyZ-00020q-00
	for dovecot@procontrol.fi; Sat, 12 Oct 2002 17:18:51 +0100
Date: Sat, 12 Oct 2002 17:18:38 +0100
Message-ID: <m365w73a1t.wl@tcob1.net>
From: Sean Rima <sean@tcob1.net>
To: dovecot@procontrol.fi
Subject: [dovecot] replacing Courier imapd
User-Agent: Wanderlust/2.9.15 (Unchained Melody) SEMI/1.14.3 (Ushinoya)
 FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2
 (i586-pc-linux-gnu) MULE/5.0 (SAKAKI)
Organization: There Can Only Be 1
X-Home-Page: http://www.tcob1.net
X-GPG-Key-FingerPrint: AB0A 3748 9565 1BFD 4E77  D9D5 1CC9 D25A 7DA7 0294
X-GPG-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7DA70294
X-OS: Linux 2.4.19
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
X-archive-position: 40
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: sean@tcob1.net
Precedence: bulk
X-list: dovecot
X-UID: 40                                                  
Status: O

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

Hi folks,

I currently use courier imapd, exim and ldap on my mail box. There are
no users on this box, all info is taken from the ldap server. I note
that dovecot does not use ldap as a backend, but curious if this in on
the cards, or even mysql backend.

Sean
- -- 
  Sean Rima                                http://www.tcob1.net
  Linux User:      231986          Jabber:   tcobone@jabber.org
  THE VIEWS EXPRESSED HERE ARE NOT NECESSARILY THOSE OF MY WIFE.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
Comment: Use GPG for Secure Mail

iD8DBQE9qEs4HMnSWn2nApQRAn22AJ4xdGWfpxAuY8dLDuHM/XUAXms0mwCfZJzk
ZD8cTK98j7f7CGcu1OENJXI=
=BS5M
-----END PGP SIGNATURE-----

From tss@iki.fi  Sat Oct 12 20:42:41 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 12 Oct 2002 20:42:41 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id B9BC12382D
	for <dovecot@procontrol.fi>; Sat, 12 Oct 2002 20:42:41 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 7E8C95E03E5C; Sat, 12 Oct 2002 20:42:41 +0300 (EEST)
Subject: [dovecot] Re: auth problem
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <000e01c27203$e947a450$1964a8c0@mobilo>
References: <000e01c27203$e947a450$1964a8c0@mobilo>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1034444559.30856.52.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 12 Oct 2002 20:42:41 +0300
X-archive-position: 41
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 41                                                  
Status: O

On Sat, 2002-10-12 at 18:27, Korbinian Riedhammer wrote:
> hi, im facing this problem:
> Fatal: can't listen in UNIX socket /var/rin/dovecot/login/
> /usr/lib/dovecot/imap-login: No such file or directory
> Errror: child xxxxx (auth) returned error 98

Well, that error message at least looks a bit strange. Is that one or
two error messages? The first one should continue but it instead shows
two paths .. plus typo in /var/rin.

Anyway, probably something wrong in your config file, maybe you've tried
to add some path to "auth = xxx"? If not, send the whole file to me and
I'll see what's wrong.

Does /var/run/dovecot/login exist? And /usr/lib/dovecot/imap-login?
You did do make install, right?


From tss@iki.fi  Sat Oct 12 20:46:54 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 12 Oct 2002 20:46:54 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 770472382D
	for <dovecot@procontrol.fi>; Sat, 12 Oct 2002 20:46:54 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 42A2D5E03E5C; Sat, 12 Oct 2002 20:46:54 +0300 (EEST)
Subject: [dovecot] Re: replacing Courier imapd
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <m365w73a1t.wl@tcob1.net>
References: <m365w73a1t.wl@tcob1.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1034444814.30856.58.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 12 Oct 2002 20:46:54 +0300
X-archive-position: 42
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 42                                                  
Status: O

On Sat, 2002-10-12 at 19:18, Sean Rima wrote:

> I currently use courier imapd, exim and ldap on my mail box. There are
> no users on this box, all info is taken from the ldap server. I note
> that dovecot does not use ldap as a backend, but curious if this in on
> the cards, or even mysql backend.

It wouldn't be hard to implement them, but they're not high on my
TODO-list yet. If anyone else doesn't write them, I eventually will. 

They would be possible through vpopmail though, since it supports them
and Dovecot supports vpopmail. I wouldn't really encourage using
vpopmail though, doesn't look very secure.


From tss@iki.fi  Tue Oct 15 04:16:57 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 15 Oct 2002 04:16:57 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 13D9A2382D
	for <dovecot@procontrol.fi>; Tue, 15 Oct 2002 04:16:57 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id D9E845E015A0; Tue, 15 Oct 2002 04:16:56 +0300 (EEST)
Subject: [dovecot] More documentation
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1034644616.24679.4.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 15 Oct 2002 04:16:56 +0300
X-archive-position: 43
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 43                                                  
Status: O

I just wrote a bit of documentation. Probably not very well organized,
improvement suggestions welcome :)

http://dovecot.procontrol.fi/doc/INSTALL
http://dovecot.procontrol.fi/doc/configuration.txt
http://dovecot.procontrol.fi/doc/mail-storages.txt

Those are also in the main dovecot.procontrol.fi web page. They also
talk about a few features not yet in CVS..


From faulerhund@faulerhund.net  Tue Oct 15 22:47:16 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 15 Oct 2002 22:47:16 +0300 (EEST)
Return-Path: <faulerhund@faulerhund.net>
Delivered-To: dovecot@procontrol.fi
Received: from moutvdom.kundenserver.de (moutvdom.kundenserver.de [195.20.224.131])
	by danu.procontrol.fi (Postfix) with ESMTP id 76DA02382D
	for <dovecot@procontrol.fi>; Tue, 15 Oct 2002 22:47:16 +0300 (EEST)
Received: from [195.20.224.206] (helo=mrvdomng.kundenserver.de)
	by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1)
	id 181Xes-0007dC-00
	for dovecot@procontrol.fi; Tue, 15 Oct 2002 21:47:14 +0200
Received: from [217.235.92.239] (helo=Bini)
	by mrvdomng.kundenserver.de with smtp (Exim 3.35 #1)
	id 181Xer-0001oK-00
	for dovecot@procontrol.fi; Tue, 15 Oct 2002 21:47:13 +0200
Message-ID: <000b01c27484$608af620$0164a8c0@Bini>
From: "Korbinian Riedhammer" <faulerhund@faulerhund.net>
To: <dovecot@procontrol.fi>
Subject: [dovecot] still problems getting it to work
Date: Tue, 15 Oct 2002 21:52:21 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-archive-position: 44
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: faulerhund@faulerhund.net
Precedence: bulk
X-list: dovecot
X-UID: 44                                                  
Status: O
Content-Length: 1645

hi all,
after havong some other trouble with my server i finally managed to
recompile and install dovecot. installed it in /usr/local (the dafault).
below u see a dump of my config file. i want to use "normal" shadow
passwords for authentification. i adjustet the pathes from /usr/ to
/usr/local/. when i login with outlook express 4 example i get the error:
unsupported authentification method. (my system isn't configured for shadow
md5). in the error log i get the the /dev/urandom is needed but not found,
well but i have it :)
maybe a chroot setting?

thx bini

imap_port = 143
#imaps_port = 993
imap_listen =
#imaps_listen =
#ssl_cert_file = /etc/ssl/certs/imapd.pem
#ssl_key_file = /etc/ssl/private/imapd.pem
disable_plaintext_auth = no
log_path = /var/log/imapd.log
log_timestamp = %d %H:%M:%S
login_executable = /usr/local/lib/dovecot/imap-login
login_user = imapd
login_dir = /var/run/dovecot/login
login_chroot = yes
login_processes_count = 1
max_logging_users = 256
imap_executable = /usr/local/lib/dovecot/imap
max_imap_processes = 1024
first_valid_uid = 1000
#last_valid_uid = 0
first_valid_gid = 101
last_valid_gid = 101
valid_chroot_dirs = /var/run/dovecot
maildir_copy_with_hardlinks = no
maildir_check_content_changes = no
overwrite_incompatible_index = yes
umask = 0077
auth = default
auth_methods = plain
#auth_realms =
auth_userinfo = shadow
auth_executable = /usr/local/lib/dovecot/imap-auth
auth_user = root
auth_chroot = /var/run/dovecot
auth_count = 1
#auth = digest_md5
#auth_methods = digest-md5
#auth_realms =
#auth_userinfo = passwd-file /etc/passwd.imap
#auth_user = imapauth
#auth_chroot = /var/run/dovecot/auth



From tss@iki.fi  Tue Oct 15 23:38:37 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 15 Oct 2002 23:38:37 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id D3448238A3
	for <dovecot@procontrol.fi>; Tue, 15 Oct 2002 23:38:37 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 4EC045E107F9; Tue, 15 Oct 2002 23:38:34 +0300 (EEST)
Subject: [dovecot] Re: still problems getting it to work
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <000b01c27484$608af620$0164a8c0@Bini>
References: <000b01c27484$608af620$0164a8c0@Bini>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1034714314.24679.17.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 15 Oct 2002 23:38:34 +0300
X-archive-position: 45
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 45                                                  
Status: O

On Tue, 2002-10-15 at 22:52, Korbinian Riedhammer wrote:
> hi all,
> after havong some other trouble with my server i finally managed to
> recompile and install dovecot. installed it in /usr/local (the dafault).
> below u see a dump of my config file. i want to use "normal" shadow
> passwords for authentification. i adjustet the pathes from /usr/ to
> /usr/local/. when i login with outlook express 4 example i get the error:
> unsupported authentification method. (my system isn't configured for shadow
> md5). in the error log i get the the /dev/urandom is needed but not found,
> well but i have it :)
> maybe a chroot setting?

You're right, it's the auth_chroot which breaks it. I fixed it in CVS
now.  But your auth process is still running as root, which makes
chrooting pretty useless, so just disable it.


From tss@iki.fi  Tue Oct 15 23:57:35 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 15 Oct 2002 23:57:35 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id BD343238A3
	for <dovecot@procontrol.fi>; Tue, 15 Oct 2002 23:57:35 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 801965E107F9; Tue, 15 Oct 2002 23:57:35 +0300 (EEST)
Subject: [dovecot] Re: still problems getting it to work
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <000b01c27484$608af620$0164a8c0@Bini>
References: <000b01c27484$608af620$0164a8c0@Bini>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1034715455.24679.22.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 15 Oct 2002 23:57:35 +0300
X-archive-position: 46
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 46                                                  
Status: O

On Tue, 2002-10-15 at 22:52, Korbinian Riedhammer wrote:
> hi all,
> after havong some other trouble with my server i finally managed to
> recompile and install dovecot. installed it in /usr/local (the dafault).
> below u see a dump of my config file. i want to use "normal" shadow
> passwords for authentification. i adjustet the pathes from /usr/ to
> /usr/local/.

Path changing isn't needed btw. Dovecot uses automatically the paths
given with --prefix if they're not set in config file.

>  when i login with outlook express 4 example i get the error:
> unsupported authentification method. (my system isn't configured for shadow
> md5). in the error log i get the the /dev/urandom is needed but not found,
> well but i have it :)
> maybe a chroot setting?

Also chrooting wouldn't work anyway with shadow authentication since it
can't open /etc/shadow. I also just tried to see if opening shadow
database before chrooting would work, but it doesn't, probably because
it wants to reopen the file if it has changed.


From thomas@xs4all.net  Sat Oct 19 15:39:57 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 15:39:57 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139])
	by danu.procontrol.fi (Postfix) with ESMTP id 163C1238A7
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 15:39:57 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9JCdus7052057
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 14:39:56 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id D6EDC2268; Sat, 19 Oct 2002 14:38:46 +0200 (CEST)
Date: Sat, 19 Oct 2002 14:38:46 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Architectural questions
Message-ID: <20021019123846.GK543@xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 47
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 47                                                  
Status: O
Content-Length: 8111


Greetings,

I have some architectural questions regarding dovecot, and though I've half
answered them by looking at the source, I'm also interested in hearing
whether my (our) wishes and suggestions are already being considered (or can
be considered, once built) for inclusion in dovecot itself.

Let me first explain why I'm doing this. I work for XS4ALL, a fairly large
ISP in the Netherlands. We provide a wide variety of services, including
shell access, pop3, webmail, et cetera. We use Sendmail on several clusters
of FreeBSD machines (loadbalanced using layer-4 ethernet switches) and
several NetApp Filers (dedicated NFS servers with fail-safe disk-arrays and
such) for backend. Several years ago (when we were a lot smaller) we noticed
the typical use of the mailboxes included leaving much old email on the
server, at least for a while, and that this is a bothersome thing when using
mbox mailboxes. (The mboxes basically have to be copied over whenever the
status of an email changes, leading to a lot of I/O.)

We briefly played with modifying sendmail and the pop server to avoid the
full copy in the common case (only status changes) by doing in-place edits
of a pre-generated Status line, as well as avoid full scanning of the mbox
file by creating special headers to mark the 'real' length of an email. It
worked, for a while, but it wasn't going to scale very well. So we switched
to maildir mailboxes for the mail spool. A modified mail.local (which we
need for other reasons as well) delivers in /var/spool/mail/u/s/username,
and mutt, uqwk, a modified pine and qmail's pop3 daemon read it from there.
Until last week our clients could choose to have mbox inboxes, to use with
'elm' or 'mail', but we decided to discontinue that support. Our new shell
servers, which are in test, don't have elm installed anymore anyway.

We still have support for mbox mailboxes in a user's homedirectory though,
by using procmail and such. So when we needed an IMAP server for use with
our webmail (based on SquirrelMail), we were forced to go with the UW-IMAP
server, with the maildir patch that's been scattered around the 'net. This
worked, for a while; we also use the maildir patch with pine after all.
However, the maildir patch is not very good. Not at all, even, and it only
seems to work by pure chance. Pine works for the average user who does not
get a lot of new mail while his pine is open or does not use procmail, and
fortunately a lot of the people that do get a lot of email use mutt, which
does work properly. The UW-IMAP server worked fine because SquirrelMail only
uses (used) a small subset of the available functionality. But that's
changing, as SquirrelMail gets actively developed, and we're also
considering other IMAP-based services. But we can't switch to Courier or
Cyrus because we need mbox support. And while looking for mbox patches for
either of those two, I ran across dovecot. Yay! :)

Dovecot is not everything we'd want, but it comes very close, and contrary
to UW-IMAP both the design and the actual source code are clean, readable
and logical, which means we can add the features we need and support them.
What we need and want to add is fairly simple, but I've only been looking at
dovecot since yesterday so I'd be happy to hear if any of it is possible,
feasible, unwise or unacceptable.

 - First off, we need the maildir support to be 'correct' in that it does
   not rely on the naming of the files in the mailbox, other than the very
   loose specification DJB gives (doesn't contain a colon or slash and
   doesn't start with a dot.) The pine/UW-imap patch breaks here because it
   depends on the first part of the filename being time() or something else
   that, when sorted alphanumerically, puts new mail at the end. Our
   LDA does this, but procmail does not, and it shouldn't have to.

 - Second, we need the maildir support to be 'correct' in that it does not
   rely on the directory order being persistant. The NetApp Filers use
   btree-indexed directories, so the order of readdir() can change
   completely whenever a file is added or removed. The pine/uw-imap patch
   relies on the '.uidvalidity' file being modified whenever the maildir sort
   order changed, and this isn't happening.

I *think*, from reading the sources, both of those are correct already. If
they aren't, I'd strongly urge you to fix it, as #1 is a problem for anyone
using procmail and #2 is a problem for anyone with 'indexed' directories
(including such new filesystems as reiserfs, and I assume FreeBSD's new
hashed directories.)

 - We need to avoid using fcntl(). The Netapps support it, but file-locking
   over NFS is very, very poorly designed and we've had too much problems of
   various kinds before, with fcntl. We also don't like the idea of having
   thousands of fcntl locks at the same time ;P Instead, we've switched to
   the locking method described in the Linux open(2) manpage under O_EXCL.
   (We call it 'dot-locking', I'm not sure where the name came from.)

   The actual implementation of that method is pretty simple, and I have a C
   version and a Python version hanging around here somewhere (the Python
   version is being used by GNU Mailman, last I looked.) If we're going to
   use dovecot, we will replace most, if not all, fcntl()s with dot-locking,
   the question is whether you want it contributed to dovecot :)

 - Every user's incoming mailbox is /var/spool/u/s/username. Other mailboxes
   are in /home/u/username/mail or /home/u/username/Mail (the second if the
   first does not exist.) We are not yet certain whether we want the inbox
   to be able to have subdir-mailboxes, as /var/spool and /home have
   different quotas and we urge people not to store their mail on
   /var/spool. (for one thing, it doesn't get backed-up.) We want these
   things to work without magical symlinks or empty files, because people
   _will_ delete them and cause unnecessary helpdesk calls :) Again, the
   question is mostly whether this is desirable in dovecot (or something
   enough like it to reduce local changes.)

 - We have over 300k mailboxes at the moment. We expect that number to keep
   growing. The indexer process (as described by design.txt) does not sound
   as a good idea in our case :) How necessary is it, really ? Especially
   since we do not expect more than 10% of those mailboxes to be actually
   used by IMAP, not even once. If disabling the indexer completely just
   means longer startup times for IMAP sessions, we can live with that.

 - The UW-IMAP maildir patch stores UID's in the indiviual filenames, using
   a 'U' flag. Will this interfere with dovecot ? We don't really need
   dovecot and UW-IMAP to share UIDs, but we would like to have an as
   painless transition as possible, without having to rename millions of
   files to remove the U flag and other flags :P It would also be nice to
   keep pine using the existing maildir patch, even though very few
   IMAP-users would use pine.

 - Would dovecot scale, architecturally speaking, to 500k+ active mailboxes ?
   The amount of hardware is not really an issue, we can add a lot of
   machines (off-the-shelve intel hadware) to each cluster, but if each
   dovecot process has to load in an index of all possible mailboxes... that
   would be a problem. Doing an inordinate number of file-accesses over NFS
   would also be a problem, but I haven't seen any indication of that in the
   source, yet.

In case it wasn't clear yet, I'm very happy to have found dovecot. The lack
of a decent mbox IMAP server has always dismayed me, let alone an
mbox+maildir one :) I should also point out that even though XS4ALL is a
commercial company, we would contribute our changes even if the licence
didn't require it, and we want to contribute them back the way you want
them, not necessarily the way it's easiest for us. We have a lot of
experience with opensource software, as a simple google on my name should
indicate ;P

Regards,
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From tss@iki.fi  Sat Oct 19 17:01:56 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 17:01:56 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id B8F982382D
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 17:01:55 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 822415E03E5C; Sat, 19 Oct 2002 17:01:55 +0300 (EEST)
Subject: [dovecot] Re: Architectural questions
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <20021019123846.GK543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035036115.1674.81.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 19 Oct 2002 17:01:55 +0300
X-archive-position: 48
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 48                                                  
Status: O
Content-Length: 8886

On Sat, 2002-10-19 at 15:38, Thomas Wouters wrote:

> We briefly played with modifying sendmail and the pop server to avoid the
> full copy in the common case (only status changes) by doing in-place edits
> of a pre-generated Status line,

UW-imapd does this as well, creating "X-Keywords:          " line for
each mail. I had thought about this first with dovecot too, but since
mutt rewrote the whole mailbox always I figured I might as well. But
with larger mailboxes this is really slow, so I think I'll support the
X-keywords trick myself too.

>  as well as avoid full scanning of the mbox
> file by creating special headers to mark the 'real' length of an email.

For each mail? Content-Length? With my tests that didn't seem to help
much, rather made it just slower.. Could be that I just did something
badly, have to look into it more when I begin optimizing mbox handling
more. Have to get it at least as fast as UW-imapd :)

> We still have support for mbox mailboxes in a user's homedirectory though,
> by using procmail and such. So when we needed an IMAP server for use with
> our webmail (based on SquirrelMail), we were forced to go with the UW-IMAP
> server, with the maildir patch that's been scattered around the 'net. This

Hm. Squirrelmail requires SORT extension which Dovecot doesn't support
yet. Notes about SORT from CVS's TODO:

 - sort (draft-ietf-imapext-sort)
    - basically sorted SEARCH, requiring CHARSET support for
      UTF-8 and ASCII
    - we could create alternative binary tree file(s) for different sort
      conditions, ".tree-sort" or something. or if we decide to just
      keep it in memory, btree could still be best choice.
    - required by squirrelmail (webmail)

>  - First off, we need the maildir support to be 'correct' in that it does
>    not rely on the naming of the files in the mailbox, other than the very
>    loose specification DJB gives (doesn't contain a colon or slash and
>    doesn't start with a dot.) The pine/UW-imap patch breaks here because it
>    depends on the first part of the filename being time() or something else
>    that, when sorted alphanumerically, puts new mail at the end. Our
>    LDA does this, but procmail does not, and it shouldn't have to.

Dovecot doesn't care as long as the file name stays same before the ':'
character.

>  - Second, we need the maildir support to be 'correct' in that it does not
>    rely on the directory order being persistant. The NetApp Filers use
>    btree-indexed directories, so the order of readdir() can change
>    completely whenever a file is added or removed. The pine/uw-imap patch
>    relies on the '.uidvalidity' file being modified whenever the maildir sort
>    order changed, and this isn't happening.

Dovecot reads them into hash so it doesn't depend on readdir()
behaviour.

>  - We need to avoid using fcntl(). The Netapps support it, but file-locking
>    over NFS is very, very poorly designed and we've had too much problems of
>    various kinds before, with fcntl. We also don't like the idea of having
>    thousands of fcntl locks at the same time ;P Instead, we've switched to
>    the locking method described in the Linux open(2) manpage under O_EXCL.
>    (We call it 'dot-locking', I'm not sure where the name came from.)

Hmm. The dot-lock means the "mbox.lock" file which gets created when
someone wants it exclusively locked. Dovecot supports it, and maildir
itself doesn't need locking at all. Dovecot's index files currently use
fcntl()-locking, but it would be possible to replace them with lock
files.

Then there's modify log file. Dovecot uses fcntl() locking for it as a
way to figure out if it's the only one using the log file. Like make
everyone read-lock the file, then if someone wants to know if it's the
only one using it it tries to set write-lock on, if it fails it knows
someone else it using it as well. I'm not sure if there's any good way
to replace that by using files, I had pretty complicated (desperate)
plans before figuring out fcntl() could be used to do it easily.

It would be possible to just assume that there's always someone else
using the modify log, but each flag change or expunge would always write
a few bytes to it then, and when log file is switched (there's .log and
.log.2) it wouldn't be truncated after last process is finished with it
which is not too bad since after the next switch it will be truncated.

Also it would be possible not to use index files at all but just keep
them in memory. I've been fixing code to make this possible and somewhat
fast.

> If we're going to
>    use dovecot, we will replace most, if not all, fcntl()s with dot-locking,
>    the question is whether you want it contributed to dovecot :)

All locking goes through file_*_lock() or mbox_lock_*() functions. mbox
locking supports it already, and file_*_lock() could be made to support
it. It doesn't get currently file name but that could be done.

>  - Every user's incoming mailbox is /var/spool/u/s/username. Other mailboxes
>    are in /home/u/username/mail or /home/u/username/Mail (the second if the
>    first does not exist.) We are not yet certain whether we want the inbox
>    to be able to have subdir-mailboxes, as /var/spool and /home have
>    different quotas and we urge people not to store their mail on
>    /var/spool. (for one thing, it doesn't get backed-up.) We want these
>    things to work without magical symlinks or empty files, because people
>    _will_ delete them and cause unnecessary helpdesk calls :) Again, the
>    question is mostly whether this is desirable in dovecot (or something
>    enough like it to reduce local changes.)

Are maildir inboxes also in /var/spool? With mbox sub-inboxes wouldn't
be even possible because dir structure == mailbox structure, and since
inbox file exists there can't be inbox-dir (except maybe with different
case but that's kludgy).

I've also thought I might as well make it possible to read the mbox
inbox from /var/mail or whereever it is. Pretty easy to do, but .lock
file is problematic if new files can't be added to the /var/mail
directory.

>  - We have over 300k mailboxes at the moment. We expect that number to keep
>    growing. The indexer process (as described by design.txt) does not sound
>    as a good idea in our case :) How necessary is it, really ? Especially
>    since we do not expect more than 10% of those mailboxes to be actually
>    used by IMAP, not even once. If disabling the indexer completely just
>    means longer startup times for IMAP sessions, we can live with that.

Indexer doesn't exist yet, and wouldn't be really needed even. I still
think it could be somewhat nice idea, the system load is probably less
during night so we could use the extra time to make mailboxes perform
faster next day.

It'd be difficult to know when exactly there is "extra time" which is
why I haven't yet done the indexer. Probably needs some external program
(script) which tells it by maybe looking at some I/O statistics from
/proc or doing a few file operations and checking the latency.

Am I right in that CPU usage still isn't any problem but rather the I/O?

>  - The UW-IMAP maildir patch stores UID's in the indiviual filenames, using
>    a 'U' flag. Will this interfere with dovecot ? We don't really need
>    dovecot and UW-IMAP to share UIDs, but we would like to have an as
>    painless transition as possible, without having to rename millions of
>    files to remove the U flag and other flags :P It would also be nice to
>    keep pine using the existing maildir patch, even though very few
>    IMAP-users would use pine.

How exactly does the U flag work? I hope it's before the ':' character
like Courier's S=filesize? Otherwise U=1234 would be thought of as 6
different flags which isn't very good since Dovecot reorders them as
1234=U.

>  - Would dovecot scale, architecturally speaking, to 500k+ active mailboxes ?
>    The amount of hardware is not really an issue, we can add a lot of
>    machines (off-the-shelve intel hadware) to each cluster, but if each
>    dovecot process has to load in an index of all possible mailboxes... that
>    would be a problem. Doing an inordinate number of file-accesses over NFS
>    would also be a problem, but I haven't seen any indication of that in the
>    source, yet.

Dovecot opens the index when opening mailbox. It doesn't open other
mailboxes indexes. Also the indexes should make the file accesses less
than otherwise, especially with mbox since it wouldn't need to read and
parse the whole mbox file. In general I've tried to keep the file I/O as
little as possible.

If your clusters access the files through NFS, there should be no
problem. Except I've never tried Dovecot through NFS, and I'm not sure
how well mmap()ing works through NFS. I know there's been problems
before but hopefully they've been fixed already.



From thomas@xs4all.net  Sat Oct 19 18:11:38 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 18:11:38 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139])
	by danu.procontrol.fi (Postfix) with ESMTP id F2204238A7
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 18:11:37 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9JFBbW0074539;
	Sat, 19 Oct 2002 17:11:37 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id 9191F2268; Sat, 19 Oct 2002 17:10:26 +0200 (CEST)
Date: Sat, 19 Oct 2002 17:10:26 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: Timo Sirainen <tss@iki.fi>
Cc: dovecot@procontrol.fi
Bcc: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021019151026.GM543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1035036115.1674.81.camel@hurina>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 49
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 49                                                  
Status: O
Content-Length: 7406

On Sat, Oct 19, 2002 at 05:01:55PM +0300, Timo Sirainen wrote:
> On Sat, 2002-10-19 at 15:38, Thomas Wouters wrote:

> > We briefly played with modifying sendmail and the pop server to avoid the
> > full copy in the common case (only status changes) by doing in-place edits
> > of a pre-generated Status line,

> UW-imapd does this as well, creating "X-Keywords:          " line for
> each mail. I had thought about this first with dovecot too, but since
> mutt rewrote the whole mailbox always I figured I might as well. But
> with larger mailboxes this is really slow, so I think I'll support the
> X-keywords trick myself too.

Well, for POP3 servers the story is a bit different than IMAP. The typical
use we were seeing was "user", "pass", "list", "retr <new mail>", "quit".
Sometimes (for some users) every few minutes. In that case, having to write
a 'RO' at a specific location in a large mbox is oodles more efficient than
copying the whole thing to local disk and back again (which is what the
popserver would do.) I'm not sure if it matters much with typical IMAP
usage.

> > as well as avoid full scanning of the mbox file by creating special
> > headers to mark the 'real' length of an email.

> For each mail? Content-Length? With my tests that didn't seem to help
> much, rather made it just slower.. Could be that I just did something
> badly, have to look into it more when I begin optimizing mbox handling
> more. Have to get it at least as fast as UW-imapd :)

Well, if I recall correctly, we added an 'X-Offset' header which pointed to
the exact (relative) byte offset for the next 'From ' line. It made our
pop3d (a modified qpopper 2.3 by the way) a much happier puppy. I'm not sure
what the difference with Content-Length was. I could find the sources, I
suppose; since we disabled mbox-inbox support we aren't using that code
anymore.

> > We still have support for mbox mailboxes in a user's homedirectory though,
> > by using procmail and such. So when we needed an IMAP server for use with
> > our webmail (based on SquirrelMail), we were forced to go with the UW-IMAP
> > server, with the maildir patch that's been scattered around the 'net. This

> Hm. Squirrelmail requires SORT extension which Dovecot doesn't support
> yet.

Ah, that's a shame. It means we can't use dovecot for our internal
SquirrelMail+IMAP testing yet :) We likely wouldn't start using dovecot for
production SquirrelMail anytime soon anyway, so it's not a big issue right
now... We'll have to see if our other uses of IMAP require it or not.

> Dovecot doesn't care [about maildir-message filenames] as long as the file
> name stays same before the ':' character.

They do.

> It would be possible to just assume that there's always someone else
> using the modify log, but each flag change or expunge would always write
> a few bytes to it then, and when log file is switched (there's .log and
> .log.2) it wouldn't be truncated after last process is finished with it
> which is not too bad since after the next switch it will be truncated.

> Also it would be possible not to use index files at all but just keep
> them in memory. I've been fixing code to make this possible and somewhat
> fast.

Hmm. I'd have to look at the code to say for sure, but I think we could live
with keeping them in memory. Accessing the same mailbox from two different
clients at the same time is not something we're too worried about, at the
moment.

> >  - Every user's incoming mailbox is /var/spool/u/s/username.

> Are maildir inboxes also in /var/spool? 

Yes. We don't use the ~/Maildir structure at all. We've always simply used
maildir mailboxes as a directly replacement of mbox mailboxes; a directory
instead of a file, and no sub-boxes :) I guess it's a philosphical
difference. To me, and to my colleagues, everything can be a mailbox, not
just something stored in an arbitrary directory somewhere. I guess we could
change that position, if necessary, but so far it hasn't proven to be.

> With mbox sub-inboxes wouldn't be even possible because dir structure ==
> mailbox structure, and since inbox file exists there can't be inbox-dir
> (except maybe with different case but that's kludgy).

Yes... don't worry, we don't even want to consider mbox-subboxes :)

> I've also thought I might as well make it possible to read the mbox
> inbox from /var/mail or whereever it is. Pretty easy to do, but .lock
> file is problematic if new files can't be added to the /var/mail
> directory.

Our /var/spool/mail subdirectories are mode 01733 (drwx-wx-wt) owned by
root, so creating files and removing them is not an issue, but reading the
directory is. You can of course still check for existance of specific
filenames.

> Am I right in that CPU usage still isn't any problem but rather the I/O?

Yes. As I said, we use several netapp filers (currently two for /home and
two for /var/spool/mail, with several hundred gigabytes filespace each) and
though they're great boxes, their performance does tend to drop off when it
gets flooded with I/O requests :) And they're used by a lot of machines, so
if they are slow to respond, a lot of our services do too.

> >  - The UW-IMAP maildir patch stores UID's in the indiviual filenames, using
> >    a 'U' flag. Will this interfere with dovecot ? We don't really need
> >    dovecot and UW-IMAP to share UIDs, but we would like to have an as
> >    painless transition as possible, without having to rename millions of
> >    files to remove the U flag and other flags :P It would also be nice to
> >    keep pine using the existing maildir patch, even though very few
> >    IMAP-users would use pine.

> How exactly does the U flag work? I hope it's before the ':' character
> like Courier's S=filesize? Otherwise U=1234 would be thought of as 6
> different flags which isn't very good since Dovecot reorders them as
> 1234=U.

No, it can't be before the :, because the UID is generated by UW-IMAP, and
the maildir spec says you can't change the uniqe part of the name, just the
info :) Here are some examples. The ',U*' is the UID.

_k2,6NtZ9.maildrop4.xs4all.nl:2,S,U1030712092
_fmT,O63l8.maildrop8.xs4all.nl:2,RS,U1026644784
990612135.16312.000000002.maildrop2.xs4all.nl:2,S,U991994304
993058841.maildrop7.49267:2,S,U993058888

(In case you're wondering, the first two files were created by standard
procmail, the third by our modified procmail which tries to allow for the
pine/uw-imap maildir patch, and the last is our mail.local's format.)

As long as dovecot doesn't read a different meaning into those flags
(ignoring them is just fine) we should be fine. I don't think we'll have
many customers switching back and forth between dovecot and UW-IMAP, just
people switching from UW-IMAP to dovecot.

> If your clusters access the files through NFS, there should be no
> problem. Except I've never tried Dovecot through NFS, and I'm not sure
> how well mmap()ing works through NFS. I know there's been problems
> before but hopefully they've been fixed already.

I'm not too worried about bugs. I've yet to see a piece of software that we
don't find oodles of small and large bugs in just by installing and trying
to run on our clientbase. That's what testing is for :) But I wouldn't mind
being happily suprised by dovecot, we'll see :)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From tss@iki.fi  Sat Oct 19 18:53:44 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 18:53:44 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id C511F2382D
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 18:53:43 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 941B65E03E5C; Sat, 19 Oct 2002 18:53:43 +0300 (EEST)
Subject: [dovecot] Re: Architectural questions
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Bcc: dovecot@procontrol.fi
In-Reply-To: <20021019151026.GM543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl>
	 <1035036115.1674.81.camel@hurina>  <20021019151026.GM543@xs4all.nl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035042823.1679.127.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 19 Oct 2002 18:53:43 +0300
X-archive-position: 50
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 50                                                  
Status: O
Content-Length: 4750

On Sat, 2002-10-19 at 18:10, Thomas Wouters wrote:
> Well, if I recall correctly, we added an 'X-Offset' header which pointed to
> the exact (relative) byte offset for the next 'From ' line. It made our
> pop3d (a modified qpopper 2.3 by the way) a much happier puppy. I'm not sure
> what the difference with Content-Length was. I could find the sources, I
> suppose; since we disabled mbox-inbox support we aren't using that code
> anymore.

Content-Length saves just the size of mail body, so it can be skipped
over. I implemented it mostly because mutt doesn't escape the "From "
lines when saving mails so it was a bit difficult sometimes to figure
out if the From-line means a new mail or if it was just written into the
mail body.

I'm not sure what I should do with Dovecot, both From-line escaping and
Content-Length writing makes it annoyingly slower then now with more 
code..

> > Also it would be possible not to use index files at all but just keep
> > them in memory. I've been fixing code to make this possible and somewhat
> > fast.
> 
> Hmm. I'd have to look at the code to say for sure, but I think we could live
> with keeping them in memory. Accessing the same mailbox from two different
> clients at the same time is not something we're too worried about, at the
> moment.

Well, Outlook (and OE I think) opens two simultaneous connections
sometimes to fetch mails.

Not having index files doesn't affect the possibility to have multiple
connections, but it affects the overall performance because it needs to
do more I/O, especially with mbox.

> > I've also thought I might as well make it possible to read the mbox
> > inbox from /var/mail or whereever it is. Pretty easy to do, but .lock
> > file is problematic if new files can't be added to the /var/mail
> > directory.
> 
> Our /var/spool/mail subdirectories are mode 01733 (drwx-wx-wt) owned by
> root, so creating files and removing them is not an issue, but reading the
> directory is. You can of course still check for existance of specific
> filenames.

OK, no problem then.

> > How exactly does the U flag work? I hope it's before the ':' character
> > like Courier's S=filesize? Otherwise U=1234 would be thought of as 6
> > different flags which isn't very good since Dovecot reorders them as
> > 1234=U.
> 
> No, it can't be before the :, because the UID is generated by UW-IMAP, and
> the maildir spec says you can't change the uniqe part of the name, just the
> info :) Here are some examples. The ',U*' is the UID.
> 
> _k2,6NtZ9.maildrop4.xs4all.nl:2,S,U1030712092
> _fmT,O63l8.maildrop8.xs4all.nl:2,RS,U1026644784
> 990612135.16312.000000002.maildrop2.xs4all.nl:2,S,U991994304
> 993058841.maildrop7.49267:2,S,U993058888

Well, maildir spec also doesn't say you can add flags with parameters
using comma separators :) But I think that's good enough extension that
Dovecot could support as well.

Programs supporting Courier's Maildir++ quota writes the mails
immediately like "something,S=size". Something like that could have been
done by UID-capable mailers too, since UID won't change.

> As long as dovecot doesn't read a different meaning into those flags
> (ignoring them is just fine) we should be fine. I don't think we'll have
> many customers switching back and forth between dovecot and UW-IMAP, just
> people switching from UW-IMAP to dovecot.

Keeping the UIDs untouched when changing could be important to some
people whose mail clients can save some extra information related to
specific messages and use UID to identify the mails. I think Evolution
does this with it's labels and Follow-Up marks, but I'm not sure.

Dovecot currently doesn't try to keep the UIDs too heavily itself
either, if it notices some corruption it just recreates the index files
with new UIDs. Supporting in-memory indexes requires still saving the
UIDs somewhere in disk so this should get fixed while doing it.

> I'm not too worried about bugs. I've yet to see a piece of software that we
> don't find oodles of small and large bugs in just by installing and trying
> to run on our clientbase. That's what testing is for :) But I wouldn't mind
> being happily suprised by dovecot, we'll see :)

We've had 3 people using it for a few months now, one of them still gets
sometimes "message not found" error from Outlook Express, I've yet to
figure out when exactly that happens. The mail isn't lost and restarting
OE helps, so it's probably something to do with having those two
simultaneous connections (and I'm just now making bigger changes there).
Other than that it's worked quite fine :)

Then of course CVS has a lot large changes which haven't been tested
much yet. Hopefully I'll get them fixed well enough this weekend to be
able to start using it myself.


From tss@iki.fi  Sat Oct 19 19:11:49 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 19:11:49 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id D02AC2382D
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 19:11:49 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 9813D5E03E5C; Sat, 19 Oct 2002 19:11:49 +0300 (EEST)
Subject: [dovecot] Re: Architectural questions
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <20021019151026.GM543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl>
	 <1035036115.1674.81.camel@hurina>  <20021019151026.GM543@xs4all.nl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035043909.31051.140.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 19 Oct 2002 19:11:49 +0300
X-archive-position: 51
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 51                                                  
Status: O
Content-Length: 1060

On Sat, 2002-10-19 at 18:10, Thomas Wouters wrote:
> > Am I right in that CPU usage still isn't any problem but rather the I/O?
> 
> Yes. As I said, we use several netapp filers (currently two for /home and
> two for /var/spool/mail, with several hundred gigabytes filespace each) and
> though they're great boxes, their performance does tend to drop off when it
> gets flooded with I/O requests :) And they're used by a lot of machines, so
> if they are slow to respond, a lot of our services do too.

I was mostly wondering with this if the reason to add more computers to
cluster is because the imap processes are taking too much memory, too
much CPU or if neither of them is any problem and the cluster is just
for redundancy or because of other running programs.

I'd be interested to know how many dovecot processes could actually run
in a single computer especially with fast NFS file access :) I'd guess
it could run a lot, but when memory gets low the I/O usage raises since
it needs to read again the parts of indexes which got dropped from
memory.


From faulerhund@faulerhund.net  Sat Oct 19 19:24:01 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 19:24:02 +0300 (EEST)
Return-Path: <faulerhund@faulerhund.net>
Delivered-To: dovecot@procontrol.fi
Received: from moutvdom.kundenserver.de (moutvdom.kundenserver.de [195.20.224.130])
	by danu.procontrol.fi (Postfix) with ESMTP id D51E6238A7
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 19:24:01 +0300 (EEST)
Received: from [212.227.126.220] (helo=mrvdomng.kundenserver.de)
	by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1)
	id 182wON-00080b-00
	for dovecot@procontrol.fi; Sat, 19 Oct 2002 18:23:59 +0200
Received: from [217.229.166.89] (helo=Bini)
	by mrvdomng.kundenserver.de with smtp (Exim 3.35 #1)
	id 182wON-0001BG-00
	for dovecot@procontrol.fi; Sat, 19 Oct 2002 18:23:59 +0200
Message-ID: <003b01c2778c$a6884370$0164a8c0@Bini>
From: "Korbinian Riedhammer" <faulerhund@faulerhund.net>
To: "Dovecot Mailinglist" <dovecot@procontrol.fi>
Subject: [dovecot] still problems gettin it to work
Date: Sat, 19 Oct 2002 18:29:08 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-archive-position: 52
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: faulerhund@faulerhund.net
Precedence: bulk
X-list: dovecot
X-UID: 52                                                  
Status: O

i checked all my options again. could it be, that it is a problem with my
compiler? does dovecot support gcc3.2 with glibc 2.2.5?

korbinian


From tss@iki.fi  Sat Oct 19 19:27:45 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 19:27:45 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 4F2F5238A7
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 19:27:45 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 0ECE55E03E5C; Sat, 19 Oct 2002 19:27:45 +0300 (EEST)
Subject: [dovecot] Re: still problems gettin it to work
From: Timo Sirainen <tss@iki.fi>
To: Korbinian Riedhammer <faulerhund@faulerhund.net>
Cc: Dovecot Mailinglist <dovecot@procontrol.fi>
In-Reply-To: <003b01c2778c$a6884370$0164a8c0@Bini>
References: <003b01c2778c$a6884370$0164a8c0@Bini>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035044864.1674.143.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 19 Oct 2002 19:27:44 +0300
X-archive-position: 53
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 53                                                  
Status: O

On Sat, 2002-10-19 at 19:29, Korbinian Riedhammer wrote:
> i checked all my options again. could it be, that it is a problem with my
> compiler? does dovecot support gcc3.2 with glibc 2.2.5?

Well, what's the problem with it now? Didn't that /dev/urandom problem
go away with unsetting auth_chroot setting?


From faulerhund@faulerhund.net  Sat Oct 19 19:56:55 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 19:56:55 +0300 (EEST)
Return-Path: <faulerhund@faulerhund.net>
Delivered-To: dovecot@procontrol.fi
Received: from moutvdom.kundenserver.de (moutvdom.kundenserver.de [195.20.224.149])
	by danu.procontrol.fi (Postfix) with ESMTP id 699AF238A7
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 19:56:55 +0300 (EEST)
Received: from [212.227.126.220] (helo=mrvdomng.kundenserver.de)
	by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1)
	id 182wuE-0005AD-00
	for dovecot@procontrol.fi; Sat, 19 Oct 2002 18:56:54 +0200
Received: from [217.229.166.89] (helo=Bini)
	by mrvdomng.kundenserver.de with smtp (Exim 3.35 #1)
	id 182wuE-0002u1-00
	for dovecot@procontrol.fi; Sat, 19 Oct 2002 18:56:54 +0200
Message-ID: <005d01c27791$4011d930$0164a8c0@Bini>
From: "Korbinian Riedhammer" <faulerhund@faulerhund.net>
To: "Dovecot Mailinglist" <dovecot@procontrol.fi>
Subject: [dovecot] Re: still problems gettin it to work
Date: Sat, 19 Oct 2002 19:02:03 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-archive-position: 54
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: faulerhund@faulerhund.net
Precedence: bulk
X-list: dovecot
X-UID: 54                                                  
Status: O

well i didn't know what to change, cause u wrote that this change u did is
pretty useless rinning the prog as root, what i do. next thing that i dont
have any idea about cvs (beside knowing its meaning) and dont hav it
installed yet.


From tss@iki.fi  Sat Oct 19 19:59:22 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 19:59:22 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id C7B16238A7
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 19:59:22 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 99EA15E03E5C; Sat, 19 Oct 2002 19:59:22 +0300 (EEST)
Subject: [dovecot] Re: still problems gettin it to work
From: Timo Sirainen <tss@iki.fi>
To: Korbinian Riedhammer <faulerhund@faulerhund.net>
Cc: Dovecot Mailinglist <dovecot@procontrol.fi>
In-Reply-To: <005d01c27791$4011d930$0164a8c0@Bini>
References: <005d01c27791$4011d930$0164a8c0@Bini>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035046762.1674.148.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 19 Oct 2002 19:59:22 +0300
X-archive-position: 55
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 55                                                  
Status: O

On Sat, 2002-10-19 at 20:02, Korbinian Riedhammer wrote:
> well i didn't know what to change, cause u wrote that this change u did is
> pretty useless rinning the prog as root, what i do. next thing that i dont
> have any idea about cvs (beside knowing its meaning) and dont hav it
> installed yet.

Well, just don't set the auth_chroot and ignores the rest of what I
said. That should get it working.

From faulerhund@faulerhund.net  Sat Oct 19 20:04:30 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 20:04:30 +0300 (EEST)
Return-Path: <faulerhund@faulerhund.net>
Delivered-To: dovecot@procontrol.fi
Received: from moutvdom.kundenserver.de (moutvdom.kundenserver.de [195.20.224.200])
	by danu.procontrol.fi (Postfix) with ESMTP id 969F2238A7
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 20:04:30 +0300 (EEST)
Received: from [195.20.224.206] (helo=mrvdomng.kundenserver.de)
	by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1)
	id 182x1a-0002pK-00
	for dovecot@procontrol.fi; Sat, 19 Oct 2002 19:04:30 +0200
Received: from [217.229.166.89] (helo=Bini)
	by mrvdomng.kundenserver.de with smtp (Exim 3.35 #1)
	id 182x1Z-0003C1-00
	for dovecot@procontrol.fi; Sat, 19 Oct 2002 19:04:30 +0200
Message-ID: <006701c27792$4f863040$0164a8c0@Bini>
From: "Korbinian Riedhammer" <faulerhund@faulerhund.net>
To: "Dovecot Mailinglist" <dovecot@procontrol.fi>
Subject: [dovecot] Re: still problems gettin it to work
Date: Sat, 19 Oct 2002 19:09:39 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-archive-position: 56
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: faulerhund@faulerhund.net
Precedence: bulk
X-list: dovecot
X-UID: 56                                                  
Status: O

yeah, the nasty error msgs are gone :)
well next question. where looks the dovcot imapd for the mail dir? /var/mail
or the homedir? 'cause i saved my Maildir in /home/user


From tss@iki.fi  Sat Oct 19 20:08:34 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 20:08:34 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 4C086238A7
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 20:08:34 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 0FC605E03E5C; Sat, 19 Oct 2002 20:08:31 +0300 (EEST)
Subject: [dovecot] Re: still problems gettin it to work
From: Timo Sirainen <tss@iki.fi>
To: Dovecot Mailinglist <dovecot@procontrol.fi>
In-Reply-To: <006701c27792$4f863040$0164a8c0@Bini>
References: <006701c27792$4f863040$0164a8c0@Bini>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035047310.1674.152.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 19 Oct 2002 20:08:30 +0300
X-archive-position: 57
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 57                                                  
Status: O

On Sat, 2002-10-19 at 20:09, Korbinian Riedhammer wrote:
> yeah, the nasty error msgs are gone :)
> well next question. where looks the dovcot imapd for the mail dir? /var/mail
> or the homedir? 'cause i saved my Maildir in /home/user

It uses ~/Maildir always.


From faulerhund@faulerhund.net  Sat Oct 19 20:17:48 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sat, 19 Oct 2002 20:17:48 +0300 (EEST)
Return-Path: <faulerhund@faulerhund.net>
Delivered-To: dovecot@procontrol.fi
Received: from moutvdom.kundenserver.de (moutvdom.kundenserver.de [195.20.224.131])
	by danu.procontrol.fi (Postfix) with ESMTP id 555172382D
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 20:17:48 +0300 (EEST)
Received: from [212.227.126.220] (helo=mrvdomng.kundenserver.de)
	by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1)
	id 182xES-0000X5-00
	for dovecot@procontrol.fi; Sat, 19 Oct 2002 19:17:48 +0200
Received: from [217.229.166.89] (helo=Bini)
	by mrvdomng.kundenserver.de with smtp (Exim 3.35 #1)
	id 182xER-0003ij-00
	for dovecot@procontrol.fi; Sat, 19 Oct 2002 19:17:47 +0200
Message-ID: <008901c27794$2b0de030$0164a8c0@Bini>
From: "Korbinian Riedhammer" <faulerhund@faulerhund.net>
To: "Dovecot Mailinglist" <dovecot@procontrol.fi>
Subject: [dovecot] Re: still problems gettin it to work
Date: Sat, 19 Oct 2002 19:22:57 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-archive-position: 58
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: faulerhund@faulerhund.net
Precedence: bulk
X-list: dovecot
X-UID: 58                                                  
Status: O

well finally it was my own stupidness!
i just forgot to set some correct permissions, now everythings fine!

thx anyway
korbinian


From ianj@ian-justman.com  Sun Oct 20 09:38:35 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sun, 20 Oct 2002 09:38:35 +0300 (EEST)
Return-Path: <ianj@ian-justman.com>
Delivered-To: dovecot@procontrol.fi
Received: from narshe.chocobo.org (dsl-207-126-72-242.dsl.netasset.net [207.126.72.242])
	by danu.procontrol.fi (Postfix) with ESMTP id C321D238A7
	for <dovecot@procontrol.fi>; Sun, 20 Oct 2002 09:38:34 +0300 (EEST)
Received: from zozo.intrn.chocobo.org (zozo.chocobo.org [207.126.72.244])
	by narshe.chocobo.org (Postfix) with ESMTP id 18975311609
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 23:38:31 -0700 (PDT)
Received: by zozo.intrn.chocobo.org (Postfix, from userid 501)
	id 5C94C870704; Sat, 19 Oct 2002 23:38:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by zozo.intrn.chocobo.org (Postfix) with ESMTP id 10A40449AD4
	for <dovecot@procontrol.fi>; Sat, 19 Oct 2002 23:38:29 -0700 (PDT)
Date: Sat, 19 Oct 2002 23:38:29 -0700 (PDT)
From: "Ian R. Justman" <ianj@ian-justman.com>
X-X-Sender: ianj@zozo.chocobo.org
To: Dovecot Mailinglist <dovecot@procontrol.fi>
Subject: [dovecot] observations/qestions of mbox concurrency ability (Yay!) on current
 CVS
Message-ID: <Pine.LNX.4.44.0210192329040.24843-100000@zozo.chocobo.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-archive-position: 59
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: ianj@ian-justman.com
Precedence: bulk
X-list: dovecot
X-UID: 59                                                  
Status: O


Hi, all.

Just been testing out the latest "CVS" (in quotes because  I'm rsyncing
the source
tree) versions of Dovecot lately.

Tested having Pine on the machine on which Dovecot was running, talking
IMAP, as well as another Pine instance, this time from my Windows machine
over the wire.  Things seem to be working wonderfully.  Deleted a message
using one instance, then refreshed the list on the other.  *poof*  Gone.

Though I'm seeing periodic "IMAP protocol error" messages in Pine, but
they don't seem to be affecting the software's operation that I can see.

Anything in particular I should be on the lookout for?

Otherwise, you just made my day.  Correction; week.  :D

--Ian.


From tss@iki.fi  Sun Oct 20 16:47:50 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sun, 20 Oct 2002 16:47:50 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 84B752382D
	for <dovecot@procontrol.fi>; Sun, 20 Oct 2002 16:47:50 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 6AC945E03E5C; Sun, 20 Oct 2002 16:47:49 +0300 (EEST)
Subject: [dovecot] Re: observations/qestions of mbox concurrency ability
	(Yay!) on current CVS
From: Timo Sirainen <tss@iki.fi>
To: "Ian R. Justman" <ianj@ian-justman.com>
Cc: Dovecot Mailinglist <dovecot@procontrol.fi>
In-Reply-To: <Pine.LNX.4.44.0210192329040.24843-100000@zozo.chocobo.org>
References: <Pine.LNX.4.44.0210192329040.24843-100000@zozo.chocobo.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035121669.24867.8.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 20 Oct 2002 16:47:49 +0300
X-archive-position: 60
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 60                                                  
Status: O
Content-Length: 1458

On Sun, 2002-10-20 at 09:38, Ian R. Justman wrote:
> Tested having Pine on the machine on which Dovecot was running, talking
> IMAP, as well as another Pine instance, this time from my Windows machine
> over the wire.  Things seem to be working wonderfully.  Deleted a message
> using one instance, then refreshed the list on the other.  *poof*  Gone.
> 
> Though I'm seeing periodic "IMAP protocol error" messages in Pine, but
> they don't seem to be affecting the software's operation that I can see.
> 
> Anything in particular I should be on the lookout for?

By default Dovecot uses .lock file and flock() locking. Some programs
may use fcntl() which doesn't work with flock(), but most use .lock file
as well so it doesn't really matter. I'm going to make the locking style
configurable later.

Anyway, I don't know of any reasons for mailbox corruption, but we don't
lock the mailbox when reading from it, so it is possible that someone
else might modify (expunge) the mailbox while Dovecot is reading it and
the IMAP client gets corrupted message.

I was thinking about fixing this using read-locking fcntl() / flock().
Maybe it could optionally create the .lock file as well, but that'd slow
down simultaneous reads.

Oh, and the mbox parsing code could use better checking, if there's any
bugs it will corrupt the mailbox at expunge/flag rewrite. I haven't seen
those though for the month or two that I've been using Dovecot+mbox to
read my mail.


From thomas@xs4all.net  Mon Oct 21 14:53:07 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 21 Oct 2002 14:53:07 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137])
	by danu.procontrol.fi (Postfix) with ESMTP id 4333B2382D
	for <dovecot@procontrol.fi>; Mon, 21 Oct 2002 14:53:07 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9LBr6ni040943
	for <dovecot@procontrol.fi>; Mon, 21 Oct 2002 13:53:06 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id DC6BB224C; Mon, 21 Oct 2002 13:51:43 +0200 (CEST)
Date: Mon, 21 Oct 2002 13:51:43 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021021115143.GS543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1035036115.1674.81.camel@hurina>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 61
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 61                                                  
Status: O
Content-Length: 1279

On Sat, Oct 19, 2002 at 05:01:55PM +0300, Timo Sirainen wrote:

> If your clusters access the files through NFS, there should be no
> problem. Except I've never tried Dovecot through NFS, and I'm not sure
> how well mmap()ing works through NFS. I know there's been problems
> before but hopefully they've been fixed already.

Hmm. I'm not sure what kind of behaviour you're looking for, but here's what
I see, using a little Python script on our FreeBSD servers with a
netapp-mounted filesystem. Mapping MAP_SHARED and PROT_READ|PROT_WRITE, two
different machines mounting the same directory, two processes on each
machine mmap()ing the same file.

When one process alters the data, the other process on the same machine sees
it instantly. The processes on the other machine do not see it at all, not
even when re-opening the mmap or being restarted. After doing an msync() in
the process that altered the data, the processes on the other machine still
don't see the change; they have to re-open the mmap or be restarted before
they see the change -- but when one of the processes re-opens or restarts,
the other does see the change without doing anything.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From thomas@xs4all.net  Mon Oct 21 15:40:02 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 21 Oct 2002 15:40:02 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139])
	by danu.procontrol.fi (Postfix) with ESMTP id 868CD23837
	for <dovecot@procontrol.fi>; Mon, 21 Oct 2002 15:40:02 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9LCe2wC017139
	for <dovecot@procontrol.fi>; Mon, 21 Oct 2002 14:40:02 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id 19E90224C; Mon, 21 Oct 2002 14:38:39 +0200 (CEST)
Date: Mon, 21 Oct 2002 14:38:39 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021021123839.GW543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina> <20021019151026.GM543@xs4all.nl> <1035042823.1679.127.camel@hurina>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1035042823.1679.127.camel@hurina>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 62
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 62                                                  
Status: O

On Sat, Oct 19, 2002 at 06:53:43PM +0300, Timo Sirainen wrote:

> > As long as dovecot doesn't read a different meaning into those flags
> > (ignoring them is just fine) we should be fine. I don't think we'll have
> > many customers switching back and forth between dovecot and UW-IMAP, just
> > people switching from UW-IMAP to dovecot.

> Keeping the UIDs untouched when changing could be important to some
> people whose mail clients can save some extra information related to
> specific messages and use UID to identify the mails. I think Evolution
> does this with it's labels and Follow-Up marks, but I'm not sure.

Well, what I meant was that currently, IMAP is being used only by
SquirrelMail, and I'm fairly sure SquirrelMail doesn't store UIDs anywhere.
Other IMAP clients would be an issue only if we allowed other IMAP clients
to connect, which we don't (except in internal tests :).

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From thomas@xs4all.net  Mon Oct 21 16:04:50 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 21 Oct 2002 16:04:50 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141])
	by danu.procontrol.fi (Postfix) with ESMTP id 3F98523837
	for <dovecot@procontrol.fi>; Mon, 21 Oct 2002 16:04:50 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9LD4gEH017726;
	Mon, 21 Oct 2002 15:04:47 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id 4840D224C; Mon, 21 Oct 2002 15:03:19 +0200 (CEST)
Date: Mon, 21 Oct 2002 15:03:19 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: Charlie Brady <charlieb@e-smith.com>
Cc: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021021130319.GX543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl> <Pine.LNX.4.44.0210191229360.24121-100000@allspice.nssg.mitel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0210191229360.24121-100000@allspice.nssg.mitel.com>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 63
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 63                                                  
Status: O
Content-Length: 2995

On Sat, Oct 19, 2002 at 12:42:25PM -0400, Charlie Brady wrote:

> > So when we needed an IMAP server for use with our webmail (based on
> > SquirrelMail), we were forced to go with the UW-IMAP server, with the
> > maildir patch that's been scattered around the 'net. This worked, for a
> > while; we also use the maildir patch with pine after all. However, the
> > maildir patch is not very good. Not at all, even, and it only seems to
> > work by pure chance.

> The best one I've found is the patch last modified AFAICT by Miquel van 
> Smoorenburg, which has maildir filenames like:
> time.pid.host,U=xxx,W=yyy:2,flags

We use two different patches, both of which have a bit of Mike in them. One
is for the IMAP server, which is an old version ('uw-imap-2000' or something
like that comes to mind, but it came from the pine 4.10 source) from before
the mailbox->append prototype changed (but with Mike's bilennium-patch.) A
big problem with later patches was that the append method changed in the
pine source, but not in the maildir patch. We considered using a newer
uw-imap but decided that the current one works good enough ;P

For pine we currently use the patch that comes with Debian's 'pine-tracker'
package (which is an installer for pine with patches, since you aren't
allowed to distributed modified binaries.) This patch also has some Mike in
it, but I'm not sure howmuch, as at least parts of it seem to be backed out
later. This patch works okay except for the two problems I noted in my
original mail: it depends on directory order not to change except when
'.uidvalidity' gets touched, and it depends on alphanumerical sort order of
files matching chronological (or at least uid-based, which should be the
same) sort order. The latter breaks with (standard) procmail, the former
occasionally with btree and (presumably) hashed directory indices.

> The storage of RFC822.SIZE, aka the on-the-wire size, in the filename 
> makes a very big difference to performance.

That's interesting. I'll keep that in mind for when we begin to see
performance issues with UW-IMAP. (I'm hoping I never have to look at the
pine source again, though.)

> But even this patch (from, e.g. 
> http://www.star.le.ac.uk/~tjg/misc/uw_imap-2001a_maildir-02.patch) has a
> number of bugs. I've fixed a few of them. You can find a source RPM at
> ftp://ftp.e-smith.org/pub/e-smith/dev/5.6dev/SRPMS/. The fixes are:

<snip fixes>

I couldn't find the source RPM for pine or (uw-)imap in that directory, but
it doesn't sound like your changes solve our fundamental problems. It's not
that big a deal, I think we've decided internally (I know _I_ have :) that
we can't offer real IMAP services based on UW-IMAP; we'd sooner go for Cyrus
or Courier, even if it does mean disallowing mboxes with IMAP. But dovecot
is an even better alternative, once it has all the features we need :)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From tss@iki.fi  Mon Oct 21 16:15:30 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 21 Oct 2002 16:15:30 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 6091723837
	for <dovecot@procontrol.fi>; Mon, 21 Oct 2002 16:15:30 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id B84CA5E03E5C; Mon, 21 Oct 2002 16:15:28 +0300 (EEST)
Subject: [dovecot] Re: Architectural questions
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <20021021115143.GS543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl>
	 <1035036115.1674.81.camel@hurina>  <20021021115143.GS543@xs4all.nl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035206128.613.8.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 21 Oct 2002 16:15:28 +0300
X-archive-position: 64
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 64                                                  
Status: O
Content-Length: 1114

On Mon, 2002-10-21 at 14:51, Thomas Wouters wrote:
> Hmm. I'm not sure what kind of behaviour you're looking for, but here's what
> I see, using a little Python script on our FreeBSD servers with a
> netapp-mounted filesystem. Mapping MAP_SHARED and PROT_READ|PROT_WRITE, two
> different machines mounting the same directory, two processes on each
> machine mmap()ing the same file.
> 
> When one process alters the data, the other process on the same machine sees
> it instantly. The processes on the other machine do not see it at all, not
> even when re-opening the mmap or being restarted. After doing an msync() in
> the process that altered the data, the processes on the other machine still
> don't see the change; they have to re-open the mmap or be restarted before
> they see the change -- but when one of the processes re-opens or restarts,
> the other does see the change without doing anything.

Requiring msync() is fine, that's done after each change, but there
should be better solution than re-mmap()ing to notice the changes. I
think FreeBSD checked the changes after fcntl() locking changes :)


From thomas@xs4all.net  Mon Oct 21 17:20:52 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 21 Oct 2002 17:20:52 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139])
	by danu.procontrol.fi (Postfix) with ESMTP id BA14223837
	for <dovecot@procontrol.fi>; Mon, 21 Oct 2002 17:20:52 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9LEKqkc068326
	for <dovecot@procontrol.fi>; Mon, 21 Oct 2002 16:20:52 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id 1D65A4ACB; Mon, 21 Oct 2002 16:19:29 +0200 (CEST)
Date: Mon, 21 Oct 2002 16:19:29 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021021141929.GY543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl> <1035206128.613.8.camel@hurina>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1035206128.613.8.camel@hurina>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 65
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 65                                                  
Status: O
Content-Length: 1435

On Mon, Oct 21, 2002 at 04:15:28PM +0300, Timo Sirainen wrote:

> Requiring msync() is fine, that's done after each change, but there
> should be better solution than re-mmap()ing to notice the changes. I
> think FreeBSD checked the changes after fcntl() locking changes :)

Hmm. More bad news; flock() doesn't work over NFS. That is, local processes
see and honor the lock even on NFS filesystems, but other machines don't see
the lock at all. fcntl() doesn't work at all (but that's probably because
we're not running lockd.)

I've tried various ways of forcing other machines to update their filesystem
cache without doing something on those machines (so you can optionally do
that after the msync()) by changing atime, mtime, nlinks, but so far,
nothing. I should point out that the file-metadata (mtime/ctime/nlinks)
returned by fstat() sometimes do get updated, and sometimes they don't. Same
for stat().

That aside, this issue isn't that big an issue for us. The
same-client-connecting-twice case we can solve by configuring the layer-4
ethernet switch to connect the same ipaddress to the same real server, so
that mmaps() are properly shared and all. We might want
per-mailbox locks so that only one real server can open a specific mailbox
(but do so multiple times) but I'll figure that one out later.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From tss@iki.fi  Mon Oct 21 17:49:30 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 21 Oct 2002 17:49:30 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 4035223837
	for <dovecot@procontrol.fi>; Mon, 21 Oct 2002 17:49:30 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 115105E03E5C; Mon, 21 Oct 2002 17:49:30 +0300 (EEST)
Subject: [dovecot] Re: Architectural questions
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <20021021141929.GY543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl>
	 <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl>
	 <1035206128.613.8.camel@hurina>  <20021021141929.GY543@xs4all.nl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035211769.613.48.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 21 Oct 2002 17:49:29 +0300
X-archive-position: 66
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 66                                                  
Status: O
Content-Length: 1820

On Mon, 2002-10-21 at 17:19, Thomas Wouters wrote:
> > Requiring msync() is fine, that's done after each change, but there
> > should be better solution than re-mmap()ing to notice the changes. I
> > think FreeBSD checked the changes after fcntl() locking changes :)
> 
> Hmm. More bad news; flock() doesn't work over NFS. That is, local processes
> see and honor the lock even on NFS filesystems, but other machines don't see
> the lock at all. fcntl() doesn't work at all (but that's probably because
> we're not running lockd.)

flock() doesn't matter, it's used only for mbox locking where .lock file
would work instead just as well. 

> That aside, this issue isn't that big an issue for us. The
> same-client-connecting-twice case we can solve by configuring the layer-4
> ethernet switch to connect the same ipaddress to the same real server, so
> that mmaps() are properly shared and all. We might want
> per-mailbox locks so that only one real server can open a specific mailbox
> (but do so multiple times) but I'll figure that one out later.

OK. I think this could be fixed internally too. Or this is mostly a
problem with index files, mbox/maildir files are currently re-mmap()ed
every time they're accessed (but I'll change mbox not to do that later).

Indexes currently have "sync_id" in their header, it's changed whenever
the file size is changed so other processes then know to re-mmap() it.
This could be optionally changed to be updated every time the file
itself has changed to force others to mmap() again. The sync_id change
itself could be checked using lseek() + read().

If fstat() or stat() doesn't show mtime changes, that could be a bit
worse problem. I think I'm relying on that with some things.. At least
new mail is checked by seeing if Maildir/cur's mtime matches
.imap.index's mtime.


From tss@iki.fi  Tue Oct 22 04:24:54 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 04:24:55 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id D2C9F2382D
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 04:24:54 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 8C06D5E03E5C; Tue, 22 Oct 2002 04:24:54 +0300 (EEST)
Subject: [dovecot] Re: Architectural questions
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <20021021141929.GY543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl>
	 <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl>
	 <1035206128.613.8.camel@hurina>  <20021021141929.GY543@xs4all.nl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035249894.5044.28.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 22 Oct 2002 04:24:54 +0300
X-archive-position: 67
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 67                                                  
Status: O
Content-Length: 1572

On Mon, 2002-10-21 at 17:19, Thomas Wouters wrote:
> That aside, this issue isn't that big an issue for us. The
> same-client-connecting-twice case we can solve by configuring the layer-4
> ethernet switch to connect the same ipaddress to the same real server, so
> that mmaps() are properly shared and all. We might want
> per-mailbox locks so that only one real server can open a specific mailbox
> (but do so multiple times) but I'll figure that one out later.

Just had a thought. Would it be feasible to _try_ to permanently assign
users to one or few specific servers (via ip or maybe login proxy)? If
those servers were down, it could fallback to any random one.

I was thinking Dovecot's indexes could just as well be stored in local
hard disk - they're not required to exist and they're not required to be
in sync when opening, so it's possible to keep multiple indexes lying
around in different servers.

That would take care of most of the mmap() and locking problems and
should make it perform a _lot_ better than through NFS. I don't know how
NFS works internally, but I doubt it has any way for remote OS to
determine what parts of file has changed, so re-mmap()ing would most
likely always reread the whole file (or the parts that it accesses)
which is quite inefficient.

I really like this idea, keeping indexes in local disk where they may be
considered as fast non-permanent data and then reading the actual mail
data via backed up NFS server. This gets me thinking of a lot more
possible optimizations to reduce NFS I/O at the cost of more local.. :)


From tss@iki.fi  Tue Oct 22 05:31:22 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 05:31:22 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id A8EB723837
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 05:31:22 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 6BF085E03E5C; Tue, 22 Oct 2002 05:31:22 +0300 (EEST)
Subject: [dovecot] Re: Architectural questions
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <1035249894.5044.28.camel@hurina>
References: <20021019123846.GK543@xs4all.nl>
	 <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl>
	 <1035206128.613.8.camel@hurina>  <20021021141929.GY543@xs4all.nl>
	 <1035249894.5044.28.camel@hurina>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035253882.5041.34.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 22 Oct 2002 05:31:22 +0300
X-archive-position: 68
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 68                                                  
Status: O

On Tue, 2002-10-22 at 04:24, Timo Sirainen wrote:
> Just had a thought. Would it be feasible to _try_ to permanently assign
> users to one or few specific servers (via ip or maybe login proxy)? If
> those servers were down, it could fallback to any random one.

Dovecot could actually do that itself too, authenticate user and then
either locally handle it or transfer it to another node based on some
configuration.

> I really like this idea, keeping indexes in local disk where they may be
> considered as fast non-permanent data and then reading the actual mail
> data via backed up NFS server. This gets me thinking of a lot more
> possible optimizations to reduce NFS I/O at the cost of more local.. :)

This again makes the indexer process possible and useful, since it would
be accessing only local disks. It could also delete some of the older
indexes if disk space is getting full.


From thomas@xs4all.net  Tue Oct 22 14:50:52 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 14:50:52 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137])
	by danu.procontrol.fi (Postfix) with ESMTP id 631112382D
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 14:50:52 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9MBoqol023592
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 13:50:52 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id 939694BC7; Tue, 22 Oct 2002 13:49:22 +0200 (CEST)
Date: Tue, 22 Oct 2002 13:49:22 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022114922.GF543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl> <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl> <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1035253882.5041.34.camel@hurina>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 69
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 69                                                  
Status: O
Content-Length: 2956

On Tue, Oct 22, 2002 at 05:31:22AM +0300, Timo Sirainen wrote:
> On Tue, 2002-10-22 at 04:24, Timo Sirainen wrote:
> > Just had a thought. Would it be feasible to _try_ to permanently assign
> > users to one or few specific servers (via ip or maybe login proxy)? If
> > those servers were down, it could fallback to any random one.

Yes, the Alteons we use can be configured quite flexibly. We can easily
configure, e.g., two servers as 'primary' and two fallback servers, or do
load-balancing based on the output of a script, or any number of things. We
only use the general load-balancing (actually just
active-connection-balancing) while keeping sessions on the same server
(based on remote IP) but we could look into the more intricate methods. A
single IMAP server with a backup is a good start though.

> Dovecot could actually do that itself too, authenticate user and then
> either locally handle it or transfer it to another node based on some
> configuration.

You mean if you have a frontend with several backends, and the frontend
proxies for the backends (with several frontends possible, for redundancy,)
hmm, that might work. Diablo (the news server software) works like this,
somewhat, too, and we also use it behind Alteon switches :)

> > I really like this idea, keeping indexes in local disk where they may be
> > considered as fast non-permanent data and then reading the actual mail
> > data via backed up NFS server. This gets me thinking of a lot more
> > possible optimizations to reduce NFS I/O at the cost of more local.. :)

> This again makes the indexer process possible and useful, since it would
> be accessing only local disks. It could also delete some of the older
> indexes if disk space is getting full.

Yes. Keeping things on local disk sounds good. As long as opening the same
mailbox on another server doesn't break anything (or breaks 'cleanly',
doesn't delete the wrong mails etc) we can definately live with much worse
performance for those cases. My professional estimate is that they will be
very, very rare ;P

But for the time being we're more concerned with the SORT extention :) I've
read the spec, and besides the natural "ugh" at having to parse the subject
that way, it seems doable... except that charset support for UTF-8, as well
as US-ASCII, is mandatory. I don't know any libraries that convert to/from
UTF-8 (though ASCII<->UTF-8 is obviously simple :) and though it's probably
easy to roll your own for iso8859-1 I'm not sure if you had a solution in
mind yet. Also, supporting the other character sets (like UW-IMAP does) is
probably a lot trickier.

Other than the charset issues I could probably whip up a working SORT
implementation given enough time... but it probably wouldn't be
super-efficient, as quicksort is so much easier to start with than, say,
a mergesort ;P

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From rueckert@informatik.uni-rostock.de  Tue Oct 22 15:47:21 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 15:47:21 +0300 (EEST)
Return-Path: <rueckert@informatik.uni-rostock.de>
Delivered-To: dovecot@procontrol.fi
Received: from linux.taugt.net (wh5035.stw.uni-rostock.de [139.30.105.35])
	by danu.procontrol.fi (Postfix) with ESMTP id D3C8D23837
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 15:47:21 +0300 (EEST)
Received: by linux.taugt.net (postwixer on board, from userid 500)
	id 827F82A150; Tue, 22 Oct 2002 14:47:22 +0200 (CEST)
Date: Tue, 22 Oct 2002 14:47:22 +0200
From: Marcus Rueckert <rueckert@informatik.uni-rostock.de>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022124722.GA942@linux.taugt.net>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl> <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl> <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1035253882.5041.34.camel@hurina>
User-Agent: Mutt/1.4i
X-archive-position: 70
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: rueckert@informatik.uni-rostock.de
Precedence: bulk
X-list: dovecot
X-UID: 70                                                  
Status: O

On 2002-10-22 05:31:22 +0000, Timo Sirainen wrote:
> Subject: [dovecot] Re: Architectural questions
> From: Timo Sirainen <tss@iki.fi>
> To: dovecot@procontrol.fi
> X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
> Date: 22 Oct 2002 05:31:22 +0300
> 
> On Tue, 2002-10-22 at 04:24, Timo Sirainen wrote:
> > Just had a thought. Would it be feasible to _try_ to permanently assign
> > users to one or few specific servers (via ip or maybe login proxy)? If
> > those servers were down, it could fallback to any random one.
> 
> Dovecot could actually do that itself too, authenticate user and then
> either locally handle it or transfer it to another node based on some
> configuration.
 
hmm

i just wanted to suggest http://www.vergenet.net/linux/perdition/
for proxying. but if dovecot could do something similar by it self this
is not needed :)

bow before god aehm cras ^^

marcus

-- 
irssi - the client of the smart and beautiful people

              http://www.irssi.de/


From cras@irccrew.org  Tue Oct 22 16:01:46 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 16:01:46 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id B564623837
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 16:01:46 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 172F74C0A0; Tue, 22 Oct 2002 16:01:46 +0300 (EEST)
Date: Tue, 22 Oct 2002 16:01:46 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022130146.GB8122@irccrew.org>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl> <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl> <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina> <20021022114922.GF543@xs4all.nl>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20021022114922.GF543@xs4all.nl>
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 71
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 71                                                  
Status: O
Content-Length: 3419

On Tue, Oct 22, 2002 at 01:49:22PM +0200, Thomas Wouters wrote:
> Yes, the Alteons we use can be configured quite flexibly. We can easily
> configure, e.g., two servers as 'primary' and two fallback servers, or do
> load-balancing based on the output of a script, or any number of things. We
> only use the general load-balancing (actually just
> active-connection-balancing) while keeping sessions on the same server
> (based on remote IP) but we could look into the more intricate methods. A
> single IMAP server with a backup is a good start though.

OK, they'd probably be better than any Dovecot proxies I think.

> > Dovecot could actually do that itself too, authenticate user and then
> > either locally handle it or transfer it to another node based on some
> > configuration.
> 
> You mean if you have a frontend with several backends, and the frontend
> proxies for the backends (with several frontends possible, for redundancy,)
> hmm, that might work. Diablo (the news server software) works like this,
> somewhat, too, and we also use it behind Alteon switches :)

Not necessarily split to frontend/backend.. Well, that's possible too but I
was thinking that every running dovecot could handle authentication and
transferring connection elsewhere (via another TCP connection, login using
some internal password, maybe use TLS too).

> Yes. Keeping things on local disk sounds good. As long as opening the same
> mailbox on another server doesn't break anything (or breaks 'cleanly',
> doesn't delete the wrong mails etc) we can definately live with much worse
> performance for those cases. My professional estimate is that they will be
> very, very rare ;P

Nothing breaks if same mailbox is opened from different computers with
different indexes (or no indexes).

> But for the time being we're more concerned with the SORT extention :) I've
> read the spec, and besides the natural "ugh" at having to parse the subject
> that way, it seems doable...

The subject sorting looked very "ugh" to me too :)

> except that charset support for UTF-8, as well
> as US-ASCII, is mandatory. I don't know any libraries that convert to/from
> UTF-8 (though ASCII<->UTF-8 is obviously simple :) and though it's probably
> easy to roll your own for iso8859-1 I'm not sure if you had a solution in
> mind yet. Also, supporting the other character sets (like UW-IMAP does) is
> probably a lot trickier.

iconv() does it all, comes with glibc. Only bigger thing to do is to parse
the headers and convert the =?xxx?yyy?= things. I think everything should
go either through UTF8 or without any conversion if both header and search
charsets are same.

> Other than the charset issues I could probably whip up a working SORT
> implementation given enough time... but it probably wouldn't be
> super-efficient, as quicksort is so much easier to start with than, say,
> a mergesort ;P

I can think of two ways to do it:

1) save search results to array, sort the array, send it to clients, delete
the array.

2) sort all mails writing results into btree file, keep the file updated
whenever new mails are added or deleted. then do the search in that order so
we can just write out the results without any sorting.

I like the 2) more, but that works only if the sort condition isn't changed.
Or if it is changed, then we'd need to have multiple btree files.. And in
general it slows down things if sorting isn't done often.


From cras@irccrew.org  Tue Oct 22 16:06:50 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 16:06:50 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id D7F1023837
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 16:06:50 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id A49264C0A0; Tue, 22 Oct 2002 16:06:50 +0300 (EEST)
Date: Tue, 22 Oct 2002 16:06:50 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022130650.GC8122@irccrew.org>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl> <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl> <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina> <20021022114922.GF543@xs4all.nl> <20021022130146.GB8122@irccrew.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20021022130146.GB8122@irccrew.org>
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 72
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 72                                                  
Status: O

On Tue, Oct 22, 2002 at 04:01:46PM +0300, Timo Sirainen wrote:
> > except that charset support for UTF-8, as well
> > as US-ASCII, is mandatory. I don't know any libraries that convert to/from
> > UTF-8 (though ASCII<->UTF-8 is obviously simple :) and though it's probably
> > easy to roll your own for iso8859-1 I'm not sure if you had a solution in
> > mind yet. Also, supporting the other character sets (like UW-IMAP does) is
> > probably a lot trickier.
> 
> iconv() does it all, comes with glibc.

Um. Of course FreeBSD didn't have glibc, but iconv() is anyway pretty
standard, man page says "Conforming to UNIX98". It comes as a separate
library as well.

BTW. does SquirrelMail also require THREAD extension? It's not much more
different from SORT luckily.


From thomas@xs4all.net  Tue Oct 22 16:23:59 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 16:23:59 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138])
	by danu.procontrol.fi (Postfix) with ESMTP id E953E2382D
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 16:23:58 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9MDNwHg059572
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 15:23:58 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id A25BF2D43; Tue, 22 Oct 2002 15:22:28 +0200 (CEST)
Date: Tue, 22 Oct 2002 15:22:28 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022132228.GG543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl> <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl> <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina> <20021022114922.GF543@xs4all.nl> <20021022130146.GB8122@irccrew.org> <20021022130650.GC8122@irccrew.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021022130650.GC8122@irccrew.org>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 73
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 73                                                  
Status: O
Content-Length: 1288

On Tue, Oct 22, 2002 at 04:06:50PM +0300, Timo Sirainen wrote:
> On Tue, Oct 22, 2002 at 04:01:46PM +0300, Timo Sirainen wrote:
> > > except that charset support for UTF-8, as well
> > > as US-ASCII, is mandatory. I don't know any libraries that convert to/from
> > > UTF-8 (though ASCII<->UTF-8 is obviously simple :) and though it's probably
> > > easy to roll your own for iso8859-1 I'm not sure if you had a solution in
> > > mind yet. Also, supporting the other character sets (like UW-IMAP does) is
> > > probably a lot trickier.

> > iconv() does it all, comes with glibc.

> Um. Of course FreeBSD didn't have glibc, but iconv() is anyway pretty
> standard, man page says "Conforming to UNIX98". It comes as a separate
> library as well.

Yeah, I noticed the same thing :) But it still has to be a concious
decision, as not all platforms come with libiconv and I wasn't sure what
your target audience is, and might become.

> BTW. does SquirrelMail also require THREAD extension? It's not much more
> different from SORT luckily.

It looks like it's optional. As a matter of fact, so is SORT :) But both
would be very nice to have, not just for SquirrelMail.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From thomas@xs4all.net  Tue Oct 22 16:41:38 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 16:41:38 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139])
	by danu.procontrol.fi (Postfix) with ESMTP id 5975F2382D
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 16:41:38 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9MDfbcj029432
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 15:41:38 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id DF54A2D43; Tue, 22 Oct 2002 15:40:07 +0200 (CEST)
Date: Tue, 22 Oct 2002 15:40:07 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022134007.GH543@xs4all.nl>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl> <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl> <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina> <20021022114922.GF543@xs4all.nl> <20021022130146.GB8122@irccrew.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021022130146.GB8122@irccrew.org>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 74
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 74                                                  
Status: O
Content-Length: 1983

On Tue, Oct 22, 2002 at 04:01:46PM +0300, Timo Sirainen wrote:

> Only bigger thing to do is to parse the headers and convert the
> =?xxx?yyy?= things. I think everything should go either through UTF8 or
> without any conversion if both header and search charsets are same.

I assume you only want to convert to UTF-8 or the other character sets when
it's really necessary, not store all data internally as UTF-8 or wchar_t ?

> I can think of two ways to do it:

> 1) save search results to array, sort the array, send it to clients, delete
> the array.

> 2) sort all mails writing results into btree file, keep the file updated
> whenever new mails are added or deleted. then do the search in that order so
> we can just write out the results without any sorting.

> I like the 2) more, but that works only if the sort condition isn't changed.
> Or if it is changed, then we'd need to have multiple btree files.. And in
> general it slows down things if sorting isn't done often.

I think 2) might be an option if you're dealing with very specific SORTs.
SquirrelMail, for instance, allows sorting on date, from, subject, arrival
and to (but the last one only in 'sent-mail' mailbox, oddly enough) and all
reverses, and in various order as well, by little buttony things on the
mailbox-index page... easy to play with. (Don't forget, you can 

. SORT (SUBJECT REVERSE FROM REVERSE TO REVERSE DATE ARRIVAL) UTF-8 ALL

and which btrees would you use how, in that case ? :) Anyway, in
SquirrelMail at least, I don't think there is a system-wide 'default' for
the criterium that's most often SORTed on. Simply storing the last SORT
might be the optimal solution, as I think (after the initial toying with the
mailbox sort order, and the occasional switch to search faster) most people
won't touch their sort order once they like or are used with what they have.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From cras@irccrew.org  Tue Oct 22 17:00:13 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 17:00:13 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id C9D3B2382D
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 17:00:13 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 93B514C0A0; Tue, 22 Oct 2002 17:00:13 +0300 (EEST)
Date: Tue, 22 Oct 2002 17:00:13 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022140013.GD8122@irccrew.org>
References: <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl> <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl> <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina> <20021022114922.GF543@xs4all.nl> <20021022130146.GB8122@irccrew.org> <20021022130650.GC8122@irccrew.org> <20021022132228.GG543@xs4all.nl>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20021022132228.GG543@xs4all.nl>
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 75
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 75                                                  
Status: O
Content-Length: 1066

On Tue, Oct 22, 2002 at 03:22:28PM +0200, Thomas Wouters wrote:
> > Um. Of course FreeBSD didn't have glibc, but iconv() is anyway pretty
> > standard, man page says "Conforming to UNIX98". It comes as a separate
> > library as well.
> 
> Yeah, I noticed the same thing :) But it still has to be a concious
> decision, as not all platforms come with libiconv and I wasn't sure what
> your target audience is, and might become.

Well, target audience should be as large as possible :) But I think it'd be
good enough to make iconv() required for charset-support, without iconv() it
would support only charsets which don't need any conversion (ascii and
"search charset foo" with "=?foo?..?=")

> > BTW. does SquirrelMail also require THREAD extension? It's not much more
> > different from SORT luckily.
> 
> It looks like it's optional. As a matter of fact, so is SORT :) But both
> would be very nice to have, not just for SquirrelMail.

Yeah. I'll add support for both later, currently there's a bit more
important things to do which you'll want fixed as well :)


From cras@irccrew.org  Tue Oct 22 17:12:23 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 17:12:23 +0300 (EEST)
Return-Path: <cras@irccrew.org>
Delivered-To: dovecot@procontrol.fi
Received: from shodan.irccrew.org (shodan.irccrew.org [80.83.4.2])
	by danu.procontrol.fi (Postfix) with ESMTP id 1E2272382D
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 17:12:23 +0300 (EEST)
Received: by shodan.irccrew.org (Postfix, from userid 6976)
	id 2C1CE4C0A0; Tue, 22 Oct 2002 17:12:20 +0300 (EEST)
Date: Tue, 22 Oct 2002 17:12:20 +0300
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022141220.GE8122@irccrew.org>
References: <20021019123846.GK543@xs4all.nl> <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl> <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl> <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina> <20021022114922.GF543@xs4all.nl> <20021022130146.GB8122@irccrew.org> <20021022134007.GH543@xs4all.nl>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20021022134007.GH543@xs4all.nl>
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
X-archive-position: 76
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 76                                                  
Status: O
Content-Length: 1875

On Tue, Oct 22, 2002 at 03:40:07PM +0200, Thomas Wouters wrote:
> > Only bigger thing to do is to parse the headers and convert the
> > =?xxx?yyy?= things. I think everything should go either through UTF8 or
> > without any conversion if both header and search charsets are same.
> 
> I assume you only want to convert to UTF-8 or the other character sets when
> it's really necessary, not store all data internally as UTF-8 or wchar_t ?

Well, there's not much stored in memory, and index files store mostly just
FETCH ENVELOPE. The envelope is better to be in format where it's suitable
for directly sending to IMAP client and those few things that are stored in
memory aren't used by search at all. I think it'll be easier if everything
was just converted when needed and it's just more CPU (and maybe memory)
usage - there should be plenty of that left :)

> I think 2) might be an option if you're dealing with very specific SORTs.
> SquirrelMail, for instance, allows sorting on date, from, subject, arrival
> and to (but the last one only in 'sent-mail' mailbox, oddly enough) and all
> reverses, and in various order as well, by little buttony things on the
> mailbox-index page... easy to play with. (Don't forget, you can 
> 
> . SORT (SUBJECT REVERSE FROM REVERSE TO REVERSE DATE ARRIVAL) UTF-8 ALL
> 
> and which btrees would you use how, in that case ? :) Anyway, in

Primary condition could be enough to store in the btree, the other
conditions are used only when primary compares equal between mails, so we
can just read those into memory and then apply the rest of the sorting.
Still faster and takes less memory than reading everything into memory and
then sorting.

Or the btree could be fully sorted with some condition, but if it's not
exactly the same we want we could just use the primary condition.

(uh, a bit badly said, hope it makes some sense :)


From thomas@xs4all.net  Tue Oct 22 21:19:54 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 21:19:54 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137])
	by danu.procontrol.fi (Postfix) with ESMTP id 08BA423837
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 21:19:54 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9MIJoWS075157
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 20:19:50 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id 761CB2D43; Tue, 22 Oct 2002 20:18:19 +0200 (CEST)
Date: Tue, 22 Oct 2002 20:18:19 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022181819.GI543@xs4all.nl>
References: <20021021115143.GS543@xs4all.nl> <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl> <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina> <20021022114922.GF543@xs4all.nl> <20021022130146.GB8122@irccrew.org> <20021022130650.GC8122@irccrew.org> <20021022132228.GG543@xs4all.nl> <20021022140013.GD8122@irccrew.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021022140013.GD8122@irccrew.org>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 77
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 77                                                  
Status: O

On Tue, Oct 22, 2002 at 05:00:13PM +0300, Timo Sirainen wrote:

> Yeah. I'll add support for both later, currently there's a bit more
> important things to do which you'll want fixed as well :)

Heh. That reminds me... Have you considered using, for instance, SourceForge
to host dovecot ? Or at least use something like syncmail, which mails out
CVS diffs on each checkin ? I use syncmail on every CVS project, both
internal and external, and I find I've grown very attached to it, and am too
used to seeing what goes on in an project just by looking at the checkins :)

(Not that I'm actively pushing you to use SourceForge or anything... it
definately has its downsides too, if you're capable of running your own CVS
server anyway.)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From thomas@xs4all.net  Tue Oct 22 21:51:09 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 21:51:09 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141])
	by danu.procontrol.fi (Postfix) with ESMTP id DA74523837
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 21:51:08 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9MIp8pE020363
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 20:51:08 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id 1F1D22D43; Tue, 22 Oct 2002 20:49:37 +0200 (CEST)
Date: Tue, 22 Oct 2002 20:49:37 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022184937.GJ543@xs4all.nl>
References: <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl> <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina> <20021022114922.GF543@xs4all.nl> <20021022130146.GB8122@irccrew.org> <20021022130650.GC8122@irccrew.org> <20021022132228.GG543@xs4all.nl> <20021022140013.GD8122@irccrew.org> <20021022181819.GI543@xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021022181819.GI543@xs4all.nl>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 78
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 78                                                  
Status: O
Content-Length: 1919

On Tue, Oct 22, 2002 at 08:18:19PM +0200, Thomas Wouters wrote:

> Heh. That reminds me... Have you considered using, for instance,
> SourceForge to host dovecot ?

And while on *that* subject, the current CVS tree needs a patch like this to
compile. (And the usual Makefile rebuilds.) But I'm sure you already noticed
:-)

Index: src/login/Makefile.am
===================================================================
RCS file: /home/thomas/cvs-root/dovecot/src/login/Makefile.am,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 Makefile.am
*** src/login/Makefile.am	9 Aug 2002 09:15:53 -0000	1.1.1.1
--- src/login/Makefile.am	22 Oct 2002 18:48:32 -0000
***************
*** 1,7 ****
  pkglib_PROGRAMS = imap-login
  
  INCLUDES = \
! 	-I$(top_srcdir)/src/lib
  
  imap_login_LDADD = \
  	../lib/liblib.a \
--- 1,8 ----
  pkglib_PROGRAMS = imap-login
  
  INCLUDES = \
! 	-I$(top_srcdir)/src/lib \
! 	-DPACKAGE=\""$(PACKAGE)"\"
  
  imap_login_LDADD = \
  	../lib/liblib.a \
Index: src/master/Makefile.am
===================================================================
RCS file: /home/thomas/cvs-root/dovecot/src/master/Makefile.am,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 Makefile.am
*** src/master/Makefile.am	9 Aug 2002 09:15:55 -0000	1.1.1.1
--- src/master/Makefile.am	22 Oct 2002 18:48:12 -0000
***************
*** 4,10 ****
  	-I$(top_srcdir)/src/lib \
  	-DSYSCONFDIR=\""$(sysconfdir)"\" \
  	-DPKG_RUNDIR=\""$(localstatedir)/run/$(PACKAGE)"\" \
! 	-DPKG_LIBDIR=\""$(pkglibdir)"\"
  
  imap_master_LDADD = \
  	../lib/liblib.a
--- 4,11 ----
  	-I$(top_srcdir)/src/lib \
  	-DSYSCONFDIR=\""$(sysconfdir)"\" \
  	-DPKG_RUNDIR=\""$(localstatedir)/run/$(PACKAGE)"\" \
! 	-DPKG_LIBDIR=\""$(pkglibdir)"\" \
! 	-DPACKAGE=\""$(PACKAGE)"\"
  
  imap_master_LDADD = \
  	../lib/liblib.a


-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From tss@iki.fi  Tue Oct 22 23:50:41 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 22 Oct 2002 23:50:41 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id BF23A23837
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 23:50:41 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 408425E01F42; Tue, 22 Oct 2002 23:50:40 +0300 (EEST)
Subject: [dovecot] Re: Architectural questions
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <20021022184937.GJ543@xs4all.nl>
References: <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl>
	 <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina>
	 <20021022114922.GF543@xs4all.nl> <20021022130146.GB8122@irccrew.org>
	 <20021022130650.GC8122@irccrew.org> <20021022132228.GG543@xs4all.nl>
	 <20021022140013.GD8122@irccrew.org> <20021022181819.GI543@xs4all.nl>
	 <20021022184937.GJ543@xs4all.nl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035319840.1665.6.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 22 Oct 2002 23:50:40 +0300
X-archive-position: 79
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 79                                                  
Status: O

On Tue, 2002-10-22 at 21:49, Thomas Wouters wrote:
> And while on *that* subject, the current CVS tree needs a patch like this to
> compile. (And the usual Makefile rebuilds.) But I'm sure you already noticed
> :-)

config.h should define the PACKAGE, and it does for me with both
autoconf 2.13 and 2.5. Did you use GNU make? automake doesn't work very
well without.

> Index: src/login/Makefile.am
> ===================================================================
> RCS file: /home/thomas/cvs-root/dovecot/src/login/Makefile.am,v
> retrieving revision 1.1.1.1
> diff -c -r1.1.1.1 Makefile.am

and diff -u in future please :)


From thomas@xs4all.net  Wed Oct 23 00:21:33 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 23 Oct 2002 00:21:33 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141])
	by danu.procontrol.fi (Postfix) with ESMTP id 151F02382D
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 00:21:33 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9MLLWBC050470
	for <dovecot@procontrol.fi>; Tue, 22 Oct 2002 23:21:32 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id D36752D43; Tue, 22 Oct 2002 23:20:00 +0200 (CEST)
Date: Tue, 22 Oct 2002 23:20:00 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: Architectural questions
Message-ID: <20021022212000.GK543@xs4all.nl>
References: <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina> <20021022114922.GF543@xs4all.nl> <20021022130146.GB8122@irccrew.org> <20021022130650.GC8122@irccrew.org> <20021022132228.GG543@xs4all.nl> <20021022140013.GD8122@irccrew.org> <20021022181819.GI543@xs4all.nl> <20021022184937.GJ543@xs4all.nl> <1035319840.1665.6.camel@hurina>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1035319840.1665.6.camel@hurina>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 80
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 80                                                  
Status: O

On Tue, Oct 22, 2002 at 11:50:40PM +0300, Timo Sirainen wrote:
> On Tue, 2002-10-22 at 21:49, Thomas Wouters wrote:

> > And while on *that* subject, the current CVS tree needs a patch like this to
> > compile. (And the usual Makefile rebuilds.) But I'm sure you already noticed
> > :-)

> config.h should define the PACKAGE, and it does for me with both
> autoconf 2.13 and 2.5. Did you use GNU make? automake doesn't work very
> well without.

Ah, hm, I must have done something wrong with the
aclocal/autoheader/automake/autoconf dance. It wasn't in my config.h or
config.h.in, but I reran aclocal and now it's in config.h.in. I'm not used
to using automake, just autoconf/autoheader :)

> > diff -c -r1.1.1.1 Makefile.am

> and diff -u in future please :)

But, but, diff -c is so much more readable! :P Sigh :)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From tss@iki.fi  Wed Oct 23 00:46:21 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 23 Oct 2002 00:46:21 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 17B3F2382D
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 00:46:21 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id ADF1E5E01F42; Wed, 23 Oct 2002 00:46:15 +0300 (EEST)
Subject: [dovecot] Re: Architectural questions
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <20021022124722.GA942@linux.taugt.net>
References: <20021019123846.GK543@xs4all.nl>
	 <1035036115.1674.81.camel@hurina> <20021021115143.GS543@xs4all.nl>
	 <1035206128.613.8.camel@hurina> <20021021141929.GY543@xs4all.nl>
	 <1035249894.5044.28.camel@hurina> <1035253882.5041.34.camel@hurina>
	 <20021022124722.GA942@linux.taugt.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035323175.1665.31.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 23 Oct 2002 00:46:15 +0300
X-archive-position: 81
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 81                                                  
Status: O

On Tue, 2002-10-22 at 15:47, Marcus Rueckert wrote:
> i just wanted to suggest http://www.vergenet.net/linux/perdition/
> for proxying. but if dovecot could do something similar by it self this
> is not needed :)

It wouldn't be difficult to add proxying for dovecot, since it already
does authentication and can SSL connections are pretty much proxied
already through separate process.

Anyway I looked at Perdition. It doesn't support AUTHENTICATE, plus I
just found buffer overflow from it without even trying much.


From tss@iki.fi  Wed Oct 23 02:52:25 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 23 Oct 2002 02:52:25 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id CBF5A2382D
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 02:52:25 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 4A2335E01F42; Wed, 23 Oct 2002 02:52:25 +0300 (EEST)
Subject: [dovecot] New mailing list: dovecot-cvs
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035330745.1664.71.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 23 Oct 2002 02:52:25 +0300
X-archive-position: 82
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 82                                                  
Status: O

Installed syncmail program what Thomas was wanting. It sends a mail of
each cvs commit, including the actual changes in source. Otherwise the
mailing list is read-only. Subscribing happens the same way as to
dovecot list, ie. dovecot-cvs-request@procontrol.fi with subscribe in
subject.

Hmm. I think I should also separate the private/public cvs repositories
running in that computer and provide anonymous pserver access..


From tss@iki.fi  Wed Oct 23 04:20:15 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 23 Oct 2002 04:20:15 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 7FDEB2382C
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 04:20:15 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id E1A4A5E01F42; Wed, 23 Oct 2002 04:20:14 +0300 (EEST)
Subject: [dovecot] anonymous CVS access
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035336014.21702.41.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 23 Oct 2002 04:20:14 +0300
X-archive-position: 83
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 83                                                  
Status: O

OK, added anon-pserver:

cvs -d :pserver:anonymous@dovecot.procontrol.fi:/home/cvs co dovecot


From thomas@xs4all.net  Wed Oct 23 14:20:20 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 23 Oct 2002 14:20:20 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139])
	by danu.procontrol.fi (Postfix) with ESMTP id 06A182382C
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 14:20:20 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9NBKJFY030421
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 13:20:19 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id BA1222E31; Wed, 23 Oct 2002 13:18:43 +0200 (CEST)
Date: Wed, 23 Oct 2002 13:18:43 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] vsnprintf()
Message-ID: <20021023111843.GA3563@xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 84
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 84                                                  
Status: O


I think I stumbled upon a bug in the i_snprintf() function. In the case of
vnsprintf() being available, it depends on vnsprintf() returning -1 when the
string was longer than the passed-in limit (or it won't terminate the
string.). But this isn't the C99-standardized behaviour, and newer glibc's
don't do that anymore either, so you can end up with a non-terminated
string. This patch should fix it, I think.

Index: strfuncs.c
===================================================================
RCS file: /home/cvs/dovecot/src/lib/strfuncs.c,v
retrieving revision 1.14
diff -c -u -r1.14 strfuncs.c
--- strfuncs.c	20 Oct 2002 03:19:10 -0000	1.14
+++ strfuncs.c	23 Oct 2002 11:19:39 -0000
@@ -401,7 +401,7 @@
 	va_end(args);
 	t_pop();
 
-	if (ret < 0) {
+	if (ret < 0 || ret >= max_chars) {
 		str[max_chars-1] = '\0';
 		ret = strlen(str);
 	}


-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From tss@iki.fi  Wed Oct 23 16:16:37 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 23 Oct 2002 16:16:37 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 2E1882382C
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 16:16:37 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id 934505E01F42; Wed, 23 Oct 2002 16:16:36 +0300 (EEST)
Subject: [dovecot] Re: vsnprintf()
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <20021023111843.GA3563@xs4all.nl>
References: <20021023111843.GA3563@xs4all.nl>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035378996.28683.11.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 23 Oct 2002 16:16:36 +0300
X-archive-position: 85
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 85                                                  
Status: O

On Wed, 2002-10-23 at 14:18, Thomas Wouters wrote:
> I think I stumbled upon a bug in the i_snprintf() function. In the case of
> vnsprintf() being available, it depends on vnsprintf() returning -1 when the
> string was longer than the passed-in limit (or it won't terminate the
> string.). But this isn't the C99-standardized behaviour, and newer glibc's
> don't do that anymore either, so you can end up with a non-terminated
> string. This patch should fix it, I think.

Hm. vsnprintf() does terminate the string with \0 always, unless it
returns -1. But I'll apply the patch anyway just to be sure :) Also
my_vsyslog() didn't check the vsnprintf() return value at all. Have to
go through that lib code more carefully some day..


From thomas@xs4all.net  Wed Oct 23 16:38:07 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 23 Oct 2002 16:38:07 +0300 (EEST)
Return-Path: <thomas@xs4all.net>
Delivered-To: dovecot@procontrol.fi
Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137])
	by danu.procontrol.fi (Postfix) with ESMTP id 07B272382C
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 16:38:07 +0300 (EEST)
Received: from centurion.xs4all.nl (centurion.xs4all.nl [194.109.0.100])
	by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g9NDc6YL048557
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 15:38:06 +0200 (CEST)
Received: by centurion.xs4all.nl (Postfix, from userid 1000)
	id E44094CF0; Wed, 23 Oct 2002 15:36:29 +0200 (CEST)
Date: Wed, 23 Oct 2002 15:36:29 +0200
From: Thomas Wouters <thomas@xs4all.net>
To: dovecot@procontrol.fi
Subject: [dovecot] Re: vsnprintf()
Message-ID: <20021023133629.GM543@xs4all.nl>
References: <20021023111843.GA3563@xs4all.nl> <1035378996.28683.11.camel@hurina>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1035378996.28683.11.camel@hurina>
User-Agent: Mutt/1.4i
X-message-flag: Danger Will Robinson!
X-archive-position: 86
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: thomas@xs4all.net
Precedence: bulk
X-list: dovecot
X-UID: 86                                                  
Status: O
Content-Length: 1204

On Wed, Oct 23, 2002 at 04:16:36PM +0300, Timo Sirainen wrote:
> On Wed, 2002-10-23 at 14:18, Thomas Wouters wrote:
> > I think I stumbled upon a bug in the i_snprintf() function. In the case of
> > vnsprintf() being available, it depends on vnsprintf() returning -1 when the
> > string was longer than the passed-in limit (or it won't terminate the
> > string.). But this isn't the C99-standardized behaviour, and newer glibc's
> > don't do that anymore either, so you can end up with a non-terminated
> > string. This patch should fix it, I think.

> Hm. vsnprintf() does terminate the string with \0 always, unless it
> returns -1. But I'll apply the patch anyway just to be sure :)

Hmm. Yeah, testing confirms you are right, I was just confused by the Linux
manpage on the printf-functions. The FreeBSD manpage states it
unambigiously:

     Snprintf() and vsnprintf() will write at most size-1 of the characters
     printed into the output string (the size'th character then gets the
     terminating `\0')

Hey, that means I can go back and clean up some of my old code :-P

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

From dgc@uchicago.edu  Wed Oct 23 20:13:44 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 23 Oct 2002 20:13:45 +0300 (EEST)
Return-Path: <dgc@uchicago.edu>
Delivered-To: dovecot@procontrol.fi
Received: from dust.uchicago.edu (dust.uchicago.edu [128.135.0.35])
	by danu.procontrol.fi (Postfix) with ESMTP id 4AEA12382D
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 20:13:44 +0300 (EEST)
Received: (from dgc@localhost)
	by dust.uchicago.edu (8.11.6/8.11.6) id g9NHDd720129;
	Wed, 23 Oct 2002 12:13:39 -0500 (CDT)
X-Authentication-Warning: dust.uchicago.edu: dgc set sender to dgc@uchicago.edu using -f
Date: Wed, 23 Oct 2002 12:13:39 -0500
From: David Champion <dgc@uchicago.edu>
To: Thomas Wouters <thomas@xs4all.net>
Cc: dovecot@procontrol.fi
Subject: [dovecot] Re: vsnprintf()
Message-ID: <20021023171339.GO4662@dust.uchicago.edu>
References: <20021023111843.GA3563@xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021023111843.GA3563@xs4all.nl>
User-Agent: Mutt/1.5.1i
X-archive-position: 87
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: dgc@uchicago.edu
Precedence: bulk
X-list: dovecot
X-UID: 87                                                  
Status: O
Content-Length: 2444

* On 2002.10.23, in <20021023111843.GA3563@xs4all.nl>,
*	"Thomas Wouters" <thomas@xs4all.net> wrote:
> 
> I think I stumbled upon a bug in the i_snprintf() function. In the case of
> vnsprintf() being available, it depends on vnsprintf() returning -1 when the
> string was longer than the passed-in limit (or it won't terminate the
> string.). But this isn't the C99-standardized behaviour, and newer glibc's
> don't do that anymore either, so you can end up with a non-terminated
> string. This patch should fix it, I think.

Ah, I'm glad glibc has fixed this. (Have they fixed snprintf(), too?)
This patch looks correct for Solaris, as well.

There's an alternative approach that depends on the newer vsnprintf()
behavior. You can use
 
{
	char c, *buf;
	length = vsnprintf(&c, 1, fmt, vp);
	buf = malloc(length+1);
	vsnprintf(buf, length, fmt, vp);
}

to dynamically size the buffer as large as it needs to be. For general
formatting routines, I sometimes use this idiom (not totally valid C,
and no error-checking):

format(...)
{
	static char *buf = NULL;	/* workspace */
	static int buf_len = 0;		/* usable area in buf (size - '\0') */
	int fmt_len;			/* length of formatted string */
	...

	if (buf == NULL) {
		/* init to minimum size */
		buf = malloc(128+1);
		buf_len = 128;
	}

	/* Format once, and find out how long the formatted data was */
	fmt_len = vsnprintf(buf, buf_len+1, fmt, vp);

	/* If longer than buf, resize buf amnd try again */
	if (fmt_len > buf_len) {
		realloc(buf, (buf_len = fmt_len) + 1);
		vsnprintf(buf, buf_len+1, fmt, vp);
	}
	...
}

This makes sure I always have a big-enough buffer, without lots of
unneeded mallocing and freeing. The down-side is that it only works on
modern systems, because of the issue with [v]snprintf()'s return value.
And it sometimes formats the string twice, which is perhaps not good,
but perhaps alright. And I guess it's not re-entrant, which could be a
problem, though it could be made re-entrant with some work. :)


Anyway, this is perhaps a little much for a first post to a list from
someone who hasn't found time to look at or compile the code yet, but
off it goes....

-- 
 -D.                    We establised a fine coffee. What everybody can say
 Sun Project, APC/UCCO  TASTY! It's fresh, so-mild, with some special coffee's
 University of Chicago  bitter and sourtaste. "LET'S HAVE SUCH A COFFEE! NOW!"
 dgc@uchicago.edu       Please love CAFE MIAMI. Many thanks.

From tss@iki.fi  Wed Oct 23 20:21:57 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 23 Oct 2002 20:21:57 +0300 (EEST)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id A6D332382C
	for <dovecot@procontrol.fi>; Wed, 23 Oct 2002 20:21:56 +0300 (EEST)
Received: by hurina (Postfix, from userid 1000)
	id C67185E01F42; Wed, 23 Oct 2002 20:21:55 +0300 (EEST)
Subject: [dovecot] Re: vsnprintf()
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <20021023171339.GO4662@dust.uchicago.edu>
References: <20021023111843.GA3563@xs4all.nl>
	 <20021023171339.GO4662@dust.uchicago.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035393715.29469.5.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 23 Oct 2002 20:21:55 +0300
X-archive-position: 88
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 88                                                  
Status: O

On Wed, 2002-10-23 at 20:13, David Champion wrote:
> There's an alternative approach that depends on the newer vsnprintf()
> behavior. You can use
>  
> {
> 	char c, *buf;
> 	length = vsnprintf(&c, 1, fmt, vp);
> 	buf = malloc(length+1);
> 	vsnprintf(buf, length, fmt, vp);
> }
> 
> to dynamically size the buffer as large as it needs to be. For general
> formatting routines, I sometimes use this idiom (not totally valid C,
> and no error-checking):

Not too bad idea :) Dovecot currently uses a bit modified GLIB's
g_printf_string_upper_bound() and then allocates enough memory based on
it. Maybe using vsnprintf() could be optional (detected by configure if
it works), if it's better/faster than my upper_bound() function.


From tss@iki.fi  Tue Oct 29 05:26:31 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 29 Oct 2002 05:26:31 +0200 (EET)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 6C4712382C
	for <dovecot@procontrol.fi>; Tue, 29 Oct 2002 05:26:31 +0200 (EET)
Received: by hurina (Postfix, from userid 1000)
	id CB8525E01F42; Tue, 29 Oct 2002 05:26:30 +0200 (EET)
Subject: [dovecot] Re: pam + radius
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
In-Reply-To: <20021028190110.D22448@misato.nikojet.com>
References: <20021028190110.D22448@misato.nikojet.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035861990.781.23.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 29 Oct 2002 05:26:30 +0200
X-archive-position: 89
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 89                                                  
Status: O

On Tue, 2002-10-29 at 05:01, Hielke Christian Braun wrote:
> i am trying to use dovecot with pam and radius. My users have names
> in the format joe@somedomain.com. When i have pam configured to use
> the normal passwd/shadow files it works fine. With radius it does not.
> I see at the radius server that the domain part of my usernames
> is always replaced with the same domain @nikojet.com. I don't think
> it is a problem with the pam radius, as the same library works fine
> with the solid state pop3 server. Is this a fundamental problem and
> dovecot/imap does not work with usernames which have a domain part or
> is it a bug? 

You probably don't have the users in /etc/passwd file too, right?
Dovecot currently wants the users to exist there too to get their UID,
GID and home directory. I'll change this later so that you could give
"gid=123 uid=456 homeroot=/var/mail" options to pam auth and it'd use
them for all users.

Or did PAM also support getting that information in some way? I'm not
sure exactly..


From tss@iki.fi  Tue Oct 29 07:01:47 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 29 Oct 2002 07:01:47 +0200 (EET)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 49C7F2382D
	for <dovecot@procontrol.fi>; Tue, 29 Oct 2002 07:01:47 +0200 (EET)
Received: by hurina (Postfix, from userid 1000)
	id 14E5B5E01F42; Tue, 29 Oct 2002 07:01:47 +0200 (EET)
Subject: [dovecot] Re: pam + radius
From: Timo Sirainen <tss@iki.fi>
To: Hielke Christian Braun <hcb@nikotel.com>
Cc: dovecot@procontrol.fi
In-Reply-To: <20021028200037.A27315@misato.nikojet.com>
References: <20021028190110.D22448@misato.nikojet.com>
	 <1035861990.781.23.camel@hurina> <20021028200037.A27315@misato.nikojet.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1035867706.779.38.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 29 Oct 2002 07:01:46 +0200
X-archive-position: 90
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 90                                                  
Status: O
Content-Length: 1099

On Tue, 2002-10-29 at 06:00, Hielke Christian Braun wrote:
> > You probably don't have the users in /etc/passwd file too, right?
> 
> I have the users in the passwd and shadow files as i need that for quotas
> to work. Though in the shadow file i don't have the password and only a x.
> The problem must be something else.

Well .. I don't know then really. Since you did get it to work by
changing PAM to use shadow auth, Dovecot is doing it at least partly
right. Maybe the radius PAM module requires something that Dovecot
didn't do..

Looking at Courier's PAM handling, it does pam_setcred() which dovecot
doesn't. You could try if doing that helps:

src/auth/userinfo-pam.c, around line 169, insert between
pam_authenticate() and pam_acct_mgmt():

	if ((status = pam_setcred(pamh, PAM_ESTABLISH_CRED)) != PAM_SUCCESS) {
		if (status == PAM_ABORT)
			i_fatal("pam_setcred_mgmt() requested abort");
		return FALSE;
	}

> Maybe it dovecot sets a realm, which is then mistakenly used by
> the pam radius module, but not by the passwd/shadow module?

PAM doesn't have any support for realms AFAIK.


From tss@iki.fi  Sun Nov  3 02:11:15 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sun, 03 Nov 2002 02:11:15 +0200 (EET)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id A5E602382D
	for <dovecot@procontrol.fi>; Sun,  3 Nov 2002 02:11:15 +0200 (EET)
Received: by hurina (Postfix, from userid 1000)
	id 5B5EF5E01F55; Sun,  3 Nov 2002 02:11:15 +0200 (EET)
Subject: [dovecot] Re: pam + radius
From: Timo Sirainen <tss@iki.fi>
To: Hielke Christian Braun <hcb@nikotel.com>
Cc: dovecot@procontrol.fi
In-Reply-To: <20021031113245.W22448@misato.nikojet.com>
References: <20021028190110.D22448@misato.nikojet.com>
	 <1035861990.781.23.camel@hurina> <20021028200037.A27315@misato.nikojet.com>
	 <1035867706.779.38.camel@hurina> <20021031113245.W22448@misato.nikojet.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1036282275.263.1.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 03 Nov 2002 02:11:15 +0200
X-archive-position: 91
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 91                                                  
Status: O

On Thu, 2002-10-31 at 21:32, Hielke Christian Braun wrote:
> It helped a bit. Now the first login to dovecot works fine. The domainpart
> of my username is not changed. But after the first login, dovecot 
> always sents the username from the first login to the radius server even when
> i login from a different client with a complete different username.

OK, fixed now in CVS. I implemented PAM support pretty wrong.


From simon@lindgren.no  Tue Nov 12 15:27:35 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 12 Nov 2002 15:27:35 +0200 (EET)
Return-Path: <simon@lindgren.no>
Delivered-To: dovecot@procontrol.fi
Received: from mail46.fg.online.no (mail46-s.fg.online.no [148.122.161.46])
	by danu.procontrol.fi (Postfix) with ESMTP id 5629F2382D
	for <dovecot@procontrol.fi>; Tue, 12 Nov 2002 15:27:35 +0200 (EET)
Received: from ti211310a080-1828.bb.online.no (ti211310a080-1828.bb.online.no [80.212.71.36])
	by mail46.fg.online.no (8.9.3/8.9.3) with ESMTP id OAA04851
	for <dovecot@procontrol.fi>; Tue, 12 Nov 2002 14:27:34 +0100 (MET)
From: Simon Lindgren <simon@lindgren.no>
To: dovecot@procontrol.fi
Subject: [dovecot] Seen bug?
Date: Tue, 12 Nov 2002 14:27:33 +0100
User-Agent: KMail/1.5
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200211121427.33943.simon@lindgren.no>
X-archive-position: 92
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: simon@lindgren.no
Precedence: bulk
X-list: dovecot
X-UID: 92                                                  
Status: O
Content-Length: 3096

Hi,

I'm using Kmail and dovecot for my IMAP pleasure, and have had some problems, 
which are evident from the following exchange with some kmail developers.

My patch to the imap protocol in KDE fixed my problem, but should dovecot be 
changed instead?

Thank you for any insight!

I've included the discussion on kmail-devel so far:

[ I wrote: ]
--
I've recently switched to IMAP for email (using dovecot as the server, 
http://dovecot.procontrol.fi/) and have a small problem:

Clicking a message brings it up, but doesn't seem to mark it read on the 
server. I need to select 'Message -> Mark Message -> Mark Message as Read' in 
order for it to "stay read" when I check for new mails on the server. 

Is anyone else seeing this behaviour? Is this a bug, or a feature?

I've assigned a shortcut key for 'Mark Message as Read' so I get by, but with 
a large number of messages and folders, it quickly becomes annoying.
--


[ Carsten Burghardt <burghardt@kde.org> wrote in reply: ]
--
As your imap-server is not really common you should check with ethereal the 
communication between kmail and your server.
--


[ I wrote in reply: ]
--
Thanks for the replies... snooping with ethereal, I get the following:
(quoting only the data sent from kmail)

When viewing a mail in kmail:
UID FETCH 203 (UID RFC822)

When specifically flagging it as 'read' in kmail: 
UID STORE 203 -FLAGS.SILENT (\SEEN \ANSWERED \FLAGGED \DRAFT)
UID STORE 203 +FLAGS.SILENT (\SEEN)

It would seem that my problem would be solved if kmail also sent the +FLAGS 
stuff when viewing a message... but I don't know if this would be according 
to the IMAP specification - or if the server should flag the message as 
'seen' when the client does the 'fetch' ?

I do have 'Mark selected message as read after 0 sec' checked - and the 
message is flagged in kmail as read, but without specifically marking it as 
read in kmail, it's still 'unread' after the next 'check mail' run. I hope 
I'm being clear.

If you still think this is a bug with my (non standard, I agree!) IMAP server 
I'll try another one.
--

[ I wrote another reply: ]
--
I made a change to imap4.cc, and it magically works for me - I've not tested 
this one very much, but it seems to do the trick so far.

I would be very interested if someone knowledgeable would tell me just how 
wrong this piece of code is, as I'm working on learning these things.

--- imap4.cc    Tue Oct 15 21:52:43 2002
+++ imap4.cc    Tue Nov 12 01:36:05 2002
@@ -289,6 +289,11 @@
       }
 
       completeQueue.removeRef (cmd);
+
+         if (aSection.find ("ENVELOPE", 0, false) == -1) {
+               doCommand (imapCommand::
+                                  clientStore (aSequence, "+FLAGS.SILENT", 
"\\SEEN"));
+         }
     }
   }
--

[ Carsten Burghardt <burghardt@kde.org> wrote: ]
--
No, everything is alright here, you should check a different server.
--

[ Bo Thorsen <bo@sonofthor.dk> wrote: ]
--
It is definately a bug in the server. The IMAP RFC specifies that a server 
must only once serve a file flagged as new. So your server violates this 
principle.



From tss@iki.fi  Wed Nov 13 02:10:37 2002
Received: with ECARTIS (v1.0.0; list dovecot); Wed, 13 Nov 2002 02:10:37 +0200 (EET)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 0CFC82382C
	for <dovecot@procontrol.fi>; Wed, 13 Nov 2002 02:10:37 +0200 (EET)
Received: by hurina (Postfix, from userid 1000)
	id 881095E01F42; Wed, 13 Nov 2002 02:10:36 +0200 (EET)
Subject: [dovecot] Re: Seen bug?
From: Timo Sirainen <tss@iki.fi>
To: Simon Lindgren <simon@lindgren.no>
Cc: dovecot@procontrol.fi
In-Reply-To: <200211121427.33943.simon@lindgren.no>
References: <200211121427.33943.simon@lindgren.no>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1037146236.32041.102.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release)
Date: 13 Nov 2002 02:10:36 +0200
X-archive-position: 93
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 93                                                  
Status: O

On Tue, 2002-11-12 at 15:27, Simon Lindgren wrote:
> My patch to the imap protocol in KDE fixed my problem, but should dovecot be 
> changed instead?

Yes, it's a bug in Dovecot.

> When viewing a mail in kmail:
> UID FETCH 203 (UID RFC822)

Fetching BODY[] always marks the message read, but I didn't before think
of RFC822 and RFC822.TEXT which should do that too. Fixing..


From tss@iki.fi  Sun Nov 24 21:01:37 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sun, 24 Nov 2002 21:01:37 +0200 (EET)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 71F052382F
	for <dovecot@procontrol.fi>; Sun, 24 Nov 2002 21:01:37 +0200 (EET)
Received: by hurina (Postfix, from userid 1000)
	id ACC765E01F27; Sun, 24 Nov 2002 21:01:36 +0200 (EET)
Subject: [dovecot] 0.99.0 released
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1038164496.787.6.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.0 
Date: 24 Nov 2002 21:01:36 +0200
X-archive-position: 94
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 94                                                  
Status: O
Content-Length: 1571

I figured now would be a good time for new release. All the major
changes are pretty much done now.

v0.99.0 2002-11-24  Timo Sirainen <tss@iki.fi>

	+ Replaced hash file with binary tree file which makes Dovecot stay
	  fast with large mailboxes after expunging multiple mails.
	+ Several speed improvements with SEARCH
	+ SEARCH CHARSET support using iconv(), although case-insensitive
	  searching is currently supported only for ASCII characters.
	+ OpenSSL support.
	+ Support for regenerating Diffie Hellman and RSA parameters with
	  specified intervals. NOTE: currently doesn't work with OpenSSL.
	+ Support for each login connection being handled in it's own process.
	  This is the default as it's more safe especially with SSL.
	+ mbox locking is now safe, other processes can't modify the mbox file
	  while we're reading it.
	+ Notify clients with "EXISTS" almost immediately after new mail is
	  received.
	+ Rawlog: Support for saving user connections into files - useful for
	  debugging.
	+ Content-Language is finally parsed correctly
	+ Lots of smaller speed optimizations
	- Partial BODY[] fetches weren't working properly
	- BODY[section] was buggy with message/rfc822 MIME parts
	- STARTTLS wasn't working
	- \* flag was missing from PERMANENTFLAGS.
	- Comments inside <> mail addresses crashed.
	- imap-login printed UTC timestamps to logfiles
	- passwd-file wasn't reread the the file changed
	- PAM authentication was implemented wrong, which caused it to break
	  with some PAM plugins.
	- Lots of smaller fixes, mostly to do with reliability



From me@squeakyweasel.net  Sun Nov 24 22:25:42 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sun, 24 Nov 2002 22:25:42 +0200 (EET)
Return-Path: <me@squeakyweasel.net>
Delivered-To: dovecot@procontrol.fi
Received: from mail.stratius.com (unknown [207.44.131.172])
	by danu.procontrol.fi (Postfix) with SMTP id 6F03B2382C
	for <dovecot@procontrol.fi>; Sun, 24 Nov 2002 22:25:41 +0200 (EET)
Received: (qmail 26597 invoked from network); 24 Nov 2002 20:25:36 -0000
Received: from unknown (HELO cobalt) (4.47.73.34)
  by 207.44.131.176 with SMTP; 24 Nov 2002 20:25:36 -0000
Date: Sun, 24 Nov 2002 12:25:45 -0800
From: "Kyle Symonds" <me@squeakyweasel.net>
Reply-To: me@squeakyweasel.net
To: dovecot@procontrol.fi <dovecot@procontrol.fi>
Subject: [dovecot] vpopmail support?
X-mailer: Foxmail 4.1 [eg]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <20021124202541.6F03B2382C@danu.procontrol.fi>
X-archive-position: 95
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: me@squeakyweasel.net
Precedence: bulk
X-list: dovecot
X-UID: 95                                                  
Status: O

Well, I read that back in 0.98 or so vpopmail support should work so I assumed it would be enabled in 0.99 but here's what I get.

gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/lib     -I/usr/local/vpopmail/include -g -O2 -Wall -W    -g -O2 -Wall -W -c userinfo-vpopmail.c
In file included from userinfo-vpopmail.c:12:
/usr/local/vpopmail/include/vpopmail.h:133: syntax error before `*'
*** Error code 1

Stop in /root/dovecot/src/auth.
*** Error code 1

Stop in /root/dovecot/src.
*** Error code 1

Stop in /root/dovecot.
*** Error code 1

Stop in /root/dovecot.

Someone want to throw a bone?  =)

--Weasel
weasel@squeakyweasel.net
http://squeakyweasel.net



From me@squeakyweasel.net  Sun Nov 24 22:32:44 2002
Received: with ECARTIS (v1.0.0; list dovecot); Sun, 24 Nov 2002 22:32:44 +0200 (EET)
Return-Path: <me@squeakyweasel.net>
Delivered-To: dovecot@procontrol.fi
Received: from mail.stratius.com (unknown [207.44.131.172])
	by danu.procontrol.fi (Postfix) with SMTP id C3A332382C
	for <dovecot@procontrol.fi>; Sun, 24 Nov 2002 22:32:43 +0200 (EET)
Received: (qmail 26623 invoked from network); 24 Nov 2002 20:32:42 -0000
Received: from unknown (HELO cobalt) (4.47.73.34)
  by 207.44.131.176 with SMTP; 24 Nov 2002 20:32:42 -0000
Date: Sun, 24 Nov 2002 12:32:51 -0800
From: "Kyle Symonds" <me@squeakyweasel.net>
Reply-To: me@squeakyweasel.net
To: dovecot@procontrol.fi <dovecot@procontrol.fi>
Subject: [dovecot] Re: vpopmail support?
X-mailer: Foxmail 4.1 [eg]
Mime-Version: 1.0
Content-Type: text/plain;
      charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <20021124203243.C3A332382C@danu.procontrol.fi>
X-archive-position: 96
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: me@squeakyweasel.net
Precedence: bulk
X-list: dovecot
X-UID: 96                                                  
Status: O

Oh yeah, the system's FreeBSD 4.7-RELEASE.  Trying to do a qmail+vpopmail+pop3+imap setup.

--Weasel
weasel@squeakyweasel.net
http://squeakyweasel.net

======= At 2002-11-24, 12:25:00 you wrote: =======

>Well, I read that back in 0.98 or so vpopmail support should work so I assumed it would be enabled in 0.99 but here's what I get.
>
>gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/lib     -I/usr/local/vpopmail/include -g -O2 -Wall -W    -g -O2 -Wall -W -c userinfo-vpopmail.c
>In file included from userinfo-vpopmail.c:12:
>/usr/local/vpopmail/include/vpopmail.h:133: syntax error before `*'
>*** Error code 1
>
>Stop in /root/dovecot/src/auth.
>*** Error code 1
>
>Stop in /root/dovecot/src.
>*** Error code 1
>
>Stop in /root/dovecot.
>*** Error code 1
>
>Stop in /root/dovecot.
>
>Someone want to throw a bone?  =)
>
>--Weasel
>weasel@squeakyweasel.net
>http://squeakyweasel.net





From tss@iki.fi  Mon Nov 25 00:24:40 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 25 Nov 2002 00:24:40 +0200 (EET)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 156622382C
	for <dovecot@procontrol.fi>; Mon, 25 Nov 2002 00:24:40 +0200 (EET)
Received: by hurina (Postfix, from userid 1000)
	id 6FDA15E01F27; Mon, 25 Nov 2002 00:24:39 +0200 (EET)
Subject: [dovecot] Re: vpopmail support?
From: Timo Sirainen <tss@iki.fi>
To: me@squeakyweasel.net
Cc: "dovecot@procontrol.fi" <dovecot@procontrol.fi>
In-Reply-To: <20021124202541.6F03B2382C@danu.procontrol.fi>
References: <20021124202541.6F03B2382C@danu.procontrol.fi>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1038176679.789.14.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.0 
Date: 25 Nov 2002 00:24:39 +0200
X-archive-position: 97
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 97                                                  
Status: O

On Sun, 2002-11-24 at 22:25, Kyle Symonds wrote:
> Well, I read that back in 0.98 or so vpopmail support should work so I assumed it would be enabled in 0.99 but here's what I get.
> 
> gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../src/lib     -I/usr/local/vpopmail/include -g -O2 -Wall -W    -g -O2 -Wall -W -c userinfo-vpopmail.c
> In file included from userinfo-vpopmail.c:12:
> /usr/local/vpopmail/include/vpopmail.h:133: syntax error before `*'
> *** Error code 1

Well, I hadn't tested it for some time, so it missed one include file.
Add #include <stdio.h> to userinfo-vpopmail.c before the
vpopmail-include and it should work.

Maybe it's time for 0.99.1 soon, there's quite a few build fixes/changes
now in CVS :)


From tss@iki.fi  Mon Nov 25 12:59:34 2002
Received: with ECARTIS (v1.0.0; list dovecot); Mon, 25 Nov 2002 12:59:34 +0200 (EET)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id 0483A2382F
	for <dovecot@procontrol.fi>; Mon, 25 Nov 2002 12:59:34 +0200 (EET)
Received: by hurina (Postfix, from userid 1000)
	id 516875E01F27; Mon, 25 Nov 2002 12:59:33 +0200 (EET)
Subject: [dovecot] 0.99.1 released
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1038221973.787.18.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.0 
Date: 25 Nov 2002 12:59:33 +0200
X-archive-position: 98
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 98                                                  
Status: O

Nothing new, just a few compiling/configuration issues fixed.

Dovecot should also be in NetBSD pkgsrc soon. Now who would want to get
it into Debian? :)

v0.99.1 2002-11-25  Timo Sirainen <tss@iki.fi>

	+ Added doc/mkcert.sh script to easily generate yourself a self-signed
	  certificate. Modify doc/dovecot-openssl.cnf before running it.
	+ --with-ssldir configure option to specify default path for /etc/ssl
	+ Added ssl_disable setting to config file
	- OpenSSL wasn't checked properly by configure
	- vpopmail authentication module didn't compile
	- We should install the binaries into libexec dir, not lib
	- doc/configuration.txt and doc/mail-storages.txt were missing


From tss@iki.fi  Tue Nov 26 23:16:04 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 26 Nov 2002 23:16:04 +0200 (EET)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id CADA92382F
	for <dovecot@procontrol.fi>; Tue, 26 Nov 2002 23:16:04 +0200 (EET)
Received: by hurina (Postfix, from userid 1000)
	id 670385E01F27; Tue, 26 Nov 2002 23:16:02 +0200 (EET)
Subject: [dovecot] 0.99.2 released
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1038345362.2676.31.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.0 
Date: 26 Nov 2002 23:16:02 +0200
X-archive-position: 99
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 99                                                  
Status: O

Mostly compiling cleanups but also one bugfix when index wasn't
exclusively locked while it was being fsck'ed - that doesn't normally
happen without crashing/whatever.

v0.99.2 2002-11-26  Timo Sirainen <tss@iki.fi>

	+ If we have to wait for a lock longer, the client is now notified
	  about it every 30 seconds.
	- Default settings still pointed to lib directory instead of the
	  libexec directory where the binaries were actually installed
	- vpopmail support had to be kludged to fix a bug in vpopmail library
	  which sometimes left extra character after the user name.
	- Login process crashed if master process didn't let some user login.
	  Normally this couldn't happen without error in configuration.
	- select() based I/O loop wasn't working so Dovecot didn't work in
	  eg. OSX. Also PAM authentication wasn't detected with OSX.
	- Didn't compile with NetBSD-current


From tss@iki.fi  Tue Nov 26 23:52:42 2002
Received: with ECARTIS (v1.0.0; list dovecot); Tue, 26 Nov 2002 23:52:42 +0200 (EET)
Return-Path: <tss@iki.fi>
Delivered-To: dovecot@procontrol.fi
Received: from hurina (ip213-185-36-189.laajakaista.mtv3.fi [213.185.36.189])
	by danu.procontrol.fi (Postfix) with ESMTP id B3BBB2382F
	for <dovecot@procontrol.fi>; Tue, 26 Nov 2002 23:52:42 +0200 (EET)
Received: by hurina (Postfix, from userid 1000)
	id 6F4C65E01F27; Tue, 26 Nov 2002 23:52:37 +0200 (EET)
Subject: [dovecot] mbox problems
From: Timo Sirainen <tss@iki.fi>
To: dovecot@procontrol.fi
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1038347557.6700.3.camel@hurina>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.0 
Date: 26 Nov 2002 23:52:37 +0200
X-archive-position: 100
X-ecartis-version: Ecartis v1.0.0
Sender: dovecot-bounce@procontrol.fi
Errors-to: dovecot-bounce@procontrol.fi
X-original-sender: tss@iki.fi
Precedence: bulk
X-list: dovecot
X-UID: 100                                                  
Status: O

Strange .. I didn't think I had done anything that could break things
too badly. Anyway, at least with Solaris EXPUNGE may corrupt part of the
mbox file, so don't do that for now.


