[FFmpeg-devel] Filtering clueless-user spam from the lists

Rich Felker dalias
Wed Jan 23 22:47:15 CET 2008

On Wed, Jan 23, 2008 at 08:45:49PM +0000, M?ns Rullg?rd wrote:
> Rich Felker <dalias at aerifal.cx> writes:
> > On Wed, Jan 23, 2008 at 08:06:19PM +0000, M?ns Rullg?rd wrote:
> >> > As humorous as this idea is, broken threading and thread hijacking are
> >> > 100% detectable algorithmically. We can leave the SWAT team the
> >> > tougher tasks that actually require human intervention. :)
> >> 
> >> While automated detection without false negatives seems easy enough,
> >> avoiding false positives is decidedly more difficult.  As has been
> >> shown, there are legitimate cases that would have been flagged by your
> >> procmail rules.
> >
> > I would not consider using bogus characters instead of > as a
> > legitimate case, but if others disagree, we can include | and other
> > stuff like that in the regex..
> Annoying as it may be, it is not sufficient reason to discard a
> message.

I was thinking of an error message "fix your mailer" instead of simply
discarding, for all offenses. But I have no objection to allowing
non-> quote characters if others want to. My procmail rules were
simply intended as a base proposal to work from, not any final demand.

> > As for Re[2]: and stuff, how about using re[:=[] -- this covers
> > quoted-printable mess as well. It would probably be a good idea to
> > allow all base64 encoded subjects too. Ideally procmail would decode
> > headers before matching them but that's apparently too much to ask
> > for.. :(
> In other words, you don't have a bomb-proof solution, just as I
> suspected.

My proposal errs on the side of avoiding false positives, i.e.
messages that break the rules could potentially get through if the
mailer base64-encodes the subject. However, as far as I know, the
regular offending mailers do not base64-encode subjects.


More information about the ffmpeg-devel mailing list