[Dovecot] Problems with dovecot-sieve on Debian Etch using dovecot LDA
I am running debian etch with dovecot 1.0 rc15 from the debian repository with postfix 2.3
I am using virtual users in a postgreSQL database as taken from the dovecot wiki while making use of the password field for authentication
I am using deliver as LDA and I am attempting to use the sieve plugin but try as I might I can't seem to get it working.
Am I wrong in thinking that a sieve daemon should become active when dovecot starts?
Here is my .dovecot.sieve
require "fileinto"; if address :is "from" "foo@example" { fileinto ".INBOX.test"; } else { # The rest goes into INBOX # default is "implicit keep", we do it explicitly here keep; }
Here is my dovecot.conf:
base_dir: /var/run/dovecot/ log_path: /var/log/dovecot/dovecot.log info_log_path: /var/log/dovecot/info.log log_timestamp: %Y-%m-%d %H:%M:%S syslog_facility: mail protocols: imaps listen: *:143 ssl_listen: ssl_disable: no ssl_ca_file: ssl_cert_file: xxxx.pem ssl_key_file: xxxx.pem ssl_key_password: ssl_parameters_regenerate: 168 ssl_cipher_list: ssl_verify_client_cert: no disable_plaintext_auth: no verbose_ssl: no shutdown_clients: yes nfs_check: yes version_ignore: no login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login login_user: dovecot login_greeting: Dovecot ready. login_log_format_elements: user=<%u> method=%m rip=%r lip=%l %c login_log_format: %$: %s login_process_per_connection: yes login_chroot: yes login_greeting_capability: no login_process_size: 32 login_processes_count: 3 login_max_processes_count: 128 login_max_connections: 256 valid_chroot_dirs: mail_chroot: max_mail_processes: 1024 verbose_proctitle: no first_valid_uid: xxxx last_valid_uid: xxxx first_valid_gid: xxxx last_valid_gid: xxxx mail_extra_groups: default_mail_env: mail_location: maildir:/home/%d/mailboxes/%n mail_cache_fields: flags mail_never_cache_fields: imap.envelope mail_cache_min_mail_count: 0 mailbox_idle_check_interval: 30 mail_debug: no mail_full_filesystem_access: no mail_max_keyword_length: 50 mail_save_crlf: no mail_read_mmaped: no mmap_disable: no mmap_no_write: no lock_method: fcntl maildir_stat_dirs: no maildir_copy_with_hardlinks: no mbox_read_locks: fcntl mbox_write_locks: dotlock fcntl mbox_lock_timeout: 300 mbox_dotlock_change_timeout: 120 mbox_min_index_size: 0 mbox_dirty_syncs: yes mbox_very_dirty_syncs: no mbox_lazy_writes: yes dbox_rotate_size: 2048 dbox_rotate_min_size: 16 dbox_rotate_days: 1 umask: 63 mail_drop_priv_before_exec: no mail_executable: /usr/lib/dovecot/imap mail_process_size: 256 mail_plugins: mail_plugin_dir: /usr/lib/dovecot/modules/imap mail_log_prefix: %Us(%u): imap_max_line_length: 65536 imap_capability: imap_client_workarounds: outlook-idle pop3_no_flag_updates: no pop3_enable_last: no pop3_reuse_xuidl: no pop3_lock_session: no pop3_uidl_format: pop3_client_workarounds: pop3_logout_format: top=%t/%p, retr=%r/%b, del=%d/%m, size=%s auth default: mechanisms: login realms: default_realm: cache_size: 0 cache_ttl: 3600 executable: /usr/lib/dovecot/dovecot-auth user: root chroot: username_chars: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@ username_translation: username_format: %n@%d master_user_separator: anonymous_username: anonymous krb5_keytab: verbose: yes debug: yes debug_passwords: yes ssl_require_client_cert: no ssl_username_from_cert: no count: 1 worker_max_count: 30 process_size: 256 passdb: driver: sql args: /etc/dovecot/dovecot-sql.conf deny: no pass: no master: no userdb: driver: sql args: /etc/dovecot/dovecot-sql.conf socket: type: listen client: path: /var/spool/postfix/private/auth mode: 438 user: group: master: path: /var/run/dovecot/auth-master mode: 438 user: group:
Thank you very much, Samir M. Nassar
On 12/29/06, Samir M. Nassar dovecot@myriapolis.net wrote:
Am I wrong in thinking that a sieve daemon should become active when dovecot starts?
There's supposed to be a daemon?
Here is my .dovecot.sieve
require "fileinto"; if address :is "from" "foo@example" { fileinto ".INBOX.test"; } else { # The rest goes into INBOX # default is "implicit keep", we do it explicitly here keep; }
Does .dovecot.sieve.err exist? I believe I tried something similar to that at first and had to change "from" to "From"
Most certainly though check for the existance (and contents) of the .dovecot.sieve.err file, it'll tell you exactly what's wrong (assuming sieve is probably configured and running).
Regards, Daniel
Daniel Ballenger http://denetron.com Sr. Systems Administrator - Denetron LLC
On Friday 29 December 2006 12:49, Daniel Ballenger wrote:
Am I wrong in thinking that a sieve daemon should become active when dovecot starts?
There's supposed to be a daemon?
It seems it is my understanding that is lacking, not the daemon. I was thinking of the managesieve extension which is not available in Dovecot 1.0 yet, although there are patches out there it seems. My MTA (KMail) supports the managesieve extention but it wasn't until looking closer at my MTA that is occured to me that "managesieve" is distinct from "managing sieve". Mea culpa.
Here is my .dovecot.sieve
require "fileinto"; if address :is "from" "foo@example" { fileinto ".INBOX.test"; } else { # The rest goes into INBOX # default is "implicit keep", we do it explicitly here keep; }
Does .dovecot.sieve.err exist? I believe I tried something similar to that at first and had to change "from" to "From"
.dovecot.sieve.err does not exist.
I have .dovecot.sieve in my users home and in the Maildir folder but I am planning on having mostly virtual users with no account on the system.
-lrwxrwxrwx 1 USER users 38 2006-12-29 09:59 Mail
/home/myriapolis.net/mailboxes/USER
But mail just goes to INBOX instead of getting routed and no .dovecot.sieve.err is generated
Thank you for the help, Samir M. Nassar
On Fri, 2006-12-29 at 12:29 -0600, Samir M. Nassar wrote:
I am running debian etch with dovecot 1.0 rc15 from the debian repository with postfix 2.3 I am using virtual users in a postgreSQL database as taken from the dovecot wiki while making use of the password field for authentication
Same setup here, except for local user accounts.
I am using deliver as LDA and I am attempting to use the sieve plugin but try as I might I can't seem to get it working.
Am I wrong in thinking that a sieve daemon should become active when dovecot starts?
There's no SIEVE daemon. SIEVE functionality is implemented as a plugin to the dovecot LDA. You sould check out the dovecot-lda module from CVS and build it against your dovecot sources.
Here is my .dovecot.sieve
This is not processed until you build and configure the sieve plugin.
Here is my dovecot.conf:
You miss a "protocol lda" section specifying which plugins should be loaded. See http://wiki.dovecot.org/LDA/Sieve for documentation.
ciao
Luca
On December 29, 2006 8:42:05 PM +0100 Luca Corti luca@leenoox.net wrote:
On Fri, 2006-12-29 at 12:29 -0600, Samir M. Nassar wrote:
I am running debian etch with dovecot 1.0 rc15 from the debian repository with postfix 2.3 I am using virtual users in a postgreSQL database as taken from the dovecot wiki while making use of the password field for authentication
Same setup here, except for local user accounts.
I am using deliver as LDA and I am attempting to use the sieve plugin but try as I might I can't seem to get it working.
Am I wrong in thinking that a sieve daemon should become active when dovecot starts?
There's no SIEVE daemon. SIEVE functionality is implemented as a plugin to the dovecot LDA. You sould check out the dovecot-lda module from CVS and build it against your dovecot sources.
Not for rc15. For recent dovecot, you should just get dovecot-sieve-1.0.
(Telling non-experts to use CVS makes debugging harder -- it's hard to know what version of code someone has.)
-frank
On Fri, 2006-12-29 at 12:47 -0800, Frank Cusack wrote:
Not for rc15. For recent dovecot, you should just get dovecot-sieve-1.0.
(Telling non-experts to use CVS makes debugging harder -- it's hard to know what version of code someone has.)
Didn't notice a packaged version of the sieve plugin was made available for download. I'm actually using the cvs checked out version with dovecot branch_1_0 and it works for me.
ciao
Luca
On Friday 29 December 2006 13:42, Luca Corti wrote:
I am using deliver as LDA and I am attempting to use the sieve plugin but try as I might I can't seem to get it working.
Am I wrong in thinking that a sieve daemon should become active when dovecot starts?
There's no SIEVE daemon. SIEVE functionality is implemented as a plugin to the dovecot LDA. You sould check out the dovecot-lda module from CVS and build it against your dovecot sources.
Thank you. The confusion was on my part. My MTA supports managesieve and I read managesieve support into dovecot 1.0 but that functionality hasn't arrived yet. My mistake.
I thought the debian packages provide dovecot-lda. From the file system it seems like dovecot-lda is built:
/usr/lib/dovecot/modules/lda/lib01_acl_plugin.so /usr/lib/dovecot/modules/lda/lib01_convert_plugin.so /usr/lib/dovecot/modules/lda/lib01_quota_plugin.so /usr/lib/dovecot/modules/lda/lib02_trash_plugin.so /usr/lib/dovecot/modules/lda/lib90_cmusieve_plugin.a /usr/lib/dovecot/modules/lda/lib90_cmusieve_plugin.la /usr/lib/dovecot/modules/lda/lib90_cmusieve_plugin.so
Here is my dovecot.conf:
You miss a "protocol lda" section specifying which plugins should be loaded. See http://wiki.dovecot.org/LDA/Sieve for documentation.
from my dovecot.conf:
protocol lda { # Address to use when sending rejection mails. postmaster_address = postmaster@myriapolis.net
# Hostname to use in various parts of sent mails, eg. in Message-Id. # Default is the system's real hostname. #hostname =
# Support for dynamically loadable plugins. mail_plugins is a space separated # list of plugins to load. mail_plugin_dir = /usr/lib/dovecot/modules/lda
# Binary to use for sending mails. sendmail_path = /usr/lib/sendmail
# UNIX socket path to master authentication server to find users. auth_socket_path = /var/run/dovecot/auth-master
# Enabling Sieve plugin for server-side mail filtering mail_plugins = cmusieve log_path = /var/log/dovecot/deliver.log info_log_path = /var/log/dovecot/deliver-info.log }
So is dovecot not picking this up?
Samir M. Nassar
On Sat, 2006-12-30 at 08:54 -0600, Samir M. Nassar wrote:
from my dovecot.conf:
[SNIP]
So is dovecot not picking this up?
This is what I have:
protocol lda { postmaster_address = postmaster@leenoox.net mail_plugins = cmusieve }
I think mail_plugins does the trick.
ciao
Luca
On Saturday 30 December 2006 11:30, Luca Corti wrote:
from my dovecot.conf:
[SNIP]
So is dovecot not picking this up?
This is what I have:
protocol lda { postmaster_address = postmaster@leenoox.net mail_plugins = cmusieve }
I think mail_plugins does the trick.
But it isn't and the logging isn't saying anything and no .err is being generated,
I am at a loss.
Samir M. Nassar
On Sat, 2006-12-30 at 11:51 -0600, Samir M. Nassar wrote:
I think mail_plugins does the trick.
But it isn't and the logging isn't saying anything and no .err is being generated,
Don't understand what you mean. Have you added mail_plugins to the Protocol lda section? What happens?
On Saturday 30 December 2006 12:09, Luca Corti wrote:
I think mail_plugins does the trick.
But it isn't and the logging isn't saying anything and no .err is being generated,
Don't understand what you mean. Have you added mail_plugins to the Protocol lda section? What happens?
It has been there all along:
protocol lda { # Address to use when sending rejection mails. postmaster_address = postmaster@myriapolis.net
# Hostname to use in various parts of sent mails, eg. in Message-Id.
# Default is the system's real hostname.
#hostname =
# Support for dynamically loadable plugins. mail_plugins is a space separated
# list of plugins to load.
mail_plugin_dir = /usr/lib/dovecot/modules/lda
# Binary to use for sending mails.
sendmail_path = /usr/lib/sendmail
# UNIX socket path to master authentication server to find users.
auth_socket_path = /var/run/dovecot/auth-master
# Enabling Sieve plugin for server-side mail filtering
mail_plugins = cmusieve
log_path = /var/log/dovecot/deliver.log
info_log_path = /var/log/dovecot/deliver-info.log}
Please advise, Samir M. Nassar
On Sat, 2006-12-30 at 12:12 -0600, Samir M. Nassar wrote:
Don't understand what you mean. Have you added mail_plugins to the Protocol lda section? What happens? It has been there all along:
Sorry, didn't notice. Check your MTA setup, how are you calling deliver from postfix?
HTH
Luca
On Saturday 30 December 2006 12:43, Luca Corti wrote:
Sorry, didn't notice. Check your MTA setup, how are you calling deliver from postfix?
from main.cf: mailbox_command = /usr/lib/dovecot/deliver
from master.cf dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
Samir M. Nassar http://myriapolis.net
On Wed, 2007-01-03 at 11:33 -0600, Samir M. Nassar wrote:
from main.cf: mailbox_command = /usr/lib/dovecot/deliver from master.cf dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
In this setup you are not using the dovecot transport (the lines you added to master.cf) mailbox_command does the work.
You can remove the dovecot transport from main.cf
OR
You can leave the dovecot transport in master.cf and substitute mailbox_command in main.cf with
dovecot_destination_recipient_limit = 1 virtual_transport = dovecot
But this only affects how deliver is called, sieve processing should occur anyway if installation and configuration are correct.
ciao
Luca
On 30.12.2006, at 20.12, Samir M. Nassar wrote:
log_path = /var/log/dovecot/deliver.log info_log_path = /var/log/dovecot/deliver-info.log
Deliver has actually write access to these files? Is anything ever
written to them?
Set debug=yes inside the protocol lda {}. Then it should log more
information about the Sieve plugin loading and such.
On Wednesday 03 January 2007 07:36, Timo Sirainen wrote:
Deliver has actually write access to these files? Is anything ever written to them?
Deliver has write access but nothing is written to them.
Set debug=yes inside the protocol lda {}. Then it should log more information about the Sieve plugin loading and such.
After setting this nothing is logged as well.
-- Samir M. Nassar http://myriapolis.net
On 3.1.2007, at 19.31, Samir M. Nassar wrote:
On Wednesday 03 January 2007 07:36, Timo Sirainen wrote:
Deliver has actually write access to these files? Is anything ever written to them?
Deliver has write access but nothing is written to them.
Set debug=yes inside the protocol lda {}. Then it should log more information about the Sieve plugin loading and such.
After setting this nothing is logged as well.
If debug is enabled, it really should write something there. So I can
think of only 3 possibilities:
Deliver is never called by Postfix.
You haven't really given enough permissions to write to the log
files (/var/log/dovecot dir permissions?).Deliver is reading a different dovecot.conf than what you're
modifying.
I'd guess 1).
On Wednesday 03 January 2007 15:07, Timo Sirainen wrote:
If debug is enabled, it really should write something there. So I can think of only 3 possibilities:
- Deliver is never called by Postfix.
How can I verify this?
- You haven't really given enough permissions to write to the log files (/var/log/dovecot dir permissions?).
Permissions are:
-rw-r--r-- 1 postfix postfix 0 2006-12-28 15:46 deliver-info.log -rw-r--r-- 1 postfix postfix 0 2006-12-28 15:46 deliver.log
- Deliver is reading a different dovecot.conf than what you're modifying.
Unless deliver is making up a .conf as it goes how is this possible?
-- Samir M. Nassar http://myriapolis.net
On 4.1.2007, at 0.39, Samir M. Nassar wrote:
On Wednesday 03 January 2007 15:07, Timo Sirainen wrote:
If debug is enabled, it really should write something there. So I can think of only 3 possibilities:
- Deliver is never called by Postfix.
How can I verify this?
Postfix's log should say that it's executing deliver.
- You haven't really given enough permissions to write to the log files (/var/log/dovecot dir permissions?).
Permissions are:
-rw-r--r-- 1 postfix postfix 0 2006-12-28 15:46 deliver-info.log -rw-r--r-- 1 postfix postfix 0 2006-12-28 15:46 deliver.log
From your other mail:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d $ {recipient}
You're executing deliver as dovecot, not as postfix.
- Deliver is reading a different dovecot.conf than what you're modifying.
Unless deliver is making up a .conf as it goes how is this possible?
Sometimes people have both /etc/dovecot.conf (from binary package)
and /usr/local/etc/dovecot.conf (installed from sources).
On Wednesday 03 January 2007 17:02, Timo Sirainen wrote:
How can I verify this?
Postfix's log should say that it's executing deliver.
I think I am getting a handle on what is happening.
when I send mail to user@myriapolis.net I get this:
Jan 3 22:02:02 hain postfix/virtual[22447]: 502AD40064: to=user@myriapolis.net, relay=virtual, delay=0.65, delays=0.52/0.01/0/0.12, dsn=2.0.0, status=sent (delivered to maildir)
when I send mail to user@hain.myriapolis.net I get: Jan 3 22:33:08 hain postfix/local[22597]: F089C40062: to=user@hain.myriapolis.net, relay=local, delay=2.6, delays=1.3/0.03/0/1.3, dsn=5.3.0, status=bounced (Command died with status 80: "/usr/lib/dovecot/deliver". Command output: deliver(stabile): Fatal: Can't open log file /var/log/dovecot/deliver.log: Permission denied ) Jan 3 22:33:09 hain postfix/bounce[22600]: F089C40062: sender non-delivery notification: C394740068
So postfix isn't calling deliver when it is doing virtual mail delivery is my guess.
-- Samir M. Nassar http://myriapolis.net
On Wed, 2007-01-03 at 22:37 -0600, Samir M. Nassar wrote:
So postfix isn't calling deliver when it is doing virtual mail delivery is my guess.
You have specified your domains as virtual in postfix, I guess mailbox_command applies to real domains, not virtual ones.
From the logs it seems you are using virtual as you transport. Set virtual transport to the name of your dovecot transport. It seems you also have some permission problem on your dovecot logfile. Fix permission on your logfiles and check the uid under which the transport is called in mster.cf.
ciao
Luca
So is dovecot not picking this up?
suggest putting garbage in your .dovecot.sieve file, sending yourself an email and checking for .dovecot.sieve.err file ... at least this way you know whether deliver is reading your .dovecot.sieve or not ... then you can backtrack problem.
a .dovecot.sieve file with the following require
require ["nosuchreq", "subaddress", "envelope", "fileinto"];
should produce a .dovecot.sieve.err file:
line 1: Unsupported features in require line
On Saturday 30 December 2006 13:43, Jim Horner wrote:
So is dovecot not picking this up?
suggest putting garbage in your .dovecot.sieve file, sending yourself an email and checking for .dovecot.sieve.err file ... at least this way you know whether deliver is reading your .dovecot.sieve or not ... then you can backtrack problem.
a .dovecot.sieve file with the following require
require ["nosuchreq", "subaddress", "envelope", "fileinto"];
should produce a .dovecot.sieve.err file:
I have done so, both in the users $HOME as well as in the maildir. No such luck.
As for postfix. I am calling deliver like this:
mailbox_command = /usr/lib/dovecot/deliver dovecot_destination_recipient_limit = 1 virtual_transport = dovecot
Samir M. Nassar
On Sat, 2006-12-30 at 14:23 -0600, Samir M. Nassar wrote:
As for postfix. I am calling deliver like this:
mailbox_command = /usr/lib/dovecot/deliver dovecot_destination_recipient_limit = 1 virtual_transport = dovecot
Looks strange to me. Have you defined a dovecot transport in master.cf? If not you should really remove the last two lines. mailbox_command is sufficient.
ciao
Luca
On Saturday 30 December 2006 19:10, Luca Corti wrote:
Looks strange to me. Have you defined a dovecot transport in master.cf? If not you should really remove the last two lines. mailbox_command is sufficient.
I have removed the lines and only mailbox_command remains. So far still no luck. Is the cmusieve plugin known to work in the debian packages for etch? If I've exhausted all inquiries here should I inquire with the package maintainer?
Samir M. Nassar
On Tue, 2007-01-02 at 16:59 -0600, Samir M. Nassar wrote:
I have removed the lines and only mailbox_command remains. So far still no luck. Is the cmusieve plugin known to work in the debian packages for etch? If I've exhausted all inquiries here should I inquire with the package maintainer?
Are you using the debian packages? If so try building from source. You find instructions in the dowloadpage and in the wiki.
ciao
Luca
On Tuesday 02 January 2007 18:00, Luca Corti wrote:
Are you using the debian packages? If so try building from source. You find instructions in the dowloadpage and in the wiki.
This is not an option. My host is a Xen session with limited RAM allocation. Even if I were to duplicate the environment I have no amd64 hardware to compile locally and install binaries on the host.
If I can't get sieve to work I will use procmail or maildrop. One of the reasons I wanted to use sieve was managesieve and the ability to edit filters from my MUA. Since I will be writing the filtering rules manually, whether it is maildrop, sieve, or procmail, the delivery mechanism isn't as important as it working.
Samir M. Nassar
On Tue, 2007-01-02 at 18:37 -0600, Samir M. Nassar wrote:
If I can't get sieve to work I will use procmail or maildrop. One of the reasons I wanted to use sieve was managesieve and the ability to edit filters from my MUA. Since I will be writing the filtering rules manually, whether it is maildrop, sieve, or procmail, the delivery mechanism isn't as important as it working.
Dovecot doesn't currently include a managesieve daemon. There are patches for this, but they are not official nor included in the official dovecot distribution. They are not part of the Debian packages for sure. I think you are better off using something else if you are having so many problems getting sieve to work, which seems quite strange.
ciao
Luca
On Tuesday 02 January 2007 20:39, Luca Corti wrote:
Dovecot doesn't currently include a managesieve daemon.
Yes.
There are patches for this, but they are not official nor included in the official dovecot distribution. They are not part of the Debian packages for sure.
Yes, we also covered this.
I think you are better off using something else if you are having so many problems getting sieve to work, which seems quite strange.
Are there no other mechanisms to test whether sieve works? If not then I will take my configuration file at face value and file a bug report with debian since LDA + sieve should work and is not.
Thanks for all the help, Samir M. Nassar
On Tue, 2007-01-02 at 16:59 -0600, Samir M. Nassar wrote:
I have removed the lines and only mailbox_command remains. So far still no luck. Is the cmusieve plugin known to work in the debian packages for etch? If I've exhausted all inquiries here should I inquire with the package maintainer?
I'm using the debian testing package, and cmusieve seems to work on my system. My setup:
protocol lda { # Address to use when sending rejection mails. postmaster_address = postmaster@whatever.dot
# Hostname to use in various parts of sent mails, eg. in Message-Id. # Default is the system's real hostname. hostname = whatever.dot
# Support for dynamically loadable plugins. mail_plugins is a space separated # list of plugins to load. #mail_plugins = mail_plugin_dir = /usr/lib/dovecot/modules/lda
# Binary to use for sending mails. #sendmail_path = /usr/lib/sendmail
# UNIX socket path to master authentication server to find users. auth_socket_path = /var/run/dovecot/auth-master
# Enabling Sieve plugin for server-side mail filtering mail_plugins = cmusieve }
Koen
On Saturday 30 December 2006 15:23, Samir M. Nassar wrote:
On Saturday 30 December 2006 13:43, Jim Horner wrote:
So is dovecot not picking this up?
suggest putting garbage in your .dovecot.sieve file, sending yourself an email and checking for .dovecot.sieve.err file ... at least this way you know whether deliver is reading your .dovecot.sieve or not ... then you can backtrack problem.
a .dovecot.sieve file with the following require
require ["nosuchreq", "subaddress", "envelope", "fileinto"];
should produce a .dovecot.sieve.err file:
I have done so, both in the users $HOME as well as in the maildir. No such luck.
yeah, we still can't tell if it is a postfix or dovecot issue ...
using the malformed sieve script just do a simple deliver
$ cat /etc/hosts | ./deliver -d me@mydomain.com -f blah@blah.com
(obviously) dovecot should be running and me@mydomain.com should be the person with the screwed up sieve script. if you still don't have a .dovecot.sieve.err file then it is on the dovecot side.
On Friday 29 December 2006 12:29, Samir M. Nassar wrote:
I am running debian etch with dovecot 1.0 rc15 from the debian repository with postfix 2.3
I have found part of the problem.
I am using postfix-2.3 and the instructions on the dovecot wiki are there for postfix <2.0 from some of the configuration options.
I will have to read up on the configuration option for postfix 2.3.
Also, in certain circumstances deliver works as advertised and everything is fine that way, the problem is making sure that postfix delivers mail to the virtual users.
Thanks for all the help, it is much appreciated.
-- Samir M. Nassar http://myriapolis.net
participants (8)
-
Daniel Ballenger
-
Frank Cusack
-
Jim Horner
-
Koen Vermeer
-
Luca Corti
-
Samir M. Nassar
-
Samir M. Nassar
-
Timo Sirainen