On 20/04/12 20:17, Ned Slider wrote:
On 16/04/12 04:56, John Hardin wrote:
On Tue, 10 Apr 2012, John Hardin wrote:
On Tue, 10 Apr 2012, Thomas Johnson wrote:
On Tue, Apr 10, 2012 at 7:08 AM, Bowie Bailey <bowie_bai...@buc.com>
wrote:
> That sounds like it might be good rule-fodder. "subject", "Subject",
> and "SUBJECT" are possibly valid, but the other funky capitalizations
> might be worth a few points.
And how would one write a rule for that?
Check the __TO_EQ_FM header rules for ideas.
I'll take a shot at something this weekend if nobody does earlier.
I supplied this directly to Thomas earlier in the week, and it's in my
sandbox:
header SUBJ_ODD_CASE ALL =~
/\n(?!(?:Subject:|SUBJECT:|subject:))(?i:subject:)/sm
describe SUBJ_ODD_CASE Oddly mixed-case Subject: header
Hi John,
I have quite a few examples of these in my archives, and I confirm your
rule catches them - nice job :-)
Further, I note that to date the examples I have also appear to be
omitting a space between the end of "Subject:" and the start of the
actual subject text (examples on pastebin below). I wonder if this could
also be leveraged into a rule?
http://pastebin.com/xPf4XgJY
For example, I'd expect to see:
Subject: Re: Some text
and not:
Subject:Re:Some text
Hmm, not as easy to write a rule as I first thought as it would appear
that when using the header Subject, SA strips the leading white space
that we are trying to test for.
So I took inspiration from your rule above, and came up with:
header LOCAL_SUBJ_MISSPACED ALL =~ /\n(?i:^Subject:(?!($|\s)))/sm
describe LOCAL_SUBJ_MISSPACED Subject: missing whitespace
which appears to work as expected.
John - please could you explain the closing /sm as I'm unfamiliar with
it's usage?
Thanks.
