On Sunday, 3 January 2010, Andrew Archibald wrote: > Greylisting in the latest stable sa-exim doesn't appear to work with the > default permissions on the tuplets directory left by a d-i fresh install, > using the 'Mail server' software collection option. > > # ls -ld /var/spool/sa-exim/tuplets/ > drwxr-x--- 2 nobody Debian-exim 4096 2009-12-17 11:20 > /var/spool/sa-exim/tuplets/ > > It seems that reconfiguring, as below, tidies up the perms. > > # dpkg-reconfigure sa-exim > Reloading exim4 configuration files: exim4. > # ls -ld /var/spool/sa-exim/tuplets > drwxrwx--x 2 nobody Debian-exim 4096 2009-12-17 11:20 > /var/spool/sa-exim/tuplets
Yes, that the permissions where set differently the first time than on subsequent invokations was a bug. > The default of running the greylistclean as nobody also surprised me. With > Debian-exim writing to the tuplets dir, nobody didn't have enough access: > > nobody@myhost:/$ /usr/share/sa-exim/greylistclean > Can't cd to (/var/spool/sa-exim/tuplets/) 92: Permission denied > at /usr/share/sa-exim/greylistclean line 79 Well, the default setup relies on you running spamd as "nobody", as described in README.greylisting. That is, however, not really a great idea - "nobody" shouldn't own any files IIUC - so I'll change the package to work with the default setup of spamd and add more information to the README files. I'll try to make it so that existing installations won't be broken... -- Magnus Holmgren holmg...@debian.org Debian Developer
signature.asc
Description: This is a digitally signed message part.
