EGROUPS.COM Blacklisted
Ronald F. Guilmette
Just a brief appeal to any of you out there who might be thinking of
setting up a mailing list with the help of EGROUPS.COM. Please don't.
In fact if you are adverse to spam, you may just want to do what I
have just done here, and blacklist the entire egroups.com domain,
either at your router or in your mail server control files, so as
to avoid being placed on various EGROUPS.COM spam lists without your
consent. (See example below.)
Seriously, this is SOOOOOOOOO lame. These people are pretending to
be professional list administrators, and not only are they spamming
but they apparently can't be bothered with little things like, oh,
CONFIRMING list subscriptions before they finalize them.
Well, gotta run now. I'm off to www.egroups.com. I gotta sign up
<pres...@whitehouse.gov> to a few dozen of their stupid non-confirming
lists. Oh yea! And I musn't forget <gray...@governor.ca.gov>!
Ron Guilmette
------- Forwarded Message
Return-Path: lfp-retsub-947224300-457933015-rfg=monke...@egroups.com
Received: from mu.egroups.com (mu.egroups.com [207.138.41.151])
by monkeys.com (8.9.3/8.9.3) with SMTP id VAA13092
for <r...@monkeys.com>; Thu, 6 Jan 2000 21:51:42 -0800 (PST)
X-eGroups-Return: lfp-retsub-947224300-457933015-rfg=monke...@egroups.com
Received: from [10.1.1.11] by mu.egroups.com with NNFMP; 07 Jan 2000 05:51:40 -0000
Date: Fri, 07 Jan 2000 05:51:40 -0000
From: "eGroups.com Manager" <in...@lotsofreestuff.com>
To: r...@monkeys.com
Subject: Welcome to the lfp group
Reply-To: lfp-unsubscribe-rfg=monke...@egroups.com
Message-ID: <853ut...@eGroups.com>
User-Agent: eGroups-EW/0.82
Mailing-List: contact lfp-...@egroups.com; run by eGroups.com
Precedence: list
X-Original-Recipient: RFC822;r...@monkeys.com
Hello!
in...@lotsofreestuff.com has included you in the lfp group at
eGroups.com, a free email service. By joining this group, you can
share information, store photographs and files, coordinate events and
more!
in...@lotsofreestuff.com says:
WELCOME AND THANK YOU FOR JOINING THE
LEGALFORM.COM and LOTSOFREESTUFF.COM
NEWSLETTER GROUP.
We will not waste your time.
WE DO NOT SELL ANYTHING IN OUR NEWSLETTER,
SAME AS OUR WEBSITE -- IT'S ALL FREE!
We provide FREE information about FREE stuff that you can use whether at home or at work, including merchandise, products, reports, manuals, legal forms, software, services and much more - all FREE!
If you sell a product or service, we'll help you in many ways in marketing on the internet.
We want to become your number one source for helpful information and FREE stuff.
Our service is always FREE and we NEVER give or sell our subscriber list to anyone.
Thank you and Welcome!
Yancey Sexton, Webmaster
TO Unsubscribe:
Click Reply in your email program and then Send.
eGroups.com asks group moderators to not add anyone to their group who
does not wish to join. If you believe this policy has been violated,
please notify us at ab...@egroups.com
Welcome!
eGroups.com - The easiest way for groups of people to communicate!
http://www.egroups.com
------- End of Forwarded Message
Paul Hoffman / IMC
>Well, gotta run now. I'm off to www.egroups.com. I gotta sign up
><pres...@whitehouse.gov> to a few dozen of their stupid non-confirming
>lists. Oh yea! And I musn't forget <gray...@governor.ca.gov>!
Great idea, Ron! Go commit fraud in the name of anti-spamming. That is sure
to help the anti-spam movement.
<sheesh>
Chuq Von Rospach
> Great idea, Ron! Go commit fraud in the name of anti-spamming. That
>is sure to help the anti-spam movement.
The ends justify the means. Anything for the cause.
chuq
--
Chuq Von Rospach - Plaidworks Consulting (mailto:chu...@plaidworks.com)
Apple Mail List Gnome (mailto:ch...@apple.com)
Pokemon is a game where children go into the woods and capture furry
little creatures and then bring them home and teach them to pit fight.
Mark Fletcher
> Just a brief appeal to any of you out there who might be thinking of
> setting up a mailing list with the help of EGROUPS.COM. Please don't.
>
> In fact if you are adverse to spam, you may just want to do what I
> have just done here, and blacklist the entire egroups.com domain,
> either at your router or in your mail server control files, so as
> to avoid being placed on various EGROUPS.COM spam lists without your
> consent. (See example below.)
>
> Seriously, this is SOOOOOOOOO lame. These people are pretending to
> be professional list administrators, and not only are they spamming
> but they apparently can't be bothered with little things like, oh,
> CONFIRMING list subscriptions before they finalize them.
>
You are absolutely correct, and I am embarassed by the mistake. When
people want to transfer their lists over to ONElist/eGroups, we have
mechanisms in place where a human has to verify that the list is legit
before the transfer can go through. That obviously didn't happen in this
case, and we're investigating what happened.
On a related note, as part of the merger of ONElist and eGroups, we're
implementing new strict anti-spamming measures across the entire
service, including pro-active deletion of potential spam lists, more
human interaction to prevent abuse of our service, and a beefed up
customer support group.
If anyone has a problem with either ONElist or eGroups, which you are
not able to resolve, please feel free to contact Kate Shambarger, our
Director of Customer Support, directly at ka...@corp.onelist.com.
Thanks,
Mark
Ronald F. Guilmette
In message <4.2.1.20000107...@mail.imc.org>,
>At 11:39 PM 1/6/00 -0800, Ronald F. Guilmette wrote:
>>Well, gotta run now. I'm off to www.egroups.com. I gotta sign up
>><pres...@whitehouse.gov> to a few dozen of their stupid non-confirming
>>lists. Oh yea! And I musn't forget <gray...@governor.ca.gov>!
>
>Great idea, Ron! Go commit fraud in the name of anti-spamming. That is sure
>to help the anti-spam movement.
It isn't fraud.
Egroups has their system setup so that anyone can subscribe anyone else
to their mailing lists. I assume that that is intentional on their part...
kind-of like MCI's ``friends and family'' plan. Egroups is intentionally
allowing me (and you, and everybody) to sign up our friends and family
to their lists. (The new subscribee's ascent to this is apparently not
required.)
Given that, and given that I'm quite sure that <gray...@governor.ca.gov>
would just love to get information from lotsoffreestuff.com via egroups.com,
I'm simply going to nominate him for this swell free service.
If there is any fraud involved here, it is egroups fradulently trying to
pretend that they have no control over what their own servers are doing,
not to mention egroups fradulent attempts to skirt the letter of current
California law by acting as front-men for the spammers using their services.
Roger B.A. Klorese
> Well, gotta run now. I'm off to www.egroups.com. I gotta sign up
> <pres...@whitehouse.gov> to a few dozen of their stupid non-confirming
> lists. Oh yea! And I musn't forget <gray...@governor.ca.gov>!
Fine... as long as you're the list-owner.
--
ROGER B.A. KLORESE rog...@QueerNet.ORG urgent: roger...@QueerNet.ORG
PO Box 14309 San Francisco, CA 94114 +1 415 ALL-ARFF
"There is only one real blasphemy -- the refusal of joy!" -- Paul Rudnick
Roger B.A. Klorese
> be professional list administrators, and not only are they spamming
> but they apparently can't be bothered with little things like, oh,
> CONFIRMING list subscriptions before they finalize them.
Do you force your list-managers to use confirmation? That is, is there
some mechanism by which it is impossible for a list-manager to add an
address unless there has been a user confirmation? I know of no product
that will conform to this, Ron, so you might as well just pull yourself
off the net.
Chuq Von Rospach
> It isn't fraud.
No, it's not -- but it is spamming, so I guess either Ronald feels
that the end does really justify the means, or Ronald ought to admit
he's promoting spamming and ought to blacklist himself.
To be really blunt about it, if Ronald is willing to say it's okay
for him to do this because he feels it's important to prove his
point, isn't that exactly what every other spammer uses to justify
THEIR reason for spamming? Because their message is so important it
overrides the rules the rest of us live with?
At the very least, Ronald simply lowers himself to the same level as
the spammers, which isn't my idea of a way to prove a point.
Ronald F. Guilmette
In message <Pine.BSI.4.10.100010...@queernet.queernet.org>,
"Roger B.A. Klorese" <rog...@QueerNet.ORG> wrote:
>On Thu, 6 Jan 2000, Ronald F. Guilmette wrote:
>> Well, gotta run now. I'm off to www.egroups.com. I gotta sign up
>> <pres...@whitehouse.gov> to a few dozen of their stupid non-confirming
>> lists. Oh yea! And I musn't forget <gray...@governor.ca.gov>!
>
>Fine... as long as you're the list-owner.
Sorry, no. It is _not_ fine.
If I wake up tomorrow morning and decide to create a mailing list called
``Great Pyramid Schemes You Can Join for only $19.95'', and if I then
unilaterally subscribe <gray...@governor.ca.gov> to my marvelous new
mailing list, that is most definitely _not_ fine. That's called spamming,
and it's now illegal under California law.
Can Egroups.Com be used as (witting or unwitting) accomplices in this type
of violation of California law? Clearly, the answer is `yes', and that
was proved by the spam I received from their server yesterday.
I for one am more than willing to overlook the participation of either
egroups.com or any other list hosting service in this type of spamming
and violation of California law IF AND ONLY IF they will just be so kind
as to do what most of the rest of the list administrators reading these
words have already done long ago, i.e. implement a simple subscription
confirmation protocol that will insure that I and other Internet users
are not exposed to the additional risk of ``subscription bombing'' IN
ADDITION to the risk of being indirectly spammed with the assistance of
their servers.
Ronald F. Guilmette
In message <Pine.LNX.4.10.100010...@godai.maison-otaku.net>,
Jeremy Blackman <lo...@maison-otaku.net> wrote:
>Another possibility, since I know Onelist and eGroups both store all list
>subscriptions for an address in a single account, and you can set global
>settings for yourself... why not have a setting on the account that says
>'I want to /always/ be asked for confirmation, even if the list admin
>subscribes me manually'?
You're missing the point... My question is ``Why don't they just do this
(confirm) for EVERYBODY and ALL OF THE TIME?''
As far as I'm concerned, that is the ONLY responsible way to run a service
like the one they are running. Anything less than that allows various
ramdom net-hooligans to, for example, launch an egroups-assisted subscription
bomb on, for example, Gray Davis, or me, or you, or...
The default setting should be set to ``No, DO NOT allow ramdom net-hooligans
to subscription bomb Joe Innocent Bystander.''
>And should we really still be cc'ing ab...@egroups.com on this? :)
Yes.
Ronald F. Guilmette
In message <Pine.BSI.4.10.100010...@queernet.queernet.org>,
"Roger B.A. Klorese" <rog...@QueerNet.ORG> wrote:
>On Thu, 6 Jan 2000, Ronald F. Guilmette wrote:
>> Seriously, this is SOOOOOOOOO lame. These people are pretending to
>> be professional list administrators, and not only are they spamming
>> but they apparently can't be bothered with little things like, oh,
>> CONFIRMING list subscriptions before they finalize them.
>
>Do you force your list-managers to use confirmation? That is, is there
>some mechanism by which it is impossible for a list-manager to add an
>address unless there has been a user confirmation? I know of no product
>that will conform to this, Ron, so you might as well just pull yourself
>off the net.
As far as I know, every modern off-the-shelf list management package now
provides, at the very least, an option which, when set, will cause the
list management package to send, via E-mail, SOME SORT of confirmation
request to each alleged new subscriber and to wait for a suitable response
BEFORE finalizing the subscription. (The better packages will even e-mail
a difficult-to-forge cookie of some sort to the alleged new subscriber and
then verify that they get the exact same cookie back from that subscriber
as part of the confirmation process.)
Certainly, if the administrator of a given server system gives any and all
mailing list adminsitartors who have access to that system carte blanche
(e.g. root access) so that they can run rampant and do anything they like,
then yes, some will undoubtedly be able to disable this prudent safety
mechanism. But for any well-managed server that belongs to any company
that makes its daily bread on the basis of providing mailing list services
to random members of the general public, the user interface provided to
the individual mailing list administrators clearly SHOULD NOT allow this
safety mechanism to be disabled.
Ronald F. Guilmette
In message <100010717...@one.eListX.com>,
James M Galvin <gal...@acm.org> wrote:
rfg> But for any well-managed server that belongs to any company that
rfg> makes its daily bread on the basis of providing mailing list
rfg> services to random members of the general public, the user interface
rfg> provided to the individual mailing list administrators clearly
rfg> SHOULD NOT allow this safety mechanism to be disabled.
>Who do you consider a "random member of the general public"?
Well, for one example, the guy who subscribed me to that list which
promoted lotsoffreestuff.com.
>Suppose elist services are provided on a for fee basis. Are such
>individuals random?
They are less random. In that case, at least we know that they have
money... money which can be, and which should be forfitted if they
are caught signing up ``subscribers'' who never asked to be on their
bleedin' lists.
>I hope not. It should be entirely reasonable to
>not only disable but not even offer the safety mechanism to a known
>elist administrator, where "known" obviously means more than just
>someone who came to my web site and told me who they were.
Yes. Money can be used as a sort-of `bond' against misbehavior.
But as I understand it, you don't need anything other than a Hotmail
account in order to start up your own new eGroups list.
Ronald F. Guilmette
In message <v04220806b49bfef7d559@[17.216.27.198]>,
>At 11:18 AM -0800 1/7/2000, Ronald F. Guilmette wrote:
>
>> It isn't fraud.
>
>No, it's not -- but it is spamming...
Sorry no. It isn't that either.
Let's review shall we?
Spamming is the act of sending someone unsolicited e-mail.
If I sign _you_ up to one (or more) mailing lists... let's say ones that
are run by Egroups.Com... then I can do that without sending you any
e-mail at all. Thus, *I* have not spammed you. Later on, Egroups.Com
may send you some unsolicited e-mails, but that's THEIR responsibility,
don't cha think? DUH!
OK, chuq, since you may have trouble working that out, let's try a simpler
example... I ask a friend to shoot you in the head with his .45 Smith &
Wesson. My friend, helpful fellow that he is, complies with my request.
Guess who goes to jail for murder, me or my friend. Don't answer right
away. Take the afternoon to think about it if you need to.
>To be really blunt about it, if Ronald is willing to say it's okay
>for him to do this because he feels it's important to prove his
>point...
To be really blunt about it, I'm more than willing to _say_ that _I_
(or anyone else on the net for that matter) *may* at any moment, go
to www.egroups.com and subscribe <gray...@governor.ca.gov> to a
couple of zillion of the lists that are being run from that site.
And I am more than willing to have the people at egroups.com con-
template the amount of grief and difficulty they would cause for
our governor and his staff if this were to happen, and if the
governor's staff was then forced to go thru the tedious process of
manually UNSUBSCRIBING from all of those same zillion egroups.com
lists just in order to return the <gray...@governor.ca.gov> mailbox
to a usable state.
(You have no idea what a huge pain in the ass, and a huge time-sink
this sort of thing can be UNTIL you have had the mailbox that you use
for most of your normal business communications rendered useless by a
malicious `subscription bomb' or two.)
>At the very least, Ronald simply lowers himself to the same level as
>the spammers, which isn't my idea of a way to prove a point.
Correction: I *would* lower myself to that level, if I did indeed
go to www.groups.com and subscribe <gray...@governor.ca.gov> to a
bunch of their inadequately-secured lists. But it is my sincere hope
that it will not be necessary to provide that sort of demonstration of
the hazards of non-confirming lists in order for egroups.com, and
others, to fully appreciate these risks, and to take steps, immediately,
to reduce them.
Frankly, I don't actually see why you're even trying to generate an
argument here chuq... other than the fact that you like to argue. I
mean _you_ _do_ understand the value and importance of doing proper
subscription confirmations, and you _do_ already have that setup for
all of the lists that _you_ manage, correct?
(I'm just guessing that you've done this for all of your lists, because
once upon a time I _was_ forge-subscribed to some Apple list or another,
and my recollection was that that subscription _did_ require a conformation
from me... which I of course never sent... and thus the subscription just
harmlessly died of its own accord, without any additional effort on my
part.)
Roger B.A. Klorese
> As far as I know, every modern off-the-shelf list management package now
> provides, at the very least, an option which, when set, will cause the
> list management package to send, via E-mail, SOME SORT of confirmation
> request to each alleged new subscriber and to wait for a suitable response
> BEFORE finalizing the subscription. (The better packages will even e-mail
> a difficult-to-forge cookie of some sort to the alleged new subscriber and
> then verify that they get the exact same cookie back from that subscriber
> as part of the confirmation process.)
>
> Certainly, if the administrator of a given server system gives any and all
> mailing list adminsitartors who have access to that system carte blanche
> (e.g. root access) so that they can run rampant and do anything they like,
> then yes, some will undoubtedly be able to disable this prudent safety
> mechanism.
But, in fact, just about every package of this sort, whether an
off-the-shelf package or a list host, DOES allow individual
list owners to add users without confirmation if they so choose. Don't
generalize without data.
Jeremy Blackman
> > Seriously, this is SOOOOOOOOO lame. These people are pretending to
> > be professional list administrators, and not only are they spamming
> > but they apparently can't be bothered with little things like, oh,
> > CONFIRMING list subscriptions before they finalize them.
>
> Do you force your list-managers to use confirmation? That is, is there
> some mechanism by which it is impossible for a list-manager to add an
> address unless there has been a user confirmation? I know of no product
> that will conform to this, Ron, so you might as well just pull yourself
> off the net.
I would, however, argue that in largely-unsupervised list hosting
situations such as eGroups/Onelist, there should be a 'self-ban' command,
which tells the listserver that you never want to be signed up for that
list again.
In other words, still allow the list admin to subscribe anyone, since too
many legitimate lists use it, and in the 'you joined' notice message,
offer not only a way to unsubscribe (since often times when they get the
unsubscribe notice, malicious users of those systems will simply
resubscribe you) but a way to say 'regardless of what the list admin says,
I want off this list permanently'.
Now, that may not be the most /elegant/ solution - it is something I
cooked up spur-of-the-moment as I read this message thread, and could
probably be improved upon - but from my point of view it seems to solve
both issues...not necessarily in the /best/ way, but it does solve them.
Another possibility, since I know Onelist and eGroups both store all list
subscriptions for an address in a single account, and you can set global
settings for yourself... why not have a setting on the account that says
'I want to /always/ be asked for confirmation, even if the list admin
subscribes me manually'?
Since I suspect most of us have, at one time or another, been on an
eGroups or Onelist list of some sort, that would also seem fairly trivial,
and if they included information about how to set that on yourself -
either in the 'you have been subscribed' message or on a website on their
page with a URL in the 'you have been subscribed' message - that would
seem to be another feasible solution.
Constructive brainstorming is always better than simply flaming people,
and may solve problems that were not originally seen. I know that
watching this has made me think about adding something similar to what I
describe above to the small list-hosting service JT and I are setting up.
:)
And should we really still be cc'ing ab...@egroups.com on this? :)
--
Jeremy Blackman - lo...@maison-otaku.net / lo...@listar.org / jer...@lith.com
Lithtech Team, Monolith Productions -- http://www.lith.com
Listar Developer -- http://www.listar.org
Jeremy Blackman
> I for one am more than willing to overlook the participation of either
> egroups.com or any other list hosting service in this type of spamming
> and violation of California law IF AND ONLY IF they will just be so kind
> as to do what most of the rest of the list administrators reading these
> words have already done long ago, i.e. implement a simple subscription
> confirmation protocol that will insure that I and other Internet users
> are not exposed to the additional risk of ``subscription bombing'' IN
> ADDITION to the risk of being indirectly spammed with the assistance of
> their servers.
I think the point that was made earlier was that the majority of
individual list owners do not have that restriction placed on them on
services other than eGroups. Hence, if I am the list administrator on a
Majordomo list, I can do:
approve <password> subscribe <list> <email>
Do they get a confirmation ticket? Not under stock majordomo, not last
time I checked. Does this mean Majordomo on a free Majordomo hosting site
could be used by list admins as a spam technique, by signing up people
without their consent? Of course! The /vast majority/ of listserver
software out there has a way for admins to add users.
However, that having been said, it probably does make sense on
un-supervised large commercial 'free' list hosting sites to have some sort
of protection against this being done, but saying 'everyone else does it'
is not valid, since while most give confirmation tickets for a normal
subscribe, if a user is /manually added/ by a list admin, it does not.
And that appears to be the case here; not that another user tried to sign
them up, but that they were manually added by the admin.
In Listserv, I can add manually. In Majordomo, I can add manually or even
just edit the user file. In Smartlist, I can edit the user files. I
suspect you can do the same in ezmlm, Mailman, and Sympa (which I have not
used as a list or site admin, so cannot attest to). In Listar, I could
edit the user file on disk, or I could just send an authenticated admin
command mail, and manually add people in that.
The key is that most listserver packages are designed around the theory
that the list admins are responsible; otherwise the sysadmin would not let
them have a list, right? But that theory goes out the window with free
hosting services with unsupervised signups, such as eGroups/Onelist.
So, while you are arguing a valid point (something should change about the
eGroups/Onelist setup) arguing that they are somehow doing something
different than all other setups is /not/ true. The problem is they are
doing the /same/ thing as the setups where the list admin can be trusted.
Just my $0.02 + state sales tax. Take as applicable.
Ronald F. Guilmette
In message <Pine.BSI.4.10.100010...@queernet.queernet.org>,
"Roger B.A. Klorese" <rog...@QueerNet.ORG> wrote:
>On Fri, 7 Jan 2000, Ronald F. Guilmette wrote:
>> As far as I know, every modern off-the-shelf list management package now
>> provides, at the very least, an option which, when set, will cause the
>> list management package to send, via E-mail, SOME SORT of confirmation
>> request to each alleged new subscriber and to wait for a suitable response
>> BEFORE finalizing the subscription. (The better packages will even e-mail
>> a difficult-to-forge cookie of some sort to the alleged new subscriber and
>> then verify that they get the exact same cookie back from that subscriber
>> as part of the confirmation process.)
>>
>> Certainly, if the administrator of a given server system gives any and all
>> mailing list adminsitartors who have access to that system carte blanche
>> (e.g. root access) so that they can run rampant and do anything they like,
>> then yes, some will undoubtedly be able to disable this prudent safety
>> mechanism.
>
>But, in fact, just about every package of this sort, whether an
>off-the-shelf package or a list host, DOES allow individual
>list owners to add users without confirmation if they so choose.
I do not know that to be the case.
But that is beside the point anyway. Are you claiming that it is a Good
Thing, that anonymous goofballs can go and get outfits like eGroups to do
their spamming for them, or are you only claiming that this is a common
situation?
>Don't generalize without data.
Funny. I was just about to say that same to you.
*I'm* not the one who is making statements of the form ``... just about
every package of this sort...''
Where is your data to backup that generalization? Have you surveyed all
such packages?
Ronald F. Guilmette
In message <Pine.LNX.4.10.100010...@godai.maison-otaku.net>,
Jeremy Blackman <lo...@maison-otaku.net> wrote:
>On Fri, 7 Jan 2000, Ronald F. Guilmette wrote:
>
>> I for one am more than willing to overlook the participation of either
>> egroups.com or any other list hosting service in this type of spamming
>> and violation of California law IF AND ONLY IF they will just be so kind
>> as to do what most of the rest of the list administrators reading these
>> words have already done long ago, i.e. implement a simple subscription
>> confirmation protocol that will insure that I and other Internet users
>> are not exposed to the additional risk of ``subscription bombing'' IN
>> ADDITION to the risk of being indirectly spammed with the assistance of
>> their servers.
>
>I think the point that was made earlier was that the majority of
>individual list owners do not have that restriction placed on them on
>services other than eGroups. Hence, if I am the list administrator on a
>Majordomo list, I can do:
>
>approve <password> subscribe <list> <email>
>
>Do they get a confirmation ticket? Not under stock majordomo, not last
>time I checked. Does this mean Majordomo on a free Majordomo hosting site
>could be used by list admins as a spam technique, by signing up people
>without their consent? Of course!
Assuming that this is true, _and_ that the admins of these ``free Majodomo
hosting sites'' (got any names?) leave things configured like that, and
that they do not take pains to disable this capability, then I for one
find it both remarkable and also rather completely absurd.
If what you are saying is true, I may switch over to writing spamware,
rather than trying to write anti-spamware, because I can see now how writing
spamware should be a damn sight easier.
Here's a simple scenario...
Spammer goes to one of the ``free Majordomo hosting sites'' and does what-
ever is necessary to create a new list. He then mails a sequence of 50,000
lines of the form:
approve <password> subscribe <list> <email>
to that site, followed by a _single_ copy of his spam (for a grand total
of only _two_ messages). Total connect time needed for the spammer to spam
50,000 people? Under 1 minute. And as an added bonus, the spammer probably
gets the benefit of (a) a nice high-performance server optimized for mailing
list distribution and (b) some nice high-bandwidth connections to same.
Swell. Just swell. NOT!
Roger B.A. Klorese
> "Roger B.A. Klorese" <rog...@QueerNet.ORG> wrote:
> >But, in fact, just about every package of this sort, whether an
> >off-the-shelf package or a list host, DOES allow individual
> >list owners to add users without confirmation if they so choose.
>
> I do not know that to be the case.
Including my hedge of "just about," I do know this to be the case, as I've
researched it lately.
> But that is beside the point anyway. Are you claiming that it is a Good
> Thing, that anonymous goofballs can go and get outfits like eGroups to do
> their spamming for them, or are you only claiming that this is a common
> situation?
Common, of course.
> >Don't generalize without data.
>
> Funny. I was just about to say that same to you.
See below.
> *I'm* not the one who is making statements of the form ``... just about
> every package of this sort...''
>
> Where is your data to backup that generalization? Have you surveyed all
> such packages?
About 20 of them, at last count, free and commercial.
Chuq Von Rospach
> The problem is they are
> doing the /same/ thing as the setups where the list admin can be trusted.
Which may well be the right thing, as long as there are ways to
police the admins appropriately.
One thing people have to watch out for is the "no risk" syndrome --
if something, anything can go wrong, then you can't do it. Risk is
not absolute, it's something to be managed. The only way you can have
no problems it to do nothing. If one admin in one thousand abuses a
priviledge, is that a reason to remove it from the other 999? Or do
you shoot that thousandth one instead?
Chuq Von Rospach
> I would, however, argue that in largely-unsupervised list hosting
> situations such as eGroups/Onelist, there should be a 'self-ban' command,
> which tells the listserver that you never want to be signed up for that
> list again.
A good idea, or at least some for of "lock this account" setup.
what I've got pencilled in to a system I'm designing is a way to flag
an account such that it's subscriptions can only be modified through
the subscription maintenance page, which would require logging in
with a password. This would allow a user to unsubscribe from
everything and then lock the account if that's what they want,
disallowing anyone else from subscribing them through other means.
Secondarily, I'm designing in a set of 'banned' tables for accounts,
domains and strings, so that the administrator of, say,
whitehouse.gov can have it arranged for the entire domain to be to be
automatically rejected, or if some account is being slammed, it can
be blackholed for the user.
I already do that on an ad hoc basis with procmail, but as I redo
everything into an SQL system, it's easier to do right, and make it
easier to administrate.
David W. Tamkin
Onelist and eGroups (the corporations have merged but the services still
operate separately) both have functions for add-with-confirm and direct-add.
They encourage using add-with-confirm the onelist.com web site states that
direct-add should be used only when one is transfering an existing list from
another host.
Yes, direct-add is at risk of abuse, and it has been abused, and there have
been occasions on both sides where management has taken action when abuse has
been reported. But whenever, in fora for discussing running lists on those
hosts, someone suggests removing the direct-add feature, other listowners
howl and scream that their lists need to reach a contingent of people who
are too helpless with email to carry out the instructions of confirming a
subscription.
The objections do not come from spammers but from people running lists for
non-technical topics, many of whom have actually had experiences with people
lost and confused at the directions to reply to the confirmation request.
(Then there are people using webmail from sites that run BigMailBox, which
won't let you reply to an address that includes an equal sign and which can-
not return an NDN for an undeliverable item if the envelope sender address
includes an equal sign. They truly cannot reply to confirmation requests
from onelist.com or egroups.com but have to follow the directions for con-
firmation by HTTP instead.)
Personally, I'd rather see it removed. Anyone incapable of answering email
is no asset to a mailing list and probably unable to gain anything from
reading a list's mail either, and anyone using a BigMailBox site should
be told of its limitations and should open an additional webmail account
at a site with less despotic software.
[On the list for discussing the Onelist/eGroups merger, one member offered
anyone who desires an additional email address to use his webmail, which runs
BigMailBox. He really wasn't offering much help.]
Roger B.A. Klorese
> Except when the subscribe requests is sent by the list manager. I agree
> with Roger -- I am not aware of any mailing list package which requires
> confirmation from the subscriber even when the list manager initiated the
> subscribe request.
And considering I'm now the product manager for a forthcoming commercial
MLM...!
(To which I added the requirement today that the site or domain admin can
set minimum levels.)
Tim Pierce
>
> As far as I know, every modern off-the-shelf list management package now
> provides, at the very least, an option which, when set, will cause the
> list management package to send, via E-mail, SOME SORT of confirmation
> request to each alleged new subscriber and to wait for a suitable response
> BEFORE finalizing the subscription.
Except when the subscribe requests is sent by the list manager. I agree
with Roger -- I am not aware of any mailing list package which requires
confirmation from the subscriber even when the list manager initiated the
subscribe request.
--
Regards,
Tim Pierce
RootsWeb.com lead system admonsterator
and Chief Hacking Officer
Dru Nelson
Hi Ron,
My name is Dru and I work at eGroups as the Director of Network Operations.
You may not remember me, but you called me a while back (Feb. 98) for some
free consulting on your escrub machine. (I built you a Freebsd kernel that
could handle the large numbers of descriptors that you needed). I supported your
efforts for a few weeks until my work was done.
Let me assure you that all of the people here at eGroups (including myself) take
spam very seriously.
You have already gotten a lot of contacts to people high up in the company that
are willing to
help, I just wanted to give you my word as well.
Take care,
"Ronald F. Guilmette" wrote:
> In message <4.2.1.20000107...@mail.imc.org>,
> Paul Hoffman / IMC <pa...@imc.org> wrote:
>
> >At 11:39 PM 1/6/00 -0800, Ronald F. Guilmette wrote:
> >>Well, gotta run now. I'm off to www.egroups.com. I gotta sign up
> >><pres...@whitehouse.gov> to a few dozen of their stupid non-confirming
> >>lists. Oh yea! And I musn't forget <gray...@governor.ca.gov>!
> >
--
Dru Nelson Director of Network Operations
http://www.egroups.com/ Voice: 415-546-2740
Michael S. Johnson
> In other words, still allow the list admin to subscribe anyone, since too
> many legitimate lists use it, and in the 'you joined' notice message,
> offer not only a way to unsubscribe (since often times when they get the
> unsubscribe notice, malicious users of those systems will simply
> resubscribe you) but a way to say 'regardless of what the list admin says,
> I want off this list permanently'.
> Another possibility, since I know Onelist and eGroups both store all list
> subscriptions for an address in a single account, and you can set global
> settings for yourself... why not have a setting on the account that says
> 'I want to /always/ be asked for confirmation, even if the list admin
> subscribes me manually'?
These solutions assume a few things:
* the service doesn't require an annoying registration process
to grant a user access to hir subscription preferences
(1: which currently requires a web browser that, despite aggressive
advertising, is not something all persons with an e-mail address are
guaranteed to have or want to use; 2: a user can be subscribed to an
eGroup-like list without being a registered user of the eGroups-like
service)
* the service wants to set aside space and CPU to store opt-out lists of
millions of such users (this would require dev time above and beyond
what is necessary for an eGroups-like service to be up and running and
profitable)
* that no trusted centralized opt-out service exists (spammers have
devalued the concept of opting-in to an opt-out list by hosting
their own for the purpose of harvesting valid e-mail addresses)
* that users will be willing to tolerate the effort of actively opting-
out of each undesired list, as opposed to automatically being not
subscribed when a confirmation ticket is purposefully ignored and
allowed to expire
Remember: people are generally lazy or distrustful. Too lazy to tolerate
manually opting out of every spam. Too distrustful to give their address
to Yet Another Opt-Out List that doesn't effectively decrease the amount
of spam received.
--
Michael
David W. Tamkin
| ... I am not aware of any mailing list package which requires
| confirmation from the subscriber even when the list manager initiated the
| subscribe request.
On ONElist and on eGroups (and I'd be surprised if the situation is different
on other major web-based listhosts), a listowner has two add commands: one
sends people confirmation requests to which they must respond in order to be
subscribed, and one forcibly adds them but tells them how to unsub.
Part of the irony in the system is the reply addresses. Any message to the
confirmation request's reply address will confirm you, so people who write
back "Hell no! I want no part of this!" get fully subscribed; but the reply
address of the notice that you've been direct-added is the -unsubscribe
address [I think a preconfirmed version on eGroups], so people who write
back, "Thanks for adding me. I look forward to enjoying the list," get
taken off.
On Coollist there have been incidents of listowners who forcibly subscribe
people and then, if they unsub themselves, forcibly resubscribe them, and
unlike eGroups and ONElist, Coollist management has been totally unrespon-
sive about the problem.