|
Grex > Coop13 > #222: Where to stop spam: before or after it reaches grex? | |
|
| Author |
Message |
gelinas
|
|
Where to stop spam: before or after it reaches grex?
| 
Dec 5 05:55 UTC 2004 |
At the grex-walk debrief today, the conversation turned to the prevalence
of spam and the various ways of combatting it. It occurred to me to ask:
is it time to change our philosophy of how best to reduce the flow?
Historically, we (grex, cyberspace communications, inc) have worked to
prevent the spam ever crossing our link. Of late, that effort has seen
decreasing success.
The off-the-shelf tools for stopping spam do not, as near as I can tell,
work before the mail crosses the link: The tools are separate from SMTP
and have to receive the message to judge its fate.
If we are willing to sacrifice the band-width, there are several anti-spam
programs we could make available to our community. Is it time to sacrifice
the bandwidth?
|
| 18 responses total. |
gelinas
|
|
response 1 of 18:
|
Dec 5 05:57 UTC 2004 |
If/when we move to a co-location site, we should get more bandwidth, so the
sacrifice would not be as painful.
Also, the solution decided upon would be implemented on the new machine, not
on the current grex.
|
prp
|
|
response 2 of 18:
|
Dec 5 21:27 UTC 2004 |
Why not go with both?
I'm currently using three: Grex, Comcast, and Mac OS X Mail. I don't know
how much Grex stops, but Comcast gets about fourteen/week and Mail gets
about four/week.
It might be nice kept a list of stuff that got stopped and sent a weekly
summary.
|
prp
|
|
response 3 of 18:
|
Dec 5 22:06 UTC 2004 |
Does Voyager offer any spam filtering service? If so, could the mail be
run through it before going to Grex. Co-location would mean changing ISP's.
Do the canadites offer spam filtering?
|
gelinas
|
|
response 4 of 18:
|
Dec 6 04:46 UTC 2004 |
To run our mail through our ISP's spam filters, we'd have to have all of our
mail delivered to their mail servers. I've not thought that this is something
we would want to do.
|
tod
|
|
response 5 of 18:
|
Dec 6 06:52 UTC 2004 |
I think the least administrative burden would be to run spamcop and an
aggressive global procmail setting which diverts positives to /dev/null
This should be further explored. Glad folks on the A2 Grexwalk thought of
it. ;)
|
dpc
|
|
response 6 of 18:
|
Dec 6 14:09 UTC 2004 |
How much bandwidth are we talking about sacrificing?
|
tod
|
|
response 7 of 18:
|
Dec 6 17:40 UTC 2004 |
No more bandwidth than currently being utilized. Its more about CPU
utilization.
|
cross
|
|
response 8 of 18:
|
Dec 8 03:27 UTC 2004 |
Realistically? Not that much. Realize that most spam gets through
grex's spam blocks; the amount we block is negligable compared to the
amount we get. So filtering it on this side of the DSL link isn't
really much of a bandwidth hit. But I've been saying this for years
and been mostly ignored.
|
dpc
|
|
response 9 of 18:
|
Dec 8 14:48 UTC 2004 |
I'm not in favor of ignoring people with good suggestions.
|
tod
|
|
response 10 of 18:
|
Dec 8 18:57 UTC 2004 |
I second Mr.Cahill's motion.
|
krj
|
|
response 11 of 18:
|
Dec 10 23:03 UTC 2004 |
The two approaches are not mutually exclusive; setting up
a system to deal with the spam after it arrives on Grex does not
preclude efforts to stop it from being transmitted here.
|
cross
|
|
response 12 of 18:
|
Dec 11 00:25 UTC 2004 |
Regarding #11; That's true as well. There's no reason we can't try
and have the best of both worlds.
|
gelinas
|
|
response 13 of 18:
|
Dec 11 04:17 UTC 2004 |
I find that two spam filters are worse than one, not better, when the goal
is individual control over the definition of spam.
|
cross
|
|
response 14 of 18:
|
Dec 11 19:25 UTC 2004 |
Well, the thing is, some things you just *know* are spam. Or virii. Or
something of the like. There's no reason for the system to not filter
those. Users are then free to filter whatever they like.
|
prp
|
|
response 15 of 18:
|
Dec 12 02:15 UTC 2004 |
Individual control would mean not blocking anything from getting to
Grex, but seperating the junk mail from the rest, so people can take
a look and see what is getting diverted.
Although I suppose it would be possible to do this at the ISP end.
|
other
|
|
response 16 of 18:
|
Dec 12 16:42 UTC 2004 |
Sure. Just add a header identifying the spam as such at the ISP and
filter for it locally.
|
devnull
|
|
response 17 of 18:
|
Dec 14 05:37 UTC 2004 |
Individual control has disadvantages, though, too.
If you block spam before the SMTP session completes, then you can give the
sender an error message, so that if there's a false positive, the sender
is likely to know that the message was rejected. Most approaches to individual
filtering hope that the reciever bothers to go looking for false positives,
which the reciever may not actually bother to do. (You could in theory
send a bounce message after the fact, with the individual approach,
but then you're hoping the return addresses are valid, and you might end up
effectively acting as a relay to send spam to some third party if the sender
address was forged, and forging return addresses is trivial.)
Also, there is a technique known as greylisting can only be done on the smtp
server recieving the mail. (The basic idea is that many (but not all)
spammers do not bother to retry if they get a temporary failure, and real
mailers do retry unless they are broken. So you can keep track of which
machines try to contact your SMTP server, and if you haven't heard from them
recently, you give a temporary failure, perhaps for an hour or so, after
which you let mail through.)
greylisting might reduce the amount of bandwidth used by spammers, too, if
it gives the temporarily failure at the rcpt to: point in the smtp session.
Of course, it is possible for an smtp server to be told about the preferences
of individual users.
|
jesuit
|
|
response 18 of 18:
|
May 17 02:15 UTC 2006 |
TROGG IS DAVID BLAINE
|