Looking at it now, it's surprising that this hasn't happened sooner: SF's mailman was abused with someone creating a bogus project with a mailing list which was then used to subscribe about 10,000 people and then spam them into oblivion.
The best/worst part is how people made it a lot worse by complaining to the list itself and spamming one another after that: http://www.geocrawler.com/lists/3/SourceForge/10386/0/
Anyway, I patched admin.py to just disallow admin web subscribes altogether.
In order of preference, for a future mailman version, it'd be nice if mailman would:
- Have a config.db entry: allow web subscribes, that can only be changed by the mailman owner (i.e. master password, not list password)
- Easier: have a sitewide mm_cfg.py variable to allow/disallow web subscribes by the list admin
Thanks, Marc
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
On 5/14/01 6:05 PM, "Marc MERLIN" <marc_news@valinux.com> wrote:
Looking at it now, it's surprising that this hasn't happened sooner: SF's mailman was abused with someone creating a bogus project with a mailing list which was then used to subscribe about 10,000 people and then spam them into oblivion.
It was going to happen sooner or later if you have people allowed to create stuff without adult supervision.
This has been a continuing discussion in the list-managers area, because of the problem of places like yahoo groups that allow this kind of thing. Unfortunately, fi you have a large population, administratively babysitting them becomes really time intensive, so you have to find 'reasonable' tradeoffs here.
- Have a config.db entry: allow web subscribes, that can only be changed by the mailman owner (i.e. master password, not list password)
This is one of the basic realities -- either disabling or limiting the size of web imports until someone has been 'cleared' as a trusted admin. That would mean some form of vetting procedurel, which means a human body in place to make sure things are legit. Until that happens, web-loads are limited to small values (because, honestly, you don't want to bother with small groups -- at worst, the damage is minimal, and most likely, someone loading in 100 addresses isn't spamming, the larger the number, the less likely it's legit).
Unfortunately, while we want to automate stuff, there are places where human bodies have to step in, and having the human body in place solves 90% of the problem, because the idiots won't bother trying -- unless they're really stupid or really arrogant.
My idea is that permission is done on a per-admin basis. Once you've vetted a guy on one list, you don't want to have to manually re-vet them on their next list, and the next, and...
And without it, you're limited to 150 subscribers via auto-loads of any sort, and to be vetted, you have to request permission, and you have to be findable through a verifiable, non-free e-mail address. That means even if the list is officially run from, say, fred@hotmail.com, you can't be vetted as admin from there -- there has to be a "real" address, not a throwaway one. And places like sourceforge get to define 'real' and "throwaway" as they see fit...
On Mon, May 14, 2001 at 08:32:17PM -0700, Chuq Von Rospach wrote:
Looking at it now, it's surprising that this hasn't happened sooner: SF's mailman was abused with someone creating a bogus project with a mailing list which was then used to subscribe about 10,000 people and then spam them into oblivion.
It was going to happen sooner or later if you have people allowed to create stuff without adult supervision.
Turns out that it actually was a misguided user with a real project who apparently thought a lot of people should know about it. The problem remains though.
BTW, there is adult supervision, SF does check and approve projects one per one, but there isn't much you can do about people who lie and set up a phony project that looks real.
- Have a config.db entry: allow web subscribes, that can only be changed by the mailman owner (i.e. master password, not list password)
This is one of the basic realities -- either disabling or limiting the size of web imports until someone has been 'cleared' as a trusted admin. That would mean some form of vetting procedurel, which means a human body in place to make sure things are legit. Until that happens, web-loads are limited to small values (because, honestly, you don't want to bother with small groups -- at worst, the damage is minimal, and most likely, someone loading in 100 addresses isn't spamming, the larger the number, the less likely it's legit).
Agreed.
Note that it introduces the concept of an uber user who gets those admin check Emails and other things to confirm instead of the list admin.
My idea is that permission is done on a per-admin basis. Once you've vetted a guy on one list, you don't want to have to manually re-vet them on their next list, and the next, and...
That could work for some, but doesn't help that much with a determined spammer who lies to get this access and then does the bad deed. That said, it'd still be a lot better than what we have now.
I guess the best would be to have a config option that says what the max number of people who can be added through the web is (0 being a possibility)
Having oversized adds go to a site admin for confirmation instead of just failing would be an added bonus.
Marc
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key
On 5/14/01 8:48 PM, "Marc MERLIN" <marc_news@valinux.com> wrote:
Turns out that it actually was a misguided user with a real project who apparently thought a lot of people should know about it. The problem remains though.
Zealots are zealots, whether it's their business, product, god or politics... (grin)
BTW, there is adult supervision, SF does check and approve projects one per one, but there isn't much you can do about people who lie and set up a phony project that looks real.
True -- which puts you a step ahead of yahoogroups, but as you note, it's not all that difficult to fake it enough to look legit. It's really a difficult thing to solve -- especially if you can't "track back" a user past a disposable email address at hotmail or any of the other freebies. If you have a trackable address, you have a chance of having THEIR ISP break a kneecap for you, and at the least, you can ban the user (and if necessary) the ISP to limit future damages....
Note that it introduces the concept of an uber user who gets those admin check Emails and other things to confirm instead of the list admin.
Well, I use the following concepts in my sites:
O site mom: basically, god.
O list mom: god for a list.
O assistant list mom: does the stuff the list mom can pawn off on them.
O content mom: handles mail that hits the admin page for some kind of hold, and monitors/administers the content of the list.
You need a site mom to oversee everything and set policy (and vet/train/monitor/break kneecaps on list moms). List moms handle administrative stuff and have access to the subscribe pages; content moms don't -- each list tends to organize as it sees fit around those restrictions.
Seems to work okay. It allows the list owner to hand off part or all of the list responsbility (at Apple, no list exists without an internal sponsor; that sponsor may or may not manage the list -- it might be someone in that group, or they may bonk an outside person to handle day to day operations). And responsibility flows upstairs, and memos flow back down.. (snicker)
That could work for some, but doesn't help that much with a determined spammer who lies to get this access and then does the bad deed.
But that's why you have to require a 'verifiable' address -- so if they do it, you have a chance of having an ISP be responsible for it, and if not, at least you can nuke that account and ISP from the 'verifiable' list so they can't pull it twice.
I guess the best would be to have a config option that says what the max number of people who can be added through the web is (0 being a possibility)
Having oversized adds go to a site admin for confirmation instead of just failing would be an added bonus.
Agreed and agreed -- it'd give the admin a chance to, say, pull a random subset to verify they'd agreed to this. If the list comes up clean, good. If not, you know you have a problem.
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> My idea is that permission is done on a per-admin basis. Once
CVR> you've vetted a guy on one list, you don't want to have to
CVR> manually re-vet them on their next list, and the next, and...I think this is the right approach, but has the disadvantage of being unweildy until we've rearchitected the user database and authentication components. Which will not happen for MM2.1.
-Barry
participants (3)
-
barry＠digicool.com -
Chuq Von Rospach -
Marc MERLIN