On Mon, 1 Sep 2014, Martin Gregorie wrote:

On Mon, 2014-09-01 at 03:17 -0400, Jude DaShiell wrote:
Messages with question marks and spaces have been showing up in my inbox
on another account.  To blacklist these [? ] would take care of those
characters in a Subject: line.  Would such a regular expression
effectively blacklist any message having just those two kinds of
characters in its Subject: line in any combination?

No: a regex along these lines
  /[? ]/
will hit all subject lines containing either a space or a question mark,
i.e. just about every subject line you'll ever see.

This one
  /[? ].*[? ]/
will only hit subjects with both characters in any order, but is
probably also far too general to use by itself. Make it a subrule (name
starts double underscore) and use a metarule to combine it with another
subrule that fires on something that usually only appears in spam and
you may have the basis of something more useful.

Maritin's proposed rule would hit a string that contained at least two
'?' or space characters as well as other characters. (EG: '?junk?' or
'this one hit').

If you want to be sure to hit subjects that contain ONLY question marks
and spaces (and at least one of each) it will take two sub-rules combined
into a metarule.
EG:
 header__SUBJECT_SPACE_QM       Subject =~ /(?:\? | \?)/
 header __SUBJECT_MORE_THAN_SP_QM       Subject =~ /[^? ]/
 meta SUBJECT_SPACE_QM  __SUBJECT_SPACE_QM && ! __SUBJECT_MORE_THAN_SP_QM

(untested)

FWIW, I would expect such a rule to have a limited useful life-span.
Now that it's been discussed here spammers will adapt their garbage to
avoid it (IE add one other kind of character to the subject, etc).

Spammers do monitor this list and just the act of disussing spam
characteristics can cause them to adapt their tactics.

--
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

Reply via email to