|
|
| Author |
Message |
| 25 new of 149 responses total. |
krj
|
|
response 52 of 149:
| 
Jan 10 17:40 UTC 2006 |
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.
|
ric
|
|
response 53 of 149:
|
Jan 10 18:04 UTC 2006 |
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.
|
krj
|
|
response 54 of 149:
|
Jan 10 21:10 UTC 2006 |
I should have phrased #51 as "Nobody knowledgable..." rather than
"Nobody intelligent..."
|
cross
|
|
response 55 of 149:
|
Jan 11 02:12 UTC 2006 |
Regarding #54; You shouldn't assume that the people who run either ISPs or
blacklists are either.
|
bhoward
|
|
response 56 of 149:
|
Jan 11 15:04 UTC 2006 |
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.
|
cross
|
|
response 57 of 149:
|
Jan 11 18:38 UTC 2006 |
Outstanding.
|
bhoward
|
|
response 58 of 149:
|
Jan 11 19:11 UTC 2006 |
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).
|
cross
|
|
response 59 of 149:
|
Jan 11 19:49 UTC 2006 |
True, but there's a big difference between upas and what passes for
mailers these days. :-)
|
tod
|
|
response 60 of 149:
|
Jan 11 21:46 UTC 2006 |
re #56
THANKS!!!
|
keesan
|
|
response 61 of 149:
|
Jan 12 00:07 UTC 2006 |
How do you plan to authorize new users?
|
bhoward
|
|
response 62 of 149:
|
Jan 12 01:24 UTC 2006 |
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.
|
kingjon
|
|
response 63 of 149:
|
Jan 12 01:55 UTC 2006 |
I thought the question was "how do you plan to authorize them *in this
temporary stopgap measure*?"
|
aruba
|
|
response 64 of 149:
|
Jan 12 03:39 UTC 2006 |
Thanks Bruce! Great job. And thanks also to STeve for dealing with the
spammers.
|
bhoward
|
|
response 65 of 149:
|
Jan 12 05:02 UTC 2006 |
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.
|
naftee
|
|
response 66 of 149:
|
Jan 12 05:32 UTC 2006 |
whoa !
bruce is great
|
mary
|
|
response 67 of 149:
|
Jan 12 10:35 UTC 2006 |
Thanks so much, Bruce!
|
ric
|
|
response 68 of 149:
|
Jan 12 16:52 UTC 2006 |
great work bruce.
BTW, it's CAPTCHA
|
slynne
|
|
response 69 of 149:
|
Jan 12 17:26 UTC 2006 |
Thanks bruce!
|
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.
|