[Dovecot] v1.2.1 released
http://dovecot.org/releases/1.2/dovecot-1.2.1.tar.gz http://dovecot.org/releases/1.2/dovecot-1.2.1.tar.gz.sig
Mainly fixes to some issues found by people when upgrading to v1.2.0.
* GSSAPI: Changed logging levels and improved the messages.
Changed the way cross-realm authentication handling is done,
hopefully it's working now for everyone.
* imap/pop3 logins now fail if home directory path is relative.
v1.2.0 deliver was already failing with these and they could have
caused problems even with v1.1.
* IMAP: Custom authentication failure messages are now prefixed with
[ALERT] to get more clients to actually show them.
+ Improved some error messages.
- pop3: AUTH PLAIN was broken when SASL initial response wasn't given.
- mbox: New mailboxes were created with UIDVALIDITY 1.
- quota-fs was defaulting to group quota instead of user quota.
- Fixed ACLs to work with mbox.
- Fixed fchmod(-1, -1) errors with BSDs
- convert plugin / convert-tool: Fixed changing hierarchy separators
in mailbox names when alt_hierarchy_char isn't set.Timo,
On Jul 9, 2009, at 10:00 PM, Timo Sirainen wrote:
http://dovecot.org/releases/1.2/dovecot-1.2.1.tar.gz http://dovecot.org/releases/1.2/dovecot-1.2.1.tar.gz.sig
I was a bit surprised to see these in the log this morning after
upgrading from 1.2.0 to 1.2.1
7/10/09 7:21:17 AM dovecot[67884] deliver(llyles): Rebuilding index
file /Users/llyles/Maildir/dovecot.index: CPU architecture changed
[..]
7/10/09 7:30:15 AM dovecot[67951] deliver(gzinkus): Rebuilding index
file /Users/gzinkus/Maildir/dovecot.index: CPU architecture changed
[..]
7/10/09 7:52:36 AM dovecot[67038] IMAP(gzinkus): Rebuilding index
file /Users/gzinkus/Maildir/.Sent Messages/dovecot.index: CPU
architecture changed
I also saw them when I recently upgraded from 1.1.16 to 1.2.0 and
simultaneously switched to a new server (FROM PowerPC to Intel Mac
Pro) but didn't expect to see them when simply upgrading to 1.2.1.
Do they have any relevance?
Thanks, B. Bodger
On Fri, 2009-07-10 at 08:03 -0500, Bruce Bodger wrote:
7/10/09 7:21:17 AM dovecot[67884] deliver(llyles): Rebuilding index
file /Users/llyles/Maildir/dovecot.index: CPU architecture changed [..] 7/10/09 7:30:15 AM dovecot[67951] deliver(gzinkus): Rebuilding index
file /Users/gzinkus/Maildir/dovecot.index: CPU architecture changed [..] 7/10/09 7:52:36 AM dovecot[67038] IMAP(gzinkus): Rebuilding index
file /Users/gzinkus/Maildir/.Sent Messages/dovecot.index: CPU
architecture changedI also saw them when I recently upgraded from 1.1.16 to 1.2.0 and
simultaneously switched to a new server (FROM PowerPC to Intel Mac
Pro) but didn't expect to see them when simply upgrading to 1.2.1.
Maybe those mailboxes just hadn't been opened since the PPC -> Intel change?
On Jul 10, 2009, at 10:47 AM, Timo Sirainen wrote:
I also saw them when I recently upgraded from 1.1.16 to 1.2.0 and simultaneously switched to a new server (FROM PowerPC to Intel Mac Pro) but didn't expect to see them when simply upgrading to 1.2.1.
Maybe those mailboxes just hadn't been opened since the PPC -> Intel change?
That's not the case. They had been opened.
No big deal: everything is working famously. Just a curiosity.
Thank you.
B. Bodger
On 11/07/2009, at 3:32 AM, Bruce Bodger wrote:
On Jul 10, 2009, at 10:47 AM, Timo Sirainen wrote:
I also saw them when I recently upgraded from 1.1.16 to 1.2.0 and simultaneously switched to a new server (FROM PowerPC to Intel Mac Pro) but didn't expect to see them when simply upgrading to 1.2.1.
Maybe those mailboxes just hadn't been opened since the PPC -> Intel change?
That's not the case. They had been opened.
No big deal: everything is working famously. Just a curiosity.
Thank you.
B. Bodger
Same thing happened to me.
Also happened when I upgraded from 1.2RC5 to 1.2.
Everything works fine, but it gave me cause for concern the first time!
Also on OS X, but I've only ever run the mail server on an Intel Mac,
which makes it even stranger. Have compiled Dovecot in 64-bit mode if
that makes a difference.
James.
Hi, I have a global script (run by "run_before" in dovecot.conf) and a user script. All scripts get compiled correctly and running. however , times to times, the filters are not applied, whereas they should, especially the one run all the time, against Spam: ------------------------------- require ["fileinto", "reject"]; if anyof( header :contains ["Subject"] ["***SPAM***"], header :contains ["X-Spam-Flag"] ["YES"] ) { fileinto "Spam"; reject "Your message has been considered SPAM by our mail server"; stop; } ------------------------------------ My config dovecot: ... plugin { sieve_before=/data/mail/global.sieve sieve_global_path=/data/mail/global.sieve sieve_global_dir=/data/mail sieve_dir=/data/mail/%d/%n/sieve sieve=/data/mail/%d/%n/local.sieve } James Brown wrote:
On 11/07/2009, at 3:32 AM, Bruce Bodger wrote:
On Jul 10, 2009, at 10:47 AM, Timo Sirainen wrote:
I also saw them when I recently upgraded from 1.1.16 to 1.2.0 and simultaneously switched to a new server (FROM PowerPC to Intel Mac Pro) but didn't expect to see them when simply upgrading to 1.2.1.
Maybe those mailboxes just hadn't been opened since the PPC -> Intel change?
That's not the case. They had been opened.
No big deal: everything is working famously. Just a curiosity.
Thank you.
B. Bodger
Same thing happened to me.
Also happened when I upgraded from 1.2RC5 to 1.2.
Everything works fine, but it gave me cause for concern the first time!
Also on OS X, but I've only ever run the mail server on an Intel Mac, which makes it even stranger. Have compiled Dovecot in 64-bit mode if that makes a difference.
James.
I have a global script (run by "run_before" in dovecot.conf) and a user script.
All scripts get compiled correctly and running.
however , times to times, the filters are not applied, whereas they should, especially the one run all the time, against Spam:
------------------------------- require ["fileinto", "reject"];
if anyof( header :contains ["Subject"] ["***SPAM***"], header :contains ["X-Spam-Flag"] ["YES"] ) { fileinto "Spam"; reject "Your message has been considered SPAM by our mail server"; stop; } This Sieve script will fail at runtime if any of the presented conditions is true, because the reject action conflicts with fileinto. This should have produced an error message in your Dovecot logs. When
Hi Joan, Joan Moreau wrote: this situation occurs, the implicit keep action is executed meaning that the message is delivered into the default folder.
My config dovecot: ... plugin { sieve_before=/data/mail/global.sieve sieve_global_path=/data/mail/global.sieve sieve_global_dir=/data/mail sieve_dir=/data/mail/%d/%n/sieve sieve=/data/mail/%d/%n/local.sieve }
Also, the config above will execute global.sieve two times sequentially if the user has no local.sieve, which is probably not what you want. Set sieve_global_path only when you want to give users some default filtering when they do not have a script of their own. The sieve_before setting is normally used to force sieve rules on all users, even when they have a script of their own (it is executed before theirs). PS: Please do not hijack threads by replying to an unrelated message. Just start a new topic. Regards, Stephan.
On 07/12/2009 03:13 PM Joan Moreau wrote:
… { … reject "Your message has been considered SPAM by our mail server"; stop; } …
Please don't do that: http://www.dontbouncespam.org/
Reject Spam in the SMTP session.
Regards, Pascal
The trapper recommends today: fabaceae.0919410@localdomain.org
Pascal Volk schrieb:
On 07/12/2009 03:13 PM Joan Moreau wrote:
… { … reject "Your message has been considered SPAM by our mail server"; stop; } …
Please don't do that: http://www.dontbouncespam.org/
Reject Spam in the SMTP session.
Regards, Pascal
really awsome, how many people dont know this simple issue and wonder by get blacklisted in rbl by backscattering/spamming
to get out of the problem, spam marked messages should filtered by a global sieve rule to a special junk folder so that it never will be honored by vacation, for pop3 users ( which will never see mail in other folders ) mails in the imap spam folder, can be down popped using the virtual plugin, a better and cheaper way is to reject known spam on the income smpt level by clamav-milter with sanesecurity antispam signatures ( but as this might not catch all spam the above sieve antisapm policy should be used ever ), for other vacation functions ( over forward script etc ) same issue ( not answer to marked spam mail ) should be honored in the reply code of the script, another possibility ist to quarantaine spam mails before getting to inbox( look amavis-new,clamav-milter ) anyway answering to spam mails should be avoided ever until most of the senders are faked
-- Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Le 10 juil. 09 à 05:00, Timo Sirainen a écrit :
http://dovecot.org/releases/1.2/dovecot-1.2.1.tar.gz http://dovecot.org/releases/1.2/dovecot-1.2.1.tar.gz.sig
Mainly fixes to some issues found by people when upgrading to v1.2.0.
[...]
- mbox: New mailboxes were created with UIDVALIDITY 1.
Thanks :-)
[...]
- Fixed ACLs to work with mbox.
Thanks again :-) :-)
- Fixed fchmod(-1, -1) errors with BSDs
Wasn't it more exactly that problem that appeared with AIX+NFS4?
For the sake of future reference, wouldn't it be more relevant to have
a memo such as "Fixed fchmod(-1, -1) errors which appeared under
certain circumstances, the operation being anyway uneeded"?
[...]
Anyway, I tested your patches as soon as you released them wrt ACLs
and mbox format (seems to be OK up to now!).
BTW, this led me to devise a more or less systematic way to compile
the hg releases under Mac OS X (with Developer Tools installed, of
course, but without many prerequisites). Could this be worth of
sharing? If yes, how?
Axel
participants (8)
-
Axel Luttgens
-
Bruce Bodger
-
James Brown
-
Joan Moreau
-
Pascal Volk
-
Robert Schetterer
-
Stephan Bosch
-
Timo Sirainen