Re: [Dovecot] Problems with dovecot/sieve and vacation

[iaslanidis]

Hello,

Thank you for the reply. I will plan to do the upgrade some time soon, that is 
not questionable. Now back to this, I checked the following:

# strings /usr/libexec/dovecot/deliver | grep sendmail
/usr/lib/sendmail

So, if I understand correctly, this is fine.

What I have in maillog is the following:

[EMAIL PROTECTED]> for <[EMAIL PROTECTED]> ORCPT=rfc822;[EMAIL PROTECTED]
Jul 19 01:58:56 se01 spampd[9143]: clean message <[EMAIL PROTECTED]> 
(0.28/3.50) from <[EMAIL PROTECTED]> for <[EMAIL PROTECTED]> 
ORCPT=rfc822;[EMAIL PROTECTED] in 0.04s, 1926 bytes.
Jul 19 01:58:56 se01 clamsmtpd: 10C4A0: [EMAIL PROTECTED], [EMAIL PROTECTED], 
status=CLEAN
Jul 19 01:58:56 se01 postfix/smtp[15494]: AC414250084: to=<[EMAIL PROTECTED]>, 
relay=127.0.0.1[127.0.0.1]:10025, delay=0.86, delays=0.55/0.01/0.06/0.24, 
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 253AE250133)
Jul 19 01:58:56 se01 deliver([EMAIL PROTECTED]): execv(/usr/lib/sendmail) 
failed: Permission denied
Jul 19 01:58:56 se01 deliver([EMAIL PROTECTED]): Sendmail process terminated 
abnormally, exit status 89
Jul 19 01:58:56 se01 deliver([EMAIL PROTECTED]): sieve runtime error: Vacation: 
Error sending mail
Jul 19 01:58:57 se01 deliver([EMAIL PROTECTED]): msgid=<[EMAIL PROTECTED]>: 
saved mail to INBOX
Jul 19 01:58:57 se01 deliver([EMAIL PROTECTED]): msgid=<[EMAIL PROTECTED]>: 
saved mail to INBOX
Jul 19 01:58:57 se01 postfix/pipe[15529]: 253AE250133: to=<[EMAIL PROTECTED]>, 
relay=dovecot, delay=1.5, delays=0.24/0.01/0/1.2, dsn=2.0.0, status=sent 
(delivered via dovecot service)

For what I see here, this could be a SELinux permission problem, am I right?

Regards,

Ioannis


On Sat, 19 Jul 2008 02:35:11 +0300, Uldis Pakuls <[EMAIL PROTECTED]> wrote:
> Vacation code calls 2 functions: first marks dupes (it seems working) ,
> then, if it success second function is called which actualy sends
> vacation message. This action (success or failure) is loged in log file.
> 1. wthat is in your log files?
> 2. the only reason I can guess about failure in second function is
> sendmail binary.  default value of "sendmail_path" (hardcoded) is
> /usr/lib/sendmail. You can verify this:  "strings
> /path/to/dovecot/deliver | grep sendmail" If default value is incorrect
> try add sendmail_path variable in dovecot.conf

Re: [Dovecot] Problems with dovecot/sieve and vacation

[Uldis Pakuls]

[EMAIL PROTECTED] wrote:

Thank you for the reply. Because of the fact that this is a production server, 
I would like to be 100% sure that upgrading sieve will fix this issue. Could 
you confirm this?

Regards,

Ioannis
  

Not sure. Vacation code is not changed since... first release sieve plugin.

Vacation code calls 2 functions: first marks dupes (it seems working) , 
then, if it success second function is called which actualy sends 
vacation message. This action (success or failure) is loged in log file.

1. wthat is in your log files?
2. the only reason I can guess about failure in second function is 
sendmail binary.  default value of "sendmail_path" (hardcoded) is 
/usr/lib/sendmail. You can verify this:  "strings 
/path/to/dovecot/deliver | grep sendmail" If default value is incorrect 
try add sendmail_path variable in dovecot.conf

e.g.:
-
protocol lda {
  sendmail_path = /usr/sbin/sendmail
  
}
-

..anyway I recommend upgrade to 1.0 release at less.

Uldis

Re: [Dovecot] Problems with dovecot/sieve and vacation

[Charles Marcus]

On 7/18/2008, [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:

Thank you for the reply. Because of the fact that this is a
production server, I would like to be 100% sure that upgrading sieve
will fix this issue. Could you confirm this?


Because its a production server, you should be most concerned about 
upgrading... you are using a VERY EARLY RELEASE CANDIDATE version (there 
were more than 30 (thats THIRTY) RC's of the 1.0 series) of an OLDER 
RELEASE version (dovecot is currently at 1.1.1 - lots of reasons to 
upgrade to the 1.1.x series)...


Hopefully you understand that most people don't have time to go back and 
read all of the release notes of all of the 40+ releases since yours was 
released to see if your particular problem was fixed.


--

Best regards,

Charles

Re: [Dovecot] Problems with dovecot/sieve and vacation

[iaslanidis]

Thank you for the reply. Because of the fact that this is a production server, 
I would like to be 100% sure that upgrading sieve will fix this issue. Could 
you confirm this?

Regards,

Ioannis

On Fri, 18 Jul 2008 13:06:04 -0400, Charles Marcus <[EMAIL PROTECTED]> wrote:
> On 7/18/2008, Ioannis Aslanidis ([EMAIL PROTECTED]) wrote:
>> # dovecot --version
>> 1.0.rc15
> 
> Upgrade... this is very old...
> 
> There are lots of reasons to upgrade, but sieve stuff has changed a LOT
> sinc rc15...
> 
> --
> 
> Best regards,
> 
> Charles

Re: [Dovecot] quota vs. antispam issue

[Johannes Berg]

On Fri, 2008-07-18 at 20:58 +0300, Timo Sirainen wrote:

> So the quota code eventually sees both ctx->dest_mail = NULL and qt- 
>  >tmp_mail = NULL. I'm not really sure what the right fix for this  
> is.. ctx->dest_mail should be set by something. Perhaps if quota/ 
> antispam overrides it it should set it, and mailbox_save_init()  
> shouldn't set it if it's already set..

Ok, that seems to work, but I think a better alternative would probably
be to make dest_mail a struct mail ** like the context.

Alternatively, we could ensure that dest_mail is never NULL to start
with, and have mailbox_save_init() create one, but I'm not sure about
the performance implications of that. The plugins could, if that's
possible (haven't checked) set those flags of what they require, and if
there are no plugins then a struct mail with no MAIL_FETCH_* flags
wouldn't hurt much, would it?

johannes


signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] quota vs. antispam issue

[Johannes Berg]

> I recently wondered about that code. The problem is:
> 
> 1. save_init() is called with dest_mail=NULL
> 2. antispam sees that dest_mail=NULL and sets it, and calls  
> super.save_init()
> 3. quota sees that dest_mail != NULL so it doesn't set qt->tmp_mail
> 4. mailbox_save_init() stores ctx->dest_mail = NULL (because it  
> doesn't see the updated value)

Good. I just analysed it down to the same thing :)

> So the quota code eventually sees both ctx->dest_mail = NULL and qt- 
>  >tmp_mail = NULL. I'm not really sure what the right fix for this  
> is.. ctx->dest_mail should be set by something. Perhaps if quota/ 
> antispam overrides it it should set it, and mailbox_save_init()  
> shouldn't set it if it's already set..

Ok, so mailbox_save_init() is the code I said about that it only sets it
up later.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] quota vs. antispam issue

[Johannes Berg]

On Fri, 2008-07-18 at 19:40 +0200, Johannes Berg wrote:
> Can you help me maybe? I don't see the bug.

> I'll keep digging but I don't see why 
> 
> return quota_check(ctx->transaction, ctx->dest_mail != NULL ?
>ctx->dest_mail : qt->tmp_mail);
> 
> should pass NULL in the second argument.

Ok, I think I see the issue, and I think both quota and antispam
(because I copied from quota) have it.

Consider quota_save_init:

quota_save_init(struct mailbox_transaction_context *t,
enum mail_flags flags, struct mail_keywords *keywords,
time_t received_date, int timezone_offset,
const char *from_envelope, struct istream *input,
struct mail *dest_mail, struct mail_save_context **ctx_r)
...
if (dest_mail == NULL) {
/* we always want to know the mail size */
if (qt->tmp_mail == NULL) {
qt->tmp_mail = mail_alloc(t, MAIL_FETCH_PHYSICAL_SIZE,
  NULL);
}
dest_mail = qt->tmp_mail;
}

return qbox->module_ctx.super.
save_init(t, flags, keywords, received_date,   
  timezone_offset, from_envelope,
  input, dest_mail, ctx_r);
}


