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=recipient@example-receive.com,
relay=spamassassin, delay=6, delays=0.33/0.01/0/5.7, dsn=4.3.0,
status=deferred (temporary failure)

...

mailbox_command = /usr/local/libexec/dovecot/deliver

It IS a (temporary failure), because soon after I revert to the simple: 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 jbutler@thebestdefense.comwrote:

...

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.4090408@example-send.com postfix/qmgr[29441]: 60990FA01BA: from=sender@example-send.com,
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.4090408@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.4090408@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=recipient@example-receive.com,
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.arc@gmail.com mail: ei04073@fe.up.pt website: http://paginas.fe.up.pt/~ei04073

Unless they've changed something, doesn't the S.A method as you are using generate backscatter, I'd be using something more efficient like MailScanner or amavisd-new either will take you no more than 15 minutes to setup and avoid the past several days of your problems, pf and dovecot work well together.

On Tue, 2009-04-14 at 08:48, James Butler wrote:

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?

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

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 if you have untrusted users in your system. Setuid-root deliver can be used to gain root privileges. You should take extra steps to make sure that untrusted users can't run it and potentially gain root privileges. You can do this by making sure only your MTA has execution access to it. For example:

# chgrp secmail /usr/local/libexec/dovecot/deliver # chmod 04750 /usr/local/libexec/dovecot/deliver # ls -l /usr/local/libexec/dovecot/deliver -rwsr-x--- 1 root secmail 4023932 2009-01-15 16:23 deliver

Then start deliver as a user that belongs to secmail group.

Is this saying that Dovecot is designed for a mail system with only ONE UID, and that systems with MANY UIDs are exceptions?? I don't think so ... Dovecot works fine with multiple UIDs in my configuration when it's running by itself. If ALL users MUST be in the same group in order for this to work, so be it.

Is there a difference between the 'secmail' group in the docs and the 'dovecot' group in my config? Maybe, but I can't see where.

...

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').

Without -d parameter deliver doesn't do auth lookup at all, it just tries to figure out where to save the mail using the environment.

I understand that part. That's is why 'spam' gets all the mail without the -d parameter ... it's the user running Spamassassin, and then, Deliver. Or am I completely off base?

...

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?

If there's a 's' in there, then deliver is running setuid-root. It sounds like that's what you want.

I have again run chmod ug+s /usr/local/libexec/dovecot/deliver:

-rwsr-sr-x 1 root dovecot 4044835 2009-04-03 13:52 deliver

(Except for the world read/execute, it looks like the example from the docs.)

No change ... same error, same non-delivery after spam-checking.

(I try to reset my stuff to whatever it was before a test so my tests don't get screwed up by multiple variables and so that I can return to the working config when the test is done. I have reverted the permissions on 'deliver' back to 755, as they were before this most-recent test, and as they were in my previous post.)

I am going to post a followup with all of my config/perm/owner stuff for easy reference. I apologize in advance ... the trees are getting lost in the forest, for me.

Thank you for your patience.

James