|
|
| Author |
Message |
| 25 new of 105 responses total. |
keesan
|
|
response 75 of 105:
| 
May 18 12:31 UTC 2002 |
Bdh try 'affected' instead of 'impacted'.
|
cmcgee
|
|
response 76 of 105:
|
May 18 13:29 UTC 2002 |
Yay Marcus!
And thanks to bdh for the articulate explanation that, for once [;-)] I
agree with.
|
jmsaul
|
|
response 77 of 105:
|
May 18 19:51 UTC 2002 |
Gee, and here I thought that important issues had to go to a vote of the whole
membership, etc., etc. I'm not suggesting that Grex has to provide tools or
anything, just that this discussion implies that people really had no idea
what was being filtered, and not everyone would be thrilled if they knew.
Remmers didn't seem to be, and I'm not.
|
jp2
|
|
response 78 of 105:
|
May 18 19:59 UTC 2002 |
This response has been erased.
|
gull
|
|
response 79 of 105:
|
May 20 01:32 UTC 2002 |
No computer system can ever be totally democratic. It just doesn't work,
because when it comes down to it, you have to have a few people (or, in some
cases, a single person) who are responsible for the integrity of the
hardware and software. The final decision almost always rests with the
person who actually does the work.
|
jmsaul
|
|
response 80 of 105:
|
May 20 02:04 UTC 2002 |
The details certainly do, but if Marcus decided, say, that since he did the
work on Picospan, he has the right to censor people's responses at will, you'd
agree that that's over the line. Right?
Now, I realize that there are important differences between the two
situations. I'm just trying to make the point that there's a line somewhere
between what it's okay for staff to do without consulting other people, and
what they really shouldn't do unless the citizenry wants them to. You may
feel that censoring responses is on the "shouldn't" side and filtering any
message containing the text of a specific Senate bill is on the "okay" side,
but there really are two categories of things here. It can sometimes be very
hard to tell where the line is even if you generally agree on it.
Me, I think what he's done is understandable, and being Marcus he's probably
done a fairly targeted job of it, but I'm really not convinced it's on the
"okay" side. I'm sort of disturbed that remmers -- who I also have a lot
of respect for, both as a technical expert and an ethical human being --
didn't even know it was happening.
|
gelinas
|
|
response 81 of 105:
|
May 20 02:15 UTC 2002 |
I'm surprised remmers didn't; I've not been around here nearly as long, but
I'd picked up on it. It's one of those things I picked up in passing, I
didn't see an announcement in MOTD or an item in a conference, but I knew.
Not as soon as I started using grex, admittedly; it took a while to find out,
but I don't use grex for mail so I didn't have a (personal) need to know.
|
gull
|
|
response 82 of 105:
|
May 20 12:38 UTC 2002 |
I knew there was spam filtering going on, but I didn't know the specifics.
Let's keep this in perspective; he targeted a specific phrasing that
occurred in a lot of spam messages. It's not as if every message that
happened to mention that senate bill was going to bounce. It's also very
obvious when the filter kicks in, so it's not like your email is somehow
being censored without anyone being aware of it, either.
|
tpryan
|
|
response 83 of 105:
|
May 20 12:54 UTC 2002 |
I've seen it discussed here in agora, more likely system problems
or system announcement items. I recognize it is something you shouldn't
get specific details about in a public forum, but was assured that Marcus
would be glad to discuss more in a F2F meeting.
|
jmsaul
|
|
response 84 of 105:
|
May 20 13:25 UTC 2002 |
Re #82: Your *inbound* mail is, isnt it?
Re #83: I really don't think spammers read BBS.
|
cmcgee
|
|
response 85 of 105:
|
May 20 14:13 UTC 2002 |
If I want to know the gory details (is there a geek equivalent for "gory")
I'd read Garage, or some other techie conference.
|
gull
|
|
response 86 of 105:
|
May 20 15:22 UTC 2002 |
Re #84: Trust me, if someone tries to send me mail and it bounces with a
weird message, I *will* hear about it.
If you really want this changed, of course, the thing to do would be to
go over to co-op and make a proposal.
|
oval
|
|
response 87 of 105:
|
May 20 20:16 UTC 2002 |
isn't that why this sytem has a pretty "democratic" hierarchy of permissions?
marcus isn't doing anything secretive or abusing power, and if he was, there
are people who would pick up on it ..
|
jmsaul
|
|
response 88 of 105:
|
May 21 00:12 UTC 2002 |
We are.
Re #86: I know. I also remember what that was like last time. Grexers
are more resistant to change than Buchanan voters.
|
mdw
|
|
response 89 of 105:
|
May 21 07:05 UTC 2002 |
The "to" address has no necessary connection with where mail is actually
delivered. Think of it this way: if you were to forward your mail to
"beedy@chinet.com", you should expect that when it shows up at chinet,
it will still be addressed to your grex address in the To: field (To
field is not supposed to be rewritten by mail software.) Spammers can
take advantage of this to route their mail right off to one set of
address, and put a completely different address in the To: field. So,
in many cases, the To: address isn't yours, but some "generic" address.
Grex looks for some of the most common ones, like "To: sales@grex.org",
and throws those out. Alas, the spammers have figured this out; last
week, the generic rule didn't catch any spam. There is, unfortunately,
an arbitrarily large population of less obvious "generic" addresses so
it's hard for grex to reject all of them. Judging from the above, it
would also be bad to reject some of those less obvious choices.
|
jmsaul
|
|
response 90 of 105:
|
May 21 15:59 UTC 2002 |
Why don't you filter based on quantity per unit time? Or just throttle how
fast the mail goes ou;t for large quantities?
|
remmers
|
|
response 91 of 105:
|
May 21 16:38 UTC 2002 |
I'm glad that this discussion has come up, and that Marcus is sharing
information about what he's set up in the way of mail filtering.
<remmers believes in an informed citizenry>
|
mdw
|
|
response 92 of 105:
|
May 21 22:15 UTC 2002 |
UCE typically shows up in small spurts, from many different sources,
usually but not always external, over a wide period of time. Throttling
could only help with flagrant internal problems; UCE is generally
neither of these. Technically we do actually "throttle" outgoing mail,
but this doesn't actually stop any mail from going out, it just slows
big pieces of mail down so that they don't saturate all available
network bandwidth. If spam were easy to detect/defeat, there would be
no spam. There are no quick & easy answers to eliminating spam.
|
bdh3
|
|
response 93 of 105:
|
May 23 05:45 UTC 2002 |
But you are doing an excellent job at it, better than most.
|
russ
|
|
response 94 of 105:
|
May 28 01:39 UTC 2002 |
Re #33: Instead of merely blocking spam, would it be possible for
Grex to use one of the "spamtrap" schemes where the mail connection
gets really S-L-O-W after it detects a spam pattern? This would
screw up the spammer's operation and perhaps congest the relay
they're using, which might make the relay's operator look at it
to see what's wrong. If they take it off-line, the spammer loses
badly.
|
jmsaul
|
|
response 95 of 105:
|
May 28 02:16 UTC 2002 |
That's a good idea, I think.
|
mdw
|
|
response 96 of 105:
|
May 28 03:04 UTC 2002 |
Problem with that is many spammers and relay machines have more network
bandwidth and CPU, relative to the problem, than we have; what hurts
them hurts us more. This strategy might be more effective, on directly
connected mail machine (with a small number of users). Doesn't work so
well where a large number of users share the same machine, so a
considerable amount of mail, both legitimate & spam, gets sent by the
same relay. Besides, for less legitimate relay machines, I don't think
the people operating them understand enough to recognize weirdly slow
mail delivery. What could we do to them that's as bad as sending the
spam in the first place?
|
russ
|
|
response 97 of 105:
|
May 28 21:39 UTC 2002 |
Re #96: Quite the opposite, Marcus: this hurts them more than us,
by congesting the sender's or relay's resources. I know that there
are systems for making it appear as if the link to the mail handler
is highly congested, throttling the transfer rate down to a few tens
of bytes per second. This forces the sender to keep the connection
open much longer to send the message, which means the process thread
and other resources are held much longer. And as long as there is
an open connection, it probably keeps the relay from opening another.
Throttling a spammer's relay down to 50 bytes/sec would be good for us.
Enough people doing it makes life really hard on spammers because they
can't get mail through, no matter how much bandwidth they have; their
process limits become the critical factor.
|
mdw
|
|
response 98 of 105:
|
May 29 01:24 UTC 2002 |
Right. As long as there's an open connection, the relay host probably
won't open another connection. That means *legitimate* mail piles up
behind the spam. That's where the rub lies.
|
gull
|
|
response 99 of 105:
|
May 29 13:04 UTC 2002 |
If the people running the relays were clueful enough to notice that kind of
thing, they wouldn't be running open relays to begin with.
|