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
[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 plugi
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
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 A
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 sho
> 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->de
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 NU
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 (ma
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 Fo
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
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
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 INTERNALDA
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 savin
>
> 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 w
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
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
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 dat
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 rathe
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'
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 :-),
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
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 alon
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 manuall
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 machin
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 f
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 1
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 Do
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
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 s
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
30 matches
Mail list logo
