Hi John,
Did a
$grep -inr __HAS_SENDER ./
in the source. No hits, what-so-ever.
On Mon, Sep 16, 2013 at 11:37 PM, John Hardin <jhar...@impsec.org> wrote:
> On Mon, 16 Sep 2013, Abhijeet Rastogi wrote:
>
>> Hi John,
>>
>> I'm sure you're pretty clear on explaining it but as a newbie I'm
>> facing issues. My concern still exists. I could see loglines like:
>>
>> Sep 16 14:41:51.607 [3999] dbg: rules: ran header rule __HAS_SENDER
>> ======> got hit: "<YES>"
>> Sep 16 14:41:51.606 [3999] dbg: rules: ran header rule __HAS_TO
>> ======> got hit: "<YES>"
>> Sep 16 14:41:51.605 [3999] dbg: rules: ran header rule __HAS_ERRORS_TO
>> ======> got hit: "<YES>"
>> Sep 16 14:41:51.604 [3999] dbg: rules: ran header rule __HAS_XMAIL
>> ======> got hit: "<YES>"
>>
>> But, I don't see that defined anywhere (grepped them against 3.3
>> version from svn). Also, in the install (CentOS5), I couldn't find it
>> either (Checked both /usr/share/spamassassin and
>> /etc/mail/spamassassin). So, what's the deal with these, where are
>> these defined?
>
>
> Did you search subdirectories as well? sa-update updates rules into
> subdirectories.
>
>
>> I would really appreciate a reply here. Thanks
>>
>>
>> On Mon, Sep 16, 2013 at 10:46 PM, John Hardin <jhar...@impsec.org> wrote:
>>>
>>> On Mon, 16 Sep 2013, Abhijeet Rastogi wrote:
>>>
>>>> Hi John,
>>>>
>>>> Thanks for the reply. I could get the above said rule as a "meta" one.
>>>> Thanks for that.
>>>
>>>
>>>
>>> Apologies if that came across as condescending, I was just trying to be
>>> thorough.
>>>
>>>
>>>> One more thing I was hoping you could help me with.
>>>>
>>>> Can you explain as to what's the difference between rules under
>>>> "./rules" and under "./rulesrc/sandbox/" directory?
>>>
>>>
>>>
>>> The "rules" directory is rules that are published no matter what. That's
>>> the
>>> "static" ruleset, the base rules that everything can depend on to be
>>> present, and rules that have always performed well.
>>>
>>> The stuff under the sandbox directories is more dynamic. The rules there
>>> are
>>> run through the nightly masscheck process, and if they perform well
>>> enough
>>> they get published. They're more "dynamic", in that older rules that stop
>>> performing well against current spam (as represented by the masscheck
>>> corpora) may stop being published, and may automatically start being
>>> published again if the corpora starts containing that type of spam again.
>>>
>>>
>>>> The reason I want to know this is because I've a requirement where I
>>>> want
>>>> to disable everything (meaning *all* rules) except a locally hosted
>>>> URIBL).
>>>> I was hoping that I could do this by adding the output of the below
>>>> command.
>>>> (running in the source code).
>>>>
>>>> cat rules/*.cf | grep -E '^(header|body)' | awk '{print $2}' | sed
>>>> 's/^/score /' | sed 's/$/ 0/'
>>>>
>>>> But, to my surprise, it didn't help. I still had various checks stull
>>>> getting applied like __HAS_TO, __HAS_ERRORS_TO etc etc. Any idea as to
>>>> what can be done about that?
>>>
>>>
>>>
>>> As __subrules don't have a score, their execution cannot be disabled by
>>> setting their score to zero.
>>>
>>> If you want to override the default behavior of SA to that degree, it's
>>> easier to change the config directory that SpamAssassin and spamd use
>>> with
>>> the -c option, so that none of the base rule files are read in the first
>>> place. You'll need to provide some minimal set of config files in
>>> whatever
>>> custom config directory you specify in order to get SA to run, but that
>>> will
>>> avoid all the extra default stuff you don't seem to want.
>>>
>>> I've never customized SA to that degree so there may be some pitfalls in
>>> this that I'm not aware of - somebody else will probably say something if
>>> there's other stuff you need to be aware of.
>>>
>>>
>>>
>>>> On Mon, Sep 16, 2013 at 10:07 PM, John Hardin <jhar...@impsec.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Mon, 16 Sep 2013, Abhijeet Rastogi wrote:
>>>>>
>>>>>> Problem is, how do I know that a certain rule like __RCVD_IN_NJABL is
>>>>>> a base rule for others?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The two leading underscores in the rule name indicate that the rule, by
>>>>> itself, is not assigned a score, thus, by itself, does not affect the
>>>>> overall score of the message at all. It must appear in a "meta" rule,
>>>>> possibly with other rules, before it can be assigned a score and affect
>>>>> the
>>>>> overall message score. So, at the most basic level, any rule having a
>>>>> name
>>>>> that starts with two underscores is _inherently_ a base for other
>>>>> rules.
>>>>>
>>>>> In order to determine *which* rules it's a base for, you have to look
>>>>> for
>>>>> that rule name in the config files. This isn't too easy to do online,
>>>>> you
>>>>> pretty much have to grep the rules files in a local install.
>
>
> --
> John Hardin KA7OHZ http://www.impsec.org/~jhardin/
> jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
> key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
> -----------------------------------------------------------------------
> WSJ on the Financial Stimulus package: "...today there are 700,000
> fewer jobs than [the administration] predicted we would have if we
> had done nothing at all."
>
> -----------------------------------------------------------------------
> Tomorrow: the 226th anniversary of the signing of the U.S. Constitution
--
Regards,
Abhijeet Rastogi (shadyabhi)
http://blog.abhijeetr.com
