On Thu, 2011-03-03 at 09:55 -0800, an anonymous Nabble user wrote:
> > Even worse, you outright ignored my post explaining this. Despite the
> > fact, you actually replied to it. And quoted it in full below.
>
> Quite the opposite, I took your advice - even though it might look to you as
> if I didn't.
OK, my apologies then.
However, I still believe disabled network tests is your main issue, and
should be fixed. That will help tremendously.
> 1) I uploaded an email to the server to test. Not what I was doing before.
> 2) You said not to use the -L option and I didn't.
> 3) turn skip_rbl_checks 1 ... I tried looking for this option and couldn't
> find the file that had this option.
> 4) I made sure DNS was available using the -D option.
>
> Those were all your suggestions that I followed and totally opposite of what
> you thought. As for #3, I just couldn't find, and when I tested it and saw
> the rules come up I thought I was in the right track.
You can use the following to find your site-config directory. That's
where your site-wide settings are.
spamassassin -D --lint 2>&1 | grep "site rules"
> > Also, I seriously doubt you tested your rules "with a real email" as you
> > said. Notice the NO_RELAYS rule hit for an example. The sample was
> > either severely damaged, or a very bad copy-n-paste from a source that
> > just does not resemble a raw mail.
>
> Like I said I uploaded an email file. I don't know if that counts as a real
> email...
What is an "email file", and how did you "upload" it? What you need for
testing is a raw email, including all headers. How you get that depends
on your server and storage backend. And/or your MUA. However, if it is a
real spam you received, NO_RELAYS must not trigger.
> > That just is not how SA works. It does not reject spam. It does not
> > block it, dump it, or otherwise prevent mail from "going through".
>
> I'm not saying it should block it (i didn't make this clear), but the
> Subject line isn't changing. From what I've read, it should change the
> subject line to ****SPAM*****, but it's not doing that. It doesn't seem
> like SA is scanning the mail. I've already looked at the sun messaging logs
> and there's no indication of SA scanning the emails.
[...]
> Again, I'm not ignoring your suggestions or anyone else's. I'm extremely
> new to SA and to Sun/Oracle messaging services. I'm trying to understand
> and researching...
So all this might also depend on on that Sun/Oracle messaging services.
Ultimately, *how* is SA being called?
I don't know, cause I don't know that server. But similar to Amavis, it
might have configuration of its own, actually overriding the vanilla SA
configuration.
Again, enabling network tests should be your main goal for now. With
real incoming spam, you then should see rules fire like RCVD_IN_*,
URIBL_BACK and SURBL_*.
> It may be easy and obvious to you, but I'm here because
> i'm starting from scratch. I probably know less than a percent of what you
> know about SA. I'm trying to learn and get advice. If my newbie behavior
> annoys or frustrate you, I apologize, but as much as I appreciate that you
> are helping, but a little understanding of how new I am to this would be
> greatly appreciated. And if I still annoy or frustrate you, just ignore my
> post, helping is voluntary.
Crucial first point: Outline your OS, mail system, and how SA gets
called.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
