Sean Straw wrote,
| Sanity check: I just want to check that a tweak that appears necessary
| shouldn't have any adverse effects.
| My problem: A spam got through yesterday, which I would have THOUGHT would
| have been caught by the above rule, but on closer evaluation:
|
| From: doa58(_at_)aol(_dot_)com (TF)
| Message-Id:
<199810131740WAA55015(_at_)aol(_dot_)com(_dot_)shortweb(_dot_)com>
|
| The domain portion STARTS with aol.com, rather than ends with it. GAAK!
| I've got to update the rules - I expect this was done just this way in
| order to foil basic checks similar to mine.
|
| I should be able to just change the messageid rule to include a closing
| bracket, but does anyone see a problem with doing this?
|
| * ! ^Message-[Ii][Dd]:.*aol\.com\>
Yes, there's a big problem. The ID that got through will still get through,
because \> will match a period. Don't escape the right-side angle bracket,
and since you don't have a `D' flag on that recipe, don't bother with
allowing for both cases, as procmail will do that for you:
* ! ^Message-Id:.*aol\.com>
You might even add a newline to the end in case a forged ID has an illegal
medial right chevron, which won't appear in mail that really came from AOL:
* ! ^Message-Id:.*aol\.com>$
Finally, I think you should check whether the character before "aol" is
an at-sign or a period in order to rule out things like gaol.com:
* ! ^Message-Id:(_dot_)*[(_at_)(_dot_)]aol\(_dot_)com>$
The period will not be magic inside brackets and won't need escaping.