As you can see, this ends up always passing a non-NULL dest_mail into
super.save_init(). Now, antispam has the same code, and let's assume
that super.save_init() is quota_save_init, the code above. It will
always be passed a dest_mail which is non-NULL, thus qt->tmp_mail will
always be NULL.

Now, consider quota_save_finish. It does not get an explicit dest_mail,
so it takes it from the mail_save_context. There, however, it ends up
being NULL because antispam created the mail and not whatever fills the
mail_save_context. Hence, _both_ ctx->dest_mail and qt->tmp_mail end up
being NULL.

I think the problem is caused by the explicit/implicit API difference.
The quick fix would probably be to assign dest_mail also to the context
in quota_save_init, like this:

diff -r ffbe9f9e0376 src/plugins/quota/quota-storage.c
--- a/src/plugins/quota/quota-storage.c Fri Jul 18 17:55:02 2008 +0300
+++ b/src/plugins/quota/quota-storage.c Fri Jul 18 19:50:53 2008 +0200
@@ -233,10 +233,14 @@
dest_mail = qt->tmp_mail;
}
 
-   return qbox->module_ctx.super.
+   ret = qbox->module_ctx.super.
save_init(t, flags, keywords, received_date,
  timezone_offset, from_envelope,
  input, dest_mail, ctx_r);
+
+   (*ctx_r)->dest_mail = dest_mail;
+
+   return ret;
 }
 
 static int quota_save_finish(struct mail_save_context *ctx)


Except, that doesn't work, the dest_mail in the context is still NULL
again although the context is the same, so whichever code sets up the
context apparently only sets it up after our plugin returns, and the
plugin doesn't have access to it.

I think actually fixing it requires changes in the storage API.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] quota vs. antispam issue

[Timo Sirainen]

On Jul 18, 2008, at 8:40 PM, Johannes Berg wrote:


Can you help me maybe? I don't see the bug.

..
0x100929f4 in mail_get_physical_size (mail=0x0, size_r=0xbfeaf030)  
at mail.c:100

100 return p->v.get_physical_size(mail, size_r);
(gdb) bt
#0  0x100929f4 in mail_get_physical_size (mail=0x0,  
size_r=0xbfeaf030) at mail.c:100
#1  0x0fe29be0 in quota_try_alloc (ctx=0x101707a8, mail=0x0,  
too_large_r=0xbfeaf060)

   at quota.c:818

..

   return quota_check(ctx->transaction, ctx->dest_mail != NULL ?
  ctx->dest_mail : qt->tmp_mail);


I recently wondered about that code. The problem is:

1. save_init() is called with dest_mail=NULL
2. antispam sees that dest_mail=NULL and sets it, and calls  
super.save_init()

3. quota sees that dest_mail != NULL so it doesn't set qt->tmp_mail
4. mailbox_save_init() stores ctx->dest_mail = NULL (because it  
doesn't see the updated value)


So the quota code eventually sees both ctx->dest_mail = NULL and qt- 
>tmp_mail = NULL. I'm not really sure what the right fix for this  
is.. ctx->dest_mail should be set by something. Perhaps if quota/ 
antispam overrides it it should set it, and mailbox_save_init()  
shouldn't set it if it's already set..




PGP.sig
Description: This is a digitally signed message part

[Dovecot] quota vs. antispam issue

[Johannes Berg]

Can you help me maybe? I don't see the bug.

QUOTA=maildir QUOTA_RULE='*:storage=100M' MAIL_PLUGINS="antispam quota" 
MAIL_PLUGIN_DIR=/home/johannes/Projects/dovecot/antispam gdb --args 
/home/johannes/Projects/dovecot/dovecot-1.1/src/imap/imap
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc-linux-gnu"...
(gdb) run
Starting program: /home/johannes/Projects/dovecot/dovecot-1.1/src/imap/imap 
* PREAUTH [CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND 
UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED 
I18NLEVEL=1] Logged in as johannes
01 select SPAM
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags 
permitted.
* 8 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1212140311] UIDs valid
* OK [UIDNEXT 9] Predicted next UID
01 OK [READ-WRITE] Select completed.
A003 APPEND SPAM () {2}
+ OK
ab

