|
|
| Author |
Message |
| 25 new of 149 responses total. |
bhoward
|
|
response 70 of 149:
| 
Jan 13 05:39 UTC 2006 |
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.
|
wlevak
|
|
response 71 of 149:
|
Jan 14 05:37 UTC 2006 |
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.
|
janc
|
|
response 72 of 149:
|
Jan 14 20:23 UTC 2006 |
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.
|
keesan
|
|
response 73 of 149:
|
Jan 15 00:33 UTC 2006 |
Can you also limit the number of new accounts that can be opened in one day
from some IP address?
|
wlevak
|
|
response 74 of 149:
|
Jan 16 00:27 UTC 2006 |
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.
|
wlevak
|
|
response 75 of 149:
|
Jan 16 00:35 UTC 2006 |
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?
|
richard
|
|
response 76 of 149:
|
Jan 19 15:39 UTC 2006 |
just make offsite email a members only perk. I've suggested this in the past.
nobody needs grex for free email anymore.
|
kingjon
|
|
response 77 of 149:
|
Jan 19 18:45 UTC 2006 |
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.)
|
jadecat
|
|
response 78 of 149:
|
Jan 19 19:45 UTC 2006 |
Technically no one NEEDS e-mail at all. Or the internet. Or water beds.
But there are people who want those things.
|
mcnally
|
|
response 79 of 149:
|
Jan 19 19:57 UTC 2006 |
re #78: exactly. Let's not talk about "needs".
|
spooked
|
|
response 80 of 149:
|
Jan 19 20:49 UTC 2006 |
Yeah, but if they want it they have a zillion other places they can find
it - so that argument is just as shakey.
|
kingjon
|
|
response 81 of 149:
|
Jan 19 20:59 UTC 2006 |
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.
|
nharmon
|
|
response 82 of 149:
|
Jan 19 21:04 UTC 2006 |
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.
|
kingjon
|
|
response 83 of 149:
|
Jan 19 21:09 UTC 2006 |
(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.
|
richard
|
|
response 84 of 149:
|
Jan 19 21:20 UTC 2006 |
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.
|
twenex
|
|
response 85 of 149:
|
Jan 19 21:24 UTC 2006 |
My, to WHOM could you be referring?
|
richard
|
|
response 86 of 149:
|
Jan 19 21:24 UTC 2006 |
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...
|
kingjon
|
|
response 87 of 149:
|
Jan 19 21:28 UTC 2006 |
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?
|
cross
|
|
response 88 of 149:
|
Jan 19 21:40 UTC 2006 |
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.
|
kingjon
|
|
response 89 of 149:
|
Jan 19 21:43 UTC 2006 |
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.
|
richard
|
|
response 90 of 149:
|
Jan 19 22:00 UTC 2006 |
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
|
keesan
|
|
response 91 of 149:
|
Jan 19 22:25 UTC 2006 |
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.
|
kingjon
|
|
response 92 of 149:
|
Jan 19 22:28 UTC 2006 |
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.)
|
keesan
|
|
response 93 of 149:
|
Jan 20 01:02 UTC 2006 |
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.
|
kingjon
|
|
response 94 of 149:
|
Jan 20 01:40 UTC 2006 |
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.
|