-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Don Levey wrote: | Craig McLean wrote: | | |>> * The spamd/spamass-milter processes should not run as root (user |>>'spamassassin'). |> |>I gather from your previous mail that you already run this as |>"spamassassin". Make sure it owns the bayes files defined by |>bayes_path. I created a subdirectory owned by the user and let SA get |>on with it. |> | | I had tried running as 'spamassassin', but ran into difficulties. In | particular, it kept giving errors that it couldn't open | /root/.spamassassin/user_prefs for writing, even when I made the file and | the directory wide-open (777). Since I seem to recall seeing somewhere that | I should make changed to the user_prefs and not the local.cf (as that might | be updated and overwritten with upgrades), I had been using the user_prefs | instead. I even went to the point of setting up a wide-open user_prefs file | in a wide open directory, and linking to that for all users, but that didn't | help (it still looked only for the one in the root home dir)
I didn't think local.cf is overwritten during upgrades. I hope it doesn't, that would be counter-productive. It is true that the /usr/[local]/share/spamassassin directory may well get overwritten, which is why local rules should be in local.cf. Also, I believe SA reads *all* files ending in .cf in /etc/mail/spamassassin for configuration, so you could just call yours localconfig.cf or some such.
| | I'm getting header tags, but I'm not getting message rewriting/attachment, | or a subject rewrite. |
Spooky. I don't want to sound like a windows specialist, but have you tried stopping and starting spamd?
|>> * I want to use RBLs for things not covered otherwise in sendmail |>> (i.e. for URLs in the messages) |> |>Make sure you have the perl Net::DNS stuff installed. Check with |>'spamassassin -D --lint, look for: |>debug: is Net::DNS::Resolver available? yes |> | | I *think* this is set up correctly; I'm not currently getting any errors | that I can see. That line is indeed present.
It should be fairly obvious from the spam you get if you see rules like RCVD_IN_SORBS, RCVD_IN_BL_SPAMCOP_NET or other hits on RBL: rules.
| |>> * Eventually, I may drop egregious spam examples, |>> but I'm not sure I want to do that yet. |> |>Well, it can be done if you choose to. |> | | Not only that, but it seems to be happening now! I vaguely remember seeing | which config file would control this, but re-Googling for it doesn't turn | anything up now. Damn this memory!
Likewise..
| |>>What seems to happen is that I can get some subset of these things, |>>but not |>>all at once. Additionally, while I often think I've got things |>>working |>>correctly, they appear to change randomly from working to |>>non-working. |> |>Can you be more specific? What's not working? Any error messages in |>messages/maillog/&c. |> | | At this particular moment, the big problem is the subject/message rewriting. | But then I'm still running as root (or, apparently, 'nobody') and I'm not | sure this is the best thing to do.
Probably not, get a dedicated user for spamd and use that, keeps things tidy.
| |>>The last point, on dropping spam, seems to be happening anyway. From |>>what I can |>>tell, anything with a score greater than 15 is being rejected |>>automatically. |>>This is seriously reducing my spam load. |> |>That may well be a function of how SA/sendmail are configured on |>Fedora? |> | | It could be - but that wasn't happening as of Friday. I was seeing scores | into the 20s come through - but tagged/rewritten.
Out of interest, you don't have a conflicting user_prefs laying about in ~ either root's or spamassassin's $HOME/.spamassassin do you? If so, get them out of the way until you get the basic config up and running. You never know...
[snip]
| | I don't think I'm getting errors on the whitelist, just user_prefs. But I | *could* combine the user_prefs and local.cf files (I did that briefly, but I | thought that was a bad idea for some reason or another).
Seeing as you want site-wide config and bayes, a site-wide config file would make more sense that using a basic config in /etc/mail/spamassassin and added configuration elsewhere.
| | I'm not seeing any error in maillog (yes, you've got the location correct) | nor anything in 'spamassassin -D --lint'. Running the latest message itself | through spamassassin -D shows that it is tagged correctly, and indeed it is | being rewritten properly (sbject and body). I ran that test as root; this | must have something to do with user IDs but I'm seeing no errors that I can | find.
Well, spamd is just spamassassin (sort of), so if it works from the command-line as root but not as "nobody" or "spamassassin", it probably: 1) something in root's user_prefs that's not in nobody's or spamassassin's 2) the opposite.
I'd consolidate the stuff in root's user_prefs into /etc/mail/spamassassin/local.cf and (re)move all user_prefs from $HOME's, then re-start spamd (remember it only picks up config changes at startup...) and see if it's fixed.
| | |>>http://www.eruditer.org:6080/spamassassin/local.cf |>>http://www.eruditer.org:6080/spamassassin/root-user_prefs |>>http://www.eruditer.org:6080/spamassassin/sysconfig-spamassassin |>>http://www.eruditer.org:6080/spamassassin/sysconfig-spamassassin-milter |> |>Can't get to those URL's, timeout... |> | | Hmm... It seems to be working from the outside; perhaps you're on a firewall | that blocks my "special" port? Unfortunately, my ISP doesn't want me to run | on port 80. I think I posted the first two anyway; the latter two are the | startups from the /etc/sysconfig directory. I'll post those if you think | it's helpful, or anything else for that matter...
Yeah, it's working now. God knows what was going on.
| Thanks for your help!
My pleasure. Good Luck! Craig. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFCUWrmMDDagS2VwJ4RAouuAKDbrVT9un8+4ZRwszXXjhaLG0amdwCghSpK cKgh3vpujbQKcwvJaHatROc= =QFRw -----END PGP SIGNATURE-----
