You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Alex <my...@gmail.com> on 2011/05/21 02:51:50 UTC
Rule dependency problems with v3.3.2-r929478
Hi,
I'd like to use Adam's khopesh rules, but there seems to be many
dependency problems, and wondered if someone could help determine what
rules I might be missing to satisfy the dependency problems. I have
the following channels installed in addition to the stock rules:
- khop-blessed_sa_khopesh_com
- khop-bl_sa_khopesh_com
- khop-dynamic_sa_khopesh_com
- khop-general_sa_khopesh_com
- khop-sc-neighbors_sa_khopesh_com
- sought_rules_yerp_org
- updates_spamassassin_org
I'm also using a few of John's rules, including the advance_fee,
fillform, and lotsa_money. I think some of his rules reference the
missing khop rules.
When trying to lint the rules, I receive the following:
__KHOP_DNSWLD has undefined dependency 'RCVD_IN_BSP_TRUSTED'
__KHOP_DNSWLD has undefined dependency 'RCVD_IN_SSC_TRUSTED_COI'
KHOP_DYNAMIC has undefined dependency '__5_SUBDOM'
KHOP_RCVD_TRUST has undefined dependency 'RCVD_IN_BSP_TRUSTED'
KHOP_RCVD_TRUST has undefined dependency 'RCVD_IN_SSC_TRUSTED_COI'
KHOP_DNSBL_ADJ has undefined dependency 'RCVD_IN_BRBL_UNFAIR'
ADVANCE_FEE_2_NEW_FORM has undefined dependency '__HDRS_LCASE'
TO_NO_BRKTS_NORDNS_HTML has undefined dependency '__UPPERCASE_URI'
TO_NO_BRKTS_PCNT has undefined dependency '__LONGLINE'
KHOP_DIALUP has undefined dependency '__GREYLISTED'
__INR_AND_NO_REF has undefined dependency '__XM_IMAIL'
__INR_AND_NO_REF has undefined dependency '__XM_APPLEMAIL'
__INR_AND_NO_REF has undefined dependency '__XM_COMMUNIG'
__INR_AND_NO_REF has undefined dependency '__XM_EDMAX'
__INR_AND_NO_REF has undefined dependency '__XM_ELM'
__INR_AND_NO_REF has undefined dependency '__XM_EMUMAIL'
__INR_AND_NO_REF has undefined dependency '__XM_EXMH'
__INR_AND_NO_REF has undefined dependency '__XM_LOTUSN'
__INR_AND_NO_REF has undefined dependency '__XM_MAILCITY'
__INR_AND_NO_REF has undefined dependency '__XM_MAILSMITH'
__INR_AND_NO_REF has undefined dependency '__XM_MSCDO'
__INR_AND_NO_REF has undefined dependency '__XM_MSOUT'
__INR_AND_NO_REF has undefined dependency '__XM_MIMETOOLS'
__INR_AND_NO_REF has undefined dependency '__XM_OPERA6'
__INR_AND_NO_REF has undefined dependency '__XM_PEGASUS'
__INR_AND_NO_REF has undefined dependency '__XM_QUALCOM'
__INR_AND_NO_REF has undefined dependency '__UA_IMP'
__INR_AND_NO_REF has undefined dependency '__UA_MSOEMAC'
__INR_AND_NO_REF has undefined dependency '__UA_MSENTOUR'
__INR_AND_NO_REF has undefined dependency '__UA_OPERA7'
Are these perhaps old rules that I shouldn't be using?
Thanks for any ideas.
Best regards,
Alex
Re: Rule dependency problems with v3.3.2-r929478
Posted by John Hardin <jh...@impsec.org>.
On Mon, 23 May 2011, Alex wrote:
>>> Is there a method for separating the experimental rules from those
>>> that are relatively safe to use in production?
>>
>> Nightly masschecks. Apparently we are short on recent SPAM, so the rules
>> are not being auto-promoted. If you have a good collection of hand-graded
>> SPAM, you should get set up to submit nightly masschecks so that we can
>> auto-promote the good rules.
>
> I see. So the generally adopted way for using those rules is that
> people run their own masschecks using the public corpa, then based on
> rules that they think are acceptable promote the rules to production?
No, the standard way to use dev sandbox rules is via sa-update. Let the
infrastructure do the testing and promotion.
Non-sandbox third party rules would be a matter of local testing at low
scores, performance evaluation, and score adjustment based on the results.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
An entitlement beneficiary is a person or special interest group
who didn't earn your money, but demands the right to take your
money because they *want* it. -- John McKay, _The Welfare State:
No Mercy for the Middle Class_
-----------------------------------------------------------------------
165 days since the first successful private orbital launch (SpaceX)
Re: Rule dependency problems with v3.3.2-r929478
Posted by Jari Fredriksson <ja...@iki.fi>.
23.5.2011 16:01, Alex kirjoitti:
>
> Can any amount of information be changed in the email for anonymity?
>
The masscheck operates on your computer, on your data. It does not send
the email corpus anywhere, only couple small logfiles having the results
per rule.
--
All the troubles you have will pass away very quickly.
Re: Rule dependency problems with v3.3.2-r929478
Posted by Alex <my...@gmail.com>.
Hi,
>> Is there a method for separating the experimental rules from those
>> that are relatively safe to use in production?
>
> Nightly masschecks. Apparently we are short on recent SPAM, so the rules
> are not being auto-promoted. If you have a good collection of hand-graded
> SPAM, you should get set up to submit nightly masschecks so that we can
> auto-promote the good rules.
I see. So the generally adopted way for using those rules is that
people run their own masschecks using the public corpa, then based on
rules that they think are acceptable promote the rules to production?
I have probably as many as 100k spams per day that I may be able to
contribute, but not the significant amount of time that would be
involved in manually inspecting each one. Would it help to inspect a
percentage of them with, say, scores above 10, and submit those?
Can any amount of information be changed in the email for anonymity?
Is there a place where the rules are located that have passed at least
one other person's masschecks?
Thanks,
Alex
Re: Rule dependency problems with v3.3.2-r929478
Posted by John Hardin <jh...@impsec.org>.
On Mon, 23 May 2011, Daniel McDonald wrote:
> On 5/21/11 8:52 PM, "Alex" <my...@gmail.com> wrote:
>
>> Is there a method for separating the experimental rules from those
>> that are relatively safe to use in production?
>
> Nightly masschecks. Apparently we are short on recent SPAM, so the rules
> are not being auto-promoted. If you have a good collection of hand-graded
> SPAM, you should get set up to submit nightly masschecks so that we can
> auto-promote the good rules.
Another problem is that Alex is referring to 3.3.2 while the dev sandboxes
on trunk and the nightly masscheck and autopromotion is for 3.4. The 3.3.x
rules are stale as of mid-december 2010 and since there isn't (as far as I
am aware) a masscheck running for the 3.3 branch, and the dev sandboxes in
the 3.3 branch aren't being updated, the situation won't improve unless
some specific manual attention is given.
I _think_ the 3.4 rules updates being produced _should_ be safe for 3.3.x,
but I am not positive.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
An entitlement beneficiary is a person or special interest group
who didn't earn your money, but demands the right to take your
money because they *want* it. -- John McKay, _The Welfare State:
No Mercy for the Middle Class_
-----------------------------------------------------------------------
165 days since the first successful private orbital launch (SpaceX)
Re: Rule dependency problems with v3.3.2-r929478
Posted by Daniel McDonald <da...@austinenergy.com>.
On 5/21/11 8:52 PM, "Alex" <my...@gmail.com> wrote:
> Hi,
>
>>> I'm also using a few of John's rules, including the advance_fee,
>>> fillform, and lotsa_money. I think some of his rules reference the
>>> missing khop rules.
>>>
>>> When trying to lint the rules, I receive the following:
>>>
>>> ADVANCE_FEE_2_NEW_FORM has undefined dependency '__HDRS_LCASE'
>>
>> That's in my sandbox so you shouldn't be getting dependency problems with
>> it.
>
> It's in 20_misc_testing.cf. I wasn't sure if that was safe for production?
>
>>> Are these perhaps old rules that I shouldn't be using?
>>
>> All of those are subrules in the current trunk sandbox. They shouldn't be
>> generating dependency problems.
>
> Is there a method for separating the experimental rules from those
> that are relatively safe to use in production?
Nightly masschecks. Apparently we are short on recent SPAM, so the rules
are not being auto-promoted. If you have a good collection of hand-graded
SPAM, you should get set up to submit nightly masschecks so that we can
auto-promote the good rules.
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: Rule dependency problems with v3.3.2-r929478
Posted by Alex <my...@gmail.com>.
Hi,
>> I'm also using a few of John's rules, including the advance_fee,
>> fillform, and lotsa_money. I think some of his rules reference the
>> missing khop rules.
>>
>> When trying to lint the rules, I receive the following:
>>
>> ADVANCE_FEE_2_NEW_FORM has undefined dependency '__HDRS_LCASE'
>
> That's in my sandbox so you shouldn't be getting dependency problems with
> it.
It's in 20_misc_testing.cf. I wasn't sure if that was safe for production?
>> Are these perhaps old rules that I shouldn't be using?
>
> All of those are subrules in the current trunk sandbox. They shouldn't be
> generating dependency problems.
Is there a method for separating the experimental rules from those
that are relatively safe to use in production?
Maybe there is a list of files that can be safely checked out regularly?
Thanks again,
Alex
Re: Rule dependency problems with v3.3.2-r929478
Posted by John Hardin <jh...@impsec.org>.
On Fri, 20 May 2011, Alex wrote:
> I'm also using a few of John's rules, including the advance_fee,
> fillform, and lotsa_money. I think some of his rules reference the
> missing khop rules.
>
> When trying to lint the rules, I receive the following:
>
> ADVANCE_FEE_2_NEW_FORM has undefined dependency '__HDRS_LCASE'
That's in my sandbox so you shouldn't be getting dependency problems with
it.
> TO_NO_BRKTS_NORDNS_HTML has undefined dependency '__UPPERCASE_URI'
Ditto.
> TO_NO_BRKTS_PCNT has undefined dependency '__LONGLINE'
mmartinec/20_misc.cf
> Are these perhaps old rules that I shouldn't be using?
All of those are subrules in the current trunk sandbox. They shouldn't be
generating dependency problems.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
It is criminal to teach a man not to defend himself when he is the
constant victim of brutal attacks. -- Malcolm X (1964)
-----------------------------------------------------------------------
162 days since the first successful private orbital launch (SpaceX)