Subject: Disposing of spam

From: Melinda Shore <[email-masked]>
Date: Fri, 30 Jan 2004 16:00:30 -0500

I never saw a response to the question about a more efficient
way to dispose of queued up spam under mailman.  It's really
getting unmanageable.

Melinda

---

From: Joe Macker <[email-masked]>
Date: Fri, 30 Jan 2004 16:29:23 -0500

>way to dispose of queued up spam under mailman.  It's really

Ditto this query?

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 30 Jan 2004 22:45:03 +0100

Ditto this query? 

This came up before. A solution for mailman is to run from cron a
perl script, such as http://www.alvestrand.no/software/mailman.pl

	jaap

---

From: Radia Perlman <[email-masked]>
Date: Fri, 30 Jan 2004 14:14:59 -0800

Perhaps sharing of the load...having a bunch of people that act
as filters for the mailing list, and delete spam. So perhaps for a few
days each month, a volunteer looks through the stack of stuff that
arrived during that time and decides what to allow through. If it's
only for a few days a month, the load on any one volunteer might be
manageable.

Radia

---

From: Aaron Falk <[email-masked]>
Date: Fri, 30 Jan 2004 14:37:08 -0800

John Heidemann, a colleague of mine, has written a perl script that 
deletes all pending messages.  It's "Just A Hack That Works For Me, not 
polished code."

I've found it reliable and _very_ useful in deleting the 500+ msgs in 
dccp and pilc queues.

See http://www.isi.edu/~johnh/SOFTWARE/MAILMAN/index.html

Kudos & thanks to [email-masked].

--aaron

---

From: Joe Macker <[email-masked]>
Date: Fri, 30 Jan 2004 17:47:47 -0500

>only for a few days a month, the load on any one volunteer might be

Radia:

Not a bad thought...but the web interface seems to grind to a halt.

I've tried to go in periodically and do the proper sorting/deletion duties, 
but it has actually frozen up for long periods of time submitted a 
queue delete,etc request. Often causing me to quit the session in frustration.
I'd love to pass this on to volunteers, but they would probably be equally 
frustrated.  This only happened once the queued messages grew to a 
significant quantity.

In my opinion, the mailman web "queued message management" 
interface is not efficiently-designed for
large numbers of bounced entry perusal and deletion/acceptance.

A scripting/sweeping approach would probably be better.

Do list managers have shell access at the ietf.org server? If so,
I have not know about or used it.  I'd like to run the recommended perl scripts.

-Joe

---

From: David Meyer <[email-masked]>
Date: Fri, 30 Jan 2004 14:52:24 -0800

Really, is there a technical (or possibility
	administrative) reason why we can't run something
	standard (like spamassassin) in front of these lists? 

	Dave

---

From: Aaron Falk <[email-masked]>
Date: Fri, 30 Jan 2004 14:53:57 -0800

> I have not know about or used it.  I'd like to run the recommended 

Joe-

The script I sent out can be run from anywhere if provided with the 
admin URL and password.  It basically automates the clicking of the 
discard button on the web page.  (crude but effective)

--aaron

---

From: Ralph Droms <[email-masked]>
Date: Fri, 30 Jan 2004 17:58:38 -0500

I've used http://www.waider.ie/hacks/workshop/perl/mailman.pl

Seems to work OK; might take some tweaking of the rules for your specific
application.  Early on I checked, and didn't see any false positives.

- Ralph

---

From: Joe Macker <[email-masked]>
Date: Fri, 30 Jan 2004 18:06:36 -0500

OK will try.
At 05:53 PM 1/30/2004, Aaron Falk wrote:

>The script I sent out can be run from anywhere if provided with the admin URL and password.  It basically automates the clicking of the discard button on the web page.  (crude but effective)
>
>--aaron

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 31 Jan 2004 01:20:23 +0100

> application.  Early on I checked, and didn't see any false positives.

Every now and then there's a genuine submission from a non-subscriber which
shouldn't be automatically discarded, which would be a slight problem with
a scripted discard approach.

But really, manual handling of spam should be an exception rather than the
rule.  What I'd really like to see is that Mailman rejects could be sent on
as input to the spamassassin bayesian filters, to train them to see similar
ones as spam.  Judging from the behaviour of spamassassin with proper
bayesian filter training on my personal systems, that should very swiftly
decimate the spams coming through to between 1/10 and 1/100th of what you
get with spamassassin active but the bayesian filters not trained.

	Henrik

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 30 Jan 2004 21:10:10 -0500

>	standard (like spamassassin) in front of these lists? 

Technically speaking, per current IESG policy you're not supposed to.  
Realistically, many list adminstrators do, out of necessity.  We're 
painfully well aware of the problem -- most of us administer some IETF 
lists, too -- and we're working on a new policy.  Stay tuned -- with 
luck, not for very much longer.

		--Steve Bellovin, http://www.research.att.com/~smb

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 30 Jan 2004 21:06:44 -0800

> application.  Early on I checked, and didn't see any false positives.

this is the "official" home for the thing I'm using.
It runs SpamAssassin on your machine, not the IETF's machine.

Since all the mail queued now comes equipped with SpamAssassin markers, it 
should be a Small Matter Of Programming just to check the spamscore instead 
of running spamassassin - much faster!

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 31 Jan 2004 10:23:36 +0100

> of running spamassassin - much faster!

Oho, this script is smarter than I realized before Harald's comment made
me look at the code!  With spamassassin set up appropriately, the
chances of loosing a proper submission should be very low indeed.

Not only that, but I now realize from the URL that I know the guy who
wrote it, and I'll ask him right away if he can add a switch which
checks for already present spamassassin tags instead of re-running
spamassassin on the local machine.

*Nice* script!

	Henrik

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 31 Jan 2004 16:02:48 -0500

In message <[email-masked]>, Henrik Levkowetz wri

>spamassassin on the local machine.

An authenticated tag?  Or one that the spammer inserted?

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 31 Jan 2004 23:13:23 +0100

> An authenticated tag?  Or one that the spammer inserted?

First reaction:
   Ah, hm... True.

Second reaction:
   I believe that if mails are run through spamassassin (at ietf.org),
it will replace possibly fake spamassassin header tags with it's own. Let
me check...
   Yes, spamassassin will replace any existing spamassassin header tags
(X-Spam-Checker-Version, X-Spam-Level, X-Spam-Status) with new ones, 
rather than add a second set.  So we should be all right on this.

	Henrik

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 31 Jan 2004 16:07:14 -0800

--On 31. januar 2004 16:02 -0500 "Steven M. Bellovin" 
<[email-masked]> wrote:

> In message <[email-masked]>, Henrik
> Levkowetz wri tes:
>

since spamassassin removes old spamassassin tags on mail before adding its 
own, tags that are present when it's queued on the secretariat machines are 
added by the secretariat spamassassin.

we do need to be careful if they turn it off....

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 31 Jan 2004 20:01:17 -0500

In message <1677043350.1075565234@localhost>, Harald Tveit Alvestrand writes:

>--On 31. januar 2004 16:02 -0500 "Steven M. Bellovin"=20
>since spamassassin removes old spamassassin tags on mail before adding its=20
>own, tags that are present when it's queued on the secretariat machines are =

Or if the mail appears, from its headers, to be IETF mailing list mail, 
but really isn't.

These evil thoughts are brought to you by the Security Area....