Program received signal SIGSEGV, Segmentation fault.
0x100929f4 in mail_get_physical_size (mail=0x0, size_r=0xbfeaf030) at mail.c:100
100 return p->v.get_physical_size(mail, size_r);
(gdb) bt
#0  0x100929f4 in mail_get_physical_size (mail=0x0, size_r=0xbfeaf030) at 
mail.c:100
#1  0x0fe29be0 in quota_try_alloc (ctx=0x101707a8, mail=0x0, 
too_large_r=0xbfeaf060)
at quota.c:818
#2  0x0fe303dc in quota_check (t=0x10170158, mail=0x0) at quota-storage.c:148
#3  0x0fe30968 in quota_save_finish (ctx=0x10177c10) at quota-storage.c:251
#4  0x0fdfec58 in antispam_save_finish (ctx=0x10177c10) at 
antispam-storage-1.1.c:178
#5  0x10097c94 in mailbox_save_finish (_ctx=0x10159004) at mail-storage.c:738
#6  0x10016988 in cmd_append_continue_message (cmd=0x10158f98) at 
cmd-append.c:408
#7  0x10015804 in client_input_append (cmd=0x10158f98) at cmd-append.c:79
#8  0x101029e0 in io_loop_handler_run (ioloop=0x10154aa8) at ioloop-epoll.c:201
#9  0x10101514 in io_loop_run (ioloop=0x10154aa8) at ioloop.c:308
#10 0x1003094c in main (argc=1, argv=0xbfeaf4b4, envp=0xbfeaf4bc) at main.c:293

I'll keep digging but I don't see why 

return quota_check(ctx->transaction, ctx->dest_mail != NULL ?
   ctx->dest_mail : qt->tmp_mail);

should pass NULL in the second argument.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] Permission problems

[M. Rodrigo Monteiro]

2008/7/18 M. Rodrigo Monteiro <[EMAIL PROTECTED]>:

>
>
> 2008/7/17 Benny Pedersen <[EMAIL PROTECTED]>:
>
>
>> On Thu, July 17, 2008 20:20, Timo Sirainen wrote:
>>
>> > This directory or one of its parent directories isn't owned by the user
>> > that logged in. So if you're using UID 108, chown -R 108 /home/vmail
>> > should do it.
>>
>> currect if id 108 gives 108
>>
>> if i am wroung tell me
>>
>>
>> --
>> Benny Pedersen
>> Need more webspace ? http://www.servage.net/?coupon=cust37098
>>
>>
> I'm reinstalling it. I'll upgrade dovecot to the latest version...
>
> Thanks for now,
> Rodrigo.
>
> --
> M. Rodrigo Monteiro
> [EMAIL PROTECTED]
> "Free as in Freedom, not free as in free beer"
> Linux User # 403730
>

Now it's a fresh installation with all the packages updated.
The problem is that I can't login with any user.
When I send an test e-mail to a new user, the directory
domain.ce.gov.br/user is created ok...

Here is the config.:


~# id dovecot
uid=201(dovecot) gid=201(dovecot) grupos=201(dovecot)

# id dovecot-auth
uid=202(dovecot-auth) gid=202(dovecot-auth) grupos=202(dovecot-auth)

# id vmail
uid=200(vmail) gid=200(vmail) grupos=200(vmail)

# /usr/local/dovecot/sbin/dovecot -n
# 1.1.1: /usr/local/dovecot/etc/dovecot.conf
log_path: /var/log/dovecot.log
info_log_path: /var/log/dovecot-info.log
ssl_disable: yes
disable_plaintext_auth: no
login_dir: /usr/local/dovecot/var/run/dovecot/login
login_executable: /usr/local/dovecot/libexec/dovecot/imap-login
valid_chroot_dirs: /home/vmail/domains
first_valid_uid: 201
last_valid_uid: 201
first_valid_gid: 201
last_valid_gid: 201
mail_location: maildir:/home/vmail/domains/%d/%n
auth default:
  user: dovecot-auth
  verbose: yes
  debug: yes
  debug_passwords: yes
  passdb:
driver: ldap
args: /usr/local/dovecot/etc/dovecot-ldap.conf
  userdb:
driver: ldap
args: /usr/local/dovecot/etc/dovecot-ldap.conf


# grep -v '^ *\(#.*\)\?$' /usr/local/dovecot/etc/dovecot-ldap.conf
hosts = localhost
dn = cn=dovecot,dc=,dc=ce,dc=gov,dc=br
dnpass = 
ldap_version = 3
base = o=mail, dc=, dc=ce, dc=gov, dc=br
deref = never
scope = subtree
user_attrs = mail,homeDirectory
user_filter =
(&(objectClass=JammMailAccount)(mail=%u)(accountActive=TRUE)(delete=FALSE))
pass_attrs = mail,userPassword
pass_filter =
(&(objectClass=JammMailAccount)(mail=%u)(accountActive=TRUE)(delete=FALSE))
default_pass_scheme = CRYPT

# tail -f /var/log/dovecot.log
dovecot: Jul 18 14:21:28 Error: auth(default):
ldap([EMAIL PROTECTED],XXX.XXX.XXX.XXX):
No password in reply

# cat /etc/saslauthd.conf
ldap_servers: ldap://127.0.0.1
ldap_search_base: o=mail,dc=X,dc=ce,dc=gov,dc=br
ldap_filter: (&(objectClass=JammMailAccount)(mail=%u@
%r)(accountActive=TRUE)(delete=FALSE))

# tail -f /var/log/dovecot-info.log
dovecot: Jul 18 14:21:26 Info: auth(default): client in: AUTH   1
PLAIN   service=imaplip=172.31.4.43 rip=XXX.XXX.XXX.XXX
lport=143   rport=3860
dovecot: Jul 18 14:21:26 Info: auth(default): client out: CONT  1
dovecot: Jul 18 14:21:26 Info: auth(default): client in: CONT   1
AHJvZHJpZ29Ac2VkdWMuY2UuZ292LmJyAHRlc3Rl
dovecot: Jul 18 14:21:26 Info: auth(default):
ldap([EMAIL PROTECTED],XXX.XXX.XXX.XXX):
pass search: base=o=mail, dc=, dc=ce, dc=gov, dc=br scope=subtree
filter=(&(objectClass=JammMailAccount)([EMAIL 
PROTECTED])(accountActive=TRUE)(delete=FALSE))
fields=mail,userPassword
dovecot: Jul 18 14:21:26 Info: auth(default):
ldap([EMAIL PROTECTED],XXX.XXX.XXX.XXX):
result: mail(mail)[EMAIL PROTECTED](userPassword)={CRYPT}YZJZNkBk381gg
dovecot: Jul 18 14:21:28 Info: auth(default): client out: FAIL  1
[EMAIL PROTECTED]temp
[EMAIL PROTECTED]

