I believe most BSD's, Solaris, HP-UX and just a few others all have and use /etc/mail to localize their mail files. If you delete that then you break those. Please leave that path alone thank you.
-- Kent Hamilton <[EMAIL PROTECTED]> Manager - Systems Admin & Networking Hunter Engineering Company > -----Original Message----- > From: Duncan Findlay [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 08, 2002 16:19 > To: [EMAIL PROTECTED] > Subject: Re: [SAtalk] BUG: Documentation wrong about sitewide > /etc/mail/spamassassin/user_prefs.template > > > On Thu, Mar 07, 2002 at 03:58:25PM -0800, Timothy Demarest wrote: > > The README states that the user_prefs.template that admins > create is > > supposed to be located in /etc/mail. However, this is not the case. > > Spamassassin will only use the following files: > > > > /etc/spamassassin/user_prefs.template > > /usr/local/share/spamassassin/user_prefs.template > > /usr/share/spamassassin/user_prefs.template > > > > This is from @default_prefs_path in > > Mail-SpamAssassin-2.11/lib/Mail/SpamAssassin.pm, starting > at line 103. The > > README should be fixed, but I think a better solution is to simply > > eliminate the use of /etc/spamassassin and /etc/mail, and use > > /etc/mail/spamassassin for all admin sitewide defaults. > There are already > > too many directories that various files need to be in, and > standardizing on > > /etc/mail/spamassassin seems like a good idea. > > > > STRONGLY DISAGREE! > > I think it is perfectly acceptible to let the local admin decide where > he/she wants to put files. Why restrict, especially when the > performance > gain/loss is so incredibly insignificant. > > Furthermore, this will break previously working systems on > upgrade. For > what reason? None. > > Fix the README, and allow the admin to choose. > > If you delete one path, delete /etc/mail/spamassassin. I > don't know what > distribution has /etc/mail and what software supports this, but Debian > certainly does not. (Wouldn't it be stupid to have an > /etc/mail with just > spamassassin stuff in it?) > > If what you are saying is that you want all files to be in > one directory, > I'm going to disagree. Defaults (as provided) should be in > /usr/local/spamassassin or /usr/spamassassin (the latter is > more for vendor > installs) while local rules/changes should be in /etc/spamassassin or > /etc/mail/spamassassin. The templates file should be in the > same dir as the > rules. > > > > Additionally, we have a goofy perl install with the prefix of > > /opt/local/gnu/perl, hence the share directory is > > /opt/local/gnu/perl/share. SpamAssassin gets installed into > the perl > > hierarchy and I have had to make symlinks from > /usr/share/spamassassin and > > /usr/local/share/spamassassin to > /opt/local/gnu/perl/share/spamassassin. Is > > there a way that SpamAssassin could use the perl prefix > when searching in > > addition to the hardcoded defaults? > > > > I agree that there must be a better way to do what we need, > but $Config > is probably not the answer. Perhaps fixpath.pl is the way to > go, it just > needs to be expanded and combined with a better make file, > that could prompt > the user for information. > > -- > Duncan Findlay > > _______________________________________________ > Spamassassin-talk mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/spamassassin-talk >
smime.p7s
Description: application/pkcs7-signature
