On Wed, May 29, 2002 at 09:25:34AM -0700, Harry Putnam wrote: | dman <[EMAIL PROTECTED]> writes: | | > The default config file has some examples. Also look at | > /etc/spamassassin/60_whitelist.cf (you're using debian, right?). | | No, not Debian. In this case RedHat 7.1
Well, ok, as long as you can find the files on your system :-). | About those examples in 60_whitelist.cf: | There are none that show multiple entries in my copy. I don't see any single line with multiple entries, but I see multiple whitelist entries (one per line). | > | The actual `From: ' line looks like: | > | | > | From: root (Cron Daemon) | > | > That's missing the address part. It should look like eg : | > | > From: [EMAIL PROTECTED] (Cron Daemon) | > | > Oh, I think I see two bugs! The first bug is in your (Harry) MTA | > config. It should be qualifying the unqualified address so that the | > actual header is | > | > From: [EMAIL PROTECTED] (Cron Daemon) | > | > (though it is recommended to use one of the top-level domains in RFC 2606) | | My usage predates RFC 2606, so I can only plead laziness... hehe. :-). Just don't use, eg, "domain.name". (http://archives.neohapsis.com/archives/postfix/2002-05/2200.html) | Sendmail is the mta in this case. I see (look at the Received: headers of mail you sent out). | I'm not sure what addition would make it use the fqdn in cron | generated mail. I don't either, but if you upgrade to RH 7.3 you'll be switching to postfix. (if you take the less-work-because-this-is-what-RH-ships route) | > The other bug is in SA. IIRC it only properly parses | > [real-name] <[address]> | > addresses and not | > [address] ([real name]) | | Well, the docs, and 60_whitelist.cf all say pointblank that file | globbing is used. In that case, you can make it work. | In that case, although it probably isn't a good | choice: | whitelist_from *root* How about whitelist_from *root*Cron Daemon* ? ... | So I guess whitelisting doesn't work quite the way I expected it | would. Somehow I assumed, all the earmarking stuff would get turned | off. The -Status and -Level headers will always be there. The -Status is very important to have because it shows that SA did process the mesage, and what SA thought of it. SA does not tag the subject if the message isn't over the threshhold. Did the message already have that ***SPAM*** marker in the subject before you sent it through SA? ... | OK, yeah, that looks like a good way to go. Maybe extend it to: | header CRON X-Cron-Env =~ /\w/ which is even less likely to be present | in a header if not a real cron message. Unless a spammer decides to add it just to trigger that rule. | But let me ask the dumb question here. By using -100 we force any | other rules that apply to add up to 102, since my limit is currently | set to 2. Or else the message is accepted. Is that how it works? Yes. The total score must be >=$threshold to be considered (and marked) as spam. If some rules score negatively, that is simply added into the total score before comparing against the threshold. ... | Has the desired effect of allowing the messages thru but they are | still earmarked as spam in subject line. Not sure I understand what | is happing there. The subject must have had that marking before SA got the message, or else something is really wrong on your system. | Shouldn't the subject `spam' label be omitted if the score is below | the set value.? Yes. -D -- "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." --Daniel Pead GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
msg05573/pgp00000.pgp
Description: PGP signature
