All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaco Kroon <jaco@kroon.co.za>
To: kernel-janitors@vger.kernel.org
Subject: Re: [KJ] spam on kj ml
Date: Thu, 05 Jul 2007 14:08:34 +0000	[thread overview]
Message-ID: <468CFB62.4020900@kroon.co.za> (raw)
In-Reply-To: <468CB2D8.9060904@bfs.de>

Rene Herman wrote:
> On 07/05/2007 02:11 PM, pradeep singh wrote:
> 
>>> > 2. Stop non subscribers from sending any mail to the list.
>>>
>>> No, do not do that. As said, just make it _moderated_ for 
>>> non-subscribers. On occasion a thread may want to be crossposted to
>>> linux-kernel and the subscribers there expect open access. Don't trade
>>> spam annoyances for spam-warring annoyances. As a moderator, you can
>>> elect to add From addresses to a approves/denies database or, better,
>>> just accept them manually and possibly send the poster a private
>>> message asking to subscribe.
>>>
>> Fair enough, let non-subscribers post then.
>> Why even send a private message to subscribe then i guess?
> 
> Moderation introduces an inevitable delay even if with enough moderators 
> it wouldn't be a large delay. Still an undesirable thing though so if I 
> see from a moderated message that it's destined specifically for the 
> alsa-devel list and is not one where it's just CCed as "catch-all sound 
> thing CC" I tend to reply to the poster privately informing of the 
> subscribtion policy and pointing out the delay. Ofcourse, fewer 
> non-subscriber posts also means fewer things to moderate...

Yes, it introduces a delay.  So here are a few further suggestions:

use dns blacklists to filter out any IP ranges within a DUL.  This 
elimates a _lot_ of spam.  Also, there are known "bad" servers out 
there, DNS BLs can also help filtering these out.  These checks are 
pretty cheap, and it's accuracy is just about perfect (most of the 
time).  I personally add a server to a local allow list periodically 
when I find that ISPs get blacklisted, this is usually done upon request 
when an email is sent to postmaster@ for the domain in question and I've 
talked to the ISP to make sure that they shouldn't be on the list. 
Users complains to their ISPs pretty quickly when mail starts bouncing.

Perform sender-callout verifications.  This filters out a _lot_ of SPAM.

Block bounces from going to the list (A lot of spam seem to have a NULL 
return path but then puts an address in the From: header).  Bounces have 
no reason to go to the list as the list return path has a -bounces appended.

Checks on the email addresses listed in headers like To: and From: to 
ensure they are formatted correctly.  This also seems to be highly 
effective, and not that costly.

Greylisting?  Annoying, but it mostly helps to filter out many of the 
"drop and run" spam bots (although, these generally tend to only help on 
the DUL ranges anyway).

If after that we still get too much spam, then set up spamassassin as 
well, get some extra rules from SARE, my SA seems to function well with 
the reject required score set to 7, in the six months where I trialled 
it I didn't get many legit messages going over that, and those that did 
I really didn't want to receive anyway (receive and forward type spam). 
  And were always HTML-based mail (which we are against anyway).

Note, none of these checks rely on spamassassin.  Spamassassin, whilst 
pretty effective is a resource consumer like few others things I've 
worked with.  Try to filter out as much stuff as possible _before_ 
passing messages to spamassassin.

>>> As said, you can hand moderator privileges out as the only 
>>> administrative
>>> list power, so just gather up a few volunteers. There should be 
>>> enough on
>>> the kernel janitors list I believe (I'm not).
>>
>> This can be tricky IMHO. How you identify whom to give priviliges. What
>> are the rules? etc etc 
> 
> You ask who wants to and would like the more active members to 
> volunteer. The rules would be "if (spam) reject(); else accept();" where 
> "spam" is pretty tightly defined. Remember -- the moderators would've 
> been put in place just as human spam filters, not as topic police so the 
> rules are pretty darn simple.

I would keep this as a last step.  Or simply put a "human check" in 
place, ie, if this person hasn't sent mail to the list before, just send 
him/her an email, asking to respond to a link, after clicking this link, 
the email is allowed to pass through.  Not sure if either ezlm, 
majordomo or mailman supports this out of the box though.

>>> > 4. Have a spamassasin server up[this may be not easy] and keep it 
>>> updated.

Yes, sa-update is not that difficult to put in a cron job on a daily 
basis, and to just restart spamd when it's done.

>>> Ofcourse, a first run through a spam-filter where everything that is 
>>> marked as spam with a high enough (define yourself..) probability
>>> doesn't even end up in the moderation queue is good.
>>>
>>> You'd be surprised how easy it is to spot the remaining spam for a human
>>> from the subjects alone -- ie, moderators can deal with the remaining 
>>> stuff  with ease.
>>
>> Same point applies here.
>> identification of the moderators and subswquent chaos like, what if X
>> moderator remains inactive for a long period...
>> all boils down to some rules. right?
> 
> Rule 1 -- trust people to get it right unless proven otherwise. I 
> believe you overestimate the amount of trouble non-subscriber moderation 
> would be. kernel-janitors sees less traffic than alsa-devel, and  _much_ 
> less from non-subscribers (it's not a topic list to CC wen you're not 
> doing specific janitor stuff) and if some of the more active articipants 
> here would volunteer I believe things should readily work themselves out.

I agree, however, stay away from human intervention as far as possible. 
  I used to do this for our local LUG ... it eventually becomes a full 
time job in it's own right.  Also, even with notifications to the 
moderators, what happens if none of them looks for three days?  No, 
imho, rather just filter as much of the crap automatically as possible, 
and let the rest come.  It should be much reduced, if it's still too 
much, then we can take further action.

Jaco
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/kernel-janitors

  parent reply	other threads:[~2007-07-05 14:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-05  8:59 [KJ] spam on kj ml walter harms
2007-07-05  9:15 ` maximilian attems
2007-07-05  9:50 ` pradeep singh
2007-07-05  9:51 ` Jaco Kroon
2007-07-05  9:54 ` Rene Herman
2007-07-05 10:20 ` pradeep singh
2007-07-05 10:22 ` pradeep singh
2007-07-05 11:11 ` walter harms
2007-07-05 11:13 ` Rene Herman
2007-07-05 12:19 ` maximilian attems
2007-07-05 12:23 ` pradeep singh
2007-07-05 12:54 ` Rene Herman
2007-07-05 14:08 ` Jaco Kroon [this message]
2007-07-05 14:53 ` Randy Dunlap
2007-07-06  0:28 ` David Miller
2007-07-06  2:03 ` Arnaldo Carvalho de Melo
2007-07-06  3:53 ` pradeep singh
2007-07-06  3:56 ` pradeep singh
2007-07-06  4:43 ` Arnaldo Carvalho de Melo
2007-07-06  4:56 ` Arnaldo Carvalho de Melo
2007-07-06  4:59 ` pradeep singh
2007-07-06  5:06 ` Alexey Dobriyan
2007-07-06  5:13 ` pradeep singh
2007-07-06 19:46 ` Nish Aravamudan
2007-07-06 20:05 ` Alexey Dobriyan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=468CFB62.4020900@kroon.co.za \
    --to=jaco@kroon.co.za \
    --cc=kernel-janitors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.