Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

158 comments

Why to Use this (2, Informative)

neonprimetime (528653) | more than 7 years ago | (#16058985)

The HowtoForge guide is great for everything however if you have a very busy mail server running Spam Assasin on 1000s of message per minute is a CPU killer. The best answer is to stop the mail before it hits Spam Assasin with a range of RBL (Realtime Blacklists) and RHBL (Same but different), Greylistings and Helo Checks.

Yeah, but... (3, Insightful)

cp.tar (871488) | more than 7 years ago | (#16058988)

... aren't blacklists still a bit... tricky?

Re:Yeah, but... (1)

TheBogBrushZone (975846) | more than 7 years ago | (#16059509)

... aren't blacklists still a bit... tricky?

They can be a real pain if your ISP isn't doing as much as they should against botnets. On a few occasions I've been unable to send mail because my ISP (NTL) is less than rigorous in that respect and have been blacklisted by SpamCop [cableforum.co.uk] and others [cableforum.co.uk] . Even now I can't report spam using SpamCop's email submission service because a number (not all) of NTL's mail servers are apparently blacklisted.

Re:Yeah, but... (1)

jank1887 (815982) | more than 7 years ago | (#16059548)

yes, but I'd also qualify running a capable high-volume mailserver as a little bit ... tricky.

RBL's are rather reliable, having few false positives from a server listing point of view. That said, you will have collateral damage from other users of shared spamming mailservers. There's no way around that, and less-than-clueful business customers will get upset about non-delivery of email. Most issues can be avoided by making customers fully aware of your mailhandling policies, and offer easy whitelisting, or customer adjustable blocking preferences.

Some RBL's recommend greylisting all RBL'd servers, and automatically flagging anything that gets through as junk/spam. Then, the legit email will have gotten through, and you need to let your server customers know to periodically review their junk folders for legit mail. Avoids the SpamAssassin overhead on those messages that get through, and blocks receipt of most of the real junk.

Re:Yeah, but... (2, Interesting)

bogado (25959) | more than 7 years ago | (#16059740)

The only problem is that the customer never knows that his email is being droped. He things that the receiver got the email and choosed to ignore it, simply because it never got returned. And you know what? He is right to think like that, if an email has not returned it should be assumed as delivered.

The problem with those black lists is that is quite easy to get in one of those and is near impossible to get out. The number of false positives that those RBL produce is huge, and this means a huge number of people not receiving emails. I had a friend that almost could not get into an international congress because she did not got any replys from the congress email because it's university was in one of those black lists.

I do not advise anyone to use black lists. There are many good ways to get rid of spam that do not have false positives, like gray listing. Check this out [acme.com] , this guy has a very good analisys of the problem and the solutions he used.

Re:Yeah, but... (2, Informative)

jank1887 (815982) | more than 7 years ago | (#16060031)

did you even read the post you replied to? either way, a response:

1)The only problem is that the customer never knows that his email is being droped
Very true, and a sign that the mailserver is making poor use of blacklists. A rejection notice should always be sent. Proper use of blacklists will, as I mentioned above, either allow the message through, but tag it, or notify the sender that it was rejected, providing alternate means of contact or correction.

2)The problem with those black lists is that is quite easy to get in one of those and is near impossible to get out
Quite easy to get in: if your mailserver is sending out lots of spam, yes it is, and it should be. It is the sign of a mailserver that is misconfigured, insecure, or just has bad policies.
Near impossible to get out: It seems you have moved to describing BL's, not RBL's. A Realtime BlockList is supposed to list a mailserver upon significant spam amounts coming from it, and then de-list after the problem has been corrected. Correction doesn't equal "Hey, we have ligit mail over here, let us through please!!!" It means ending the flood of spam from the server. the onus is on the server operator to be a good net-citizen. otherwise, our servers don't want to talk to his servers. Some blocklists are overagressive, and have poor de-listing practices. It's the implementing admin's job to understand the lists he implements and the potential impacts of those lists.
As I mentioned above, alternate forms of contact and customer whitelisting capability are crucial if you are actually blocking mail. RBL's are very effective when used conscientiously. Combined with grey listing, they can cut your 'processed' spam (i.e., what you pay to handle) down to almost nothing.

Re:Yeah, but... (2, Insightful)

CerebusUS (21051) | more than 7 years ago | (#16060728)

I'd agree with you _if_ the only reason a server ever got put onto an RBL was due to relaying and misconfiguration. The trouble is that some addresses are inevitably put on the list due to a disagreement about terms of service or what constitutes "spam."

As the network admin for a consulting company, I'll never use an RBL on our mail because any lost communication from a customer or potential customer costs us more than potentially allowing some spam through (or buying larger hardware to handle better spam detection)

Re:Yeah, but... (1)

element-o.p. (939033) | more than 7 years ago | (#16060639)

I do not advise anyone to use black lists. There are many good ways to get rid of spam that do not have false positives

That seems a little bit optimistic, to me. I used to work at an ISP that had a sendmail farm as a front-end for an i-Planet mail server (grrr....), and you could tell when the spammers would unleash a flood from botnets on other ISPs' networks: the sendmail farm would grind to a halt, delaying legit mail from our users by 1-5 hours, at times.

You simply *cannot* filter that much mail real time without denying e-mail from known spam sources out of hand; if your domain is well-known enough, blocking by RBL becomes a matter of survival, not convenience.

Besides, I am reminded of a quote (as best as I remember it) by Paul Vixie, the author of Bind and Vixie cron, I believe, on the Nanog mailing lists:
We know that blacklists hurt spammers because of the changes they make to get around them. And anything that hurts spammers, we should be all over.
(My apologies to Paul if I didn't get the quote exactly right)

They are, but it's... (0)

Anonymous Coward | more than 7 years ago | (#16059572)

collateral damage.

Re:Yeah, but... (3, Interesting)

jrockway (229604) | more than 7 years ago | (#16059904)

I'm having excellent luck with OpenBSD's spamd blacklisting and greylisting. Haven't lost any important mail, but my SPAM has been cut by about 98%. It's truly amazing.

http://www.openbsd.org/spamd/ [openbsd.org]

Re:Yeah, but... (0)

Anonymous Coward | more than 7 years ago | (#16060111)

Haven't lost any important mail,

How do you know?

Re:Yeah, but... (1)

Lord Ender (156273) | more than 7 years ago | (#16060542)

What do you think SPAM stands for?

Re:Yeah, but... (1)

jrockway (229604) | more than 7 years ago | (#16060917)

Nothing, but everyone else capitializes it these days, so "SPAM" looks correct now. Thanks for your insightful comment, though; I appreciate it.

Re:Yeah, but... (1)

Lord Ender (156273) | more than 7 years ago | (#16061232)

"everyone else capitializes it these days"

Sure, if by "everyone," you mean "a small minority."

But I'm always willing to share insight with the sightless masses.

Actually, I'm doing you a favor. Just like someone would be doing the President a favor if they mentioned to him that he was pronouncing "nucular" incorrectly.

Re:Yeah, but... (1)

ajs (35943) | more than 7 years ago | (#16060321)

Yes, blacklists are tricky. You need to find one whose philosophy you and your users are willing to live with. This is why I use Spamhaus's SBL/XBL list which excludes only those hosts which are known problems. I happen not to agree with the philosophy that I should not be allowed to recieve mail from a network that has one spammer on it. Others disagree and wish to exclude the whole network. Salt to taste.

RBLs and not getting your mail (1, Insightful)

BadAnalogyGuy (945258) | more than 7 years ago | (#16058995)

If you're running the mail servers for a business, how prudent is it to run a spam filter in the first place? While using something that relies on checking the content of the mail may be useful in getting rid of the most egregious spam, you don't want to block all items identified as spam. You can't run the risk of blocking your customers.

RBLs are notorious (especially SpamAssassin) for blacklisting entire domains when only a small subset of those users are actually sending spam.

If you're running your own mail server at home, then a whitelist would probably be more useful than a blacklist since you already know who you want to contact you.

But you gotta hand it to the Unix folks for making the task of setting up a spam filter this difficult. I am curious how difficult it would be to set up a spam filter on an Exchange server.

What the heck are you talking about? (2, Insightful)

Anonymous Coward | more than 7 years ago | (#16059017)

You clearly have no understanding of how SpamAssassin works. Blacklists are only one of many negative as well as positive factors that SpamAssassin takes into account when evaluating whether a message is spam or not. You can adjust the score threshold to a level you're personally comfortable with.

I have 3 tiers, ham (non-spam), possible spam (that gets moved into my junk folder), and true spam (really high scores) that gets rejected at the mail server. Also, for anyone else running anti-spam software at the server, DO NOT BOUNCE EMAIL BACK TO SENDERS if you're not rejecting at connect time. If someone used my email address to send spam (not to be confused with my server), I don't want to receive the bounces for it.

Re:What the heck are you talking about? (1)

Ucklak (755284) | more than 7 years ago | (#16059389)

The problem I have, or maybe I haven't figured it out yet, is that 95% of spam (that we get) comes from RIPE and APNIC addresses that are using for hire SMTP servers. The other 5% is from zombie machines on charter.net, rr.com, and other ISPs in the US.

How can I just block out IP addresses instead of domain names without using an external firewall?

Re:RBLs and not getting your mail (2, Interesting)

slapyslapslap (995769) | more than 7 years ago | (#16059029)

If you're running the mail servers for a business, how prudent is it to run a spam filter in the first place? While using something that relies on checking the content of the mail may be useful in getting rid of the most egregious spam, you don't want to block all items identified as spam. You can't run the risk of blocking your customers. Most start out thinking this way. Then they get so burried in spam that they start to think much differently. It CAN be done properly with minimal collateral dammage. A good way to do it is to always send a rejection back to the sender with a reason why. In the event that a real user is rejected, at least they know and can try again via another account, fax, or phone.

Re:RBLs and not getting your mail (3, Insightful)

Ed Avis (5917) | more than 7 years ago | (#16059140)

A good way to do it is to always send a rejection back to the sender with a reason why.
Um, and the 'sender' is who exactly? Please don't tell me you're using the From: address...

Re:RBLs and not getting your mail (1)

Drachemorder (549870) | more than 7 years ago | (#16059341)

If it's a valid business email and not spam, I'd expect that the "From:" address should be meaningful. Granted, spammers wouldn't have valid addresses in the "From:" field, but I don't care whether or not a spammer gets my "rejected" message. I only care about notifying the false positives, and a legitimate email should have a valid address to reply to.

Re:RBLs and not getting your mail (2, Insightful)

shadowmas (697397) | more than 7 years ago | (#16059427)

You might not care if the spammer doesnt get your rejected message. i dont either, but i certainly do care if you're 'rejected' messages end up in my inbox just because some spammer used my email address as his 'From' address. do everyone a favour either reject any spam at the time you recieve it (via a smtp error code) or dont reject it at all. It would be almost the same as havng a open smtp server since spammers can use your server to send spam as backscatter.

Re:RBLs and not getting your mail (1)

emurphy42 (631808) | more than 7 years ago | (#16059494)

No, no, the point is that spammers typically have someone else's valid addresses in the "From:" field, and then you end up spamming that someone else with the bounce message. Unintentional, sure, but you should still fix it (e.g. by checking SPF).

Re:RBLs and not getting your mail (1)

Osiris Ani (230116) | more than 7 years ago | (#16059555)

Granted, spammers wouldn't have valid addresses in the "From:" field, but I don't care whether or not a spammer gets my "rejected" message.

Actually, spam will rather often have a valid address in the "From" field. Unfortunately, it rarely ever has any true association to the originating spammer, but is instead usually simply yet another address culled from their list of potential recipients. Sometimes that address will even be yours.

As such, this practice to which you adhere actually makes you part of the problem; you're sending unsolicited automated replies to people who didn't first attempt to contact you. In other words, your mail server is generating spam, probably in great amounts.

Re:RBLs and not getting your mail (1)

Ed Avis (5917) | more than 7 years ago | (#16059806)

Suppose your normal mail is 90% spam and 10% legit (a pretty reasonable figure if your address is published on the web; my mail is two orders of magnitude worse than that). Then suppose that your spam filter is 90% accurate, in that it tags 90% of spam as spam, and only tags 10% of legitimate mail as spam. (Again, real spam filters usually have much lower false positive and false negative rates than this, after a bit of training.) Then for every one genuine 'rejected' message you send out, you'll send 81 completely bogus messages to forged 'From' addresses. Indeed, your server will be producing almost as much spam as it receives. And once people start getting spam from your mail server, they'll tag it as spam in their mail programs, and your domain and the keywords you use in your rejected messages will get associated with spamminess. You might even get onto a few blacklists. Legitimate mail from your domain will start to be filtered as spam by other people, and as for that one genuine rejection message you were so keen to send out... it's likely to be silently dropped into the recipient's spam folder.

Now I am doom-mongering a bit here. I do still get 'your mail was filtered out' messages from various people, and a lot of the time they don't get marked as spam because each one is different. I don't see any genuine ones, BTW, just bogus ones from worms spoofing mail from my address. The point stands that if you try to send a rejection message for every possible-spam you receive, almost all of them will be bogus and you will be pumping out almost as much sewage as you receive.

Antivirus companies used to be particularly bad at this; see Anti-Virus Companies: Tenacious Spammers [attrition.org] .

Re:RBLs and not getting your mail (1)

farnz (625056) | more than 7 years ago | (#16061018)

If you're running sensibly, your server does the spam checking *before* returning the final 2xx result at end of data. Thus, once you discover that the mail's spammy, you give the server that's sending mail your way a 5xx result, and let it handle sending a bounce mail to the sender. Spam senders tend to just drop mail on 5xx codes, so you've not lost anything.

That way, your mail server never sends bounces. If a server delivering mail to you starts sending backscatter bounces, it's their problem, and they need to find a way to stop it.

Re:RBLs and not getting your mail (5, Informative)

grasshoppa (657393) | more than 7 years ago | (#16059058)

If you're running the mail servers for a business, how prudent is it to run a spam filter in the first place? While using something that relies on checking the content of the mail may be useful in getting rid of the most egregious spam, you don't want to block all items identified as spam. You can't run the risk of blocking your customers.

New to the business? You don't block anything in this situation; You mark it with a header ( that's part of the email message that you would likely never see. Most mailers won't display them unless you ask it specifically to do so ), and leave the blocking/filtering up to the end user.

For my uses, I have spamassassin running with a couple RBLs ( both in house and external ). I don't delete any mail; It is instead redirected to a specific folder when it's identified as spam. Over the past 6 months spam has made it into my inbox twice, and i've had no false positives.

If you know what you are doing, this is the ideal solution.

RBLs are notorious (especially SpamAssassin) for blacklisting entire domains when only a small subset of those users are actually sending spam.

Uh, no they aren't. Spamassassin isn't an RBL.

There are a few RBLs that are notorious for their blocking behavior, and as such, few use them.

If you're running your own mail server at home, then a whitelist would probably be more useful than a blacklist since you already know who you want to contact you.

I'd agree with this; Automated whitelists are the way to go.

But you gotta hand it to the Unix folks for making the task of setting up a spam filter this difficult.

It's only difficult when you don't understand the process.


I am curious how difficult it would be to set up a spam filter on an Exchange server.


Curiously enough, most of the time I hear people recommending placing a spamassassin enabled email server in front of an exchange server if you want decent spam protection.

Overall, I'd give your post a 9/10 on the troll scale. It wasn't bad, had factual data twisted in such a way as to be completely false. I even bit, not to argue with you but to make sure innocents don't read your post and get confused.

Re:RBLs and not getting your mail (1)

Amouth (879122) | more than 7 years ago | (#16059211)

I agree with the spamassassin box in front of the exchange server.

for my work domain. I have two virtual slackware boxes running that do nothing but take mail clamav and spamassassin and then forward it to exchange.. we get about 1-2 messages a second per box and most of them are spam - exchange is a very nice work group server and the integration between outlook - mobile devices and OWA is quite nice - it has it's issues and security holes but I find that using linux spam filters and having exchange only except inbound connections from them removes most of the exploitable issues.

i feel that neither linux nor ms have the best solution but for us a soulution of both works Quite well

Re:RBLs and not getting your mail (1)

otisg (92803) | more than 7 years ago | (#16059240)

But how do you know you didn't get any false positives? You could know that only if you examined every single email marked as spam. Did you really do that? If so, then what is the point of running spam filters? The whole problem is that spam consumes our time, and thus we want to get rid of it without ever seeing it. We don't want to monitor our spam filters.

Re:RBLs and not getting your mail (1)

Pollardito (781263) | more than 7 years ago | (#16059407)

it actually is easier to clean up spam when you have the likely candidates sorted into their own folder. even if you're still looking at each header/sender before deleting it, you're ahead of the game because you're not working in a mixed mode (opening some and acting on them, deleting others) when dealing with spam or dealing with regular mail.

Re:RBLs and not getting your mail (1)

grasshoppa (657393) | more than 7 years ago | (#16059409)

But how do you know you didn't get any false positives? You could know that only if you examined every single email marked as spam. Did you really do that?

Two reasons;

1) In my environment,if I don't acknowledge an email I get follow ups from the person until I do. I have never come across a situation where their email has been in the spam folder.

2) I glance at my spam folder on occation ( about once a week ). I look at the senders and the subjects. Takes me a minute ( usually less ).

If so, then what is the point of running spam filters?

To keep it out of my general user base.

The whole problem is that spam consumes our time, and thus we want to get rid of it without ever seeing it. We don't want to monitor our spam filters.So you want a spam appliance. Not going to happen; Spammers are constantly working to get around filters; You need someone or something constantly adapting to them. If you have an automated method for this ( bayes ), then you need a human keeping it on track.

Further, you need to train your users as to what to do if a spam gets through to their inbox ( drag it to the spam folder ).

Nothing will ever make spam go away entirely ( until we get a better protocol that is ), so the best that can be done is education combined with good spam filters.

Re:RBLs and not getting your mail (1)

ajs (35943) | more than 7 years ago | (#16060363)

New to the business? You don't block anything in this situation; You mark it with a header ( that's part of the email message that you would likely never see. Most mailers won't display them unless you ask it specifically to do so ), and leave the blocking/filtering up to the end user.

Most businesses do not do this. Most use a spam-filtering appliance that uses a very conservative blacklist (often run by the appliance provider in conjunction with a service contract), fingerprinting and some heuristics to assess spam probability (much like SpamAssassin, and often using SpamAssassin), and then leaves the choice of what to do to the messages up to the administrator. Typical installs that I have seen discard all of the mail that's high probability spam. Some appliances keep such "discarded" mail for some period in a quarantine, and periodically give the user a list of held messgaes, making it possible to retrieve those that are mis-identified.

The setup where headers are added so that users can do their own filtering really only works in a highly technical environment, and even then there will be administrative staff for which this is not a reasonable option.

Re:RBLs and not getting your mail (4, Insightful)

Philosinfinity (726949) | more than 7 years ago | (#16059067)

If you're running the mail servers for a business, how prudent is it to run a spam filter in the first place? While using something that relies on checking the content of the mail may be useful in getting rid of the most egregious spam, you don't want to block all items identified as spam. You can't run the risk of blocking your customers.
The firm that I work for gets something like 160,000 emails from external sources a day. Roughly 10% of these are legitimate. How prudent is it to force users to sift through 90% crap in order to get to the legitimate 10%. Currently, we use Postini as our primary MX host. They forward legitimate messages directly to our Exchange server, filter out 100% guaranteed spam, and drop the remainder into a quarantine that we check every few hours. Basically, all I am getting at is that spam filtering is necessary for enterprise environments and that there are actually some good tools to acheive it.

Re:RBLs and not getting your mail (1)

insanehomelesguy (929505) | more than 7 years ago | (#16060933)

I have to agree. It seems non-sensical to even think about it not being an option to filter. There are some fantastic black lists out there. But, having tools like this tutorial makes that more stream lined and even able to whitelist senders who are on a RBL. If they actually have legitimate e-mail to send. Filtering saves users time that can be spent doing their job. It also prevents other problems, like phising, virus or other exploit from getting to the user. Which saves me a lot of time. Time I can spend doing other things. Like surfing Slashdot.

Re:RBLs and not getting your mail (1)

John Fulmer (5840) | more than 7 years ago | (#16059165)

Okay. I'll bite.

> If you're running the mail servers for a business, how prudent is it
> to run a spam filter in the first place?

Many businesses feel that they have a responsibility to block a certain amount of spam, especially porn spam.

> RBLs are notorious (especially SpamAssassin) for blacklisting entire
> domains when only a small subset of those users are actually
> sending spam.

Um.... SpamAssassin != a RBL. It is a spam filter that uses multiple algorithms to try to identify spam. RBL's are *ONE* source of information, and is almost never used as the sole determinator of spam/ham decisions in the SpamAssassin config.

> If you're running your own mail server at home, then a whitelist
> would probably be more useful than a blacklist since you already
> know who you want to contact you.

From: old_friend@newemail.com
Subject: New Job

Hey! I just started at this new company and they have a job you'd love. Let me know soon,

of

PS.. You might want to update your email address for me. This is my new primary email.

Whitelists have limited usefullness in email except as a another source of information to your filter. Gmail does an excellent job of this, IMHO.

> But you gotta hand it to the Unix folks for making the task of
> setting up a spam filter this difficult. I am curious how difficult
> it would be to set up a spam filter on an Exchange server.

Damn near impossible, short of purchasing a package. Exchange traditionally isn't the worlds friendliest package to interface with directly.

In most corporate environments, spam filtering happens offbox before it reaches the email servers and is frequently done by an appliance. Same for anti-virus.

Re:RBLs and not getting your mail (1)

TFGeditor (737839) | more than 7 years ago | (#16059206)

For our U.S.-based business, we simply blacklist all email from IP addresses outside the U.S. and Canada. We do not do business with any foreign interests, so we receive no legitimate email from other countries. This cuts our spam load by about 70 percent.

The other thing is to blackhole email that the domain name in the From field (e.g. comcast.net) does not match the sending IP. This reduces spam (which invariably has a fake From address) by another 20 percent. Whatever gets past these is handled at the local machine level by filters. Net result: perhaps 5 spams per week (out of thousands) make it to users' Inboxes.

Re:RBLs and not getting your mail (1)

secolactico (519805) | more than 7 years ago | (#16059702)

The other thing is to blackhole email that the domain name in the From field (e.g. comcast.net) does not match the sending IP

I don't think this is very wise. What about hosted virtual domains? Maybe my email domain is mydomain.com but my mail server's PTR is mail.provider.com.

I have found that making sure PTR and A match cuts a lot of incoming spam from dynamic addresses.

Re:RBLs and not getting your mail (1)

mhollis (727905) | more than 7 years ago | (#16060127)

For our U.S.-based business, we simply blacklist all email from IP addresses outside the U.S. and Canada. We do not do business with any foreign interests, so we receive no legitimate email from other countries. This cuts our spam load by about 70 percent.

Increasingly, businesses in the US and Canada will find it impossible to do this (depending one one's business). The economy and business is global and, as time goes forward most non-local industries will need to be able to communicate across national boundaries. The spammers know this.

It used to be that you could safely block all e-mail from China. Multinationals can't do that any more. They're in China and are opening markets in many of the countries where spammers used to (and still do) operate freely.

Of course, if what you are doing is local lawn care, or dry cleaning for your locality, you'll be able to safely block anything from outside of the US (or your own nation). But many businesses are increasingly needing to find markets, services and suppliers internationally.

Re:RBLs and not getting your mail (3, Interesting)

raddan (519638) | more than 7 years ago | (#16059258)

We block somewhere around 200k spam emails a day. And we have a very similar setup sitting in front of our Exchange server. The kinds of things we can do with Postfix simply aren't possible with Exchange, and once we learned the ins and outs of Postfix, we found it to be easier to use than Exchange. For one, Postfix has real documentation [postfix.org] . Not to mention that the main developer posts regularly on the mailing list. Ever talk to MS's corporate support people for Exchange? Exchange is so huge and complex no one person knows the entire program. Postfix is a model of simplicity by comparison.

Re:RBLs and not getting your mail (3, Interesting)

just_another_sean (919159) | more than 7 years ago | (#16059454)

As someone who uses Exchange I can say that setting spam filtering up is easy. You can use RBLs or not. You can set thresholds that let a lot in or block a lot with many false positives. If you're worried about losing business mail then you can configure it to be safe about that and never outright refuse or delete mail.

But I don't like it because once you check the boxes, set the sliders and press OK, that's it. Unless you then get into scripting or third party products or any other solutions I can't think of you don't get to customize it any further. In other words, at that point, if you want more, it's just like Unix. I've never worked with any but can't you buy Sendmail or OpenExchange and get a lot of the point and click stuff for free too? And for a lot less then the dragon's horde a small business spends on MS Exchange?

One last thing to mention, we feel the same way as you about losing a customer's mail. So our users don't get anywhere near the spam they used to but the IT Admin that works for me spends anywhere from an hour to two a day checking the spam filter to see what gets tagged. Whitelisting? So far we found a few half ass solutions in forums that for various reasons don't do exactly what we need.

All in all, like most Window's based solutions in my experience, Exchange is easy to set up, hard to customize. We're working on a OpenBSD solution [flakshack.com] as a front end in our spare time. Hopefully we can get it to get the worst of the spam and then set Exchange to be a lot more lax when it gets in... Anything that keeps us from checking the spam filter all day.

Re:RBLs and not getting your mail (1)

Tweekster (949766) | more than 7 years ago | (#16059486)

Basically, most businesses are willing to lose one email that is important if it means saving hours a week...Because anyone I have dealt with in business, understands the fact that email is not a reliable form of communication. They follow up with a call if they send something critical.

99% means losing one legit email per 100, in all likelyhood it wasnt important,

I use ASSP, automatic whitelists are built as people send emails so email has become useable for my organization. They understand if an email is blocked, the sender is notified, the sender calls the office (that has happened twice, and the sender would complain about it, trust me)

99% is good enough, period. I keep a seperate account so that if something isnt received that should have been, it will be in that box and I can retreive it, that happens maybe once a month.

People always clamor on about how "what about losing that important email" well the way it works in the real world, if it is important, the person simply doesnt put their full faith in email to begin with.

If someone expects email to be reliable, they will learn soon enough, spam filter or not.

You can and should run the risk of blocking your customers, with a proper whitelist system that hardly ever happens, coupled with a content analysis system you are set. End users in a business should not have to sift through crap deleting an important email because they want to get rid of the 100 junk emails. (I used to see them do that regularly)

The important thing to remember is, they were already deleting important emails on accident. Now they just dont have to delete junk. The whitelist makes it far more effective because in all likelyhood, the email will be delivered without problems.

I am sorry, but anyone who bickers on about "that one important email" obviously doesnt live in reality, or doesnt live in the business world (or will quickly be exiting the business world) by trusting a system that is inherently unreliable.

Re:RBLs and not getting your mail (1)

cortana (588495) | more than 7 years ago | (#16059636)

Spamassassin is far more accurate at classifying spam than humans. You will lose less mail if you let Spamassassin do the job.

Re:RBLs and not getting your mail (1)

misleb (129952) | more than 7 years ago | (#16059678)

If you're running the mail servers for a business, how prudent is it to run a spam filter in the first place? While using something that relies on checking the content of the mail may be useful in getting rid of the most egregious spam, you don't want to block all items identified as spam. You can't run the risk of blocking your customers.


Well, the sender should get a notification if a message was blocked by an RBL. Same can be done with SpamAssassin+Amavisd. Send a bounceback for low scored spam and drop the most egregious. Unless your customers are particularly sensitive and/or irritable, it shouldn't be a disaster if there is a false positive now and then. The way I see it, users run about the same risk of accidently deleting an important email (i've done it) while manually trying to clean spam from their inbox (or even special spambox).

If you have to, have SpamAssassin archive all blocked spam.

-matthew

Re:RBLs and not getting your mail (1)

dragonator (470749) | more than 7 years ago | (#16060872)

Yes, it can be a bit of a pain. There are however some nice tools to handle it for you and make most of the pain go away... along with the spam.

Try a proxy tool called ASSP. I've been using it for several months and am very happy with it.

useless article (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16058999)


a single page article that tells you how to filter internal domain mail from external ?

there is nothing on this page about how to use RBL (which is a lame way of filtering as it is) or whitelists or anything else, did the submitter actually what this article covers ?

useless, now wheres my point and click interface ?

Useless (2, Insightful)

Anonymous Coward | more than 7 years ago | (#16059011)

The layout of the linked site is awful and sticking configuration snippets in text areas is awful. I didn't even see any warnings and if you're doing this, there are plenty of things that could go wrong. IMHO, setting up an MTA to reject spam at SMTP time is an involved process that requires the admin know what they are doing, blindly following a poorly written howto is a recipe for disaster.

Re:Useless (0)

Anonymous Coward | more than 7 years ago | (#16059111)

If you're really interested in these matters, use this [acme.com] approach. At the very least, it's well written and an easy read.

Re:Useless (0)

Anonymous Coward | more than 7 years ago | (#16059178)

If you're interested in this, you should start by reading the RFC's and manual for your MTA instead of relying on second hand knowledge.

postgrey (1)

viniosity (592905) | more than 7 years ago | (#16059018)

I started using postgrey on my mail server a few months ago and my spam dropped from several hundred per day to about 10 per week. I wrote up this great how-to but figure that if spammer's got wise my advantage would be lost so I never published it.

Re:postgrey (1)

rel4x (783238) | more than 7 years ago | (#16061265)

In a world where e-mail address are $10-$30 per million, the amount of people using your custom config would probably never be high enough for spammers to care. No Spammer bothers to adjust their software to best every menial anti-spam fix. Only the big ones.

bad idea... (3, Informative)

Vellmont (569020) | more than 7 years ago | (#16059035)

If you do this, and you're an ISP (which you likely are if you're getting 1000s of spams a minute) you're very likely to block legit mail from ever getting to subscribers. Realtime Blacklists aren't reliable enough to use alone in blocking spam. You'd serve customers better by buying more/faster machines to handle the load.

If you DO decide to do this, be VERY carefull about the RBLs you use. Some RBLs list entire blocks of IP addresses of ISPs that have hosted spammers, and some even list every DSL/Cable modem static IP address. I've had me mail blocked by overzealous ISPs before (for just being on a cable modem static IP), so I'm not a big fan of using RBLs or other simple techniques to block spam at the postfix/sendmail level.

Re:bad idea... (0)

Anonymous Coward | more than 7 years ago | (#16059083)

and some even list every DSL/Cable modem static IP address. I've had me mail blocked by overzealous ISPs before (for just being on a cable modem static IP)

And why were you sending mail direct from your cable modem static IP? You should have been using your ISP's smarthost.

Wrong (0)

Anonymous Coward | more than 7 years ago | (#16059156)

You should be able to send email between any 2 routable IP's. It's unfortunate that we have a minority of criminals and amoral profiteers ruining it for everyone. I myself reject residental hosts on networks operated by irresponsible ISP's (comcast, netvision, road runner, verizon). That doesn't mean I agree with forcing people to use a smarthost to send legitimate email.

Re:bad idea... (1)

glesga_kiss (596639) | more than 7 years ago | (#16059257)

And why were you sending mail direct from your cable modem static IP? You should have been using your ISP's smarthost.

Because when I hook my laptop up to the net away from home using wifi or gprs, it can't get to my ISP's smarthost. So instead I have a publicly accessible server with authetication and SSL set up that I can use from anywhere. This is way better than the last 8 years where I've had to manually change the outgoing server.

I've had to stop this approach because of some RBL lists blocking my mail. The whole of @aol.com ignores me. Instead I now use GMails SMTP server. It also has SSL and authentication, and can be reached for anywhere.

Re:bad idea... (0)

Anonymous Coward | more than 7 years ago | (#16059421)

And why were you sending mail direct from your cable modem static IP? You should have been using your ISP's smarthost.
Because when I hook my laptop up to the net away from home using wifi or gprs, it can't get to my ISP's smarthost. So instead I have a publicly accessible server with authetication and SSL set up that I can use from anywhere. This is way better than the last 8 years where I've had to manually change the outgoing server.

Okay, so hang your mail server off the cable modem and then configure it to use the smarthost. That's what I do. Client talks to the mail server, mail server talks to the smarthost - it's one extra hop, hardly a big deal. Now if your ISP smarthost finds itself on an RBL, then you have trouble.

Re:bad idea... (1)

Drizzt Do'Urden (226671) | more than 7 years ago | (#16059433)

Make your personnal SMTP server relay through you ISP's, and everything will be fine!

This is what I did, 2 years and counting without problems :)

Re:bad idea... (1)

Albanach (527650) | more than 7 years ago | (#16059439)

Because when I hook my laptop up to the net away from home using wifi or gprs, it can't get to my ISP's smarthost. So instead I have a publicly accessible server with authetication and SSL set up that I can use from anywhere. This is way better than the last 8 years where I've had to manually change the outgoing server.

The question remains - why aren't you using your ISP's smarthost.

There's no reason you can't run an SMTP server at the end of your cable modem - it, however should still pass it's traffic directly to your ISP's smarthost for onward delivery.

That way you won't hit and RBL lsiting Cable / DSL users.

Re:bad idea... (0)

Anonymous Coward | more than 7 years ago | (#16059667)

There's no technical reason to relay through an ISP's heavily loaded server, you're conflating seperate problems. A static IP and matching forward / reverse DNS is good enough for us (and many other receivers) to whitelist. We have no qualms about blocking 'smarthosts' either!

The question therefore is: Why use a smarthost?

Re:bad idea... (2, Insightful)

Vellmont (569020) | more than 7 years ago | (#16060049)


it, however should still pass it's traffic directly to your ISP's smarthost for onward delivery.

And why would I want to have to rely on my ISPs mailserver to be up to send outgoing mail? I like reliability, I don't like outages. I also don't want to rely on them to route my mail properly, decide I'm a spammer and block me, or whatever. Also, why would I want to make it easier for my ISP to snoop on my mail? (who knows if they'll send targeted advertising, etc).

If you don't mind all those things, fine. But there's very good reasons to not use your ISPs mailserver.

Re:bad idea... (1)

Fez (468752) | more than 7 years ago | (#16061178)

And why would I want to have to rely on my ISPs mailserver to be up to send outgoing mail? I like reliability, I don't like outages. I also don't want to rely on them to route my mail properly, decide I'm a spammer and block me, or whatever. Also, why would I want to make it easier for my ISP to snoop on my mail? (who knows if they'll send targeted advertising, etc).

If you don't mind all those things, fine. But there's very good reasons to not use your ISPs mailserver.


Then you're probably violating your ToS, unless you've paid for a business account with a static IP in which case they can be de-listed from RBLs.

Mail should NOT be coming from end-user dynamic IPs directly. Period. No excuses. Your ISP's mail servers exist for a reason, and secure relays such as Gmail exist for a reason.

I know around here the cable provider has a TLS/SSL/SMTP Auth setup for their customers to use remotely, yours might have one as well.

Re:bad idea... (0)

Anonymous Coward | more than 7 years ago | (#16059089)

RBL lists are the bain of internet service providers, I say. They continually blacklist whole blocks of IP space that are 'clean' due to 1 IP being a spam source, thus killing the email service of potentially hundreds of legitimate customers. Don't use them, there's got to be a better way than trusting some 3rd party, one which there is no control over.

Hard Filter by RBL -- A NoNo (4, Informative)

Kirth (183) | more than 7 years ago | (#16059079)

Don't filter by RBL. Use them to give scores to Spamassassin, but don't reject mail on basis that some host is in some RBL.

* There are RBLs nearly impossible to get out from, and you might actually get an IP assigned months earlier to somebody who never requested a removal.
* False positives. Mails misidentified as spam (typically: newsletters which the signed up person no longer wants, vacation-mails in foreign languages) might bring you onto an RBL.
* Collateral damage. A shared server with 1000 users and 2000 domains might turn up in an RBL because one of those users had an inscecure formmail running a night long. And even after removal by the sysadmins in the morning, 1499 users can't mail you the next 18 hours.
* Spurious criterions for getting listed. Like "unsolicited bounces" or "sent mail to secret spamtrap"

So while RBLs are really a useful tools for deciding whether a mail might be spam, using them as THE ONLY reference on whether something is spam or not is just foolish.

Re:Hard Filter by RBL -- A NoNo (3, Insightful)

repetty (260322) | more than 7 years ago | (#16059147)

>> * Collateral damage. A shared server with 1000 users and
>> 2000 domains might turn up in an RBL because one of those
>> users had an inscecure formmail running a night long. And
>> even after removal by the sysadmins in the morning, 1499
>> users can't mail you the next 18 hours.

Good point. On the other hand, I don't fucking care. I don't hear anyone knocking on my door, offering to help me filter out my spam. RBL's work GREAT on a tough problem, which is why they haven't gone away.

And the collateral damage? If a user/subscriber abuses a service then the service provider SHOULD be held accountable and those other 1499 users are better off elsewhere.

--Richard

Re:Hard Filter by RBL -- A NoNo (1)

eXtro (258933) | more than 7 years ago | (#16059895)

Name a provider where a user hasn't abused the service at some point in time. Perhaps only people capable of running their own provider should have email access? Fine, but name a backbone provider that hasn't been abused.

Re:Hard Filter by RBL -- A NoNo (3, Insightful)

iangoldby (552781) | more than 7 years ago | (#16060648)

I agree that ISPs should to some extent be held accountable, but to hold them 100% accountable ignores the fact that it is virtually impossible to pre-emptively stop all forms of email abuse.

For example, SORBS have a policy that they will blacklist a server if they receive three or more emails to their spam trap addresses. These addresses are kept secret, so the ISP can't know what these spam trap addresses are. Suppose a malicious client of the ISP discovers (or guesses) one or more of these spam trap addresses. He can then send just three emails, the contents of which need not be 'spammy' in the least. The ISP's server will then be blacklisted for at least 48 hours, but usually much longer. An ISP has absolutely no defence against this kind of thing.

You could easily think of other examples where the ISP has no possible way to recognise that malicious email is being sent until after it has gone out of the door.

But the real issue is that the people who suffer are the other customers. They are completely disempowered, because they will just be ignored if they contact the RBL operator (since they are not the administrator of the blacklisted server). They could in principle find another ISP, but that is usually an unacceptable solution due to the disruption involved. If they don't have their own domain, they lose their email address, which means they will continue to lose emails. They can't win.

ISPs should be fighting against spam, but not with RBLs. The only time it is justified to use an RBL as a single criterion for rejecting email is when the administrator of the filter is also the only consumer of the filtered email. (Or perhaps if you have the explicit approval of all consumers that missing some non-spam emails is acceptable.)

Re:Hard Filter by RBL -- A NoNo (3, Insightful)

wayne (1579) | more than 7 years ago | (#16059734)

* Spurious criterions for getting listed. Like "unsolicited bounces" or "sent mail to secret spamtrap"

Neither sending bounces to forged email addresses (backscatter [wikipedia.org] ) nor sending email to spam traps is a "spurious criteria" for getting listed. If you are doing either of these, you are part of the spam problem and you deserver to have your email blocked.

Configure your mail server to reject *during* the SMTP session, or only send bounces after the fact if the email passes something like SPF. Using SPF's "best guess" default record of "v=spf1 a mx ptr" when there isn't an SPF record may by safe, but you are still risking sending backscatter to innocent people. Domainkeys and DKIM validate the From: header, which isn't where you should send bounces to, so it can only be used when the Envelope-From and the From: header match. Really, the easiest thing to do is just to always reject during the SMTP session and not accept-then-bounce.

I'll Do It One Better... (2, Interesting)

Beefslaya (832030) | more than 7 years ago | (#16059101)

Here is a link setups to build servers with postfix, amavisd, SpamAssassin, ClamAV, Razor (you could also use these settings just for postfix to add better spam resistance).

I not only am I the President, I'm a user.

http://www.freespamfilter.org/ [freespamfilter.org]

Enjoy...I love it...

Re:I'll Do It One Better... (1)

Beefslaya (832030) | more than 7 years ago | (#16059228)

Also, "The Book of Postfix" (yes it's a regular book) is great for showing you how to fight spam with just postfix.

90% of spam problems are because admins and ISP absolutley refuse to follow the RFC guidelines set forth. (i.e. DNS entries for all "servers" live on the Internet, proper hostnames.)

Then it's just a matter of blocking non-RFC compliant servers from sending you mail. It's that easy.

A good RBL experience? (4, Informative)

autocracy (192714) | more than 7 years ago | (#16059112)

I am aware there's definitely a fair number of over-zealous blacklists, but I've had an extremely good experience using cbl.abuseat.org as a blacklist source, and haven't encountered any false-positives while perusing my mail logs.

Re:A good RBL experience? (1)

Beefslaya (832030) | more than 7 years ago | (#16059141)

A lot of the RBL's reference each other. So adding more then 2 or 3 usually is redundant.

I've had GREAT results with them.

http://rfc-ignorant.org/ [rfc-ignorant.org] has been a great one for me.

Re:A good RBL experience? (1)

NastyGnat (515785) | more than 7 years ago | (#16059393)

You might consider using sbl-xbl.spamhaus.org instead. That covers cbl.abuseat.org as well as several other rbls all in one check. I've been running the settings below in my postfix for roughly the last year and the only "false positives" I've had to deal with are with sites that are open relays and had to get their site fixed. In each case they apparently requested to get removed, got removed within a few hours, and then within a few weeks got relisted again because they didn't atually fix the problm.

Eventually I agreed to whitelist the IP address of one site but have had to play chase the address 5 times each time they call and ask why we're blocking their mail. They complain it's our problem that they get blocked despite the fact that CBL has a copy of the messages sent via their open relay. When asked why they keep changing IP addresses, they said they didn't want to bore us with their security precautions.

As far as hard lists to get removed from, sorbs appears to get the most complaints, especially with some of their ideals about $50 fees for removal and entire subnet blocking. None the less if you stay active with your mail system you should be able to determine quickly if you have any false positives and need to remove any rbls. FWIW we're doing
Postfix+Amavisd-new(with Spamassassin)+Vexira(clamAV as a failover)+Greylisting+Bayes learning as well as smptd auth for users outside or local network. We're not running and ISP here, but we see about 175-200K e-mails a month with about half of them getting rejected at SMTP for one reason or another.

Anyway, here is a glimpse at our postfix rules.
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access hash:/etc/postfix/white-blacklist, reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_rbl_client relays.ordb.org, reject_rbl_client list.dsbl.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client dul.dnsbl.sorbs.net, check_policy_service inet:127.0.0.1:10030, permit

RBL-based rejection can be a BAD thing (1)

frostyboy (221222) | more than 7 years ago | (#16059129)

Rejecting mail outright based on RBL results is an invitation for loads of false positives. If you're getting "1000s of messages per minute," chances are you are a large business or an ISP. Either way, your customers sending mail from foobaz.net (for example) won't be happy when their no longer gets through because some boneheads at spamcop or spamhaus put them on the RBL.

If you don't have the proper setup to accept that many messages and do adequate "tag-and-forward" spam analysis, or at least reject later in the delivery cycle based on cumulative results from multiple RBLs, you need to beef-up your mail architecture. Of course, you could just set it to randomly drop 80% of all of your incoming email into /dev/null and you would likewise solve your traffic problem.

Great guide, ... NOT (2, Informative)

xming (133344) | more than 7 years ago | (#16059139)

There are more explaination on the postfix.org than this FA (fine article). Wisely using good RBL (for open proxies) and graylisting and some helo/header checks should reduce a lot of spam.

Greylisting + a bit more (2, Interesting)

stabiesoft (733417) | more than 7 years ago | (#16059154)

I use a combination of greylisting (10 mins for normal IP addresses and an hour for dynamically assigned IP addresses). I also do a very quick check on a few sender domains such as yahoo.com A "from" yahoo.com must be from a machine with .yahoo.com. If not, it is rejected. Works quite well with less than one spam per day. Given that yesterday had 466 spam's that got rejected, I'm pretty happy. I cannot recall anyone complaining they can't get in. Greylisting works really well because real mail servers try hard to deliver whereas spammers don't try that hard for delivery.

Re:Greylisting + a bit more (0)

Anonymous Coward | more than 7 years ago | (#16059311)

> spammers don't try that hard for delivery

My mail logs disagree, zombies try to deliver a message a preset number of times no matter what you do.

If ISP's can shape their traffic for BT, they can monitor it for spikes in a users port 25 egress and cut them off. There's no excuse for the current situation, Microsoft have a lot to answer for.

Re:Greylisting + a bit more (2, Insightful)

Just Some Guy (3352) | more than 7 years ago | (#16059951)

I also do a very quick check on a few sender domains such as yahoo.com A "from" yahoo.com must be from a machine with .yahoo.com. If not, it is rejected.

If by that you mean that you're using SPF [openspf.org] or similar, that's a great idea. If it means that you wrote your own code that does something like "if fromdomain != helodomain: reject()", then your system is pathologically broken and needs to be updated.

sendmail tweaks (5, Informative)

ltjohhed (231735) | more than 7 years ago | (#16059227)

A far more effective and less faulty way to filter out some spam can be done by using the new features added in sendmail 8.13.

FEATURE(`great_pause',5000)
That one is given in your .mc file.

Wait's 5000ms to say HELO (EHLO) and all MTA's starting to send data (spambots not being all that RFC-aware) before that is discarded.

I've measured that it atleast cuts 15-20% of the total amount of spam.
   

Shame the article is about Postfix. (2, Insightful)

AltGrendel (175092) | more than 7 years ago | (#16059949)

Ok, I recognize that you are probably trying to promote Sendmail. But for a variety of reasons, there are folks out there that can't or don't want to use Sendmail. I don't use Sendmail because I consider it overly complex. I use postfix and yes, I use the RBLs before it gets to SpamAssassin (gasp). If you tune it properly, it works just fine, thank you. Also the email list archives are extremely helpful in this matter, as is the list itself if you've done your homework first.

Whoever marked this as offtopic. (0)

Anonymous Coward | more than 7 years ago | (#16060289)

Didn't read the whole post.

Idiot.

Re:Shame the article is about Postfix. (1)

KillerBob (217953) | more than 7 years ago | (#16061098)

I don't use Sendmail because I consider it overly complex.


Please don't get the impression that I'm trying to evangelize you... but Sendmail used to be overly complex. More recent versions are actually pretty good from the configuration perspective, especially if you're using a binary distribution such as a slackpackage or deb package. It's really just a question of changing your sendmail.mc file, and compiling it. Copy to the right location, and restart Sendmail. Poof. It's done.

Enabling a RBL or RHBL in Sendmail is as simple as adding a line to the end of your configuration file:
FEATURE(`enhdnsbl', `bl.spamcop.net', `"Spam blocked. See: http://spamcop.net/bl.shtml [spamcop.net] ?"$&{client_addr}', `t')dnl


Personally... I found that Sendmail was the mail package that "just worked" for me. I tried qmail, PostFix, and a bunch of other ones, and by far, Sendmail with Procmail was the easiest to set up filters and other configuration.

Re:sendmail tweaks (2, Interesting)

leighklotz (192300) | more than 7 years ago | (#16060220)

It's FEATURE(`greet_pause',5000) not FEATURE(`great_pause',5000).
The previously-referenced Acme [acme.com] page mentions it.

Re:sendmail tweaks (1)

Shadowlore (10860) | more than 7 years ago | (#16061246)

If you run a server that needs to handle a lot of email, and do so in a timely manner, this will hose you. if you run an enterprise environment where there are applicaitons (usually JavaMail based ones) that bork and die on this but are sending legitimate mail, this will hose you.

There are many legitimate applications that will die if you do this. To recommend this as a general solution is a mistake. Sure, we would all love it if the legitimate apps worked properly, but that isn't the real world. The real world is painful.

If you want a personal or small-medium user amount email address that your friends/family/etc. can send you email to but get no spam, you can set up an encryption based mail system. Only encrypted and/or signed mail is allowed in. Period. You can run this type of system in two ways:

1) Look for signed/encrypted message, extract key and verify signature. Check key against your key database. If it is not a valid signed/encrypted AND is not in your trusted/accepted keys list: reject it.

OR

2) Look for signed/encypted email, verify signature and if the signature is not correct reject it.

I use it on one of my addresses and am transitioninng all other than mailing lists to it. 100% spam free. I use option 1. If someone with a valid key does send a signeed and/or encrypted spam I can remove that key from the allowed list and that problem goes away. The likelihood of getting spam from this account is slim to none.

Not useful of unsolicited emails, but I have an application mechanism for people who want in. The time I spend validating new senders is a tiny fraction of the time spent cleaning spam, running spam filters, and trying to keep up with the latest spam fighting techniques on the server.

Monitor the results of your blacklists! (2, Interesting)

reed (19777) | more than 7 years ago | (#16059289)

Warning, I used to use RBLs to reject mail, but occasionally all of yahoo or somethnig gets added to a blacklist, and so mail from yahoo would start bouncing (including yahoo groups -- they really ought to use a seperate network for yahoo groups as their free webmail!). So instead of rejecting mail, I started just inserting a warning header, X-Spam-Blacklists:, which is easy to do with Exim. (I assume also with Postfix). Then I could filter the message in Thunderbird into a "probably spam" folder. You could also set up SA to increase a messages score if it's in a blacklist, I think, but I've never tried it.

So if you do set up RBL rejection, make sure you pay attention to what it's rejecting. Skim through the log file a few times in the week or two after doing it, otherwise you'll never no that it's being rejected.
 

greylisting not all that useful. (4, Insightful)

nblender (741424) | more than 7 years ago | (#16059301)

To all you greylisters, I don't know what part of the interweb you're from but when I survey my spam, I find that great tracts of it come from zombies via their ISP's mail server which means greylisting is no longer effective. It was effective last year but I think you folks missed the boat. I moderate a mailing list for a popular open source operating system project that uses greylisting and I still get about 100 spam per day as owner-listname...

Spammers are having their zombies dig through the windows configurations to find the owners email relay and using that to send their spam. It's not that difficult and combats greylisting.

Re:greylisting not all that useful. (1)

badger.foo (447981) | more than 7 years ago | (#16059549)

Your comments certainly do not match my experience here.

As far as I can tell from my logs, greylisting remains effective, getting rid of certainly no less than 85% per cent (likely more in the 95%+ range) of the spam attempts. Whatever spam does get past greylisting mostly gets dealt with by content filtering (spamassassin/clamav). Then again, there are several greylisting implementations, and the one you are using is perhaps not very good to start with or not too well tuned.

http://www.bgnett.no/~peter/pf/en/spamd.html [bgnett.no] gives you a rough idea of how to do MTA independent greylisting with OpenBSD's PF (doable on other BSDs as well).

I did notice a few months back that spammers started trying to inject their payload via secondary or even teritary MXes for the domain they target. After a few weeks of that, I intorduced a setup rougly like the one described above on our secondaries, and it pretty much killed the remainder of our spam.

Re:greylisting not all that useful. (1)

stormpunk (515019) | more than 7 years ago | (#16059560)

I run a small server and I find greylisting to be very useful. Just because you still get spam doesn't mean it is pointless. About 90% of incoming attempted deliveries to my server are blocked before the mail even gets to spamassassin. The zombies aren't enough reason to throw away greylisting. It's a simple measure and even if it eliminates 1% of incoming spam, and doesn't cause any major headaches I figure I might as well put it in.

Greylisting, conservative RBLs, some simple HELO checks (don't accept mail from somebody claiming to be your own mail server), domain name existance check, and SPF are all pieces that work together to at least slow down the onslaught.

greylisting will always be useful (2, Insightful)

wayne (1579) | more than 7 years ago | (#16059649)

Greylisting will always be useful, at least to a certain degree. When you get email from an unrecognized source, one that you can't judge as being a source of legitimate email or if it is a spam source, greylisting lets the reputation systems like DNSBLs and DCC/Razor/etc. catch up. Also, good ISPs and mail admins have tools to watch for likely spam runs. Again, greylisting gives those tools time to act and purge the spam.

Sure, greylisting also gets rid of spam from spambots that don't retry email, and that's a plus but, as you mention, making sure the email gets retried isn't that hard.

Greylisting is not a Final and Ultimate Solution to the Spam Problem, but it will always be a useful tool.

Re:greylisting not all that useful. (1)

Draco_es (628422) | more than 7 years ago | (#16059824)

when I survey my spam

Unfortunately, I can't survey my spam, because is near to 0 (well, it's a toy system, 500 users, but are lots of organizations like mine that get lots of spam). OpenBSD's spamd with greylisting & blackllisting(spews1) & spamtrap does the job near perfectly. Other tricks like trapping connections to secondary MX while primary is up can be very effective, also.

I think that the kind of spam you describe can't the more common at all. ISP's can rate-limit their customers, and if their main mailserver gets into blacklists they may get into trouble, so I'am sure they track zombie's IP which use their SMTP relay. Besides, SMTP AUTH headers give a lot of info about who's owned.

Re:greylisting not all that useful. (3, Insightful)

Just Some Guy (3352) | more than 7 years ago | (#16059992)

Spammers are having their zombies dig through the windows configurations to find the owners email relay and using that to send their spam.

In other words, greylisting makes zombies relay spam through their ISP, forcing said ISPs to deal with the problem to keep their mailserver from being both overwhelmed and added to every DNS RBL in existence. In what possible way is this not a Good Thing?

Re:greylisting not all that useful. (1)

Greyfox (87712) | more than 7 years ago | (#16060401)

It's not like any one single method will completely solve your spam problem. I'm using a combination of greylisting and SPF checking on my domains at home and a couple of spams a week get through to SpamAssassin. Thus far SpamAsssin has been giving me a 100% success rate at tagging the spams that do get through and a 0% false positive rate. Pretty good, I think.

Total bullshit. (0)

Anonymous Coward | more than 7 years ago | (#16060649)

Yes, greylisting has become less effective. Now its only blocking ~90% of the spam instead of ~95%. Oh no! Considering it is essentially a freebie, with no real downside, and no false positives ever, that's damn good. Of course you still need to filter spam after that, but cutting out 90% of it for free is a great help.

Some words of wisdom (3, Informative)

bfree (113420) | more than 7 years ago | (#16059308)

Here is an insightful blog posting from Justin Mason [taint.org] about using RBL's (and bl.spamcop.net in particular which this HOW-TO mentions) for filtering spam. You could see a staggering amount of false positives unless any rbl is only one part of a scoring system which decides whether a mail should be rejected.

Alternative guide (0)

Anonymous Coward | more than 7 years ago | (#16059320)

For those of us who like details, here's an alternative spam filtering guide: http://www.flakshack.com/anti-spam/wiki/index.php [flakshack.com] .

I'm using the setup presented to filter about 1000 messages per day before they hit our exchange server. It works very well and so far has had no false positives. However, it's difficult and time consuming to set up and needs to be trained with sa-learn before using.

assp is better (0)

Anonymous Coward | more than 7 years ago | (#16059344)

http://assp.sourceforge.net/ [sourceforge.net]

We use ASSP its an SMTP mail proxy that sits infront of your mail server.

The advantage of assp is it can reject emails without having them processed and it has a greylist and penelty box. The offical site explains it better than i can. All i know is since we started using it (and after training the bayes database) ive had no spam for several months....

More of this kind of thing (1, Offtopic)

stunt_penguin (906223) | more than 7 years ago | (#16059662)

I for one, welcome our spamfighting overlords, and think that we should see more of this kind of thing on the front page of ./

Although we've got our share of trolls and fanboys ruining it for the rest of us, I daresay that there are at least a few slashdotters out there who could write guides at least as good as this on a number of geeky and related subjects and present them on the front page, in much the same vein as the original content presented in book reviews etc. It might even be worth paying the author a few bucks for the privelige.

I know that the news presented here is usually linked-to content, but I think some original guides with relevant links would be content at least as worthy as the 'Nanocosmetics used since Aincent Egypt' article posted by that little troll Roland last night.

Filtering against dictionary spam (2, Informative)

knarfling (735361) | more than 7 years ago | (#16059694)

At my last company, we had a big problem with spam. But because the company did some online marketing, there were people in our marketing department that WANTED to get some of the spam so they could see what tactics the competition was using. At one point our mail gateways were so clogged, mail was being delayed by up to 4 or 5 hours at our gateway.

We fixed the problem by having postfix discard any mail that was not addressed to a legitimate email account. We ran a script that would pull all valid email addresses from exchange and told postfix to reject anything else. We set that script to run every hour to catch any changes to email addresses. Our emails that went through spamassassin dropped by almost 90%.

Our only trouble was that if we rejected with NDR, there were tens of thousands of Non-Delivery Reports being sent out, and if we rejected without an NDR, people who mispelled email names (sean@domain instead of shawn@domain) never got a report stating that their email did not go through.

Overall, it was a huge success and we didn't have to mess with greylistings or blacklists.

Re:Filtering against dictionary spam (2, Informative)

DrGalaxy (89127) | more than 7 years ago | (#16060571)

Agree with parent.

I call this technique "early recipient rejection". As soon as the SMTP client sends "RCPT TO:" our postfix systems check a database list of valid recipients and drop the message immediately if it is not valid.

To set up early recipient rejection with postfix, read the docs about "check_recipient_access" and apply that directive to your "smtpd_recipient_restrictions" section in main.cf.

Another HOWTO that I'm biased toward (1)

Just Some Guy (3352) | more than 7 years ago | (#16059901)

I wrote basically the same article [freesoftwaremagazine.com] a year ago for Free Software Magazine. We've been using this setup at my office for the last year, and it's been working perfectly - to the point that an upset coworker told me yesterday that she's received four spams last week and wondered if something was wrong.

Mail Gateway like Barracuda (0)

Anonymous Coward | more than 7 years ago | (#16060192)

Has anyone found a good open source gateway solution that incorporates a web front end for user configs and quarantine? Basically an open source Barracuda appliance?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...