> Also, if you guys ever need any help, I'd love to lend a hand. I've been
> curious about writing a spam reporting system, and it might make a great
> plugin for spamassassin (then again, I've had nothing but trouble when
> trying to analyze message headers to figure out how to detect forged
> h
Chris Petersen <[EMAIL PROTECTED]> writes:
> anyway, just a suggestion. It's a "check" on a variety of other spam
> filters that I've seen, so I thought I'd mention it.
We already have both a check for valid undisclosed recipients and
invalid ones. I recently tweaked the invalid one to match
> Is it a properly formatted header according to the relevant RFCs? If
> not, this entry in an ACL in my exim.conf rejects it at SMTP time.
not sure there. presumably it's all ok.
> If you want, how about coming up with a test like exim's that looks
> for syntactic validity of the header. All
On Thu, May 16, 2002 at 09:52:13AM -0700, Chris Petersen wrote:
| like the subject says... This is one of the most common spam recipients
| that I receive...
Is it a properly formatted header according to the relevant RFCs? If
not, this entry in an ACL in my exim.conf rejects it at SMTP time
> It depends on your setup. If each user is invoking spamassassin
> directly form procmailrc, then it's no problem. If spamd is running
> as root (or some other user), then there can be security concerns,
> especially since some of the rules require an eval.
aha, that makes sense, then...Ev
On Thu, May 16, 2002 at 09:52:13AM -0700, Chris Petersen wrote:
> also, what's the reasoning for not letting users define filtration regex's
> in their user files?
It depends on your setup. If each user is invoking spamassassin
directly form procmailrc, then it's no problem. If spamd is runnin
