Sorry, everyone, this is really long, but I have been thinking
about it quite a lot lately for reasons that will be obvious if
you read all of this, and I'm hoping that putting some thoughts
out here will perhaps suggest a better solution to someone who's
smarter than I.

Peter M. Weiss +1 814 863 1843 writes:
> from any mail server?  Put another way, this is
> an SMTP protocol spoofing problem, and not a LISTSERV(R)
> solution.

This is true, but it doesn't mean Listserv couldn't do something
about it.  (The "confirm" option is most used, these days, to solve
the spoofing problem rather than any problem inherent to Listserv.)
I don't say Listserv *should* do something, just that it could,
possibly -- see below.

> Nevertheless, LISTSERV(R) is able to detect SPAM (if
> the heuristics are not defeated by mis-configuration)
> at near current levels of code.

The current spam-detection is totally useless for this problem.
(That's not a criticism -- it wasn't designed to detect this.)

We are experiencing it too.  I think one of our mailing lists is
listed by the "Kaboom" mailbomb generator program.  Therefore many,
many subscriptions are spoofed to that list (though usually not
multiple subscriptions to the same list for one person).  It may
be more than one list, but I've only been monitoring the one list.
I know that each victim is usually subscribed to multiple lists
either here or elsewhere, since the purpose is to harass them.  In
the two months I have been collecting these subscription requests,
we've received about 8000 of them, for the one list.

I really don't know what to do about it.  Here are some partial
solutions we've considered (some of which are specific to Listserv,
some not) and why they are not complete solutions.

--  Use "confirm" option for lists:  This stops people from being
subscribed against their will and getting lots of list traffic,
but it doesn't prevent them getting dozens of confirmation requests
from the dozens of lists they are spoofed for.

--  Close affected lists to outside subscriptions:  obviously
useless for public lists, and anyway it doesn't help -- the user
would simply get the message that they aren't allowed instead of
the confirmation or whatever.

--  Change the name of the affected list:  Annoying to list
members, and as Howard is experiencing, it still doesn't help the
victim, as now he gets "this list doesn't exist."

--  Serve affected users off:  First, this is locking the barn door
after the horse has been stolen.  By the time I know a user has
been made a victim, he's already received the mail.  Second, it
obviously prevents the user from ever doing legitimate subs --
not a big problem here, as our volume is low enough that such
people could be handled manually, but it could be a big problem
at other sites.

(I did serve one guy off -- his request -- after he cussed me out
for being so irresponsible as to run software that automates list
management.  Obviously we Listserv-runners are all too lazy to do
this by hand to protect this guy from these annoying automated
responses.  Sigh.  I think I can imagine how this particular person
became a target for mailbombing... but I digress.)

--  Turn off Listserv completely and manage lists by hand:  apart
from the obvious objection :-) this STILL wouldn't help as the
victims would now instead get bounces from the mail system.

--  Have Listserv automagically detect when someone is being
victimzed, and serve them off or silently drop requests from
them:  Fabulous idea!  I don't know how though.  Someday when we
all sign with PGP or similar tool, that would do it.  Careful
analysis of Received: headers can suggest, but not prove, that
mail is being spoofed.  I wouldn't like to silently bit-bucket
mail on that basis though.

    There is one thing Listserv could do here -- it could set a
limit, like the spam limit.  Assume that if a user subscribes to
more than X number of mailing lists in Y amount of time, it's a
mailbomb attempt, so serve this user off, or drop his requests,
or something.  Of course you also need to notify him and give him
a way to continue if he really DOES want to subscribe to 137
mailing lists today.

--  The solution I'm currently considering:  we have a little
perl script filter in place that grabs requests to subscribe to our
affected list, and forwards a copy to me.  It could just as
easily drop these requests silently.  This would not work for
lists that do get lots of legitimate subscription requests.  It
would work for our particular list because it's for a campus
group and legitimate subscriptions usually happen by someone
asking the list owner personally.

--  Track down the source of the spoofed requests and complain to
their school/employer/ISP:  Sure, if I wanted to spend several
hours a day on it.  Preliminary investigation indicates that the
spoofed requests come from lots of different sources (since any
fool can download Kaboom or whatever mailbomb software he likes
and run it on his PC).  I'd love to do this if I only had a clone
of myself.

The biggest problem with anything we can do is that the
mailbombers will NEVER KNOW.  They probably don't even know if
they successfully annoyed their victim, unless they happen to
both use a public forum and the victim gripes, or guesses who
did it and complains directly.  If a limit on subscriptions per
day became widely used and widely known, then I suppose
eventually mailbombers would switch to other methods and leave
list management software alone.

        Cathy
--
Catherine Foulston      [log in to unmask]      Rice University Network Management