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