Re: [OT] good job guys with the anti-spam !

[Oleg Verych]

* Tue, 31 Jul 2007 23:40:11 +0200
>
[]
> eventhough people often write only when they have something to complain
> about, I for once would like to congratulate Matti and David, our mail
> admins, for the wonderful job they've done with the spams lately. This
> month, I might have seen maybe one or two instead of perhaps 30 per day
> earlier. While it did not bother me that much earlier, I can say that
> the list is more pleasant to read every day, and I think that's great.
>
> Kudos guys !
>
> Willy
>
> PS: please do not start another one of those long useless threads from now on
>

Instead let me share an idea and see what will happen (if any).
The mailing list policy:

1. sent mails must have in-reply-to (rfc2821 SHOULD) with valid, i.e.
   existing in archives, message-id;

2. otherwise sender gets response about creating new thread. Replying
   to that message will enable (1).

I don't know how performance of ever increasing anti-spam
rules/software grow vs message-id lookup will be affected.

Gmane shows good performance on load, which is times bigger than LKML's.
News server requires unique ids, so...

Ah, if spammers will become smart and will reply with appropriate headers
set up, everything will fall apart.

Finally. What i see:
* no spam,
* big patch-bombs in one thread (easy to skip)
* more order, if useless/obsolete footers removed, but such info is
  sent in (2).

* easy blacklisting if rules are not obeyed since day X

  Oh, no, don't say we value bug reports. Reports must be organized in
  other way, one of which i've described as development tracking system.
  Such e-mail policy is unavoidable part of this it. E-mail is everything
  it requires. Of course some html, css, javascript, perl guys will be
  free to implement any web-face they like. But story if git-web have
  something to learn instead.
--
-o--=O`C
 #oo'L O
<___=E M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/