http://dovecot.org/releases/1.0/dovecot-1.0.6.tar.gz http://dovecot.org/releases/1.0/dovecot-1.0.6.tar.gz.sig
* IDLE: Interval between mailbox change notifies is now 1 second,
because some clients keep a long-running IDLE connection and use
other connections to actually read the mails.
* SORT: If Date: header is missing or broken, fallback to using
INTERNALDATE (as the SORT draft nowadays specifies).
+ deliver: If message begins with a "From " line, ignore it.
+ zlib plugin: If maildir file has a "Z" flag, open it with zlib.
- CREATE: Don't assert-crash if trying to create namespace prefix.
- SEARCH: Fixes to handling NOT operator with sequence ranges.
- LDAP reconnection fixes
- Maildir: Don't break when renaming mailboxes with '*' or '%'
characters and children.
- mbox: Fixed "file size unexpectedly shrinked" error in some
conditions.
- quota+mbox: Don't fail if trying to delete a directory.
- Fixes to running from inetd- Timo Sirainen tss@iki.fi:
- mbox: Fixed "file size unexpectedly shrinked" error in some conditions.
Shrink, shrunk, shrunk :)
Thanks for the new version.
-- Ralf Hildebrandt (Ralf.Hildebrandt@charite.de) plonk@charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de This is the first age that's paid much attention to the future, which is a little ironic since we may not have one. -- Arthur Clarke
On Sun, 2007-10-28 at 12:14 +0100, Ralf Hildebrandt wrote:
- Timo Sirainen tss@iki.fi:
- mbox: Fixed "file size unexpectedly shrinked" error in some conditions.
Shrink, shrunk, shrunk :)
Shrink, shrank, shrunk :P
- Timo Sirainen tss@iki.fi:
On Sun, 2007-10-28 at 12:14 +0100, Ralf Hildebrandt wrote:
- Timo Sirainen tss@iki.fi:
- mbox: Fixed "file size unexpectedly shrinked" error in some conditions.
Shrink, shrunk, shrunk :)
Shrink, shrank, shrunk :P
ARGGGGHHGHGHGH. I suck.
-- Ralf Hildebrandt (Ralf.Hildebrandt@charite.de) plonk@charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de Ich habe hier Windows 2000 spontan f�llt mir dazu die Szene aus das "Leben des Brian" ein, in der der Mitgefangene im Kerker Brian als G�nstling bezeichnet, weil er vom Kerkermeister angespuckt wurde.
- Ralf Hildebrandt Ralf.Hildebrandt@charite.de:
- Timo Sirainen tss@iki.fi:
On Sun, 2007-10-28 at 12:14 +0100, Ralf Hildebrandt wrote:
- Timo Sirainen tss@iki.fi:
- mbox: Fixed "file size unexpectedly shrinked" error in some conditions.
Shrink, shrunk, shrunk :)
Shrink, shrank, shrunk :P
ARGGGGHHGHGHGH. I suck.
Go, see a shrunk. ;)
p@rick
-- state of mind Agentur für Kommunikation, Design und Softwareentwicklung
Patrick Koetter Tel: 089 45227227 Echinger Strasse 3 Fax: 089 45227226 85386 Eching Web: http://www.state-of-mind.de
Amtsgericht München Partnerschaftsregister PR 563
- Patrick Ben Koetter p@state-of-mind.de:
ARGGGGHHGHGHGH. I suck.
Go, see a shrunk. ;)
A shrunk shrink? Right now, we have to sell our Schrank (cupboard).
-- Ralf Hildebrandt (Ralf.Hildebrandt@charite.de) plonk@charite.de Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..." -- Actual explanation obtained from the Micro$oft help desk.
On Oct 27, 2007, at 8:16 PM, Timo Sirainen wrote:
http://dovecot.org/releases/1.0/dovecot-1.0.6.tar.gz http://dovecot.org/releases/1.0/dovecot-1.0.6.tar.gz.sig
Thanks for the release, Timo
Should dovecot-sieve-1.0.2 work ok with v1.0.6 ?
B. Bodger
On Sun, 2007-10-28 at 09:49 -0400, Bruce Bodger wrote:
On Oct 27, 2007, at 8:16 PM, Timo Sirainen wrote:
http://dovecot.org/releases/1.0/dovecot-1.0.6.tar.gz http://dovecot.org/releases/1.0/dovecot-1.0.6.tar.gz.sig
Thanks for the release, Timo
Should dovecot-sieve-1.0.2 work ok with v1.0.6 ?
Yes.
On Sunday, October 28 at 03:16 AM, quoth Timo Sirainen:
- SORT: If Date: header is missing or broken, fallback to using INTERNALDATE (as the SORT draft nowadays specifies).
Since this is a subject I looked at before, I'm rather curious. Where in the SORT draft does it say to fall back to INTERNALDATE? What I read (from http://tools.ietf.org/id/draft-ietf-imapext-sort-19.txt, section 2.2) is this:
As used in this document, the term "sent date" refers to the date
and time from the Date: header, adjusted by time zone to normalize
to UTC. For example, "31 Dec 2000 16:01:33 -0800" is equivalent
to the UTC date and time of "1 Jan 2001 00:01:33 +0000".
If the time zone is invalid, the date and time SHOULD be treated
as UTC. If the time is also invalid, the time SHOULD be treated
as 00:00:00. If there is no valid date or time, the date and time
SHOULD be treated as 00:00:00 on the earliest possible date.The key part is that last sentence: without a Date header, there is no valid date or time, so the date and time SHOULD be treated as 00:00:00 on the *earliest possible* date. The earliest possible date, however, is not INTERNALDATE, but is instead the earliest timestamp in any of the Received headers (or INTERNALDATE, if that's earlier, though that would be pretty rare).
Even if we didn't feel like parsing Received headers, mail_get_received_date() (i.e. the current 1.0.7 implementation) is wrong because it isn't 00:00:00 on that date.
Thus, I think mail_sort_get_date() in imap-sort.c should look more like this:
static time_t mail_sort_get_date(struct mail *mail) { time_t t, t2;
t = mail_get_date(mail, NULL);
if (t == 0 || t == (time_t)-1) {
/* missing or broken Date: header */
const char *const *headers = mail_get_headers(mail, "Received");
if (headers != NULL && headers[0] != NULL) {
while (headers[1] != NULL) headers++; // find the last one
/* first, find the semicolon */
const char * curs = headers[0];
while (curs[0] != ';' && curs[0] != 0) {
if (curs[0] == '(')
while (curs[0] != ')' && curs[0] != 0) curs++;
curs++;
}
if (curs[0] == ';') {
curs++;
if (curs[0] != 0) {
int tz;
message_date_parse((const unsigned char *)curs,
strlen(curs), &t, &tz);
}
}
}
t2 = mail_get_received_date(mail); // INTERNALDATE
if (t2 < t) t = t2;
}
return t;}
However, this doesn't follow the spec's requirement of being 00:00:00 on that date. I'm not sure if there's an easy fix, though (be nice if we could just apply a bitmask; but we can't).
What do you think?
~Kyle
A tyrant must put on the appearance of uncommon devotion to religion. Subjects are less apprehensive of illegal treatment from a ruler whom they consider God-fearing and pious. On the other hand, they do less easily move against him, believing that he has the gods on his side. -- Aristotle
On Thursday, November 1 at 02:31 PM, quoth Kyle Wheeler:
On Sunday, October 28 at 03:16 AM, quoth Timo Sirainen:
- SORT: If Date: header is missing or broken, fallback to using INTERNALDATE (as the SORT draft nowadays specifies).
Since this is a subject I looked at before, I'm rather curious. Where in the SORT draft does it say to fall back to INTERNALDATE? What I read (from http://tools.ietf.org/id/draft-ietf-imapext-sort-19.txt, section 2.2) is this:
A better, more stable link is here: http://tools.ietf.org/html/draft-ietf-imapext-sort
As used in this document, the term "sent date" refers to the date
and time from the Date: header, adjusted by time zone to
normalize to UTC. For example, "31 Dec 2000 16:01:33 -0800" is
equivalent to the UTC date and time of "1 Jan 2001 00:01:33
+0000".
If the time zone is invalid, the date and time SHOULD be treated
as UTC. If the time is also invalid, the time SHOULD be treated
as 00:00:00. If there is no valid date or time, the date and
time SHOULD be treated as 00:00:00 on the earliest possible date.~Kyle
The fact that we live at the bottom of a deep gravity well, on the surface of a gas-covered planet going around a nuclear fireball 90 million miles away, and think this to be normal, is obviously some indication of how skewed our perspective tends to be... -- Douglas Adams
On Thu, 2007-11-01 at 14:31 -0500, Kyle Wheeler wrote:
On Sunday, October 28 at 03:16 AM, quoth Timo Sirainen:
- SORT: If Date: header is missing or broken, fallback to using INTERNALDATE (as the SORT draft nowadays specifies).
Since this is a subject I looked at before, I'm rather curious. Where in the SORT draft does it say to fall back to INTERNALDATE?
Just search for INTERNALDATE :)
DATE
Sent date and time from the Date: header, adjusted by time
zone. This differs from the SENTON criteria in SEARCH, which
uses just the date and not the time, nor adjusts by time zone.
If the sent date can not be determined (a Date: header is
missing or can not be parsed), the INTERNALDATE for that
message is used as the sent date.Treating invalid time as 00:00:00 should probably be done at some point, but it's a pretty rare problem and also a SHOULD, not a MUST :)
On Friday, November 2 at 04:50 PM, quoth Timo Sirainen:
On Thu, 2007-11-01 at 14:31 -0500, Kyle Wheeler wrote:
On Sunday, October 28 at 03:16 AM, quoth Timo Sirainen:
- SORT: If Date: header is missing or broken, fallback to using INTERNALDATE (as the SORT draft nowadays specifies).
Since this is a subject I looked at before, I'm rather curious. Where in the SORT draft does it say to fall back to INTERNALDATE?
Just search for INTERNALDATE :)
DATE Sent date and time from the Date: header, adjusted by time zone. This differs from the SENTON criteria in SEARCH, which uses just the date and not the time, nor adjusts by time zone. If the sent date can not be determined (a Date: header is missing or can not be parsed), the INTERNALDATE for that message is used as the sent date.
Very interesting... two different pages on the IETF's website have two different texts for version 19 of that draft. Odd.
Anyway, at best, it would seem that the text has multiple potential interpretations, because the parenthetical explanation there of what it means for a sent date to be un-determinable is different from (and contradictory of) what it says in section 2.2 (which is what I quoted).
Treating invalid time as 00:00:00 should probably be done at some point, but it's a pretty rare problem and also a SHOULD, not a MUST :)
I would tend to disagree - the draft says more than simply that invalid time must be treated as 00:00:00, but rather:
If there is no valid date or time, the date and time SHOULD be
treated as 00:00:00 on the earliest possible date.Thus, even if you fall back to INTERNALDATE, the time should be zeroed out. But you're right, it is a SHOULD rather than a MUST.
~Kyle
If God can work through me, he can work through anyone. -- St. Francis of Assisi
On Fri, 2007-11-02 at 10:29 -0500, Kyle Wheeler wrote:
DATE Sent date and time from the Date: header, adjusted by time zone. This differs from the SENTON criteria in SEARCH, which uses just the date and not the time, nor adjusts by time zone. If the sent date can not be determined (a Date: header is missing or can not be parsed), the INTERNALDATE for that message is used as the sent date.Very interesting... two different pages on the IETF's website have two different texts for version 19 of that draft. Odd.
Anyway, at best, it would seem that the text has multiple potential interpretations, because the parenthetical explanation there of what it means for a sent date to be un-determinable is different from (and contradictory of) what it says in section 2.2 (which is what I quoted).
I think you should bring these up in imap-protocol list. I noticed this only because I was comparing Dovecot's and UW-IMAP's SORT output and wondered why it was different.
participants (5)
-
Bruce Bodger
-
Kyle Wheeler
-
Patrick Ben Koetter
-
Ralf Hildebrandt
-
Timo Sirainen