# tail -f /var/log/syslog
Jul 18 14:21:26 sedsrv043 slapd[1888]: conn=0 op=1 SRCH
base="o=mail,dc=,dc=ce,dc=gov,dc=br" scope=2 deref=0
filter="(&(objectClass=JammMailAccount)([EMAIL PROTECTED]
)(accountActive=TRUE)(delete=FALSE))"
Jul 18 14:21:26 sedsrv043 slapd[1888]: conn=0 op=1 SRCH attr=mail
userPassword
Jul 18 14:21:26 sedsrv043 slapd[1888]: <= bdb_equality_candidates: (mail)
not indexed
Jul 18 14:21:26 sedsrv043 slapd[1888]: <= bdb_equality_candidates:
(accountActive) not indexed
Jul 18 14:21:26 sedsrv043 slapd[1888]: <= bdb_equality_candidates: (delete)
not indexed
Jul 18 14:21:26 sedsrv043 slapd[1888]: conn=0 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Jul 18 14:21:28 sedsrv043 slapd[1888]: conn=0 op=2 SRCH
base="o=mail,dc=,dc=ce,dc=gov,dc=br" scope=2 deref=0
filter="(&(objectClass=JammMailAccount)([EMAIL PROTECTED]
)(accountActive=TRUE)(delete=FALSE))"

In phpLDAPadmin the userPassword attribute is {CRYPT}YZJZNkBk381gg


Regards,
Rodrigo.


-- 
M. Rodrigo Monteiro
[EMAIL PROTECTED]
"Free as in Freedom, not free as in free beer"
Linux User # 403730

Re: [Dovecot] Problems with dovecot/sieve and vacation

[Charles Marcus]

On 7/18/2008, Ioannis Aslanidis ([EMAIL PROTECTED]) wrote:

# dovecot --version
1.0.rc15


Upgrade... this is very old...

There are lots of reasons to upgrade, but sieve stuff has changed a LOT 
sinc rc15...


--

Best regards,

Charles

Re: [Dovecot] changing INTERNALDATE or similar

[Timo Sirainen]

On Jul 18, 2008, at 7:19 PM, Mateusz Kijowski wrote:



Why does it matter where the timestamp lives? No matter how it was
stored, you would have had the exact same problem because your client
told Dovecot to use the current timestamp when saving the messages.

And why would keeping the INTERNALDATE in mtime be bad? It only
changes if you write to the file. And existing mails must not be
modified or you'll get other problems as well.


I guess that with the zlib plugin this date is extracted from the gzip
metadata, right? I didn't preserve mtimes of gzipped mails...


I hadn't thought of that before. Yes, I should mention this in the  
wiki page that the mtime should be preserved.




PGP.sig
Description: This is a digitally signed message part

Re: [Dovecot] changing INTERNALDATE or similar

[Timo Sirainen]

On Jul 18, 2008, at 7:20 PM, Karl Rudnick wrote:


On Fri, 2008-07-18 at 08:52 -0700, Timo Sirainen wrote:


Why does it matter where the timestamp lives? No matter how it was
stored, you would have had the exact same problem because your client
told Dovecot to use the current timestamp when saving the messages.

And why would keeping the INTERNALDATE in mtime be bad? It only
changes if you write to the file. And existing mails must not be
modified or you'll get other problems as well.


Actually, it wasn't the client (Outlook) that told Dovecot. I rarely
save to my IMAP server from Outlook - only Thunderbird and  
Evolution. I

think it was a result of my original migration from mbox (uw-imap) to
Maildir (uw-imap). I did this by having both IMAP servers (uw and
dovecot) accounts alive simultaneously in evolution and let evolution
copy from the uw-account to the dovecot-imap account. It could be
evolution's fault, but I thought it was doing an IMAP4 copy, in which
case the INTERNALDATE should have been preserved according to the  
spec,

but maybe evolution was just doing its own thing.


You had two servers. There's no trans-server COPY command, so the  
client has to fetch the messages from one server and save the messages  
to another using APPEND command, which takes a parameter to specify  
the INTERNALDATE.



So, before the
migration, there was not even the concept of a timestamp on the uw- 
imap

store for each mail.


With mboxes it's stored in the From-line for each message.

Unfortunately, dates can change unexpectedly - not just when you  
modify
the file, as I move data around between machines as they become  
obsolete

and the wrong settings in the move can obliterate those mtimes - we
humans do make mistakes. Nevertheless, I am happy with my current
situation and at least understand what's going on.


Perhaps if you're not careful when copying. :) Anyway there isn't  
really any other good place to store the INTERNALDATE than mtime.  
Perhaps the timestamp in file name could be used, although maildir  
filenames aren't required to start with the timestamp so it should  
fallback to mtime then anyway.


PGP.sig
Description: This is a digitally signed message part

Re: [Dovecot] changing INTERNALDATE or similar

[Mateusz Kijowski]

>
> Why does it matter where the timestamp lives? No matter how it was
> stored, you would have had the exact same problem because your client
> told Dovecot to use the current timestamp when saving the messages.
>
> And why would keeping the INTERNALDATE in mtime be bad? It only
> changes if you write to the file. And existing mails must not be
> modified or you'll get other problems as well.

I guess that with the zlib plugin this date is extracted from the gzip 
metadata, right? I didn't preserve mtimes of gzipped mails...

--
Mateusz



signature.asc
Description: This is a digitally signed message part.

Re: [Dovecot] changing INTERNALDATE or similar

[Karl Rudnick]

On Fri, 2008-07-18 at 08:52 -0700, Timo Sirainen wrote:

> Why does it matter where the timestamp lives? No matter how it was  
> stored, you would have had the exact same problem because your client  
> told Dovecot to use the current timestamp when saving the messages.
> 
> And why would keeping the INTERNALDATE in mtime be bad? It only  
> changes if you write to the file. And existing mails must not be  
> modified or you'll get other problems as well.
> 
Actually, it wasn't the client (Outlook) that told Dovecot. I rarely
save to my IMAP server from Outlook - only Thunderbird and Evolution. I
think it was a result of my original migration from mbox (uw-imap) to
Maildir (uw-imap). I did this by having both IMAP servers (uw and
dovecot) accounts alive simultaneously in evolution and let evolution
copy from the uw-account to the dovecot-imap account. It could be
evolution's fault, but I thought it was doing an IMAP4 copy, in which
case the INTERNALDATE should have been preserved according to the spec,
but maybe evolution was just doing its own thing. So, before the
migration, there was not even the concept of a timestamp on the uw-imap
store for each mail.

Unfortunately, dates can change unexpectedly - not just when you modify
the file, as I move data around between machines as they become obsolete
and the wrong settings in the move can obliterate those mtimes - we
humans do make mistakes. Nevertheless, I am happy with my current
situation and at least understand what's going on. 

THANKS, all, for your explanations and suggestions

[Dovecot] Problems with dovecot/sieve and vacation

[Ioannis Aslanidis]

Hello,

First of all, initial data:

# dovecot --version
1.0.rc15

# dovecot -n
# /etc/dovecot.conf
protocols: imaps pop3s
disable_plaintext_auth: yes
login_dir: /var/run/dovecot/login
login_executable(default): /usr/libexec/dovecot/imap-login
login_executable(imap): /usr/libexec/dovecot/imap-login
login_executable(pop3): /usr/libexec/dovecot/pop3-login
login_max_processes_count: 256
login_max_connections: 512
verbose_proctitle: yes
first_valid_uid: 200
last_valid_uid: 200
first_valid_gid: 200
last_valid_gid: 200
mail_location: maildir:%h/Maildir
maildir_copy_with_hardlinks: yes
umask: 7
mail_executable(default): /usr/libexec/dovecot/imap
mail_executable(imap): /usr/libexec/dovecot/imap
mail_executable(pop3): /usr/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/lib/dovecot/imap
mail_plugin_dir(imap): /usr/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/pop3
pop3_uidl_format(default):
pop3_uidl_format(imap):
pop3_uidl_format(pop3): %u
auth default:
  mechanisms: login plain
  user: nobody
  passdb:
driver: ldap
args: /etc/dovecot-ldap.conf
  userdb:
driver: ldap
args: /etc/dovecot-ldap.conf
  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user: postfix
  group: postfix
master:
  path: /var/run/dovecot/auth-master
  mode: 384
  user: vmail
  group: vmail



I am trying to get a vacation autoresponder to work, but I was not able
to. Everything else is working fine. Spam scripts work, forward scripts
work, ... but vacation does not work.

I have tried different configurations, simple:

require "vacation";
vacation "I am currently testing the vacation autoresponder.";

And a little more complex:

require ["fileinto", "vacation"];
## Move spam to spam folder
if exists "X-Spam-Flag" {
  fileinto "spam.incoming";
  # Stop here so that we do not reply on spams
  stop;
}
vacation
  # Reply at most once a day to a same sender
  :days 1
  :subject "Out of office reply test"
  # List of recipient addresses which are included in the auto replying.
  # If a mail's recipient is not on this list, no vacation reply is sent
for it.
  :addresses ["[EMAIL PROTECTED]"]
  "I'm testing the vacation autoresponder.";


The script gets compiled as I have checked the dates and the
.dovecot.lda-dupes gets created; however, there is no autoreply message.
Additionally, I noticed that my recipient e-mail address gets added to
.dovecot.lda-dupes:

# cat .dovecot.lda-dupes
�
 �H+��
�,[EMAIL PROTECTED]


And, I also noticed that, if I delete this file and I send an e-mail to
that address, I receive the e-mail duplicated, but only the first time,
before .dovecot.lda-dupes gets created.


I checked the mail headers of the e-mail upon reception and they seem fine:

Return-Path: <[EMAIL PROTECTED]>
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: from wr-out-0506.google.com (wr-out-0506.google.com
[64.233.184.232])
by mail.fluendo.com (Postfix) with ESMTP id E5777250133
for <[EMAIL PROTECTED]>; Fri, 18 Jul 2008 17:48:30 +0200 (CEST)
Received: by wr-out-0506.google.com with SMTP id c49so243003wra.19
for <[EMAIL PROTECTED]>; Fri, 18 Jul 2008 08:48:29 -0700
(PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:message-id:date:from:to
 :subject:mime-version:content-type:content-transfer-encoding
 :content-disposition;
bh=iMPULXt7n6+6MVu47vQWBga4lMRSIYkfGnO59XcugXQ=;
b=bLLBZZxblyF2LFTPMXPgVesAM/Ep/P5GwgN7aaGjd7JFVpXBBNU7Mq4OaeNbFZRzIN

jk+wgDl3uvAg3GkhOso7+kxAI+SOe/u8nDBzzCp5muKieMC5xe84gJOh0+bviaaoahDf
 vxKWX9e/BTvBkq1AOTOfTnlHRONQ00aoNza44=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=message-id:date:from:to:subject:mime-version:content-type
 :content-transfer-encoding:content-disposition;
b=PgczmkJcZnKNF2sIhkrPgtbt9OJaNjYVXeJ5498WjvodyiY97ZQEpTFjXoFrM3RWGI

EsRDyre253LVRbBJIZses3nbJLWGCQ9aebPnJQMQr6I1dnNL8AIqB6oMjIDp43Yjlj30
 muP/LU0PigmTrnsy9+k9kWEy0MRG+ehBBUgn0=
Received: by 10.90.101.17 with SMTP id y17mr289500agb.72.1216396109274;
Fri, 18 Jul 2008 08:48:29 -0700 (PDT)
Received: by 10.90.99.17 with HTTP; Fri, 18 Jul 2008 08:48:29 -0700 (PDT)
Message-ID: <[EMAIL PROTECTED]>
Date: Fri, 18 Jul 2008 17:48:29 +0200
From: "Ioannis Aslanidis" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Test 12
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: ClamAV using ClamSMTP

-- 
Ioannis Aslanidis







I would really like to have this solved as soon as possible, so any help
is greatly welcome. If you require any further information, please, do
not hesitate to contact me.

Thanks in advance for your prompt reply.

Regards,

Ioannis
begin:vcard
fn:Ioannis Aslanidis
n:Aslanidis;Ioannis
org:Flumotion Services S.A.;In

Re: [Dovecot] changing INTERNALDATE or similar

[Timo Sirainen]

On Jul 18, 2008, at 6:33 PM, Karl Rudnick wrote:

How could any implementation of this protocol possibly use a file  
system

time stamp to represent that important piece of meta-data,
no matter where the file lives? It seems totally reasonable that  
this is
what Outlook uses for the Received date (and I rarely defend  
Microsoft).


This seems like a real design flaw in the dovecot implementation. I  
am fairly

new to dovecot (and like many aspects of it over uw-imap), but having
to really be careful with my mail store's mtimes borders on the  
absurd.
I realize it is "implementation defined", but the intent of the  
definition

surely does not refer to file system time stamps. Any chance this can
be reconsidered? Is this an actual dovecot issue or a more general  
Maildir issue?


Why does it matter where the timestamp lives? No matter how it was  
stored, you would have had the exact same problem because your client  
told Dovecot to use the current timestamp when saving the messages.


And why would keeping the INTERNALDATE in mtime be bad? It only  
changes if you write to the file. And existing mails must not be  
modified or you'll get other problems as well.




PGP.sig
Description: This is a digitally signed message part

Re: [Dovecot] changing INTERNALDATE or similar

[Karl Rudnick]

Looking at the IMAP4rev1 protocol (RFC 2060), we have the following
definition:

INTERNALDATE   The internal date of the message.
2.3.3.  Internal Date Message Attribute

   The internal date and time of the message on the server.  This is not
   the date and time in the [RFC-822] header, but rather a date and time
   which reflects when the message was received.  In the case of
   messages delivered via [SMTP], this SHOULD be the date and time of
   final delivery of the message as defined by [SMTP].  In the case of
   messages delivered by the IMAP4rev1 COPY command, this SHOULD be the
   internal date and time of the source message.  In the case of
   messages delivered by the IMAP4rev1 APPEND command, this SHOULD be
   the date and time as specified in the APPEND command description.
   All other cases are implementation defined.

How could any implementation of this protocol possibly use a file system 
time stamp to represent that important piece of meta-data,
no matter where the file lives? It seems totally reasonable that this is
what Outlook uses for the Received date (and I rarely defend Microsoft).

This seems like a real design flaw in the dovecot implementation. I am fairly
new to dovecot (and like many aspects of it over uw-imap), but having
to really be careful with my mail store's mtimes borders on the absurd.
I realize it is "implementation defined", but the intent of the definition
surely does not refer to file system time stamps. Any chance this can
be reconsidered? Is this an actual dovecot issue or a more general Maildir 
issue?

On Fri, 2008-07-18 at 02:00 -0700, [EMAIL PROTECTED] wrote:
> --
> 
> Message: 4
> Date: Thu, 17 Jul 2008 23:12:55 +0300
> From: Timo Sirainen <[EMAIL PROTECTED]>
> Subject: Re: [Dovecot] changing INTERNALDATE or similar
> To: [EMAIL PROTECTED]
> Cc: Dovecot Mailing List 
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="utf-8"
> 
> On Thu, 2008-07-17 at 13:04 -0700, [EMAIL PROTECTED] wrote:
> > I believe it's still true that any mail files that are IMAP STORE'd
> > (uploaded)
> 
> You mean IMAP APPENDed.
> 
> > to Dovecot by a client will have a current mtime, rather than
> > the "Date" in the message.  That means might need to compare mtime's
> to
> > "Date" headers for new files that appear too.
> 
> This is only because the client doesn't specify the date to APPEND
> command.
> 
> > Here we just patched Dovecot to treat "INTERNALDATE" the same as the
> > "Date" header. Constantly verifying mtime's became too much of a
> chore
> > for those clients that rely on it (although this technically is
> against
> > the RFC).
> 
> Would probably have been better to set the default INTERNALDATE based
> on
> the Date: header in APPEND command. Should be pretty easy to do with
> Maildir I think.

Re: [Dovecot] zlib plugin nad moving mails, bug?

[Nuno Lopes]

This was a bug in version 1.0 which is now corrected in version 1.1.rc6 
by looking at the file header instead of the Z flag.


http://dovecot.org/pipermail/dovecot-news/2008-May/69.html

Regards,
--
Nuno

Mateusz Kijowski wrote:

Hi,


Recently I gzipped mails older than 30 days in our users' maildirs. I used 
find and gzip. Gzip added 'Z' at the end of the filename and everything 
seemed to work fine, users did not notice any difference in performance 
(yet :-), and I saved about 30% of our mail storage space.


There seems to be a problem when moving gzipped messages from one folder to 
another though. Dovecot drops the Z flag, moved messages are not processed by 
the zlib plugin and email clients end up showing garbage.


Is there something wrong with my config, or did I encounter a bug?

dovecot -n follows:

# 1.0.13: /etc/dovecot/dovecot.conf
base_dir: /var/run/dovecot/
log_path: /var/log/dovecot.log
protocols: imap imaps pop3s
ssl_ca_file: /etc/certs/certum-chain.crt
ssl_cert_file: /etc/certs/wild.dfqs.pl.crt
ssl_key_file: /etc/certs/wild.dfqs.pl.key
ssl_cipher_list: ALL:!LOW:!MEDIUM
login_dir: /var/run/dovecot/login
login_executable(default): /usr/lib64/dovecot/imap-login
login_executable(imap): /usr/lib64/dovecot/imap-login
login_executable(pop3): /usr/lib64/dovecot/pop3-login
login_greeting: imap.dfqs.pl ready.
login_process_per_connection: no
login_processes_count: 5
login_max_processes_count: 32
max_mail_processes: 4096
verbose_proctitle: yes
mail_location: maildir:~/mail:INDEX=/var/lib/dovecot/indexes/%Ln
mail_debug: yes
maildir_copy_with_hardlinks: yes
maildir_copy_preserve_filename: yes
mail_executable(default): /usr/local/lib64/dovecot-post-login-imap.sh
mail_executable(imap): /usr/local/lib64/dovecot-post-login-imap.sh
mail_executable(pop3): /usr/local/lib64/dovecot-post-login-pop3.sh
mail_plugins(default): imap_quota trash quota acl zlib
mail_plugins(imap): imap_quota trash quota acl zlib
mail_plugins(pop3): quota
mail_plugin_dir(default): /usr/lib64/dovecot/plugins/imap
mail_plugin_dir(imap): /usr/lib64/dovecot/plugins/imap
mail_plugin_dir(pop3): /usr/lib64/dovecot/plugins/pop3
mail_log_max_lines_per_sec: 0
imap_client_workarounds(default): outlook-idle tb-extra-mailbox-sep
imap_client_workarounds(imap): outlook-idle tb-extra-mailbox-sep
imap_client_workarounds(pop3): outlook-idle
pop3_uidl_format(default):
pop3_uidl_format(imap):
pop3_uidl_format(pop3): %08Xu%08Xv
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
namespace:
  type: private
  separator: /
  inbox: yes
namespace:
  type: public
  separator: /
  prefix: Public/
  location: 
maildir:/var/vmail/Public:CONTROL=~/Public/control:INDEX=~/Public/index

namespace:
  type: shared
  separator: /
  prefix: Shared/
  location: 
maildir:/var/vmail/Shared:CONTROL=~/Shared/control:INDEX=~/Shared/index

auth default:
  verbose: yes
  debug: yes
  worker_max_count: 512
  passdb:
driver: pam
args: dovecot
  userdb:
driver: ldap
args: /etc/dovecot/dovecot-ldap.conf
  socket:
type: listen
client:
  path: /var/run/dovecot/auth-client
  mode: 432
  user: root
  group: vmail
master:
  path: /var/run/dovecot/auth-master
  mode: 432
  user: root
  group: vmail
plugin:
  quota: maildir:storage=12582912:ignore=Trash
  acl: vfile:
  trash: /etc/dovecot/dovecot-trash.conf
  

Re: [Dovecot] zlib plugin nad moving mails, bug?

[Timo Sirainen]

On Fri, 2008-07-18 at 16:14 +0200, Mateusz Kijowski wrote:
> Recently I gzipped mails older than 30 days in our users' maildirs. I used 
> find and gzip. Gzip added 'Z' at the end of the filename and everything 
> seemed to work fine, users did not notice any difference in performance 
> (yet :-), and I saved about 30% of our mail storage space.
> 
> There seems to be a problem when moving gzipped messages from one folder to 
> another though. Dovecot drops the Z flag, moved messages are not processed by 
> the zlib plugin and email clients end up showing garbage.
> 
> Is there something wrong with my config, or did I encounter a bug?
..
> maildir_copy_with_hardlinks: yes

Hardlink copying is broken with zlib plugin. v1.1 works differently and
it works there (although non-hardlink copying was broken there, fixed
only in hg).



signature.asc
Description: This is a digitally signed message part

[Dovecot] zlib plugin nad moving mails, bug?

[Mateusz Kijowski]

Hi,


Recently I gzipped mails older than 30 days in our users' maildirs. I used 
find and gzip. Gzip added 'Z' at the end of the filename and everything 
seemed to work fine, users did not notice any difference in performance 
(yet :-), and I saved about 30% of our mail storage space.

There seems to be a problem when moving gzipped messages from one folder to 
another though. Dovecot drops the Z flag, moved messages are not processed by 
the zlib plugin and email clients end up showing garbage.

Is there something wrong with my config, or did I encounter a bug?

dovecot -n follows:

# 1.0.13: /etc/dovecot/dovecot.conf
base_dir: /var/run/dovecot/
log_path: /var/log/dovecot.log
protocols: imap imaps pop3s
ssl_ca_file: /etc/certs/certum-chain.crt
ssl_cert_file: /etc/certs/wild.dfqs.pl.crt
ssl_key_file: /etc/certs/wild.dfqs.pl.key
ssl_cipher_list: ALL:!LOW:!MEDIUM
login_dir: /var/run/dovecot/login
login_executable(default): /usr/lib64/dovecot/imap-login
login_executable(imap): /usr/lib64/dovecot/imap-login
login_executable(pop3): /usr/lib64/dovecot/pop3-login
login_greeting: imap.dfqs.pl ready.
login_process_per_connection: no
login_processes_count: 5
login_max_processes_count: 32
max_mail_processes: 4096
verbose_proctitle: yes
mail_location: maildir:~/mail:INDEX=/var/lib/dovecot/indexes/%Ln
mail_debug: yes
maildir_copy_with_hardlinks: yes
maildir_copy_preserve_filename: yes
mail_executable(default): /usr/local/lib64/dovecot-post-login-imap.sh
mail_executable(imap): /usr/local/lib64/dovecot-post-login-imap.sh
mail_executable(pop3): /usr/local/lib64/dovecot-post-login-pop3.sh
mail_plugins(default): imap_quota trash quota acl zlib
mail_plugins(imap): imap_quota trash quota acl zlib
mail_plugins(pop3): quota
mail_plugin_dir(default): /usr/lib64/dovecot/plugins/imap
mail_plugin_dir(imap): /usr/lib64/dovecot/plugins/imap
mail_plugin_dir(pop3): /usr/lib64/dovecot/plugins/pop3
mail_log_max_lines_per_sec: 0
imap_client_workarounds(default): outlook-idle tb-extra-mailbox-sep
imap_client_workarounds(imap): outlook-idle tb-extra-mailbox-sep
imap_client_workarounds(pop3): outlook-idle
pop3_uidl_format(default):
pop3_uidl_format(imap):
pop3_uidl_format(pop3): %08Xu%08Xv
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
namespace:
  type: private
  separator: /
  inbox: yes
namespace:
  type: public
  separator: /
  prefix: Public/
  location: 
maildir:/var/vmail/Public:CONTROL=~/Public/control:INDEX=~/Public/index
namespace:
  type: shared
  separator: /
  prefix: Shared/
  location: 
maildir:/var/vmail/Shared:CONTROL=~/Shared/control:INDEX=~/Shared/index
auth default:
  verbose: yes
  debug: yes
  worker_max_count: 512
  passdb:
driver: pam
args: dovecot
  userdb:
driver: ldap
args: /etc/dovecot/dovecot-ldap.conf
  socket:
type: listen
client:
  path: /var/run/dovecot/auth-client
  mode: 432
  user: root
  group: vmail
master:
  path: /var/run/dovecot/auth-master
  mode: 432
  user: root
  group: vmail
plugin:
  quota: maildir:storage=12582912:ignore=Trash
  acl: vfile:
  trash: /etc/dovecot/dovecot-trash.conf


signature.asc
Description: This is a digitally signed message part.

Re: [Dovecot] v1.1.0 released

[Johannes Berg]

On Fri, 2008-07-18 at 14:28 +0200, Anders wrote:
> Johannes Berg wrote:
> 
> > On Sat, 2008-06-21 at 04:46 +0300, Timo Sirainen wrote:
> >> http://dovecot.org/releases/1.1/dovecot-1.1.0.tar.gz
> 
> > Cool. I guess now I really have to debug why antispam+quota segfaults.
> 
> How is this coming along? Apart from this quota issue, do you consider
> antispam stable for Dovecot v1.1?

Haven't even had a chance to look at it. It appears to work fine until
you have quota and antispam enabled, where it segfaults on new messages,
but I don't know why yet.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [Dovecot] Run script before delivery

[Uldis Pakuls]

Juan Asensio Sánchez wrote:

Hi

Is it possible to run one script before the "real" delivery of a
message (with lda, or before the execution of the sieve scripts) but
after the creation of necessary folders (Dovecot automatically creates
the folders for virtual users)? I want to to this to manually create a
fixed empty sieve script in each user home folder, so in the global
sieve script include that personal script, because if personal script
doesn't exists, global script is not executed, or am I wrong?

Thanks in advance.
  
It is possible write wrapper script which is run instead of lda,  script 
does things you need and then calls lda.

All folders can be created with this script too.
Also it is possible to write plugin for lda doing same thing.

Uldis

Re: [Dovecot] Need suggestion regarding index file and Quota settings.

[Ed W]

Off the wall, but have you also considered using Dovecot (or other 
software, eg nginx) proxy options?


I only have a small setup, but I have seen others use the idea that all 
backend servers are also frontend servers, but the proxy option then 
forwards the connection to the correct other machine (with only a few 
servers the probability they hit the correct server first time is also 
respectable).


You can also stick a single proxy only machine in front of 
everythingthing else to point connections to the correct backend 
straight off.  Dovecot is apparently respectable as a high performance 
frontend proxy - some other people like nginx (no personal experience)


I believe you will find instructions on using indexes on NFS on either 
the wiki or a couple of previous answers from Timo here.  I think 
basically that v1.1 is best for indexes on NFS?


Good luck

Ed W

Re: [Dovecot] v1.1.0 released

[Anders]

Johannes Berg wrote:

> On Sat, 2008-06-21 at 04:46 +0300, Timo Sirainen wrote:
>> http://dovecot.org/releases/1.1/dovecot-1.1.0.tar.gz

> Cool. I guess now I really have to debug why antispam+quota segfaults.

How is this coming along? Apart from this quota issue, do you consider
antispam stable for Dovecot v1.1?


Cheers,
Anders.

Re: [Dovecot] Permission problems

[M. Rodrigo Monteiro]

2008/7/17 Benny Pedersen <[EMAIL PROTECTED]>:

>
> On Thu, July 17, 2008 20:20, Timo Sirainen wrote:
>
> > This directory or one of its parent directories isn't owned by the user
> > that logged in. So if you're using UID 108, chown -R 108 /home/vmail
> > should do it.
>
> currect if id 108 gives 108
>
> if i am wroung tell me
>
>
> --
> Benny Pedersen
> Need more webspace ? http://www.servage.net/?coupon=cust37098
>
>
I'm reinstalling it. I'll upgrade dovecot to the latest version...

Thanks for now,
Rodrigo.

-- 
M. Rodrigo Monteiro
[EMAIL PROTECTED]
"Free as in Freedom, not free as in free beer"
Linux User # 403730

Re: [Dovecot] Kerberos check logic incorrect

[Timo Sirainen]

On Thu, 2008-07-17 at 21:36 -0400, Bryan Jacobs wrote:
> In configure.in, there is a check that does `krb5-config --version |
> grep -v 1\.2`, making sure there is no "1.2" in the version of Kerberos
> in use.  This is to prevent compiling against MIT Kerberos version 1.2,
> which is too old for Dovecot.
> 
> Unfortunately for this idea, Heimdal 1.2.1 is out.  And Dovecot builds
> fine against it.
> 
> Whoever committed this check also appears to have removed the comment
> warning that it was broken, to add insult to injury.

Oh? I do see the comment.

> Please fix your checks to be for FEATURES, not version numbers.  You
> never know when something else that correctly implements the features
> you want will come along.

I usually do that, but for some reason this wasn't done with Kerberos. I
tried to find out the original bug report but couldn't. So I just
removed the v1.2 check completely now:
http://hg.dovecot.org/dovecot-1.1/rev/ecad3f2402a9



signature.asc
Description: This is a digitally signed message part

[Dovecot] Kerberos check logic incorrect

[Bryan Jacobs]

In configure.in, there is a check that does `krb5-config --version |
grep -v 1\.2`, making sure there is no "1.2" in the version of Kerberos
in use.  This is to prevent compiling against MIT Kerberos version 1.2,
which is too old for Dovecot.

Unfortunately for this idea, Heimdal 1.2.1 is out.  And Dovecot builds
fine against it.

Whoever committed this check also appears to have removed the comment
warning that it was broken, to add insult to injury.

Please fix your checks to be for FEATURES, not version numbers.  You
never know when something else that correctly implements the features
you want will come along.

Bryan Jacobs


signature.asc
Description: PGP signature

[Dovecot] Run script before delivery

[Juan Asensio Sánchez]

Hi

Is it possible to run one script before the "real" delivery of a
message (with lda, or before the execution of the sieve scripts) but
after the creation of necessary folders (Dovecot automatically creates
the folders for virtual users)? I want to to this to manually create a
fixed empty sieve script in each user home folder, so in the global
sieve script include that personal script, because if personal script
doesn't exists, global script is not executed, or am I wrong?

Thanks in advance.

[Dovecot] Need suggestion regarding index file and Quota settings.

[Tim Chen]

Dear All,

My system has about 30,000 accounts and these accounts are
created as unix system users. Each account has its own entry
in /etc/passwd with different UID and home directory.

We plan to deploy an Layer 4 switch as a load balancer. Proposed
architecure is as the following:

 internet  Layer 4 switch  mail server1  NFS storage
   |   |
   |--- mail server2 -|

Both mail servers will share the same storage which contains users'
home with Maildir inside. Dovecot will be installed on the mail servers
serving pop3 and imap4 protocols.

Since the layer 4 switch will direct connection to backend mail server
in random(or some of its algorithm), users can not guarantee which mail
server to use. My first question is which kind of INDEX settings should
I apply?
1) INDEX=MEMORY
2) INDEX=/nfs/%u
3) INDEX=/var/spool/%u

Will INDEX stored on disk outperform INDEX stored in memory?
If INDEX stored on NFS storage, we can be sure the consistency of INDEX
file,
but what about the performance and locking problem?
If INDEX stored on local disk, since users may connect to different mail
servers
every time. Will that impose the problem of inconsistency? What kind of
syndrome
will happen if the INDEX became inconsistent to real maildir content?

My second question is about quota. We use maildir as mail storage format.
Our users
were divided into 3-4 groups, each group of users with different quota size
ranging
from 100MB - 1G. To my best knowledge, dovecot's quota setting in config
file
supports only "one global configuration". (We are not using db, we use only
/etc/passwd).
dovecot.conf
   quota_rule = *:storage=10MB
Since dovecot supports both fs and maildir++ quota, I would like to ask for
your suggestion:

1. Should I use system quota instead? How about the comparision of
performance?
   Is there any drawback/limitation using system quota?
2. Is there any settings of dovecot that could fullfil my situation?
3. My thought is to modify dovecot.conf, comment out quota_rule =
*:storage=10MB and leave
   only the quota = maildir in the plugin { block. According to my
experiment, dovecot
   will read the maildirsize file under user's home. Then I have to set the
maildirsize
   file for every user individually! It seems to be a little crappy but
works.

Looking for your valuable suggestions!
Thanks very much.

Tim Chen