I'm running a courierfilter to filter incoming mail right at the SMTP
dialog.  Unfortunately, since I have been doing this, I cannot use
`sendmail` as an unprivileged user (!= root, != daemon) anymore:

  $ echo test | sendmail $my_address
  432 Mail filters temporarily unavailable.
  sendmail: Unable to submit message.

These are the permissions on the courierfilter socket directories and the
socket of my courierfilter:

  $ cd /var/lib/courier/
  $ ls -lad allfilters filters
  drwxr-x---    2 daemon   daemon       4096 2003-12-05 23:00 allfilters
  drwxr-x---    2 daemon   daemon       4096 2003-12-05 23:00 filters
  $ sudo ls -la allfilters
  allfilters:
  srwxr-xr-x    1 daemon   daemon          0 2003-12-05 23:00 myfilter.pl

I think the socket(s) would need to be accessible (readable? writable?
executable?) for unprivileged users for them to be able to successfully
send mail using `sendmail`.  `sendmail` is suid "root", and changes to the
group "daemon" when called, so it should be able to access and read the
socket directories just fine.  Still, it gives the above error message.

The author of Courier suggested that maybe the Debian packages do
something wrong.

I'm not sure this is a bug in the Courier Debian packages, it may very
well be some quirk in my local installation.  Anyhow, as Stefan Hornburg
requested, I'm filing a bug report in hope of finding a remedy for the
problem soon.

Do you still have this problem?

What would be interesting is, are there entries in the logfile?
432 suggests that the filterscript just doesn't execute successfully
(I'm not 100% sure about that, it works so if using perlfilter, you seem
to use your own filter). I have the permissions

drwxr-x---    2 daemon   daemon       4096 Feb 12 21:17 allfilters/

srw-rw----    1 daemon   daemon          0 Feb 12 21:17 perlfilter

on a RedHat installation, and that works great.

Willi

Willi Mann V. wrote:

Yes, I still have this problem:

| io:~> echo test | sendmail julian@mehnle.net
| 432 Mail filters temporarily unavailable.
| sendmail: Unable to submit message.

This appears in my log file:

| Feb 24 02:10:49 io submit: Permission denied

Hmm, the only difference between your permissions and my permissions that I could see is that my socket is not group-writable and not world-writable.

I made my socket group-writable, and now it works!

Sam, is it supposed to work that way (after all, /usr/sbin/sendmail is suid root, so shouldn't that make any permissions of the socket irrelevant?)?  If yes, then apparently every courierfilter needs to make sure its socket is group-writable for group "daemon" (i.e. the group used by Courier), right?

Julian Mehnle wrote:


sendmail.c viewed in annotate mode:
should at least give the reason:

http://cvs.sourceforge.net/viewcvs.py/courier/courier/courier/courier/sendmail.c?annotate=1.12


385 mrsam 1.5  	/*
386            	** Immediately drop uid, force GID to MAILGID
387            	** The reason we can't just setgid ourselves to MAILGID
is because
388            	** that only sets the effective uid.  We need to also
set both
389            	** real and effective GIDs, otherwise maildrop filtering
will fail,
390            	** because the real gid won't be trusted.
391            	*/
392            	setgid(MAILGID);
393            	setuid(getuid());

What should be documented is:

If you don't use libfilter, you have to take care yourself of permissions :

from libfilter.c:

	strcpy(ssun.sun_path, tmpsockname);
	unlink(ssun.sun_path);
	if ((listensock=socket(PF_UNIX, SOCK_STREAM, 0)) < 0 ||
		bind(listensock, (struct sockaddr *)&ssun, sizeof(ssun)) < 0 ||
		listen(listensock, SOMAXCONN) < 0 ||
/* look here */	chmod(ssun.sun_path, 0660) ||
		rename (tmpsockname, sockname) ||
		fcntl(listensock, F_SETFL, O_NDELAY) < 0
		)
	{
		perror("socket");

If you think this problem is solved please close this bug (or retitle to
permission of courierfilter sockets should be documented, severity
wishlist).

Willi

FYI, the documentation problem will probably be fixed by the next upstream release.

This is the change from CVS:
http://cvs.sourceforge.net/viewcvs.py/courier/courier/courier/courier/filters/courierfilter.sgml?r1=1.1&r2=1.2

Julian Mehnle wrote:

Uhm, forget that.  There is no documentation fix for _this_ omission yet.
The CVS change mentioned above fixes a slightly different omission in the
`courierfilter` documentation.

I guess I'll have to create a patch for _this_ omission myself and submit
it to Courier's author.

I have recently taken over maintenance of the courier packages.  Can you
confirm if this has been fully documented upstream?

I have recently taken over maintenance of the courier packages.  Can you
confirm if this has been fully documented upstream?