Reindl Harald wrote:
just ask your distribution how they broke your environment

this is *not* a spamassassin issue and all the stuuf you do abvoe is not supposed to make things better - how do you imagine "I deleted the /usr/bin/X11 link and created a new directory /usr/bin/X11 but it still failed" has any relation to spamassassin?
While not a direct Spamassassin issue Sapmassassin is the only package this problem affects, every other package configures properly.. It is ultimately a perl issue, but as Bill Cole helpfully wrote:
The sa-compile script DOES use a SA utility function to untaint the whole %ENV hash, but there's a special catch for $ENV{'PATH'}: if any directories included are not absolute (e.g. commonly '.' and '~/bin') OR are writable by more than their owning user & group, $ENV{'PATH'} remains tainted and won't be used or passed to child processes. Often a bad member directory is unobvious because it is a symlink name and symlinks are usually technically mode 777 because the system doesn't use the mode of a symlink itself.
I was checking to see if all of the directories in $PATH were OK.. I posted the entire results of those tests to allow someone more knowledgeable than I am about Spamassassin and perl to see if there was another problem.

The reason for deleting and reinstalling  /usr/bin/X!1 was to test is a Bill Cole's suggestion that a symbolic link might be the cause of the issue, I think I've shown it's not.

Which links back to specific Spamassassin code. Determining why that code is not functioning correctly is the route to solving the whole problem. If it turns out the Spamassassin code its to blame then it is a Spamassassin issue.

Reply via email to