|
|
| Author |
Message |
| 25 new of 149 responses total. |
bhoward
|
|
response 44 of 149:
| 
Jan 9 07:09 UTC 2006 |
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.
|
keesan
|
|
response 45 of 149:
|
Jan 9 14:23 UTC 2006 |
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?
|
ric
|
|
response 46 of 149:
|
Jan 9 17:21 UTC 2006 |
You'd be surprised at how many spam messages you could fit into 100k.
|
ric
|
|
response 47 of 149:
|
Jan 9 17:26 UTC 2006 |
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"
|
aruba
|
|
response 48 of 149:
|
Jan 10 02:41 UTC 2006 |
How could you execute a spam script from the web?
|
cross
|
|
response 49 of 149:
|
Jan 10 04:42 UTC 2006 |
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.
|
albaugh
|
|
response 50 of 149:
|
Jan 10 17:13 UTC 2006 |
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?
|
krj
|
|
response 51 of 149:
|
Jan 10 17:36 UTC 2006 |
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.
|
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
|