We allow anyone who gets an account to have instant access to email. I personally prefer that grex continue providing open access to email but I am worried that we have made the barriers too low for would-be spammers and vandals. Their continued misbehavior is ruining the value of email for legitimate users by getting the system repeatedly listed in various spam databases and unfortunately, is consuming an inordinate amount of staff time that could be better spent on other system problems. The purpose of this item is to discuss whether to raise the barrier for access to email and possible ways of implementing such barriers, be they social or technical.149 responses total.
No social system is going to work with spam weasels, sadly. We're going to have to come up with a decent way to throttle exim from handling 100+ emails at once from someone, or make email only available to some kind of 'verified' user. One of the reasons I haven't been participating in coop for the last several weeks is that just about all my time spent on Grex lately has been watching for spammers, and cleaning up after them. I have removed more than 150,000 emails from the queue because of these idiots. The net really isn't what it once was, and Grex needs to adjust itself to these realities. I note that M-Net has gone through much the same problem, and they elected to shut off outbound mail. We have to figure something out. I'm hoping that a throttle system will work, and/or a spam filter system that can apply to outbound mail as well.
What size throttle? Is there any need for grexers to send more than 50 copies of the same mail at once?
I liked the idea of implementing an ascii CAPTCHA test in newuser, to keep spammers from creating accounts automatically. That would at least slow them down, I think.
I would like to suggest a more radical approach, to bring Grex's email service to a graceful end. Email is not a core part of Grex's mission, it's just something that happened along the way. And free e-mail is available from an awful lot of providers now. There are lots of ideas for programming and configuration changes which could allow Grex to continue providing email service, but all of these require staff time resources; the last year or so has pretty well demonstrated that Grex doesn't have staff time resources for that sort of development. (I use Grex as my principal non-work e-mail address.)
I think it is important for Grex, as an organization, to be a good netizen. And having spam come from us is a perfect way to spoil our reputation. I'm with Ken, I do not think providing e-mail is an efficient use of staff resources. When m-net turned off their e-mail, we laughed. Now we're beginning to see the wisdom of that decision.
I email other grexers from within grex and would really really hate to be forced to use webmail to do it. Sometimes I am trying to teach them to use 'talk', and it helps to write emails about this. I prefer dealing with the spammers some other way than punishing the rest of us.
resp:1 looks like poetry
hic hic hello
Guess only to/from grex mail can be allowed !
Hmm. How about for 48 hours, you are limited to local mail. After 48 hours, you gain the right to run a program which asks you to type in an ascii CAPTCHA, which if answered correctly places you into a group that is allowed full email privileges? Implementing this should be relatively easy.
I'm not in favor of removing mail from Grex if we can help it, as mail is still the best communications system there is. If we can't control the spammers however, we may have to stop it. That would be really horrid though. In terms of a throttle on the number of emails, I'm not sure. I know most people send less than 20 emails a day, judging from a time when I went over the logs of several days. We should be able to change that throttle as needed.
I'd favor having the ASCII CAPTCHA in newuser itself. I've been toying with the idea of a newuser rewrite in either Perl or Python....
Bruce's description in #10 sounds good to me.
What is a CAPTCHA?
Some sites use a graphic image of a sequence of letters and/or numbers. They're somewhat difficult to read, intentionally so, in order to be very hard for a program to read. You have to identify the sequence of characters and then type them in, which authenticates you as a human being. Other free e-mail systems use them to prevent comptuers systems from automatically creating e-mail accounts to use for spam. Someone (bhoward?) had the idea of using ASCII art -- for example, figlet fonts -- on Grex in the same way. Computers would have a hard time identifying such characters, so only human beings would be able to run newuser to create an outbound e-mail account. Does that explain the concept, Sindi?
So how will that stop or even slow down a spammer who already knows about grex and has a graphical browser?
It will make it very difficult for them to automate their procedure for creating multiple accounts.
(At which point they'd probably give up and go somewhere else that's easier.)
How about a throttle on outbound mail which limits users to 5 per day?
Why does a spammer need multiple accounts if we don't have any limit on number of outgoing mails per day? Five per day is too low for normal users. I get about 10 a day here and answer them all. Make it 25 at least.
Its just an arbitrary number but does the idea of a cap on number per day seem reasonable?
I wonder how to implement it. You'd have to maintain some sort of hash and `expire' data from it every day. That would be easy to implement, but I've found that things like that tend to be fragile: I like to minimize moving parts, if I can. That's why I'd prefer something that just relied on groups or something like that.
It's very difficult to control email on a system in which users can pipe things to sendmail. We're not talking about joe schmoe using elm to send 50,000 emails. Presumably, direct queue injection via the sendmail binary - or possibly SMTP from localhost via a perl script. <ric goes to test something>
Grex does accept SMTP from localhost... I presume there are mail clients (PINE?) that use SMTP rather than direct queue injection via sendmail...
You can control access to the SMTP port on the localhost interface using PF. Access to the sendmail binary can be controlled via group membership, as I outlined in some post somewhere.
Re#20 Right now, they don't need multiple accounts but from the debris left behind in their acccounts, it appears they are splitting their target lists into smaller sets and setting each account to work on a different subset. I don't recall offhand if each account was pumping out the same message so it is possible, they were using a different account to send different messages. Re#22 Perhaps the simplest way is to have exim maintain a hash table. Each time a mail is sent, you hash on the senders login, retrieve a record containing a message count and a date stamp. If the time stamp is <= 24 hours old, just increment the message count for the sender and refuse to accept the message for processing. If the time stamp is more than 24 hours old, the message count is reset to 1 and the date stamp is set to the current time. Today is the first day I've had a real chance to dig into how exim works and may be extended so I lack the vocabulary to describe this using proper exim terms. However, it appears there are a few different mechanisms one could use.
(25 slipped in ahead of my 26)
Do the spammers use mail lists (available with Pine, don't know about other mail programs)? Is there anything specific they do which can be restricted to paying members without seriously interfering with mail use by other normal users?
> If the time stamp is <= 24 hours old, just increment the message count > for the sender and refuse to accept the message for processing. If > the time stamp is more than 24 hours old, the message count is reset > to 1 and the date stamp is set to the current time. 26: Don't you mean "If the time stamp is more than 24 hours old *and the message count is higher than x*?
let's say I wanted to use grex to send spam.
I'd create an account.
I'd upload a list of addresses... say 50,000 email addresses, one per line.
I'd create a text file with my spam message.
Then i'd run the following perl script:
##################################################
#!/usr/local/bin/perl
open(FH,"~/addresses.txt") or die;
while(<FH>) {
chomp;
system("cat ~/spam.txt | mail -s Spam $_");
}
close(<FH>);
##################################################
And poof. 50,000 spam messages go out.
That being said.. the only way I can think of to stop spam from happening
on grex is to unplug grex or disable outgoing mail.
you could reduce spam by creating a waiting period for access to email.
But I'd make it longer than 48 hours... a week, at least.
You could reduce it even more by allowing access to email ONLY to members.
Then a spammer would have to give money to grex and (theoretically) be
"verified" before they could send their spam.
A limitation of 50 outbound emails per day or even 100 outbound emails per
day per account would also be useful, combined with an ASCII CAPTCHA on
newuser *AND* the delay for access to outbound mail.
If a spammer wants to manually create 100 accounts, wait a week for each,
then send out 100 emails per day - each.... that'd be an awful lot of
work to send 10,000 messages per day. Easier to hack into someone's
unsecure version of Wordpress.
If, on top of the last step, you do some mail logging that reports how
many emails each user sends - per day - over a certain threshhold.. you
could eliminate those user accounts pretty easily.
Could grex automatically delete large mail lists, perhaps anything with more than 100 @ signs in it?
That doesn't solve the problem. Spammers typically send out N emails with one person in each email. Some don't of course, but the recent barrage of emails from AOL and .ro idiots does this, so that isn't a solution.
Romania is a country, not an ISP. Can you be a little more specific with domain suffixes when you sling insults?
First, correcting an editing error by rewording slightly what I said in #25: Each time a mail is sent, you hash on the senders login, retrieve a record containing a message count and a date stamp. If the time stamp in the record is <= 24 hours old, just increment the message count for the sender and refuse to accept the message for processing if the message count is over the 24 message limit. If the time stamp in the record is more than 24 hours old, the message count is reset to 1 and the date stamp is set to the current time. Re#29 No, because the message count is a max of how many messages they are allowed to send in a 24 hour period. If the next message sent pushes them over the max message count, that is only a problem if it has been less than 24 hours since the timestamp of the first message. The idea is that the first message starts a 24 hour count down. That count should be reset once 24 hours has past but we don't actually need to check until the next time they send a message.
I agree with a week long waiting period
Typed-in twice, and still dropping words.
"...if the message count is over the 24 message limit"
should have read:
"...if the message count is over the 24 hour message limit"
El Senor Bruce da howard.
(somehow it seems like there ought to be a sudden snap of castanets when he says that...)
Or a flourish of mariachi guitar..
Ole!
everybody dance !
Comcast is now blocking mail from Grex, which means I can't remind certain members to renew their memberships.
Are we still on the RBL list? Can we try not letting new users send outgoing mail for the first week, and if that does not work, then try other things?
We could declare a emergency moratorium on mail privileges for new users but allow existing users to keep their mail privileges until outbound mail limits can be implemented. Any spammers with existing accounts would either lie low or quickly be identified and locked. This might allow us a respite to get off the blacklists and focus on fixing mail.
Is there a new spammer this week? Comcast at least lets you know why they bounced your mail (RBL). Would it be fair to allow unlimited outbound mail to members but only maybe 100K per day for others? Or would spammers find some way to sign up for 1000 new addresses?
You'd be surprised at how many spam messages you could fit into 100k.
Oh, one thing you'll want to remember is that people could write a spam script in perl, and execute it from the web, so the email would be generated by the "nobody" "apache" or "httpd" user - depending on how apache is configured here. Ah, I see it's "www"
How could you execute a spam script from the web?
Via a CGI script. Fortunately, I think grex is configured NOT to allow normal users to execute CGI scripts out of their personal web directories.
Is it not also possible, perhaps probable, that SPAM is being sent with a spoofed from address of @cyberspace.org, and that is accounting for the blacklisting? Or is the blacklisting smart enough to know where the mail actually originated from?
Nobody intelligent acts on the basis of a From: line in spam; such lines are all presumed to be forged. Mail recipient programs know the IP address they are receiving the mail from.
If bhoward's proposal in resp:44 can be quickly implemented (with user groups?), it should be done to buy staff time to work on a better fix.
re 49 - ah, yes, grex doesn't allow php or cgi scripts in home directories. re 50 - Ken is right in #51 .. peole forge from addresses all the time, and spam blockers (and those who write spam blocking software) all all aware of this. Black listing is pretty much always IP based. Even if you receive a million spams from the Ann Arbor Observer, and they did NOT forge their from address... their IP address would be blacklisted, not the organization. So if they changed their IP address they could start sending spam again - until that was also blacklisted.
I should have phrased #51 as "Nobody knowledgable..." rather than "Nobody intelligent..."
Regarding #54; You shouldn't assume that the people who run either ISPs or blacklists are either.
Just to let you know... Pending next weeks discussion at the BOD meeting, I have implemented an initial throttle on email for newusers. The net effect of this is that all grex users as of this evening, will see no change to their mail access. Any newuser account created from this evening onward, will not be able to send mail to external sites until their account has been added to a file containing a list of authorized users. Mail within grex continues to be available to all users. Note, this has been implemented on an emergency basis in order to give staff time to stabilize the situation from a technical standpoint until the BOD are able to discuss this issue next week.
Outstanding.
Don't start dancing yet...it needs to settle in and I wasn't all that familiar with exim when the grex spam problem really started to explode recently. I'm watching the logs and doing further tests carefully as my mailer science skills have rusted a bit since the mispent days of my hacking youth when I used to do this for a living (and for some strange reason, actually liked hacking on mail systems).
True, but there's a big difference between upas and what passes for mailers these days. :-)
re #56 THANKS!!!
How do you plan to authorize new users?
I've proposed three ways:
o write a program that presents a CAPCHA which if correctly
entered, will add said user to the list of authorized
mail users.
o Automatically vest newuser accounts with mail privs after
a hold down period (currently suggested at 48 hours) has
elapsed.
o Some combination of the above two.
I thought the question was "how do you plan to authorize them *in this temporary stopgap measure*?"
Thanks Bruce! Great job. And thanks also to STeve for dealing with the spammers.
Re#63 Sindi didn't indicate what time frame she meant; I don't intend to do a lot about adding newusers in the interim. If a newuser thinks to send mail to staff, we'll certainly add them but my priority is on implementing mechanisms to adding them or delegate the support load for doing so out to the individual users. As a next step, I'm looking at: * Changing /usr/local/etc/exim.outbound to a dbm file (I used a flat file for yesterdays change but that is hard to update efficiently) * Writing monitoring script to periodically count up how much mail has been sent by each person that has sent mail in the last 24 hours and automatically throw anyone over the limit on the explicitly depermitted list. Removal of offenders from said will be a manual process. * Thinking about how to flesh my CAPCHA prototype script into a proper secure setuid C program and also how to implement the 48 (or N) hour hold down if that is what the BOD or membership decide to go for.
whoa ! bruce is great
Thanks so much, Bruce!
great work bruce. BTW, it's CAPTCHA
Thanks bruce!
Re#68 Yeah, thanks for the correction. I keep forgetting the spelling because I learned the current term for it long after I had been using and implementing them.
The most effective limit to spammers is the 5 minute delay. Each outbound e-mail would be subject to a 5 minute delay before sending, and then only ONE e-mail would be sent. Additional e-mail would require another 5 minute wait. The total e-mail for a user waiting to be sent would also be limited to a fixed amount, say 2 Meg. Limits on who could have an e-mail account are also reasonable. Potential user from sources that are identifiable, (schools, identifiable companies, etc.) should be assumed genuine. Users from internet services that don't identify users should be subject to additional verification. Potential users from that block of IP address in South Korea, where they refuse to identify the owners, and any like them, should be denied access. The ultimate deterrent, and one that will probably be necessary against the worst offenders, is to take legal action against them. Current Federal law prohibits mass sending of e-mail to recipients thhat the sender does not have an established relationship. This is enforced by the FBI and possibly, the Secret Service, depending on content. Fraudulently obtaining accounts, and using the system in ways not permitted by the rules of operation may be prosecutable under Michigan's computer tresspass law.
Implementing a five minute delay on outgoing mail would be fairly complex, I fear. An upper limit on the number of emails per day is probably vastly easier to do.
Can you also limit the number of new accounts that can be opened in one day from some IP address?
I don't see how it would more difficult to do than the things discussed above. Mail would go int an output queue, and be sent out every five minutes. Exect timing is not necessary here. It's the average effect that would stifle spammers. Counting over a five minute interval would be no more complicated than counting email sent per day, but require less data accumulation. In addition, it would essentially reset every five minutes, thus correcting quickly any errors, without the need of operator intervention. While the mail is waiting in the queue, the outgoing mail could be scanned for unacceptable output, and excessive use by one or more users. Again, exact amounts are not necessary here. It's the average effect that would stifle spammers.
When services complain of unacceptable mail form Grex, it would be the ideal time to complain to them of their unacceptable mail to Grex. I am referring to the so-called "returned" mail that didn't come form here. I used to complain of this to the "postmaster" or "administrator" of the systems this came from, with some effect. But, all of them have stopped accepting complaints at these standard addresses. They are helping spammers didtribute their spam, and they don't seem to care. If they won't pay any attention to our complaints, why should we pay any attention to their's?
just make offsite email a members only perk. I've suggested this in the past. nobody needs grex for free email anymore.
And every time you've suggested it several counterexamples to "no one needs ..." have been brought up. If it were a members-or-dialups-only I think fewer would object on strictly pragmatic grounds, but I still don't agree with that position. (The idea of anything as a "member perk," IMO, is in discord with the founding principles of Grex -- I suggest you read the discussion about the decision to restrict outgoing telnet and ftp.)
Technically no one NEEDS e-mail at all. Or the internet. Or water beds. But there are people who want those things.
re #78: exactly. Let's not talk about "needs".
Yeah, but if they want it they have a zillion other places they can find it - so that argument is just as shakey.
There are several people in the 734 area code whose only source of email -- or any Internet at all -- is Grex. (Some of them are introduced to Grex in their first exposure to a *computer*.) While Grex is not an ISP, it has in the past made these people a priority -- "open access" is, after all, one of its founding principles. I don't want to change this; my family was in this position for a long time, and might be again.
I am in the 734 area code, and I do not support the idea that people living closer to Grex are a "priority". If there is no financial problem with keeping the lines open, then okay. But if Grex needs to decide whether to dump modem access or dump disk space...I vote for dumping the modem access.
(So would I -- but I don't think it'll come to that.) By "priority" I don't mean "highest-priority" -- I'm just saying that to assume that everyone who logs into Grex has other access to email and thus we can freely restrict it to members only has a false antecedent.
If you dont restrict email to members, then how else do you solve the email spam problem other than closing newuser? Because these are likely not new users spamming, they are persons we all know who they are, who have a habit of running newuser constantly and churning out new logins and email addresses.
My, to WHOM could you be referring?
last year I had a certain grexer flood my email box with 10,000 emails. I notified staff, but what could they do? If they took out his login, he'd just run newuser again. If they blocked his ip address, he'd use an anonymizer. unless you restrict offsite email to new users, or take it away altogether, what can staff do? they can do nothing...
There have been several suggestions for reducing the *amount* of mail someone could send. I also wouldn't mind a delay (even of a couple of weeks). If "we all know who they are," then why haven't their ISPs been notified of their activities?
My understanding is that the restrictions on email are not for email within grex, but rather for mail going from grex to the rest of the Internet. So what if there's some set of users who are in some area code local to michigan who can only use grex as their email source? Adjust the technology so they're not shut out, or ask them to contribute to grex financially in some way. Or, introduce another class of users who are somehow considered `verified.' Verification could be by becoming a member (one of the requirements for membership is that your identity is verified by the treasurer), or by going through some other process (logging in from a dialup or sending a letter via US mail to grex, for instance). Verification gets you onto the green sheet to send email offsite. Perhaps someone doesn't want to pony up the $6 a month to become a member. Okay, fair enough, but are you serious telling me they can't come up with 50c for a stamp, envelope, and sheet of paper? Don't think of it as a ``member perk.'' Create another class of users, of which members may be a subset, who are verified and therefore trusted to send offsite email.
I wouldn't object to that, either, except that verification of non-US users (some of whom may not have other email -- I'm thinking of something in the discussion the *last* time this was brought up) would cost them more than 50 cents.
verification involves too much staff time. even just verifying members means somebody has to physically do it, and grex isn't paying anyone for that time
Only new members are verified, not all 47 or so of us every year. How many new members do we get in a year? And how many people do you think would write grex asking for outgoing email in a year? They could send $1 to sdf instead and get a much bigger mailbox.
The people you introduce to computers and to Grex are the people I was thinking of, Keesan. The verification idea was intended as something to allow them email while restricting it for the rest of the nonmembers. (If SDF has a local dialup phone line in the 734 area code, I wasn't aware of it.)
FOr $7/month you can get sdf-related internet connection, with sdf as your email and webspace provider. Local phones all over the country. Anyone living in Washtenaw County should be able to afford $6/month and if not, come up with a good reason why they should be subsidized to be a member.
I think the idea that providing a service to someone is "subsidizing" them is foreign to the central principles of Grex -- *open access.* I suggest that everyone look at the precedent vote (found in /usr/local/grexdoc/archives/votes/vote02); the primary reason for restricting access to ftp, telnet, etc., was that they took up too much bandwidth. I have no objections to requiring some sort of verification (which is what that motion said the Board could do once the link increased), but I worry at discriminating against either local (734 area code) or international users.
Most of my spam has international 'from' addresses such as .de and .cn. Low income residents of our county can qualify for $150/month of food stamps. I will gladly buy $6/month of food from any of them that can't come up with $6/month to be a grex member and use outgoing ftp and telnet.
Eliminating modems or restricting services to members only is a change to Grex's basic mission, and could jeopardize our 501(c)3 status with the IRS. See Grex's 501(c)3 application at http://www.cyberspace.org/local/grex/501c3.html for what they expect of us now.
but grex already restricts some things to members, like outbound telnet and ftp right?
Yes, but for the primary consideration of *bandwidth*. I suggest you read the precedent-setting vote.
Regarding #90; Then come up with a way to make it easy; use the technology. For instance, Grex considers receipt of money from an account that's been verified on paypal as sufficient verification. Why wouldn't sending a penny via PayPal be considered sufficient for verification purposes? Perhaps we could consider some sort of vouch-for program where members could verify the identity of other users (here, I'm thinking specifically of users who are set up with grex access by, say, Sindi and Jim). We could consider some sort of call-back verification for dial-in users, similar to how BBS's used to operate in the dial-up world back in the day. Most of this would be handled electronically with a minimim of manual intervention. Regarding #96; I don't think you need to make it ``members only.'' But it is reasonable to impose some level of verification on the process, and I don't see why members shouldn't be allowed to verify users. That said, I don't see why getting rid of dialin access would be a fundamental change in grex's mission.
It is not necessary to verify the identity of every user. Users who connect through a service that requires identification to get the service, are already identified to a sufficient extent, ie. educational institutions, users who use their employer's access, etc. It's the commercial services that sell access to anyone for money, that is the problem. Yahoo and Yahoo Korea, are two that produce a lot of spam.
So do we allow access to anyone coming from an .edu? Is there a list of trustworthy ISPs somewhere? Would every applicant for outgoing email have to be manually checked out?
Regarding #100; Not true. There are plenty of public kiosk settings at, say, universities that don't require any sort of authentication to use. Blindly applying a regular expression to the connecting hostname is not a good idea. You are correct that you don't need to verify every user, though.
Listen, if the government becomes more draconian in its attempts to regulate the 'net, grex may one day be REQUIRED to verify all users. As it is, some terrorist living in the U.S. could log on to grex using an anonymizer to hide his location, and using an anonymously generated login, and pass along terrorist information to his people back at home. It is safer than calling them on the phone since we all know they wiretap international phone records now. Also someone who is into child porn and wants an email to use for such correspondence, would be far safer using a Grex email than a Yahoo or Hotmail email. Grex doesn't require any verifiable personal info to take out a login. I am sure the Homeland Security Department would love to shut a place as open as Grex down, if they were aware of it.
Ok, terrorists using Grex. This conversation has gone too far.
Won't someone PLEASE think of the children?
richard's absolutely nuts !
I really doubt grex is on anyone's anti-terrorism radar.
talk to bap.
Re #99: Dan: Dial-up access is an essential part of Grex's chritable mission for a number of reasons, not least of which is that we told the IRS it was an essential part of our charitable mission. If we were to eliminate our phone lines, we would have to notify the IRS, and they might cancel our 501(c)3 status.
Does m-net have dialup? Do they have 501(c)3 status?
Regarding #109; Huh? That's a thin argument, I think. I do see where dialins are mentioned on the application for 501(c)3 status, but it also seems to me that that could be amended in light of changes in technology and undue financial burden that would jeopardize the rest of grex's mission, etc. Note that no where in the articles of incorporation are dialins mentioned; only computer conferencing. Regardless, I'm not sure why removing the dialin lines is at issue right now.
It isn't. Removing dialup access would reduce operating costs, and would be an option if Grex's income continued to decline.
Re #110: M-Net's application was different than Grex's. The rules say that if you change your charitable activities, you must notify the IRS of the change. Frankly, I think keeping those dialins open is the most charitable thing that Grex does, and I'm proud that we do it.
Regarding #113; It makes sense as long as people use them. But keeping them around if they're not used, or only rarely used, makes little sense.
Re #114: Charity rarely makes economic sense -- if it did, it wouldn't be charity. So long as there are users who use the dialins, I think they should be left open. (If it were between closing the dialins and closing the Internet link I would be in favor of the latter, personally, but I suspect I'm in the extreme minority on that point.)
So a charity that offered sliderules to the masses would be putting its resources to good use? Like I said, as long as they're using them, I don't have a problem with it. Once they stop, it would be foolish to continue offering the service.
Re #116: I didn't say that. It *would* be performing a charitable function, however.
I use the dialin lines several times a day.
User's from .edu domains can be checked against the institutuion' online directory. Public access users would not be listed there. At the University of Michigan, public access users cannot e-mail.
What does that have to do with anything?
re #119: Strictly hypothetically, let's imagine that someone logs in and tries to send 10,000 spam messages from an IP address that reverse-lookup tells us belongs to a student computer lab at a large public university, for example UCLA. What good do you suppose that knowledge does us? Do we know who to contact at potentially any .edu-listed institution across the country if we have a problem? Will that person respond to our inquiries? Even if we do and even if they would, who's going to be willing to spend their time trying to track down each spammer that way? I'll grant that people connecting through a .edu address might be less likely to spam than other users (I don't know that for a fact, or have any real reason to believe it, but I'll certainly admit the possibility and even accept it for the sake of argument..) But so what?
re #104 Is that so hard to believe?
Without proof? You bet.
WMD are hidden on Grex
I think triludaa has some Weapons of Mass Disturbance.
Do you think he tested them on himself?
I think, that while it's possible that terrorists could use grex, it's pretty unlikely. Why wouldn't they go for something easier?
Well, one thing we know about Grex is that "It gets easier.."
Maybe there's a sleeper cell in the 734 area code who isn't very well funded and can't afford a real ISP.
Maybe GMail is only a matter of time and AOL and Yahoo mail are obviously not viable communication mediums?
For what, though? Yahoo and AOL might be the obvious choices. Steganographic techniques are still pretty effective. Not to mention random postings on blogs, and the like. Terrorists communicating via Bill O'Reilly's blog would almost be poetic.
If I were part of al Qaeda I'd make sure to hide my messages in freerepublic posts..
Why hide them? *snicker*
I thought it was pretty obvious by now that terrorists DO communicate via Bill O'Reilly's blog.
Yes, but we're talking about so-called "Islamo-fascists", not the regular kind.
Fornier seems more like a Sean Hannity type...
OK, here is a simple verification scheme. New users get a restricted account. To get the unrestricted account, they must send Grex a self addressed stamped envelope. Someone at Grex sends them in this envelope, a computer generated random password. The user must report this password online to the Grex staff who then removes the restrictions. Perhaps this last step could be automated. This process uses the postal service to verify the name and address of the user, or at least that the name and address are valid and the user is receiving mail there.
I think i get around 3 - 5 help requests every few days asking about how to get outgoing mail. I tell them is down for now for new users. so i was thinking about something. would it be hard to setup a database of longtime trusted users <those of us that have been here since mid 90's> to have outgoing and incoming e-mail privilages, and those who are new <within a few months> not alowed outgoing/incoming e-mail unless they pay for an account here?
How about a new category of half-member, who pays $3/month for outgoing mail and does not get telnet or ftp privileges? If spammers are not willing to pay $6/month, probably they would not pay $3 either.
I think making them pay for it may be unnecessary. Simply require some sort of verification -- a couple of cents from Paypal could be one way (Paypal adds a random number of cents to your bank account, then asks you how many it added, to verify that it is in fact yours), while meeting someone official in person could be another. The typing-in-a-word-on-the-screen thing could be a first line of defense.
Paypal does not work with the three browsers I tried it with (the ones at grex).
yea, and i know a lot of people arent comfortable using paypal, or other means of online payment, and that may not have checking accounts or access to a moneyorder.
That's why I suggested it as "one way."
Another way is to send a dollar bill in the mail.
The trouble with that, unfortunately, is that it a) requires someone to sort through it and b) isn't really authentication, just a hoop to jump through, like the typing-in-the-word thing. The three advantages to Paypal are that they do authentication for us, one person couldn't use more than one (Paypal) account (so we'd know if one person were setting up a thousand accounts with email), and it would be relatively easy (I suppose) to automate. This is not to say that Paypal ought to be our only method.
I'm not sure it follows that the phishers (who seemed to have been the biggest mail problem-users before we shut things down for new users) won't have access to multiple identities to register with.. However it's probably sufficient to make registration for mail cumbersome enough and difficult to automate to discourage the majority of the problem users.
(My references to automation were on the system staff end -- part of objections to previous suggestions was that the staff are volunteers and can't afford to devote large amounts of time to Grex.)
I dont understand. I have 3 paypal accounts.
TROGG IS DAVID BLAINE
You have several choices: