dovecot - Jul 2003 - Date sort-order ignoring timezone, and a few Q's.

Timo, thanks for writing and releasing Dovecot. I've recently
discovered it and have been very impressed at the speed and balance
between flexibility and simplicity.

I had to make a packet-trace to be sure that encryption with OpenSSL was
working correctly, since it all 'just worked' first time without complex
configuration, which I don't think I've ever seen before ;-) LDAP too
was quite straightforward (after I worked out where my virtual-domain
schema differed from what was required).

One small glitch I have noticed is that when the client requests a list
of messages sorted by date, the timezone is ignored.

For example, listed in descending order:

07/07/2003 00:01 +0300 (= 21:01 UT)
06/07/2003 23:15 +0100 (= 22:15 UT)
06/07/2003 19:03 +0100 (= 18:03 UT)

I think that this should instead be...

06/07/2003 23:15 +0100 (= 22:15 UT)
07/07/2003 00:01 +0300 (= 21:01 UT)
06/07/2003 19:03 +0100 (= 18:03 UT)

It's most noticable when the client (Mulberry in my case) is configured
to display all times in the local timezone. (Mulberry has recently added
custom flags which work perfectly with Dovecot - I was hoping this would
be the case, and was one of the reasons I was looking for something to
replace the version of Courier I previously had installed). Mulberry 
does
like to have NAMESPACE otherwise it usually asks for folder locations on
connecting, btw. No real problem, though.

A little tip: if anyone is interested in having their MDA write Maildir
with CR+LF so that sendfile(2) can be used on all messages (not just 
those
created by Dovecot), Exim offers this natively by adding the
"use_crlf"
option to the appendfile transport which seems to work fine with 0.99.10
(though not 0.99.9.1, maybe because of 2003-06-04 17:39 in Changelog).

It seems Dovecot is using the ,W= Maildir tag for some type of size
instead of ,S= but I haven't traced far enough to work out what exactly
W/virtual_size means, am I right in guessing that it might be 'wire 
size'
i.e. message-size-with-CRLF-line-endings? (If so, use_crlf in exim.conf
can be augmented with "maildir_tag = ,W=$message_size" to help keep
overheads to a minimum).

And, one final question: for a dual-stack machine to listen on both IPv6
and IPv4 sockets, is the currently preferred option simply to start two
instances of Dovecot with their own dovecot.conf containing different
*_listen parameters?

--Stu

On Mon, 2003-07-07 at 03:51, Stuart Henderson wrote:
> One small glitch I have noticed is that when the client requests a list
> of messages sorted by date, the timezone is ignored.
It's not ignored, I just recently "fixed" it. Now it's
properly fixed :)
> It seems Dovecot is using the ,W= Maildir tag for some type of size
> instead of ,S= but I haven't traced far enough to work out what exactly
> W/virtual_size means, am I right in guessing that it might be 'wire 
> size'
> i.e. message-size-with-CRLF-line-endings?
Yes. S means the actual size of the file, W is the size with CRs.
> And, one final question: for a dual-stack machine to listen on both IPv6
> and IPv4 sockets, is the currently preferred option simply to start two
> instances of Dovecot with their own dovecot.conf containing different
> *_listen parameters?
Currently, yes. I'll probably add support for multiple listening sockets
per server some day.

>> One small glitch I have noticed is that when the client requests a
>> list of messages sorted by date, the timezone is ignored.
>
> It's not ignored, I just recently "fixed" it. Now it's
properly fixed
> :)
Heheh.. Yes, I confirm that. (:
>> It seems Dovecot is using the ,W= Maildir tag for some type of size
>> instead of ,S= but I haven't traced far enough to work out what
>> exactly W/virtual_size means, am I right in guessing that it might
>> be 'wire  size'
>> i.e. message-size-with-CRLF-line-endings?
>
> Yes. S means the actual size of the file, W is the size with CRs.
Thanks, that's good.
>> And, one final question: for a dual-stack machine to listen on both
>> IPv6 and IPv4 sockets, is the currently preferred option simply to
>> start two instances of Dovecot with their own dovecot.conf
>> containing different *_listen parameters?
>
> Currently, yes. I'll probably add support for multiple listening
> sockets per server some day.
There is no problem to have two instances running, though it might be 
more admin-friendly to allow the listen addresses to be supplied on the 
command-line, since it would save maintaining a second config file (and 
I imagine this would be easier for you than changing the socket code), 
but this is quite a low priority I think.