This applies possibly to newer versions too. Exim, by its default configuration, will not use procmail if it is not readable by the recipient user. procmail, as a big exception among everything in /usr/bin, is installed o-r. ll /usr/bin/procmail -rwsr-s--x 1 root root 76040 Nov 6 2016 /usr/bin/procmail In /etc/exim/exim.conf: (not really, simplified by me) procmail: require_files = $local_part:+$home/.procmailrc:+/usr/bin/promail To make it work, the possible ways are: - make procmail binary o+r - remove $local_part from the line in exim.conf (try to read as exim user, not recipient user) - remove +/usr/bin/procmail from the line (do not check the binary) Any of these may be undesirable for different reasons, maybe someone can find a better way.
Do you happen to know if this used to work (and changed recently)?
I found a procmail binary from 2009 that is world un-readable. For the exim part, it installs /etc/exim/exim.conf.dist (as example), and the problem is only noticeable if this file is copied to exim.conf. I don't know if it ever worked before. It is possible that last time (long ago) I started with a different configuration.
ok, so here's the thing from Exim point of view: the procmail router from the exim.conf.dist file comes straight from upstream. I don't like to change that file for that reason. I just installed procmail on Ubuntu to see what they do, and they have -rwsr-sr-x 1 root mail /usr/bin/procmail So perhaps, we should consider your first suggestion o+r, or drop an einfo in the procmail ebuild to suggest one needs that for mta integration or something. One interesting thing here, the ebuild installs using: insopts -m 6755 but somehow the following happens when merging: * >>> SetUID and SetGID: [chmod o-r] /usr/bin/procmail ... [ ok ] * >>> SetGID: [chmod o-r] /usr/bin/lockfile ... [ ok ] Which feels like some security/qa check biting this particular use-case.
Ok, this is on purpose. (Done via portage's misc-functions.sh) I think the best we can do is drop an ewarn or something in procmail if sfperms is in FEATURES. I added this warning, and assume that's the best we can do, hence closing this bug. Thanks for the report and analysis!
