You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2005/01/20 19:25:53 UTC
removing the rule-name-length limit (was Re: svn commit: r125722)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> On Thu, Jan 20, 2005 at 12:36:29AM -0800, Daniel Quinlan wrote:
> > -1 on this change, the new formatting is terrible compared to the old
> > formatting.
ah, I didn't post examples of what the new formatting looks like --
here it is in "report_safe 1":
0.1 FROM_HAS_MIXED_NUMS From: contains numbers mixed in with letters
1.0 THIS_IS_A_VERY_LONG_RULE_NAME A very very long rule name and this is
a very very long description lorem ipsum
0.2 FROM_ENDS_IN_NUMS From: ends in numbers
2.5 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
[83.208.49.79 listed in sbl-xbl.spamhaus.org]
or in "report_safe 0" header mode:
X-Spam-Report:
* 0.1 FROM_HAS_MIXED_NUMS From: contains numbers mixed in with letters
* 1.0 THIS_IS_A_VERY_LONG_RULE_NAME A very very long rule name and
* this is a very very long description lorem ipsum
* 0.2 FROM_ENDS_IN_NUMS From: ends in numbers
* 2.5 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
* [83.208.49.79 listed in sbl-xbl.spamhaus.org]
This is entirely consistent with what the test_log stuff does -- cf.
RCVD_IN_XBL hits above, so I can't see why it's "terrible". If it's
terrible, maybe we should fix test_log too ;)
> > It's just not all that hard to name and describe rules with
> > the limits. Yes, it's a bit more work when writing rules, but easily
> > readable reports are far more important.
Descriptions -- "Relay HELO'd using suspicious hostname (IP addr 1)",
naming rules within the limits -- let's just say "FROM_WEBMAIL_END_NUMS6".
Neither of these are comprehensible, let alone easily readable.
Duncan Findlay writes:
> I'm also -1. I believe I wrote most of that formatting stuff and we
> agreed on it at the time (I think...). If we're going to change it, we
> need to come up with an alternative that's just as readable...
Now, I can't find any agreement in bugzilla that those limits
should have been imposed. ;)
(I can find bug 1978, which was the original proposition, but has no
resolution -- last comment is Theo noting that lint-rules-from-freqs was
modified to do it. Then, later, bug 3093, which suggests "I can't see
any reason to not" (have --lint catch > 22 char rulenames) -- and the code
was also added to Conf.pm.)
There was a suggestion to use wrapping instead, but that didn't happen. It
appears that this was implemented before we added Text::Wrap usage for the
"content preview" -- since we now already have that, using wrapping is now
trivial.
our current translations have the following description lengths:
German: under 50 chars: 201 too long: 380: 65% too long
French: 236 158: 40% too long
Dutch: 476 113: 19% too long
Polish: 275 107: 28% too long
in other words *none* of our translations yet implement the 50 character
limit (bug 4007, bug 4040). In bug 4040, Klaus notes that he doubts it's
*possible* to bring German descriptions under 50 characters anyway.
In addition, there's been traffic on the users list, and in bug 3340,
noting that "make test" fails with add-on rulesets. Now, we could kludge
around that by adding new command-line parameters until we look like gcc,
or we could berate people writing third-party rules, or we could change
the test suite to not run --lint. Alternatively, we could remove the
limits that cause this frequent confusion.
In other words, this change just makes *using* SpamAssassin a little
easier, even if it isn't as "pure" as enforcing strict limits. It also
makes developing rules easier (or less drudgery), it makes the automc
stuff easier to develop and use, and it makes translation easier to
develop and use.
So, I suggest we try to come up with a proposal that:
1. allows German-language 70-character descriptions ;)
2. allows long enough rule names to support the additional 13 characters
that should be added to each rule name in automc (bug ID, comment number,
"T_MC_" prefix, and underscores between them, ie.
"T_MC_rulename_2243_13"). right now, we avoid this more-or-less by just
adding 7 chars, "MC_rulename_9Ac". But still, "make test" and buildbot
will fail, if a bug with a rule name of longer than 15 characters in it is
mass-checked.
- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Exmh CVS
iD8DBQFB7/exMJF5cimLx9ARAlJIAJ4przWUZBhA9f+8Pso9kQBffIl7FACfQcp3
lRGXZICaDKvLY+cPqIEwv0o=
=WuPo
-----END PGP SIGNATURE-----
Re: removing the rule-name-length limit (was Re: svn commit: r125722)
Posted by Theo Van Dinter <fe...@kluge.net>.
On Thu, Jan 20, 2005 at 04:53:51PM -0500, Duncan Findlay wrote:
> Sure. IIRC, 22 was somewhat arbitrary, but worked well given the
> maximum length of lines and length of most descriptions.
As I recall, it was 22 for rule name, plus 50 for description == 72. Add in
another couple for spacing, the "*", etc, and you were near the 78/80 length
for which we were aiming.
--
Randomly Generated Tagline:
"The Mets were great in 'sixty eight,
The Cards were fine in 'sixty nine,
But the Cubs will be heavenly in nineteen and seventy."
-- Ernie Banks
Re: removing the rule-name-length limit (was Re: svn commit: r125722)
Posted by Duncan Findlay <du...@debian.org>.
On Thu, Jan 20, 2005 at 12:43:52PM -0800, Justin Mason wrote:
> OK -- I'm happy to go for:
>
> - relax the description limit to allow 2-line descs
> - keep 22-char limit on rulenames
> - except for T_-prefix names
--lint should really be treating these "limits" as suggestions, not
errors. Like "hey, that's a bit long and it might look funny" not
"Your description is too long -- how dare you be so verbose".
That was certainly my intention when I implemented it, at least.
> That still leaves the problem of a few unreadable rule names, like
> FROM_WEBMAIL_END_NUMS6, though. I'd like to relax the rulename
> limit a *little* -- 28 chars maybe?
Sure. IIRC, 22 was somewhat arbitrary, but worked well given the
maximum length of lines and length of most descriptions.
--
Duncan Findlay
Re: removing the rule-name-length limit (was Re: svn commit: r125722)
Posted by Daniel Quinlan <qu...@pathname.com>.
jm@jmason.org (Justin Mason) writes:
> ah, I didn't post examples of what the new formatting looks like --
> here it is in "report_safe 1":
The example I posted *was* "report_safe 1", so the new formatting does
not look like that at all.
> Now, I can't find any agreement in bugzilla that those limits
> should have been imposed. ;)
Nice try, but today's code changes are the things that get votes, not
code changes from 2 years ago...
> our current translations have the following description lengths:
>
> German: under 50 chars: 201 too long: 380: 65% too long
> French: 236 158: 40% too long
> Dutch: 476 113: 19% too long
> Polish: 275 107: 28% too long
>
> in other words *none* of our translations yet implement the 50 character
> limit (bug 4007, bug 4040). In bug 4040, Klaus notes that he doubts it's
> *possible* to bring German descriptions under 50 characters anyway.
I'm more willing to discuss increases to description lengths (given the
expansion factor of many languages over English) than rule name lengths
as I think carrying over to two lines does not render reports that
unreadable. However, I think increasing the rule name length from 22 is
too much.
If I look at all of the rule name lengths from the custom rule sets
(including a French one) on the Wiki, 9992 rules have a length of 22 or
lower and only 16 rules have a length of 23 or 24 (none are longer than
24).
> 1. allows German-language 70-character descriptions ;)
German typically requires approximately 25-35% the length of English, so
changing the limit to 65 or 70 characters would be fine with me.
> 2. allows long enough rule names to support the additional 13 characters
> that should be added to each rule name in automc (bug ID, comment number,
> "T_MC_" prefix, and underscores between them, ie.
> "T_MC_rulename_2243_13"). right now, we avoid this more-or-less by just
> adding 7 chars, "MC_rulename_9Ac". But still, "make test" and buildbot
> will fail, if a bug with a rule name of longer than 15 characters in it is
> mass-checked.
Just ignore the limits for T_ rules. That's fine with me.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/