Re: [Dovecot] EVERYONE USING DOVECOT PLEASE SIGN: Thanks, Administrators of Dovecot!
Chris Hobbs wrote: On 8/17/10 9:28 AM, Jerrale G wrote: *Our gratitude goes to, but not limited to:* *Timo Sirainen and Charles Marcus* Please add New Haven Unified School District to the chorus. We migrated away from GroupWise this summer and in addition to getting to use a better suite of products (dovecot+postfix+SOGo), we're saving the district a nice chunk of money. Thank you, I'm sorry that I missed the original post, but United Defense Group, LLP of Studio City, California also uses Dovecot. Although I'm at work, I will also note these Dovecot users: - Music for Humans, Burbank California - Internet Society - Los Angeles Chapter, Los Angeles, California - MyPhotoDiet.com, Providence Rhode Island James Butler
Re: [Dovecot] Mailing list's prefix
Eric Rostetter wrote: Quoting Timo Sirainen : Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. It wouldn't break any of my filters. Personally, I like it when a mailing list uses the [LISTNAME] prefix. I get thousands of messages per day and a bunch of list messages, and even after filtering, having that type of prefix makes it visually easier for me to get a handle on what's important and what is not. When such a prefix is missing, the message subjects when there are many messages are actually more difficult to visually process, for me, even when all of the messages within a directory are from the same list. My 2 cents. James Butler IT Director United Defense Group, LLP
Re: [Dovecot] For the record: Postfix+Spamassassin+ClamAV+Dovecot
Egbert Jan van den Bussche wrote: >> -Oorspronkelijk bericht- >> Van: dovecot-bounces+egbert=vandenbussche...@dovecot.org >> [mailto:dovecot-bounces+egbert=vandenbussche...@dovecot.org] >> Namens James Butler >> Verzonden: vrijdag 17 april 2009 20:58 >> Aan: Dovecot Mailing List >> Onderwerp: [Dovecot] For the record: >> Postfix+Spamassassin+ClamAV+Dovecot >> >> >> Postfix 2.5.5 >> SpamAssassin 3.2.5 (under Perl 5.10.0) >> ClamAV 0.95.1 >> Dovecot 1.2.rc2 >> >> works fine on Fedora 10. >> >> Installed Dovecot and ClamAV from source and everything else >> using yum. >> >> I'm using the ClamAV plugin for Spamassassin: >> http://wiki.apache.org/spamassassin/ClamAVPlugin >> >> I'm calling Spamassassin with: >> >> /etc/postfix/main.cf: >> mailbox_command = /usr/bin/spamc -f -e >> /usr/local/libexec/dovecot/deliver >> >> Postfix hands off to Spamassassin, which processes ALL mail (not just >> attachments) through the ClamAV plugin before parsing for >> spam, and then hands the whole mess off to Dovecot for >> 'deliver' to handle. >> >> How simple is that? >> >> Since ClamAV scanns all mail, it might be too >> processor-intensive for really large mail systems, but it is >> working great for our 120+ user system with lots of spam >> coming in. If you're using Procmail or some other >> preprocessor that can hand off to a pipe, then you could skip >> the plugin and pipe messages over a certain size (i.e. >1024) >> to clamd, instead. >> >> Enjoy! >> >> James > > Hi! > > Apologies for digging an old thread from the bin. I was wondering how this > relates to Amavisd? Should I regard the proposed plugin solution as a 'poor > mans' solution when one does not want to install amavis? > > Thanks! > Egbert Jan (NL) > > The plugin setup is required for my solution because of issues between Procmail and Postfix when Postfix is running in a QMail-style Maildir setup, which Procmail seems to have issues with, at least for me. (I couldn't get Procmail to recognize environment variables correctly in my Fedora 10 installation, so I just stopped using it in favor of Dovecot's Sieve.) Amavisd would *replace* Procmail, similar to what Sieve would do. You would pipe your mail to Amavisd, test messages there, and then send qualified messages to 'deliver' or to another program for further processing/flagging. For example, under Amavisd, you would want to test for messages >1024 bytes (1 MB) and pipe them through your anti-virus app and then from there *back* to Amavisd to check for virus flags (into the bit bucket or 'deliver' to the user's 'Possible Virus' directory) and then on to 'deliver' for normal delivery if there were no flags. I've never used Amavisd, but this seems to be its purpose. FYI, the above setup is easy to administer and since additional apps are not required, it keeps the overhead down a bit. It could be considered a "poor man's replacement" for Amavisd in that it makes Amavisd irrelevant, AFAIK ... but Amavisd probably does other stuff that I simply haven't found the need for, so I really couldn't tell you. James
Re: [Dovecot] Sieve "redirect"
> Is there an alternative to the "redirect" Sieve capability?
>
> For example:
>
> if header :contains "Subject" "Listserv" {
> redirect "list-us...@example.com";
> redirect "list-us...@example.com";
> redirect "list-us...@example.com";
> stop;
> }
>
> How can I do the above without using "redirect"?
>
> Unfortunately, "redirect" seems to be unsupported by Dovecot.
>
> Thank you.
>
> James
>
Here's why I posted this:
sievec global.before.sieve global.before.svbin
line 7: error: unsupported sieve capability 'redirect'.
error: validation failed.
Error: failed to compile sieve script 'global.before.sieve'
Sieve 0.1.4, Dovecot 1.2.rc2
James
[Dovecot] Sieve "redirect"
Is there an alternative to the "redirect" Sieve capability?
For example:
if header :contains "Subject" "Listserv" {
redirect "list-us...@example.com";
redirect "list-us...@example.com";
redirect "list-us...@example.com";
stop;
}
How can I do the above without using "redirect"?
Unfortunately, "redirect" seems to be unsupported by Dovecot.
Thank you.
James
[Dovecot] For the record: Postfix+Spamassassin+ClamAV+Dovecot
Postfix 2.5.5 SpamAssassin 3.2.5 (under Perl 5.10.0) ClamAV 0.95.1 Dovecot 1.2.rc2 works fine on Fedora 10. Installed Dovecot and ClamAV from source and everything else using yum. I'm using the ClamAV plugin for Spamassassin: http://wiki.apache.org/spamassassin/ClamAVPlugin I'm calling Spamassassin with: /etc/postfix/main.cf: mailbox_command = /usr/bin/spamc -f -e /usr/local/libexec/dovecot/deliver Postfix hands off to Spamassassin, which processes ALL mail (not just attachments) through the ClamAV plugin before parsing for spam, and then hands the whole mess off to Dovecot for 'deliver' to handle. How simple is that? Since ClamAV scanns all mail, it might be too processor-intensive for really large mail systems, but it is working great for our 120+ user system with lots of spam coming in. If you're using Procmail or some other preprocessor that can hand off to a pipe, then you could skip the plugin and pipe messages over a certain size (i.e. >1024) to clamd, instead. Enjoy! James
Re: [Dovecot] SELinux and "i_stream_read() failed: Permission denied"
> On Thu, 2009-04-16 at 17:01 -0700, James Butler wrote: >> > But there's no dovecot.deliver anymore in v1.2: >> > >> > ~/cvs/dovecot-1.2/src/deliver% grep dovecot.deliver deliver >> > ~/cvs/dovecot-1.2/src/deliver% >> > >> > It is in v1.1 though. >> > >> >> I have no answer for you, except: >> >> # dovecot -n >> - 1.2.rc2: /usr/local/etc/dovecot.conf > > That doesn't necessarily mean that your deliver binary is the same > version as dovecot. For example do you happen to be using deliver binary > from another directory than /usr/local/libexec/dovecot/? Try grepping > "1.2.rc2" and "dovecot.deliver" from the deliver binary to see if it > contains either string. > >> # ls -la /tmp >> total 104 >> -rw--- 1 user dovecot 0 2009-04-15 15:47 >> dovecot.deliver..1239835658.9325.c6f5c942d0424f70 > > Hmm. Is this before you allowed unlinking or does it still happen > afterwards? These shouldn't be visible since they're created and > immediately unlinked afterwards. > D'oh! [r...@ltfs450 root]# cd /usr/local/libexec/dovecot [r...@ltfs450 dovecot]# grep dovecot.deliver deliver [r...@ltfs450 dovecot]# grep 1.2.rc2 deliver Binary file deliver matches HOWEVER, in my /etc/postfix/main.cf, I called a different binary: mailbox_command = /usr/bin/spamc -f -e /usr/libexec/dovecot/deliver [r...@ltfs450 root]# cd /usr/libexec/dovecot [r...@ltfs450 dovecot]# grep dovecot.deliver deliver Binary file deliver matches [r...@ltfs450 dovecot]# grep 1.1 deliver Binary file deliver matches I was running the old version of deliver. Thanks for clearing that up, Timo. James
Re: [Dovecot] SELinux and "i_stream_read() failed: Permission denied"
> On Wed, 2009-04-15 at 18:55 -0700, James Butler wrote: >> > On Wed, 2009-04-15 at 16:47 -0700, James Butler wrote: >> >> "i_stream_read() failed: Permission denied" is an error message >> >> generated >> >> when a large-ish file (>128kb in my case) is attached to a message >> that >> >> has been passed to Dovecot's deliver program when SELinux is being >> >> enforced. >> > .. >> >> The problem is that deliver is not running with the correct SELinux >> >> policy >> >> to be able to write to the global /tmp directory >> > >> > BTW. Dovecot v1.2+ no longer writes to /tmp directory. Writing to /tmp >> > was pretty evil. >> >> I hear ya. I'm running v.1.2.rc2 ... is there a newer version? > > Are you sure the deliver is also from v1.2.rc2? You mentioned: > >> deliver(user): unlink(/tmp/dovecot.deliver.. \ >> 1239836047.9469.46242b1037005551) failed: Permission denied > > But there's no dovecot.deliver anymore in v1.2: > > ~/cvs/dovecot-1.2/src/deliver% grep dovecot.deliver deliver > ~/cvs/dovecot-1.2/src/deliver% > > It is in v1.1 though. > I have no answer for you, except: # dovecot -n - 1.2.rc2: /usr/local/etc/dovecot.conf # ls -la /tmp total 104 -rw--- 1 user dovecot 0 2009-04-15 15:47 dovecot.deliver..1239835658.9325.c6f5c942d0424f70 -rw--- 1 user dovecot 0 2009-04-15 15:47 dovecot.deliver..1239835664.9329.c2eb40454a80d780 -rw--- 1 user dovecot 0 2009-04-15 15:47 dovecot.deliver..1239835665.9331.b61a334c362dc35f -rw--- 1 user dovecot 0 2009-04-15 15:51 dovecot.deliver..1239835870.9420.71fa4ab59306c936 -rw--- 1 user dovecot 0 2009-04-15 15:54 dovecot.deliver..1239836046.9470.76b013baec297b2c -rw--- 1 user dovecot 0 2009-04-15 15:54 dovecot.deliver..1239836047.9469.46242b1037005551 -rw--- 1 user dovecot 0 2009-04-15 15:54 dovecot.deliver..1239836056.9482.384c6f25d95f5d2a ...etc... James
Re: [Dovecot] SELinux and "i_stream_read() failed: Permission denied"
> On Wed, 2009-04-15 at 16:47 -0700, James Butler wrote: >> "i_stream_read() failed: Permission denied" is an error message >> generated >> when a large-ish file (>128kb in my case) is attached to a message that >> has been passed to Dovecot's deliver program when SELinux is being >> enforced. > .. >> The problem is that deliver is not running with the correct SELinux >> policy >> to be able to write to the global /tmp directory > > BTW. Dovecot v1.2+ no longer writes to /tmp directory. Writing to /tmp > was pretty evil. > > I hear ya. I'm running v.1.2.rc2 ... is there a newer version?
[Dovecot] SELinux and "i_stream_read() failed: Permission denied"
Not a problem ... sharing a solution (this time)! Please correct my
understanding of the process, if required.
"i_stream_read() failed: Permission denied" is an error message generated
when a large-ish file (>128kb in my case) is attached to a message that
has been passed to Dovecot's deliver program when SELinux is being
enforced.
In my case, these messages are first run through Spamassassin, then passed
to deliver, however the SELinux policy that is being violated relates to
deliver, and not to Spamassassin, even though I do NOT generate the errors
WITHOUT running Spamassassin. I'm not going to guess as to why that is.
The policies below resolve the issue, and now large-ish (even LARGE)
attachments come through without a whimper with
Postfix+Spamassassin+Dovecot.
The problem is that deliver is not running with the correct SELinux policy
to be able to write to the global /tmp directory (in my case, after
receiving the big attachment from SA), even if that directory's
permissions allow it. (Bless you, SELinux!) Small-ish file attachments do
not trigger this deliver functionality.
Here's a complete error message, and its subsequent errors in the course
of delivering a large-ish message+attachment:
===
deliver(user): unlink(/tmp/dovecot.deliver.. \
1239836047.9469.46242b1037005551) failed: Permission denied
deliver(user): copy: i_stream_read() failed: Permission denied
deliver(user): read(mail, uid=1) failed: Permission denied
deliver(user): read(mail, uid=1) failed: Permission denied
deliver(user): msgid=: save failed to INBOX: Internal error occurred. \
Refer to server log for more information. [2009-04-15 17:54:07]
===
This is the final error series received before the policies were finally
updated, and shows an error during deliver's attempt to "unlink()"
(remove) the temporary file. Previous errors occurred during attempts to
"stat()" and "creat()" (sic) the temporary files.
Basically, the "dovecot_deliver_t" context needs to be able to create,
read, write and remove files in the /tmp directory ("tmp_t" context).
Below, I am pasting my "local_postfix.te" SELinux policy file. It includes
instructions for using it, and for figuring out how to do other SELinux
policy adjustments on your own. This is my COMPLETE Postfix+Dovecot
SELinux policy group. I also have policies for Spamassassin, if anyone
wants them. If you are running Sendmail or another MTA instead of Postfix,
you can build on what you find below and establish your own policies.
I hope this proves useful. Again, please feel free to correct any
misunderstandings I may be promoting with this message.
Use at your own risk, please! No guarantees ... it just worked, for me.
James
## NOTE: I have broken lines in the following using the standard "\"
notation to fix the email format better. However the local_postfix.te file
should NOT have ANY lines broken. Remove my "\" notation and keep the
lines together and you should be okay. ##
### HOW TO USE THIS
# SELinux, Postfix, Dovecot#
# SELinux needs help resolving Postfix+Dovecot context issues. #
# This file + the following instructions should get you#
# on your way to resolving the policies between those contexts.#
# #
# 1) Create this file with the data shown below: #
# local_postfix.te #
# 2) Compile this file:#
# checkmodule -M -m -o local_postfix.mod local_postfix.te #
# 3) Create SELinux policy package:#
# semodule_package -o local_postfix.pp -m local_postfix.mod#
# 4) Move policy package to normal SELinux modules directory: #
# mv local_postfix.pp /etc/selinux/targeted/modules/active/modules/#
# 5) Update kernel with new policy package:#
# semodule -i \#
# /etc/selinux/targeted/modules/active/modules/local_postfix.pp #
# #
# Test: Send mail from remote to this system. #
# Check /var/log/maillog for mail errors and #
# /var/log/messages & /var/log/audit/audit.log for more specific #
# SELinux errors #
# Also, SELinux will provide the command (sealert...) for more details #
# Use the error info you see in messages (or sealert...) to create #
# new entries in local_postfix.te, then re-compile, package#
# and update the kern
Re: [Dovecot] auth-master: Permission denied [sigh]
Well bust my buttons! Thanks, Timo! FUNCTIONING! Let Postfix figure out
the proper user. BTW, my 'deliver' is set to 755. Nothing special.
> I'm not all that good with Postfix configuration, but:
Clearly quite good enough.
> On Tue, 2009-04-14 at 13:05 -0700, James Butler wrote:
>> ## POSTFIX CONFIG ##
>>
>> /etc/postfix/main.cf:
>>
>> mailbox_transport = spamassassin
>
> Remove this.
Right ... don't bother sending to the custom Postfix transport, below.
>> /etc/postfix/master.cf:
>>
>> spamassassin unix - n n - - pipe
>> user=spam:dovecot argv=/usr/bin/spamc -f -e
>> /usr/libexec/dovecot/deliver -f ${sender} -d ${user} -m ${extension}
>
> Remove this (JB: CUSTOM TRANSPORT) and add to main.cf:
>
> mailbox_command = /usr/bin/spamc -f -e /usr/libexec/dovecot/deliver
Et voila. Once the SELinux policies were adjusted to allow Postfix to run
spamc, we're off and running!
Here is my current setup that's WORKING:
Mail => Postfix => spamc | deliver => INBOX
/etc/postfix/main.cf:
mailbox_command = /usr/bin/spamc -f -e /usr/libexec/dovecot/deliver
/etc/postfix/master.cf:
[no changes to default]
/usr/local/etc/dovecot.conf:
socket listen {
master {
path = /var/run/dovecot/auth-master
# Fairly permissive mode ... might be unnecessary
mode = 0666
# Default user (root)
# user =
# Group with access to /var/run/dovecot ... might be unnecessary
group = dovecot
}
client {
path = /var/run/dovecot/auth-client
# Permissive mode ... might be unnecessary
mode = 0666
# Default user (root)
# user =
# Group with access to /var/run/dovecot ... might be unnecessary
group = dovecot
}
}
If anyone wants a copy of my SELinux local_postfix.te and instructions for
using it, I'll happily post them.
The "might be unnecessary" items above I just left as they were because
the setup is working and I really don't want to futz with it any further,
today. I'll probably test different settings in dovecot.conf over the next
couple of days, and if something changes, I'll post back under this
thread.
Thank you all so much for your time and effort in helping me solve this
problem.
James
(Merry Christmas, Noel!)
Re: [Dovecot] auth-master: Permission denied [sigh]
> On Wed, 2009-04-15 at 07:52, Timo Sirainen wrote:
>
>
>> Perhaps you shouldn't be using the pipe at all. Maybe you should just
>> put the command to mailbox_command and have it do all the work? Then
>> there's no need to worry about things like setuid-roots or whatever.
>
>
> Given what his conf showed before he's using local users only, so your
> right, he'd be better off using something
> like mailbox_command = /path/to/procmail ... and let procmail deal
> with SA and be done with it.
>
> If he wants advanced he needs to be using MailScanner or amavisd-new,
> but I think they're overkill for what he wants, so procmail would be
> better suited.
>
Already went through Procmail. It knows nothing about Dovecot's mail
structure, so everything still needs to be piped through deliver.
In addition, there was/is an issue with Procmail not resolving the {HOME}
variable correctly in a Maildir system. Works great with Sendmail and
mbox's, just not so good with Maildir's. Again, I couldn't get anyone to
share a successful setup, and in fact nobody on the Procmail list had ever
gotten Postfix+Procmail+Spamassassin+Dovecot working, so that attempt
died.
MailScanner is slowly in the process of being attempted, even though it is
simply a wrapper that accepts the mail from Postfix then pipes it over to
Spamassassin and other programs like AV apps. When I received your
suggestion to try those two programs, yesterday, I started installing all
of the various Perl modules required by MailScanner, but it's gotten hung
up by not recognizing that MailTools' lates version is, in fact, installed
and available, so I stopped working on MailScanner until
Postfix+Spamassassin+Dovecot completely ends its run.
Amavisd-new is another type of Perl wrapper. I guess I will need to try
that one, if all else fails. I'm not a big fan of wrapping stuff in Perl.
I am not yet satisfied that Postfix+Spamassassin+Dovecot will not work.
James (probably related to Noel, but not invited to Christmas Dinner. :( )
Re: [Dovecot] auth-master: Permission denied [sigh]
Please take a look at my post from 1:05PM today with all of my configuration information. Is the problem being caused by something there? I have been working on this for over two weeks, and I have no idea what's what, anymore. Now I DO understand that it's either setuid-root deliver and use -d from the pipe or do not use setuid-root deliver or -d or a pipe. As it is, there is no other mechanism that I can think of to include an anti-spam program in the mail delivery stream. And I haven't even gotten started trying to include an anti-virus program! (I'm assuming that, too, will require a pipe.) If there is a setup guide for running Postfix+Spamassassin+Dovecot that does not require a pipe, I would be MORE than grateful to learn its location. I have yet to discover one. Even within the config files and docs there are no examples of piping to deliver from Spamassassin, which seems a little unusual, considering the popularity of Spamassassin. James > On Tue, 2009-04-14 at 14:17 -0700, James Butler wrote: >> Oh, that was fun. >> >> Making the change below resulted in mail getting deferred with "Fatal: >> destination user parameter (-d user) not given" ... which apparently is >> caused by running deliver as 'root'! > > I thought you wanted to use -d? There's really no way to make deliveries > working to multiple users via pipe, unless you use -d. > > Perhaps you shouldn't be using the pipe at all. Maybe you should just > put the command to mailbox_command and have it do all the work? Then > there's no need to worry about things like setuid-roots or whatever. > > >
Re: [Dovecot] auth-master: Permission denied [sigh]
Oh, that was fun. Making the change below resulted in mail getting deferred with "Fatal: destination user parameter (-d user) not given" ... which apparently is caused by running deliver as 'root'! (http://archive.netbsd.se/?ml=dovecot-general&a=2008-02&t=6558196) So I am back to: -rwxr-xr-x 1 root dovecot 4044835 2009-04-03 13:52 deliver which doesn't produce the error and delivers the mail. Still no joy with Postfix+Spamassassin+Dovecot. This is unbelievably hard to get going. I started with the default installations of everything on a brand new system. I only made minimal changes as indicated by the docs. Then I made small changes as indicated by this and other mailing lists. I always reverted back to the original defaults between each effort. Now I'm just stumped. I'm not a newbie ... I've been administrating public servers for over 10 years, and using and working on the Internet since 1968! This is just the first time I've tried to use Postfix+Spamassassin+Dovecot. Previous installations have all used Sendmail+Spamassassin+Dovecot with zero issues. I want the benefits of using the Maildir storage system, but the past two weeks of trying to get this going are making me question whether that benefit is worth it. Can anyone please post their successful Postfix+Spamassassin+Dovecot setup for me to learn from? I would really appreciate it. James > I have changed /usr/local/libexec/dovecot/deliver permissions as follows: > > -rwsr-s--- 1 root dovecot 4044835 2009-04-03 13:52 deliver > > Because of message returned to 'sen...@example-send.com': > > "local configuration error. Command output: > /usr/local/libexec/dovecot/deliver must not be both world-executable and > setuid-root. This allows root exploits. See [LDA#multipleuids wiki page]." > > Same auth-master "Permission denied" error. > > Thanks again. > > James
Re: [Dovecot] auth-master: Permission denied [sigh]
I have changed /usr/local/libexec/dovecot/deliver permissions as follows: -rwsr-s--- 1 root dovecot 4044835 2009-04-03 13:52 deliver Because of message returned to 'sen...@example-send.com': "local configuration error. Command output: /usr/local/libexec/dovecot/deliver must not be both world-executable and setuid-root. This allows root exploits. See [LDA#multipleuids wiki page]." Same auth-master "Permission denied" error. Thanks again. James
Re: [Dovecot] auth-master: Permission denied [sigh]
Here is everything I could think of that might pertain to this, as
currently configured on my dedicated server. It's all fresh! :)
## SYSTEM ##
Fedora 10
Postfix 2.55
Dovecot 1.2.rc2
Spamassassin 3.2.5
SELinux (no SELinux restrictions. Testing done with SELinux=permissive.)
SASLAuthd (not required for local delivery)
## dovecot -n ##
# 1.2.rc2: /usr/local/etc/dovecot.conf
# OS: Linux 2.6.27.15-170.2.24.fc10.i686 i686 Fedora rel 10 (Cambridge)
protocols: imaps
listen: *:993
ssl_cert_file: /etc/pki/dovecot/certs/dovecot.pem
ssl_key_file: /etc/pki/dovecot/private/dovecot.pem
login_dir: /usr/local/var/run/dovecot/login
login_executable: /usr/local/libexec/dovecot/imap-login
first_valid_gid: 0
mail_location: maildir:~/Maildir
auth default:
passdb:
driver: pam
userdb:
driver: passwd
## /usr/local/etc/dovecot.conf ##
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0666
# user =
group = dovecot
}
client {
path = /var/run/dovecot/auth-client
mode = 0666
# user =
group = dovecot
}
}
## POSTFIX CONFIG ##
/etc/postfix/main.cf:
mailbox_transport = spamassassin
/etc/postfix/master.cf:
spamassassin unix - n n - - pipe
user=spam:dovecot argv=/usr/bin/spamc -f -e
/usr/libexec/dovecot/deliver -f ${sender} -d ${user} -m ${extension}
## PERMISSIONS / OWNERSHIP ##
/usr/local/libexec/dovecot:
-rwxr-xr-x 1 root root 197513 2009-04-03 13:52 checkpassword-reply
-rwxr-xr-x 1 root dovecot 4044835 2009-04-14 13:52 deliver
-rwxr-xr-x 1 root root1044608 2009-04-03 13:52 dovecot-auth
/var/run:
drwxrwxrwx 3 root dovecot4096 2009-04-14 12:07 dovecot
/var/run/dovecot:
drwxr-x--- 2 root dovecot4096 2009-04-09 06:56 login
/usr/bin/spamassassin:
-rwxr-xr-x 1 root root 27023 2008-09-04 14:51 spamassassin
/home/user:
drwx-- 4 user dovecot4096 2009-04-14 12:00 user
## 'ps aux' OUTPUT (trimmed) ##
root Ss 11:14 0:02 /usr/local/sbin/dovecot
root S 12:07 0:00 dovecot-auth
root S 12:07 0:00 dovecot-auth -w
root Ss 11:14 0:31 /usr/bin/spamd -d -c -m5 -H --username spam -r \
/var/run/spamd.pid
spam S 11:14 0:27 spamd child
spam S 11:14 0:08 spamd child
## 'ps aux | grep deliver' numerous times until I caught one: ##
postfix S 12:47 0:00 pipe -n spamassassin -t unix user=spam:dovecot \
argv=/usr/bin/spamc -f -e /usr/libexec/dovecot/deliver -f ${sender} \
-d ${user} -m ${extension}
spamSs 12:47 0:00 /usr/bin/spamc -f -e /usr/libexec/dovecot/deliver \
-f sen...@example.com -d user -m
## /var/log/maillog OUTPUT ##
Apr 14 14:53:15 ltfs450 postfix/smtpd[23173]: connect from \
IP-ADD-RES-SS.dedicatedprovider.com[IP.ADD.RES.SS]
Apr 14 14:53:15 ltfs450 postfix/smtpd[23173]: C7FB9FA00FA: \
client=IP-ADD-RES-SS.dedicatedprovider.com[IP.ADD.RES.SS]
Apr 14 14:53:15 ltfs450 postfix/cleanup[23177]: C7FB9FA00FA: \
message-id=<49e4ea41.6020...@example-send.com>
Apr 14 14:53:15 ltfs450 postfix/qmgr[23171]: C7FB9FA00FA: \
from=, size=2215, nrcpt=1 (queue active)
Apr 14 14:53:15 ltfs450 postfix/smtpd[23173]: disconnect from \
IP-ADD-RES-SS.dedicatedprovider.com[IP.ADD.RES.SS]
Apr 14 14:53:16 ltfs450 spamd[4121]: spamd: connection from \
localhost.localdomain [127.0.0.1] at port 50035
Apr 14 14:53:16 ltfs450 spamd[4121]: spamd: processing message \
<49e4ea41.6020...@example-send.com> for spam:653
Apr 14 14:53:20 ltfs450 spamd[4121]: spamd: clean message (2.2/5.0) \
for spam:653 in 4.7 seconds, 2167 bytes.
Apr 14 14:53:21 ltfs450 spamd[4121]: spamd: result: . 2 - \
AWL,RDNS_DYNAMIC,TVD_SPACE_RATIO scantime=4.7,size=2167,user=spam,\
uid=653,required_score=5.0,rhost=localhost.localdomain,raddr=127.0.0.1,\
rport=50035,mid=<49e4ea41.6020...@example-send.com>,autolearn=no
Apr 14 14:53:21 ltfs450 deliver(user): Can't connect to auth server \
at /var/run/dovecot/auth-master: Permission denied
Apr 14 14:53:21 ltfs450 postfix/pipe[23179]: C7FB9FA00FA: \
to=, relay=spamassassin, delay=5.2, \
delays=0.01/0.01/0/5.2, dsn=4.3.0, status=deferred (temporary failure)
Apr 14 14:53:21 ltfs450 spamd[4119]: prefork: child states: II
Re: [Dovecot] auth-master: Permission denied [sigh]
Thank you for your continued attention, Timo.
> On Tue, 2009-04-14 at 10:22 -0700, James Butler wrote:
>> > On Mon, 2009-04-13 at 15:48 -0700, James Butler wrote:
>> >> 1) User 'spam:dovecot' runs Smapassassin
>> >> 2) Hands off to deliver (root:dovecot)
>> >
>> > Have you set up some kind of setuid-root deliver, or why is it running
>> > as root:dovecot here instead of spam:dovecot?
>>
>> I have no idea how it is running, except for these clues:
>>
>> 1) Deliver is owned by root:dovecot
>
> That makes no difference what the file's owner is.
Ok. I'm looking at the "Multiple UID" section, here ... it seems to
indicate otherwise.
>> 2) When Spamassassin executes and then its output gets piped to Deliver
>> WITHOUT a '-d ${user}' parameter, mail gets delivered to 'spam'
>>
>> So it seems like Spamassassin IS running as user 'spam:dovecot'.
>
> Not necessarily.
Hmm. I don't understand this. See my master.cf entry, below. (Sorry I
didn't reference it directly in that last message. I've posted it,
previously.)
>> Then it hands off to Deliver which starts out as being owned by
>> root:dovecot. The runtime parameters instruct Deliver to switch from its
>> default ownership to 'user1:dovecot', AFAICT.
>
> deliver can't change any ownership to anything unless it runs as root,
> which can't happen unless spamassassin somehow executes deliver as root,
> which I doubt.
>
> I'm pretty sure the problem is that spamassassin isn't running as
> spam:dovecot.
See my master.cf entry, below.
>> >> 3) Deliver assumes 'user1:dovecot' identity
>> >> 4) Can't access auth-master in 'root:dovecot' directory (777)
>> >
>> > 4) happens before 3).
>>
>> But my error (4) is labeled with:
>>
>> deliver(user1):
>>
>> Does that not indicate that Deliver has switched from its default
>> ownership to run as 'user1',
>
> No. The "user1" just means that it's going to deliver the mail to that
> user. It doesn't tell anything about what permissions the process is
> actually running with.
How can I determine which permissions the 'deliver' process is actually
running with? I don't see it running with any permutation of 'ps'.
>> > My guess is that deliver isn't really started with dovecot group
>> > permission.
>>
>> My settings in Postfix's master.cf instruct:
>>
>> /usr/local/libexec/dovecot/deliver -f ${sender} -d ${user}
>>
>> If: ${user} = user1:dovecot
>>
>> Then isn't deliver being executed as user1:dovecot?
>
> No. You didn't show the full master.cf line. Typically deliver is
> executed via pipe, such as:
>
> dovecot unix - n n - - pipe
> flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f
> ${sender} -d ${recipient}
>
> The important part there is the user=vmail:vmail part. It's executed as
> that user.
Here's my current, non-working entry (referenced above):
spamassassin unix - n n - - pipe
user=spam:dovecot argv=/usr/bin/spamc -f -e /usr/libexec/dovecot/deliver
-f ${sender} -d ${user} -m ${extension}
Here's the one where all mail gets delivered to user 'spam':
spamassassin unix - n n - - pipe
user=spam:dovecot argv=/usr/bin/spamc -f -e /usr/libexec/dovecot/deliver
Here's the one without Spamassassin that delivers to the recipient:
dovecot unix - n n - - pipe
/usr/libexec/dovecot/deliver
NOTE:
1) spamassassin unix - n n - - pipe
user=USERNAME argv=/usr/bin/spamc -f -e /usr/libexec/dovecot/deliver
Runs through Spamassassin and then delivers to USERNAME.
2) user= is required.
3) user=${user} fails, as ${user} is not resolved.
4) user=root fails because I'm not allowed to run SA as root in this context
>> And would I really need to put ALL of my users into the same (dovecot)
>> group just to be able to get mail to them? That would make little sense
>> to
>> me, as the whole point of using groups would be eliminated.
>
> If you're using multiple UIDs, you typically have to run deliver as
> setuid-root: http://wiki.dovecot.org/LDA#multipleuids
Here's from the doc page you referenced, which I have read many, many times:
===
Multiple UIDs
If you're using more than one UID for users, you're going to have problems
running deliver. Most MTAs won't let you run deliver as root, so for now
you'll need to make it setuid root. However it's insecure to make deliver
setuid-root, especially
Re: [Dovecot] auth-master: Permission denied [sigh]
> On Mon, 2009-04-13 at 15:48 -0700, James Butler wrote:
>> 1) User 'spam:dovecot' runs Smapassassin
>> 2) Hands off to deliver (root:dovecot)
>
> Have you set up some kind of setuid-root deliver, or why is it running
> as root:dovecot here instead of spam:dovecot?
I have no idea how it is running, except for these clues:
1) Deliver is owned by root:dovecot
2) When Spamassassin executes and then its output gets piped to Deliver
WITHOUT a '-d ${user}' parameter, mail gets delivered to 'spam'
So it seems like Spamassassin IS running as user 'spam:dovecot'.
Then it hands off to Deliver which starts out as being owned by
root:dovecot. The runtime parameters instruct Deliver to switch from its
default ownership to 'user1:dovecot', AFAICT.
>> 3) Deliver assumes 'user1:dovecot' identity
>> 4) Can't access auth-master in 'root:dovecot' directory (777)
>
> 4) happens before 3).
But my error (4) is labeled with:
deliver(user1):
Does that not indicate that Deliver has switched from its default
ownership to run as 'user1', per the runtime parameters, and then been
denied access to auth-master?
>> So it's 'auth-master' that is (a) not available to 'user1' AND (b) not
>> available to group 'dovecot'. Huh? Why not?
>
> My guess is that deliver isn't really started with dovecot group
> permission.
My settings in Postfix's master.cf instruct:
/usr/local/libexec/dovecot/deliver -f ${sender} -d ${user}
If: ${user} = user1:dovecot
Then isn't deliver being executed as user1:dovecot?
And would I really need to put ALL of my users into the same (dovecot)
group just to be able to get mail to them? That would make little sense to
me, as the whole point of using groups would be eliminated.
Obviously I have a lot of confusion about who is running what when, and
why auth-master is not allowing access to itself.
The only thing I know for sure is that when I use the '-d ${user}'
parameter in master.cf, the ${user} has no permission to access/execute
auth-master, regardless of '/var/run/dovecot' directory permissions.
If I omit that parameter, and let Deliver keep running as user 'spam',
mail gets delivered (to 'spam').
If I omit the whole Smapassassin loop and go straight to Deliver, mail
gets delivered (to ${user}).
It is only when I try to switch from 'spam' to '${user}' that I have this
problem.
Here's my Deliver ownership/perms, again:
-rwxr-xr-x 1 root dovecot 4044835 2009-04-03 13:52 deliver
Shouldn't there be an 's' in there, somewhere?
Should I be looking at some other executable, like dovecot-auth?
Thank you for your help.
James
Re: [Dovecot] auth-master: Permission denied [sigh]
My latest test:
spam:dovecot => user: spam
user1:dovecot => user: user1
root:dovecot => binary: /usr/local/libexec/deliver
root:dovecot 777 => dir: /var/run/dovecot/
Still getting:
deliver(user1): Can't connect to auth server at \
/var/run/dovecot/auth-master: Permission denied
What's the key to this problem?
If I set spam, user1, deliver and /var/run/dovecot/ to the same group, and
give read/write permission in that directory to that group, why can't they
all use auth-master?
1) User 'spam:dovecot' runs Smapassassin
2) Hands off to deliver (root:dovecot)
3) Deliver assumes 'user1:dovecot' identity
4) Can't access auth-master in 'root:dovecot' directory (777)
So it's 'auth-master' that is (a) not available to 'user1' AND (b) not
available to group 'dovecot'. Huh? Why not?
I'm obviously missing info about the temporary 'auth-master'.
Can anyone please give me a hand? I'd really appreciate it.
Thank you.
James
> Thank you! Even setting the /var/run/dovecot tree to all chmod 777s
> doesn't help. I'm probably mis-remembering the ownership of auth-master,
> in my original note. I haven't seen it since I left my notes at work.
>
> With regard to this maillog entry:
>
>> postfix/pipe[29452]: 60990FA01BA: to=, \
>> relay=spamassassin, delay=6, delays=0.33/0.01/0/5.7, dsn=4.3.0, \
>> status=deferred (temporary failure)
>
> It IS a (temporary failure), because soon after I revert to the simple:
>>> mailbox_command = /usr/local/libexec/dovecot/deliver
> the message arrives to the recipient user's mailbox.
>
> It's the spamassassin => deliver handoff and user SWITCH that seems to be
> problematic.
>
> But then, my brain is all garbled, at this point, so I can't really trust
> any of my logic. I'll check back in, tomorrow.
>
> Thanks, again.
>
> James
>
>> Hi,
>>
>> I was having problems with permissions on auth-master too. I solve them
>> creating manually the folder /var/run/dovecot with correct permissions
>> but
>> i
>> see you already did that :\
>>
>> On Sun, Apr 12, 2009 at 5:27 PM, James Butler
>> wrote:
>>
>>> I've been messing with this for too long, now, and I'm blind to
>>> whatever's
>>> wrong. Or I'm simply being dense. Either way, I need help with a common
>>> issue.
>>>
>>> I'm trying to get Postfix+Spamassassin+Dovecot going on Fedora 10.
>>> (I'll
>>> get back to the global Sieve thingy soon, but I need to get this going,
>>> first.)
>>>
>>> When using the simple:
>>> mailbox_command = /usr/local/libexec/dovecot/deliver
>>> everything is cool, except there's no Spamassassin involvement,
>>> obviously.
>>>
>>> The problem shows itself when the Spamassassin user hands off to the
>>> recipient user and Deliver + the recipient user tries to access
>>> /var/run/dovecot/auth-master.
>>>
>>> Thank you for any insight you can provide.
>>>
>>> /var/run/dovecot: 755 root:dovecot
>>> /var/run/dovecot/login: 750 root:dovecot
>>> /var/run/dovecot/auth-master: 750 root:dovecot
>>> (I think. auth-master is a temporary file? Comes and goes.)
>>>
>>> >From /etc/postfix/main.cf
>>>
>>> mailbox_transport = spamassassin
>>>
>>> >From /etc/postfix/master.cf:
>>>
>>> spamassassin unix - n n - - pipe
>>> user=spam argv=/usr/bin/spamc -f -e /usr/libexec/dovecot/deliver
>>> -f ${sender} -d ${user} -m ${extension}
>>>
>>> Here's my 'socket listen' section from /usr/local/etc/dovecot.conf:
>>>
>>> socket listen {
>>> master {
>>> path = /var/run/dovecot/auth-master
>>> mode = 0666
>>> #user =
>>> group = dovecot
>>> }
>>> client {
>>> path = /var/run/dovecot/auth-client
>>> mode = 0666
>>> #user =
>>> group = dovecot
>>> }
>>> }
>>>
>>> >From /var/log/maillog:
>>>
>>> Postfix receives the message:
>>>
>>> postfix/smtpd[29447]: connect from \
>>> IP-ADD-RE-SS.ptr.example-send.com[IP.ADD.RE.SS]
>>> postfix/smtpd[29447]: 60990FA01BA: \
>>> client=IP-ADD-RE-SS.ptr.example-send.com[IP.ADD.RE.SS]
>>> postfix/cleanup[29451]: 60990FA01BA: \
>>> message-id=<49e20bf2.4090...@example-send.com>
>>> postfix/qmgr[29441]: 60990FA01BA: from=, \
>>> size=812, nrcpt=1 (qu
Re: [Dovecot] auth-master: Permission denied [sigh]
Thank you! Even setting the /var/run/dovecot tree to all chmod 777s
doesn't help. I'm probably mis-remembering the ownership of auth-master,
in my original note. I haven't seen it since I left my notes at work.
With regard to this maillog entry:
> postfix/pipe[29452]: 60990FA01BA: to=, \
> relay=spamassassin, delay=6, delays=0.33/0.01/0/5.7, dsn=4.3.0, \
> status=deferred (temporary failure)
It IS a (temporary failure), because soon after I revert to the simple:
>> mailbox_command = /usr/local/libexec/dovecot/deliver
the message arrives to the recipient user's mailbox.
It's the spamassassin => deliver handoff and user SWITCH that seems to be
problematic.
But then, my brain is all garbled, at this point, so I can't really trust
any of my logic. I'll check back in, tomorrow.
Thanks, again.
James
> Hi,
>
> I was having problems with permissions on auth-master too. I solve them
> creating manually the folder /var/run/dovecot with correct permissions but
> i
> see you already did that :\
>
> On Sun, Apr 12, 2009 at 5:27 PM, James Butler
> wrote:
>
>> I've been messing with this for too long, now, and I'm blind to
>> whatever's
>> wrong. Or I'm simply being dense. Either way, I need help with a common
>> issue.
>>
>> I'm trying to get Postfix+Spamassassin+Dovecot going on Fedora 10. (I'll
>> get back to the global Sieve thingy soon, but I need to get this going,
>> first.)
>>
>> When using the simple:
>> mailbox_command = /usr/local/libexec/dovecot/deliver
>> everything is cool, except there's no Spamassassin involvement,
>> obviously.
>>
>> The problem shows itself when the Spamassassin user hands off to the
>> recipient user and Deliver + the recipient user tries to access
>> /var/run/dovecot/auth-master.
>>
>> Thank you for any insight you can provide.
>>
>> /var/run/dovecot: 755 root:dovecot
>> /var/run/dovecot/login: 750 root:dovecot
>> /var/run/dovecot/auth-master: 750 root:dovecot
>> (I think. auth-master is a temporary file? Comes and goes.)
>>
>> >From /etc/postfix/main.cf
>>
>> mailbox_transport = spamassassin
>>
>> >From /etc/postfix/master.cf:
>>
>> spamassassin unix - n n - - pipe
>> user=spam argv=/usr/bin/spamc -f -e /usr/libexec/dovecot/deliver
>> -f ${sender} -d ${user} -m ${extension}
>>
>> Here's my 'socket listen' section from /usr/local/etc/dovecot.conf:
>>
>> socket listen {
>> master {
>> path = /var/run/dovecot/auth-master
>> mode = 0666
>> #user =
>> group = dovecot
>> }
>> client {
>> path = /var/run/dovecot/auth-client
>> mode = 0666
>> #user =
>> group = dovecot
>> }
>> }
>>
>> >From /var/log/maillog:
>>
>> Postfix receives the message:
>>
>> postfix/smtpd[29447]: connect from \
>> IP-ADD-RE-SS.ptr.example-send.com[IP.ADD.RE.SS]
>> postfix/smtpd[29447]: 60990FA01BA: \
>> client=IP-ADD-RE-SS.ptr.example-send.com[IP.ADD.RE.SS]
>> postfix/cleanup[29451]: 60990FA01BA: \
>> message-id=<49e20bf2.4090...@example-send.com>
>> postfix/qmgr[29441]: 60990FA01BA: from=, \
>> size=812, nrcpt=1 (queue active)
>> postfix/smtpd[29447]: disconnect from \
>> IP-ADD-RE-SS.ptr.example-send.com[IP.ADD.RE.SS]
>>
>> Spamassassin processes the message as user 'spam':
>>
>> spamd[4121]: spamd: processing message\
>> <49e20bf2.4090...@example-send.com> for spam:653
>> spamd[4121]: spamd: clean message (3.0/5.0) for spam:653 in 5.2
>> seconds,\
>> 793 bytes.
>> spamd[4121]: spamd: result: . 2 - RDNS_DYNAMIC,TVD_SPACE_RATIO \
>> scantime=5.2,size=793,user=spam,uid=653,required_score=5.0, \
>> rhost=localhost.localdomain,raddr=127.0.0.1,rport=42493, \
>> mid=<49e20bf2.4090...@example-send.com>,autolearn=no
>>
>> Spamassassin pipes result to Deliver which runs as recipient user.
>>
>> Deliver as recipient user doesn't have permission to auth:
>>
>> deliver(recipient): Can't connect to auth server at \
>> /var/run/dovecot/auth-master: Permission denied
>> postfix/pipe[29452]: 60990FA01BA: to=, \
>> relay=spamassassin, delay=6, delays=0.33/0.01/0/5.7, dsn=4.3.0, \
>> status=deferred (temporary failure)
>>
>> 1) I must use the 'user=' arg for spamc
>> 2) Can't use 'user=${user}' or $user:
>> fatal: get_service_attr: unknown username: ${user}
>> 3) Must use '-d ${user}' Deliver arg, otherwise
>> message gets delivered to user 'spam'
>>
>> AArrgh! TIA.
>>
>>
>
>
> --
> telemóvel: 963446125
> mail: rui@gmail.com
> mail: ei04...@fe.up.pt
> website: http://paginas.fe.up.pt/~ei04073
>
[Dovecot] auth-master: Permission denied [sigh]
I've been messing with this for too long, now, and I'm blind to whatever's
wrong. Or I'm simply being dense. Either way, I need help with a common
issue.
I'm trying to get Postfix+Spamassassin+Dovecot going on Fedora 10. (I'll
get back to the global Sieve thingy soon, but I need to get this going,
first.)
When using the simple:
mailbox_command = /usr/local/libexec/dovecot/deliver
everything is cool, except there's no Spamassassin involvement, obviously.
The problem shows itself when the Spamassassin user hands off to the
recipient user and Deliver + the recipient user tries to access
/var/run/dovecot/auth-master.
Thank you for any insight you can provide.
/var/run/dovecot: 755 root:dovecot
/var/run/dovecot/login: 750 root:dovecot
/var/run/dovecot/auth-master: 750 root:dovecot
(I think. auth-master is a temporary file? Comes and goes.)
>From /etc/postfix/main.cf
mailbox_transport = spamassassin
>From /etc/postfix/master.cf:
spamassassin unix - n n - - pipe
user=spam argv=/usr/bin/spamc -f -e /usr/libexec/dovecot/deliver
-f ${sender} -d ${user} -m ${extension}
Here's my 'socket listen' section from /usr/local/etc/dovecot.conf:
socket listen {
master {
path = /var/run/dovecot/auth-master
mode = 0666
#user =
group = dovecot
}
client {
path = /var/run/dovecot/auth-client
mode = 0666
#user =
group = dovecot
}
}
>From /var/log/maillog:
Postfix receives the message:
postfix/smtpd[29447]: connect from \
IP-ADD-RE-SS.ptr.example-send.com[IP.ADD.RE.SS]
postfix/smtpd[29447]: 60990FA01BA: \
client=IP-ADD-RE-SS.ptr.example-send.com[IP.ADD.RE.SS]
postfix/cleanup[29451]: 60990FA01BA: \
message-id=<49e20bf2.4090...@example-send.com>
postfix/qmgr[29441]: 60990FA01BA: from=, \
size=812, nrcpt=1 (queue active)
postfix/smtpd[29447]: disconnect from \
IP-ADD-RE-SS.ptr.example-send.com[IP.ADD.RE.SS]
Spamassassin processes the message as user 'spam':
spamd[4121]: spamd: processing message\
<49e20bf2.4090...@example-send.com> for spam:653
spamd[4121]: spamd: clean message (3.0/5.0) for spam:653 in 5.2 seconds,\
793 bytes.
spamd[4121]: spamd: result: . 2 - RDNS_DYNAMIC,TVD_SPACE_RATIO \
scantime=5.2,size=793,user=spam,uid=653,required_score=5.0, \
rhost=localhost.localdomain,raddr=127.0.0.1,rport=42493, \
mid=<49e20bf2.4090...@example-send.com>,autolearn=no
Spamassassin pipes result to Deliver which runs as recipient user.
Deliver as recipient user doesn't have permission to auth:
deliver(recipient): Can't connect to auth server at \
/var/run/dovecot/auth-master: Permission denied
postfix/pipe[29452]: 60990FA01BA: to=, \
relay=spamassassin, delay=6, delays=0.33/0.01/0/5.7, dsn=4.3.0, \
status=deferred (temporary failure)
1) I must use the 'user=' arg for spamc
2) Can't use 'user=${user}' or $user:
fatal: get_service_attr: unknown username: ${user}
3) Must use '-d ${user}' Deliver arg, otherwise
message gets delivered to user 'spam'
AArrgh! TIA.
Re: [Dovecot] Global Sieve File
Thank you very much for your reply, Mr. Bosch. Still trying to iron it out. > If you are using the new Sieve implementation, you can use the new > multiscript feature. It is not explained on the wiki yet (I should give > the new Sieve its own page), but things are outlined in the > configuration section of the INSTALL file: I'm still getting permissions errors like when I wasn't using 'sieve_before': dovecot: deliver(user1): sieve: binary open(/dovecot/global.svbin) \ failed: Permission denied dovecot: deliver(user1): sieve: open(/dovecot/global.svbin.tmp) \ failed for binary save: Permission denied dovecot: deliver(user1): sieve: rename(/dovecot/global.before.svbin.tmp, \ /dovecot/global.before.svbin) failed for binary save: Permission denied A normal user (user1) doesn't have permission to do anything in the directory that stores the global.sieve/.svbin files, which is owned by dovecot:dovecot. Has anyone got a successful installation of a global Sieve file they could describe? Using the multiscript feature would be great, if you have done it successfully. I very much appreciate the way this is supposed to go, according to the docs, and I really hope to find someone who is actually using a global Sieve file successfully, so I can learn from their example. I'm sure it's something simple, but I just can't see the problem in my own installation. Thanks a lot. (Local Sieve files work fine, but I still have a need for a global filter.) James
[Dovecot] Global Sieve File
Is anyone here using a global Sieve file that handles messages for an entire server with many users? I understand and use local Sieve files, but I would like to learn more about how to set up Sieve to filter ALL incoming messages using a single file. I would love to read about how you managed to get it working. I'm running Fedora 10 with Postfix 2.5.5 and Dovecot 1.2.rc2. Thanks for any insight! James
Re: [Dovecot] Global Recipe Location
Thank you for your response, Mr. Bosch. > James Butler schreef: >> Hmmm. I'm having difficulty finding a good place for a global Sieve >> script. > First of all, you should start a new thread (i.e. don't reply on an > existing message) if you have a completely new question. Otherwise, some > people may miss it and you'll mess the threads up in general. I apologize. I thought I had created a new thread. I will be more careful in the future. >> The problem seems to be related to saving the compiled version >> (xxx.svbin.tmp) in the same location as the script (xxx.sieve), which >> happens using the credentials of the recipient user. > The .svbin.tmp is a temporary version of the binary that is produced > (and removed) when the script is recompiled. So, the actual name for the > Sieve binary is global.svbin. Thank you. >> i.e. >> >> drwxr-xr-x dovecoter dovecoter /scripts >> -rw-r--r-- dovecoter dovecoter /scripts/global.sieve >> -rw--- recipient USERGROUP /scripts/global.svbin.tmp >> >> Where should I be storing a global script that will process all incoming >> mail, and is not user-specific? Also, I would love some suggestions >> regarding how the permissions should be set, or anything that would make >> this work as expected. > > The main problem is that the recipient users will not be able to write > in the global directory, or they are not able to replace an existing > binary with a recompiled version. This makes it impossible for deliver > to store compiled global script binaries (it will work though). To > prevent this, you must manually pre-compile your global scripts using > the sievec tool each time you change them. Read the man page for more > info. If this is the method for utilizing a global script, I am still unable to implement it. I have manually pre-compiled the global.sieve script into global.svbin in the same location, however I still get the error (shown below), plus there is now another error, since a normal user does not have permission to even access the binary, which is owned by the Dovecot user. Here are the errors: (Running as recipient user1, try to open the pre-compiled script, which is owned by the Dovecot user:) dovecot: deliver(user1): sieve: binary open(/dovecot/global.svbin) failed: Permission denied (No permissions, so it tries to create its own .tmp file:) dovecot: deliver(user1): sieve: rename(/dovecot/global.svbin.tmp, /dovecot/global.svbin) failed for binary save: Permission denied For the record, here's my global script stuff: drwxr-xr-x dovecotuser:dovecotgroup /scripts -rw-r--r-- dovecotuser:dovecotgroup /scripts/global.sieve -rw--- dovecotuser:dovecotgroup /scripts/global.svbin And here's what is being attempted with regard to error #2, above: -rw--- user1:user1group /scripts/global.svbin.tmp Note that this .tmp file remains in the directory along with the other files, and it is not removed. Mr. Bosch, I am curious about your statement: "This makes it impossible for deliver to store compiled global script binaries (it will work though)." I'm not sure what is 'impossible' and what 'will work though'. I can definitely *store* a compiled global script binary ... it just seems to be tricky to *use* it. ;) I appreciate any clarity you can give. James
[Dovecot] Global Recipe Location
Hmmm. I'm having difficulty finding a good place for a global Sieve script. The problem seems to be related to saving the compiled version (xxx.svbin.tmp) in the same location as the script (xxx.sieve), which happens using the credentials of the recipient user. i.e. drwxr-xr-x dovecoter dovecoter /scripts -rw-r--r-- dovecoter dovecoter /scripts/global.sieve -rw--- recipient USERGROUP /scripts/global.svbin.tmp Where should I be storing a global script that will process all incoming mail, and is not user-specific? Also, I would love some suggestions regarding how the permissions should be set, or anything that would make this work as expected. (Also, is there any documentation available regarding this type of thing?) Thanks. James
Re: [Dovecot] Adding Sieve Extensions
> On Fri, 2009-04-03 at 13:43 -0700, James Butler wrote: >> And if it's not too much trouble, is there a way to include currently >> un-included extensions, like 'editheader', into Dovecot/Sieve? How >> complicated is it? I'm guessing that it is more complicated than simply >> writing a Capability definition and generating a plugin ... > > I guess it depends on what you mean by "generating a plugin". The > working kind of "generating" is "writing the necessary code" :) So no, > it's not simple. If it were, it would have been implemented already. > > Of course. :) Silly question. Thanks again. James
Re: [Dovecot] Adding Sieve Extensions
And if it's not too much trouble, is there a way to include currently un-included extensions, like 'editheader', into Dovecot/Sieve? How complicated is it? I'm guessing that it is more complicated than simply writing a Capability definition and generating a plugin ... James
Re: [Dovecot] Adding Sieve Extensions
> On Fri, 2009-04-03 at 13:08 -0700, James Butler wrote:
>> - Dovecot v.1.2.beta4
>> - Sieve 0.1.4
>>
>> I am getting this in my sieve log:
>>
>> main script: line 7: error: unsupported sieve capability 'editheader'.
>
> Right, this isn't supported.
>
>> main script: line 7: error: unsupported sieve capability 'discard'.
>> main script: line 7: error: unsupported sieve capability 'redirect'.
>
> These don't need to be "require"d.
>
>> Since this is a global script, I figured I need to add a header or flag
>> to
>> the message then detect it and avoid a loop condition.
>
> I think MTAs are pretty good at catching loops nowadays.
>
So this is pretty common ... forking messages to users on the same server
using a global script that will get hit again when the forks arrive? I
hesitate to test because I've previously experienced loops with a
Sendmail/Procmail setup that brought my (remote) server to its knees. (I'm
now using Postfix v.2.5.5.)
If it's cool, though, I'm going to start here with my recipe writing:
if header :contains "Subject" "List Title" {
redirect ["endus...@example.com","endus...@example.com"];
discard;
stop;
}
Thanks, again.
James
Re: [Dovecot] Adding Sieve Extensions
> On Fri, 2009-04-03 at 12:34 -0700, James Butler wrote:
>> How can I add an extension to Dovecot's Sieve implementation?
>>
>> I would like to use 'editheader' and 'redirect'.
>
> I'm not really sure what you mean. editheader isn't implemented,
> although Konstantin is apparently trying to implement it for
> dovecot-libsieve. redirect is implemented and can be used in the same
> way as all other sieve implementations:
>
> redirect "em...@example.com";
>
>
Thank you for your response!
- Dovecot v.1.2.beta4
- Sieve 0.1.4
I am getting this in my sieve log:
main script: line 7: error: unsupported sieve capability 'editheader'.
main script: line 7: error: unsupported sieve capability 'discard'.
main script: line 7: error: unsupported sieve capability 'redirect'.
main script: line 12: error: unknown command 'addheader'.
I wish to receive list messages to a list user (i.e. li...@example.com),
then distribute them to the appropriate end users, then discard the
original message. Here's what I am currently experimenting with:
if not header :contains "X-noloop" "true" {
if header :contains "Subject" "List Title" {
addheader :last "X-noloop: true";
redirect ["endus...@example.com","endus...@example.com"];
discard;
stop;
}
}
Since this is a global script, I figured I need to add a header or flag to
the message then detect it and avoid a loop condition.
James
[Dovecot] Adding Sieve Extensions
How can I add an extension to Dovecot's Sieve implementation? I would like to use 'editheader' and 'redirect'. Thank you! James
