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.
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.
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.
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?
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.
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. ;)
How much bandwidth are we talking about sacrificing?
No more bandwidth than currently being utilized. Its more about CPU utilization.
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.
I'm not in favor of ignoring people with good suggestions.
I second Mr.Cahill's motion.
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.
Regarding #11; That's true as well. There's no reason we can't try and have the best of both worlds.
I find that two spam filters are worse than one, not better, when the goal is individual control over the definition of spam.
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.
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.
Sure. Just add a header identifying the spam as such at the ISP and filter for it locally.
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.
TROGG IS DAVID BLAINE
You have several choices: