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
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
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
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
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
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'
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
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):
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
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
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
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
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
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
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
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
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
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
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
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
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
[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
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
23 matches
Mail list logo
