Re: svn commit: r125369 - /spamassassin/trunk/rules/70_scraped.cf

[Daniel Quinlan <qu...@pathname.com>]

jm@apache.org writes:

> bug 2243: MC_T_ALL_8BITS_795 MC_T_CONTENT_TYPE_8BITS_969 MC_T_DATE_8BITS_58 MC_T_FROM_8BITS_547 MC_T_MESSAGEID_8BITS_160 MC_T_MESSAGE_ID_8BITS_640 MC_T_RECEIVED_8BITS_302 MC_T_REPLY_TO_8BITS_339 MC_T_SUBJECT_8BITS_953 MC_T_TO_8BITS_996 MC_T_X_INFO_8BITS_340 MC_T_X_MAILER_8BITS_606 MC_T_X_MIMEOLE_8BITS_42 MC_T_X_MSMAIL_PRIORITY_8BITS_338 MC_T_X_ORIGINATING_EMAIL_8BITS_605 MC_T_X_ORIGINATING_HOST_8BITS_535 MC_T_X_PRIORITY_8BITS_253 MC_T_8BIT_HEADERS_615 MC_T_8BIT_HEADERS2_933 MC_T_8BIT_HEADERS3_903 MC_T_8BIT_HEADERS_38 MC_T_8BIT_HEADERS2_615 MC_T_8BIT_HEADERS3_501 MC_T_8BIT_HEADERS4_892 MC_T_8BIT_HEADERS5_805 MC_T_8BIT_HEADERS6_94 MC_T_8BIT_HEADERS7_838 MC_T_8BIT_HEADERS8_376

These really need a T_ prefix.  Swap the MC and the T?

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

Re: svn commit: r125369 - /spamassassin/trunk/rules/70_scraped.cf

[Loren Wilton <lw...@earthlink.net>]

> > they solved and I'm sick to death of them! >:(    Some sensible wrapping
> > code would be simpler, and save EVERYONE a lot of trouble.
>
> I don't think wrapping code is a solution at all.  Email is
> fundamentally 80 columns.  Names that go over about a quarter of that
> length mean that the descriptions are going to always wrap which is
> really gross.

FYI: To the best of my knowledge the wrapping code already exists for
descriptions.  At least, it existed and worked in 2.6x; I suppose it may
have been removed as an 'improvement' in 3.0.

As best I recall the indenting and alignment code was set for the longest
rule name up to some maximum length, and then any rule name longer than that
simply caused that single line to indent the description farther.  This was
simple, readable, and workable.

Line wrap also occurred on those lines that needed it.  This was not
necessarily related to the length of the name, since a rule could have a
long name and a short description.

I would be in favor of limiting rule names to 78 characters.  This will fit
conveniently in an 80 character mail line.

        Loren

Re: svn commit: r125369 - /spamassassin/trunk/rules/70_scraped.cf

[Daniel Quinlan <qu...@pathname.com>]

> Due to our absurd rule-name-length limitation policy ;), we cannot do the
> sensible thing, which would indeed be:

I don't think it's absurd as long as the language is POSIX, C, or "en".

>   MC_{bugnum}_{cmtnum}_{rulename}

I don't think cmtnum is needed if the rule has only been mentioned once,
but I'm okay with always including it if that's much simpler to
implement.

  T_{Bnnnn}_{rulename}[_{cmtnum}]

so you'd get:

  T_B4012_FOO_BAR

for most cases and:

  T_B4012_FOO_BAR_11

sometimes.

> but current naming scheme is:
>
>   MC_{rulename}_{rnd}
>
> where {rnd} is a 3-digit random number.   (the idea is that hopefully
> the rulename will be short enough to scrape past the length limit,
> since --lint is used to ensure rules are valid before they're checked
> into 70_scraped.cf.)

I definitely want to stick with "T_" for test rules.

> My current plans are to fix this by removing that stupid limit on rulename
> and description lengths.   They've caused WAY, *WAAAY* more problems than
> they solved and I'm sick to death of them! >:(    Some sensible wrapping
> code would be simpler, and save EVERYONE a lot of trouble.

I don't think wrapping code is a solution at all.  Email is
fundamentally 80 columns.  Names that go over about a quarter of that
length mean that the descriptions are going to always wrap which is
really gross.

I'd be fine with bumping up the limit by 2 (22+2) for T_ rules since
their final name will be 2 characters shorter.  I'd even be okay with
not having any limit on size for test rules.  I'm not okay with getting
rid of the length limit at this point.

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

Re: svn commit: r125369 - /spamassassin/trunk/rules/70_scraped.cf

[Daniel Quinlan <qu...@pathname.com>]

Actually, can I suggest a different naming convention?

  T_<bug number>_<test name>

For example,

  T_4081_FOO_BAR

Short and easy to look up.  Also, does your code handle naming for
new/overlapping/existing predicates for meta rules?

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/