Fight Spam With Nolisting 410
An anonymous reader writes with the technique of Nolisting, which fights spam by specifying a primary MX that is always unavailable. The page is an extensive FAQ and how-to guide that addressed the objections I immediately came up with. From the article: "It has been observed that when a domain has both a primary (high priority, low number) and a secondary (low priority, high number) MX record configured in DNS, overall SMTP connections will decrease when the primary MX is unavailable. This decrease is unexpected because RFC 2821 (Simple Mail Transfer Protocol) specifies that a client MUST try and retry each MX address in order, and SHOULD try at least two addresses. It turns out that nearly all violators of this specification exist for the purpose of sending spam or viruses. Nolisting takes advantage of this behavior by configuring a domain's primary MX record to use an IP address that does not have an active service listening on SMTP port 25. RFC-compliant clients will retry delivery to the secondary MX, which is configured to serve the role normally performed by the primary MX)."
Oblig. (Score:5, Insightful)
Your post advocates a
(x) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(x) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
(X) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
(x) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
(X) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
(x) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(x) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
Re:Oblig. (Score:4, Insightful)
Re:Oblig. (Score:4, Interesting)
First, at least some botnets will hit secondary MX-es first. The reason for this is because one person too many out there think that the secondary MX gets invoked only when the first one fails and do not put full sets of antispam software on it.
Second, as far as detecting SPAM is concerned the fact that a system has tried your first MX is valuable information. So while the first MX may not accept the message it should still be available to record the attempt. As a result, if you have multiple level different priority MX-es you can vastly improve on standard greylisting. The first MX resets with the usual "greylisted for 300 seconds, come again". After that system expects that you appear on the second, third, etc in the correct order and try on all MX-es of equal value before going up. In other words your connection pattern should follow the one of a normal MTA. Zombie writers are too lazy to do that (and that takes too much resources as far as they are concerned) so they fail the test and get their greylist timeout pushed up. Normal MTAs get their greylist timeout adjusted down and may even be allowed in on one of the last MX-es. I have done that using exim/mysql and I know a few other people who do that as well (trivial actually). In fact, looking at my mail logs it looks like yahoo does something similar for receiving mail and I can bet that they are not the only ones.
Re: (Score:3, Interesting)
Read them both. While the statistics are correct (mine roughly the same), the technical bit is typical "I shall use naked Postfix or die" technological rococo (not to use harsher words).
I am aware that implementing a generic expandable grey/black/integrity-listing framework is much more difficult in "naked" Postfix compared to Exim and Sendmail, but it is not that difficult. Postfix has a policy server and it mostly works. In fact I know quite a few people who have taken my grey/black/connection-sequenc
Teergrubing your Third MX Record? (Score:3, Interesting)
Re:Oblig. (Score:5, Interesting)
> (x) It will stop spam for two weeks and then we'll be stuck with it
There is another anti spam technology called (doubleverify?), if a message smells like spam the smtp server rejects it saying unavailable and waits for the sender to send it again (an hour or so later). For people who use it it works fine, but people who use it are in the minority, thus spammers won't bother writing new systems that keep track of what was rejected etc. They appeal to the (cheap) masses.
Same here, unless this becomes widely popular few spammers will adopt it. Thus there's a chance for this to work (hopefully, unlike doubleverify this is not patented)
Re: (Score:2)
Great. Lots of emails delayed for an hour, lots of emails lost due to non-rfc compliant sender. Doubleverify are welcome to the patent on that utterly useless (in the real world) idea.
Re: (Score:3, Insightful)
It fails to account for the fact that spammers use fake FROM-addresses, and stupid &%@! SMTP servers bounce the email to the fake FROM-address. I receive around 10000 bounced spam-emails per day of this type because one spammer somewhere decided to use my domain as a fake FROM-address.
Just discard the email. Don't bounce!
Re:Oblig. (Score:5, Insightful)
Mail should not be silently discarded (except in the most extreme circumstances). Reject it. Rejecting a mail means that the receiving MTA returns an error code (in the 5xx range) to the sending MTA, so that the sending MTA may bounce (which it won't do if it is a zombie, so no scatterback).
Re: (Score:3, Informative)
How did this get marked insightful? Sending a temporary failure SMTP response code is not a bounce, and should not result in the generation of a
Re:Oblig. (Score:5, Funny)
Re: (Score:3, Insightful)
I didn't say confidential information.
An example would be an invitation to tender. Anyone can read that along the way, but if I lost out on a tender because my spam filter didn't like the sender's SMTP agent, I'd be pissed.
Also, you'd be amazed what happens in the business world. All sorts of stuff are sent via email that shouldn't be.
Re:Oblig. (Score:4, Funny)
Dear Partner,
My name is Sgt James Clayton. I need your help in keeping the money that we moved from Ba'qubah in Iraq safe. We moved this money some months ago to a Security Company in Italy. You know the funds are legal and it is oil money. we want to move the funds from Italy now to a secure place or location. Can you provide that? The total amount is US$25 Million dollars in cash. This money is in cash and we want to move it to you as soon as possible. Mostly $100 dollar bill notes.Total of US$25 Million dollars. So your share for helping me is US$12.5 Million dollars.Will you help? The whole process is simple and straightforward. I am still in iraq and i will be discharged soon but no one knows when this War will be over. I dont want to take any chances of loosing the funds. That is why we must act now.We are sharing everything 50/50. This is a legitimate transaction. If you are interested, i willprovide you further details and instructions. Please keep this confidential. We can't affo
rd more political problems. Can i trust you and will you help? Waiting for your urgent and positive response. Please send your full contact details so that i can reply you back asap. If you have any questions please feel free to ask, I look forward to hearing from you.
Yours Truly,
Sgt James Clayton.
That's "greylisting". (Score:5, Informative)
It's been pretty much defeated now because so many spammers have their machines try to hammer the message through until it does go through.
I'm using greylisting right now and the only advantage is that many times a spammer will end up on an RBL during the 15 minutes that I'm refusing his messages.
Remember, the spammers have, effectively, unlimted bandwidth and unlimited processing power at their disposal.
Re:That's "greylisting". (Score:5, Interesting)
I sincerely doubt that most of them would ever try more than the primary MX when delivering mail either.
Non-complience with the standards by email handling programs just makes it easier for the spammers by taking away a postmasters anti-spam tools
Re:That's "greylisting". (Score:4, Informative)
A better solution would be to ignore the problem, because those appliances are broken and need to be replaced or fixed no matter what.
Re:That's "greylisting". (Score:4, Informative)
However, I still believe that the best way to handle this situation is by not working around it. When users complain that a good fraction of their mail gets bounced for no apparent reason, there may be action. When you implement a workaround, things will remain as they are.
This does not only affect greylisting. I have seen bad SMTP bugs in NAI's virus checker, "SurfControl E-mail Filter", "logsat spamfilter for ISP", and another spamfilter whose name I forgot. tried to issue bug reports via their support system. It often is near impossible to submit a bug report when you are not a user of their product, and once you get through they are completely uninterested when you are not Microsoft or Sendmail. Pointing them to the RFC does not work at all, they fix bugs by the "if it delivers mail then it must be OK" paradigm.
Re:That's "greylisting". (Score:4, Informative)
see: http://it.slashdot.org/comments.pl?sid=132222&cid
From the FAQ (http://www.olympus.net/doubleVerifyNL):
DoubleVerify gets two chances to automatically identify mail. When mail arrives at our mail server the first time our server requests the sending mail server to send it a second time. Spammers rarely comply. Legitimate mail servers typically resend the mail about fifteen minutes later. Once OlympusNet receives mail the second time, it immediately delivers that mail and continues to immediately deliver mail from that sender. The DoubleVerify process works invisibly and is handled automatically by the mail servers.
Re:That's "greylisting". (Score:5, Interesting)
From the link...
--snip log example--
This spammer got stuck for 47 minutes. Current spamd sets its socket receive buffer size to one character, forcing the sender to send one TCP packet for each byte of data, even if its a non-compliant "dump and disconnect" mailer. Of course, the spammer nearly immediately tries to retransmit the spam. Repeatedly.
Re: (Score:3, Informative)
The trick is that I don't just use greylisting, I use greylisting + spamtrap driven RBLs, so that once the greylisting period runs out the RBLs have a much greater chance of having been hit by the same spammer and thus they catch him.
Grylisting on its was a temporary fix, but it makes spamtrap driven RBLs pretty much bulletproof.
You could get pretty much the same result s
Re: (Score:3, Informative)
Zero Spam is easy... (Score:4, Interesting)
*If* you are serious about getting rid of the spam then just do it. The technical part is readily available.
I deployed that almost a year ago and never looked back. I still see the occassional spam in a
mailing list folder because those go through unfiltered for obvious reasons but I couldn't care less.
My inbox has been spam-free since then and that's what matters.
I don't quite get why people are still bothering with greylisting, spamassassin, razor, dcc, bayes and
the ilk. I tried them all and they're more trouble than it's worth. You get false positives, false negatives,
it's a stupid game that you can't win.
Re: (Score:3, Interesting)
Most e-mail servers resend within 15 minutes (usually like 5-10), so it doesn't cause for much delay. Besides, once an e-mail made it through, we would simply allow all future emails from the same sender to the same recipient for up
Yep Funny (Score:4, Funny)
1. Please select format:
( ) In soviet Russia
(x) The same old form on spam subject we're tired to see here
( ) Some comment on female parts
( ) Suggesting you/slashdot_readers are virgins
( ) Will it run Linux?
( ) Cowboy Neal
2. Are you:
(x) Meant to be funny
( ) In a bad day, trolling
(x) Being authoritative on this subject
(x) Expecting to be modded up
( ) Agreeing with the news
(x) Trying to piss over something people might think it's interesting or relevant
3. Include "I'll be modded down for this but...."? (Y/N)
No
Thank you for submitting your message to the Slashdot forum.
Slashdot Quick'n'simple Form: The easy way to show people how smart your are!
Re: (Score:2, Funny)
We will later have to google: how to type a three page long sarcastic remark in such
time as to still be able to submit it to a
You are commended, but for what we have no idea.
Re: (Score:3, Informative)
Whiney Mac Fanboy is a subscriber. They (subscribers) get to see the articles before us mortals. First post isn't hard when you can reply to the article before the article is available to the unwashed masses.
Obligatory: Oblig. (Score:2)
Sorry, that wasn't meant to be a rant.
Re: (Score:3, Insightful)
All I actually wrote was the first paragraph & subject. 30 seconds work.
Re: (Score:3, Insightful)
http://www.craphound.com/spamsolutions.txt [craphound.com]
The point is that there aren't any truly novel, effective spam solutions waiting out there. Whatever it is they're suggesting, it's been thought of before, or something like it, and it's already been found wanting.
We don't need to rewrite the objections from scratch, and can just re-tread the old ones by filling out the form. Somebody will fill out that form for EVERY anti-spam solution posted o
Address Book (Score:3, Interesting)
One for mail addressed to someone in your mailbox.
One for everyone else.
90% of my spam problem would be solved by this simple recipe.
Re: (Score:2)
For a domain not having the catch all enabled remove a huge amount of spam though.
Re:Address Book (Score:5, Interesting)
Flowchart:
Re: (Score:2)
I'd say a great many of your check marks might have also been said about the "grey listing" technique. I have been using greylisting for a relatively short time (about two months) but the results have been more than remarkable. This technique certainly warrants a slightly better evaluation than the one you provided above.
Greylisting works for exactly the same reasons this other technique purports -- by utilizing a standard of behavior that real mail servers are suppos
Re:Oblig. (Score:5, Insightful)
Those statements could be refering to their use as open relays though.
Re: (Score:3, Interesting)
I do have the numbers to back this up... check out the stats at slowspam.com [slowspam.com] - this exploits the fact that some spammers target low priority MX hosts and then holds them in a tar pit for as long as they keep the connection open - 671 hours in one case.
More of an explanation here [blogspot.com].
Re: (Score:2)
You forgot option D
D) A Slashdot subscriber who gets to read the articles (and comment on them) before the articles are released to the great unwashed masses.
Re:Oblig. (Score:5, Funny)
We salute you, Hormel marketing, our spam overlords.
Re:MOD PARENT UP +5 THE FUNNAH (Score:5, Insightful)
The second time, I thought it was "ho-hum".
After hundreds, maybe even thousands, they are just plain lame.
The only good thing about them is that you instantly know that you can skip over them and not miss anything at all.
Re: (Score:3, Insightful)
The reason is that a lot of people preach some new approach to fighting spam, and in reality there are a finite set of reasons which defeat every single one of these ideas to date. When someone comes up with an approach that passes this form, then we'll have something to talk about. If it can't pass this form, then further discussion isn't really merited since it's not even novel enough to get past the standard set of
Temporary Solution (Score:5, Insightful)
Re:Temporary Solution (Score:4, Interesting)
I used to received about 6 million spams a day across 3 relays for this domain.
I removed all MX records for the domain, and the hostnames have nothing to do with the domain (so A record lookups won't help), but 30 days later I still was receiving over 2 million spams a day. After about 6 months the number really started falling off.
Re: (Score:2)
If you are really no longer using those addresses for communications, you could use them as a spam canaries.
Increase the spam "score" of any message that goes to those addresses. If it's multiple "unrelated" addresses then it's even more likely to be spam.
The spammer has to somehow detect this or send more unique emails - which slows them down.
Re: (Score:3, Informative)
I handled other domains on the same servers, so I'd still see the requests come in
Re: (Score:3, Interesting)
It's not hard to think that spammers are probably keeping lists of IP addresses rather than DNS names. They don't care about correctness, so there is no need for them to try the correct SMTP server. Therefore, why bother with the overhead of DNS? Or
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
I've got a similar story. When a good local ISP got bought up by a crappy CLEC who ran it into the ground, I switched over to the ILEC's DSL offering. However, they never closed my e-mail account, so I kept reading from it. After a while they switched their authentication so that I had to log in as "user@domain.net" instead of just my user name, but it still accepted my password.
Naturally, all I got was spam on that account. But then the CLEC dropped the old domain name, which got snatched up by an ISP
Spammers often try secondary MX's. (Score:5, Insightful)
The more machines you have to maintain, the more likely you are to focus your efforts on the most critical ones and just let the other slide. Spammers are happy to exploit this.
Re: (Score:2, Insightful)
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Not only do most spammers not pay for ba
Re:Temporary Solution (Score:4, Funny)
Re:Temporary Solution (Score:4, Informative)
This means that servers *must* be RFC-compliant to deliver mail to a no-listed server - they must try to deliver to servers in the published order, and must try at least two.
The big advantage with no-listing is that if the sending server immediately tries the secondary after the primary fails, here is almost no delivery delay.
The big disadvantage of course is that an RFC-compliant spammer gets almost no delay either.
Re: (Score:3, Informative)
http://www.joreybump.com/code/howto/unlisting.htm
Short Term Solution (Score:5, Insightful)
1) It's bad netiquette, and a lot of people don't like that, including myself and I'm sure many other administrators.
2) It's an artificial "defense" that is easily circumvented because the rule is obvious. It's security through obscurity with the added suck that there is no obscurity.
3) It's solving a symptom and not any of the actual problems (e.g. hosts being compromised to send spam).
Thanks, but I'll pass.
Re: (Score:2)
I'm sure you advocate murdering the spammers for their deeds... (I don't though I quietly hope to see headlines to that effect in the daily news) but expecting marketers to "follow ettiquette" ain't gonna happen. At all professional levels, the same basic abandon of moral and ethical standar
funny (Score:4, Funny)
Funny, I fight afternoon meeting schedulings in almost the same way. Just specify a primary time that's always unavailable.
OT - Re:funny (Score:4, Funny)
When I worked overnights, I had a similar system.
Boss: We need to talk.
Me: Great. What night would you like to come in?
Boss: No, I mean you should stay late.
Me: But you don't come in until 9, and my shift ends at 7.
Boss: But it's important!
Me: Why is it always about your needs. Your need to have a meeting. Your need to get a decent night's sleep. What about my need not to sit around for two hours on the clock waiting for you to show up, surfing the web, all the while getting paid one-and-a-half my regular pa...okay, fine, you win.
Then, when I became the boss years later, I would always show up at the beginning of the night shift to talk to the employees, and then go to the bar. It made the employees feel noticed and made my superiors think I was motivated. Turns out my best defense against assholes like me is actually having been me.
I run a mailserver, this is a bad idea (Score:5, Insightful)
Dumb idea. You're better sending all your domain mail to gmail, using their spam filtering, and then pulling it from there.
I run a high volume mailserver, this is a bad idea (Score:5, Interesting)
We have thousands of domains pointed to our mail servers and secondary MX servers. Looking at the long run stats, I'd be tempted to completely disregard this technique.
When we take a primary down for maintenance, the secondaries and alternate primaries (same weight MX) see the load almost immediately.
I second the opinion that if this has any effect, it's only for low volume applications, with few/one domain.
We generally see more hits straight to the secondaries by spammers hoping for less rigorous checking. It would be interesting to profile IPs connecting to secondaries without being seen at the primary assuming a primary is always available - I bet that a very high percentage of these connections to secondaries could be viewed as spam.
The problem remains that most tricks of this sort - including greylisting - are eventually circumvented by spammers once the trick gains critical mass. Lets not forget that there are a lot of broken, yet not open relay, mail servers out there. Good engineers and administrators quickly find that Jon Postel's words ring true with their customers "Be liberal in what you accept, and conservative in what you send." - don't let your RFC enforcing configuration be responsible for delaying/blocking the delivery of that big contract your PHB was waiting for!
Re:I run a high volume mailserver, this is a bad i (Score:4, Informative)
I run a fairly low-key server, which I only use for my family, so I am not sure how relevant my data is.
I remember at one point last year checking on the usage my backup MX gets and was surprised to see a lot of mail coming through it. Surprised because my primary server is (almost) always available. Upon a closer inspection I was astounded by what I found: all the email that came through the backup MX was spam for the past year was spam. No exceptions!
Certainly, mine is an extreme case, but I think the trend is very clear.
Won't work. (Score:5, Insightful)
However, this idea would have been *great* six years ago. Once the developer invents a time machine, he's got the spam problem licked for at least a week!
Re: (Score:2)
Do you have any experimental results to back up your claim? Any actual reason to believe it's true? Because he has results that dispute it. Read the article. In his quick experiment, 47% of confirmed spammers tried the primary only, 36% tried the secondary only, and only 17% tried both. While possible that his sample is skewe
Re: (Score:3, Informative)
he has results that dispute it.
If you take a look at his page, he says that he used DNSBL.
DNSBL host != spam-bot
Spam-bots are a subset of the hosts that would be listed in a DNSBL.
Next time, before attacking someone, you might want to work on your reading comprehension skills. You'll look like much less of a fool.
Re: (Score:2)
This is bullshit! (Score:3, Funny)
There is more spam than penises needing enlargement, dammit!
I cant believe this is allowed to go on. How long did it take for callerID and no-call lists to get here? How long before we start putting these people in jail!
No more bandaids, lock these fuckers up!
Re: (Score:2)
Re: (Score:2)
A lot of spam is aimed at getting money. So, follow the money (hey, that sounds like a good catchphrase).
Their customers are the ones at fault here. (Score:2, Interesting)
A number of recent studies have shown that most of the major purchasers of goods adverti
Re: (Score:3)
Re: (Score:2)
Re:This is bullshit! (Score:4, Insightful)
Spam is NOT free speech. You cant come into my home screaming penis ads at me without getting your ass kicked, so why should you be able to do it into my mail server?
Re:This is bullshit! (Score:5, Insightful)
You need not open your mail to have your resources (bandwidth, disk space, processing power) consumed by spam. I work at a major telecom company running the edge mail servers, along with another full time engineer. Of the 12 million emails we get a day, about 100,000 are legitimate mail. The rest is just spam, and it uses up the bandwidth that could've been resold to customers, it uses up the disk space on the expensive mail servers we bought a few months ago, hell it forced us to buy those expensive new servers in the first place. I figure, just in the extra salary (if not for the spam one guy would be enough to handle the load), having to upgrade perfectly adequate five year old servers, and buying licenses for anti-spam products at four different levels of mail delivery throughout the enterprise just to keep our users from being deluged with useless garbage, the company has spent about $200,000 last year, and will spend about the same amount this year. All because a bunch of asshats want to force our employees to read their idiot advertising, using our network resources to push their message.
That's not free speech, that's theft. And that's never been legal.
Attacks on 2ndary relays (Score:3, Informative)
Since in our case, the 2ndary MX was a dumb sendmail relay only without knowledge of the user DB, it shot the traffic load out thru the roof with bounces to junk spam that, because they couldn't be rejected during the actual delivery attempt, hammered our backup relay.
This is just a dumb idea.
Re: (Score:2)
Some spammers target secondary MX first (Score:5, Insightful)
Based on watching a few corporate spam sites and even stuff which reaches my private, never-posted addresses, *much* of the spam could be eliminated by moving non-Windows clients. I'm not just talking about zombies. Some of the spam I see hits lists of addresses which are valid and include very difficult to guess addresses inside the company. Once somebody inside your company, or a buddy of yours is rooted, your previously private address is out there; I've never had this happen via any route but a Windows user. Of course, people who CC: everybody they know with idiotic crap instead of BCC: make this problem much worse.
Oh, and please stop with the lame form letter responses to these articles. It was cute once, long ago. I know at least five people will have posted them by now. Damn spammers.
Thanks slashdot... (Score:2)
Okay everyone, switch your primary back - and don't post it on
Oh, wait... doh!
buh (Score:3, Funny)
Of course, the same might be true of legitimate senders, as well....
And WHY won't google rent out Gmail's filters? (Score:4, Insightful)
Re: (Score:2)
I will say that GMail is less likely to mark a valid e-mail as spam though, from what I've n
Opposite of what I've seen (Score:2)
Not as good an idea as it sounds (Score:4, Informative)
Spammers IGNORE the MX priority (Score:5, Insightful)
Re: (Score:3, Informative)
What's with the breakage to fight spam? (Score:3, Insightful)
Re: (Score:3, Insightful)
I like to think there's an answer out there in game theory, but with the players numbering in the hundreds of millions if not billions, may be unsolvable.
Re: (Score:3, Interesting)
Because spam has broken the infrastructure. A working broken solution is better than a fully broken solution.
I now use my work e-mail and nothing else. Mail from outside lands in the junk folder as low priority stuff to be sifted later.
My home private e-mail hasn't been checked since October. It's been hammered to the point of being useless. I've gone to reach me by pager, phone, or business radio.
I no longer spend 20 minutes a day sortin
They will respond (Score:4, Interesting)
Many people were already using this trick, probably hoping it wouldn't show up as lead story on slashdot.
In some ways, selfish ways, it's like the story of the two hikers who face a bear. The first hiker immediately sits down and starts putting on his running shoes. The other says, "What are you doing? You can't outrun the bear!" The first hiker says, "I don't have to outrun the bear. I just have to outrun you."
Many spammers, faced with a failed attempt at sending mail, do not bother to retry or try other MX. Instead, they just move on to the next target in the list, since trying a new target is just as easy as retrying an old target. No real difference to them. But it means you just push your spam attempts onto other people who haven't elected to bend the standards to divert the spammers.
The "good" spam sending programs run many threads, timeouts don't punish them, their limit is more the bandwidth. Attempts to divert spammers onto others who have not tried the tricks should create an ethical question. Are we just arranging for the bear to eat our friend?
The only solution... (Score:3)
Just like MailHurdle (Score:2, Informative)
It works wonderfully. We've been using for about a year at my organization. It works by initially rejecting all incoming mail from unknown servers. If the server is legit, it will retry the email, and on that retry, MailHurdle will allow the mail through.
It instantly eliminated well over half of our incoming spam. Very clever technique, and it certainly works.
Nolisting + Port Knocking? (Score:4, Interesting)
Instead of blocking the connection to the primary at a firewall or using an "unused" IP address, the primary SMTP server could give a greeting banner and then immediately return a "temporarily unavailable" status code (and cache who was connecting there).
In other words, an RFC compliant MTA should be connecting to the higher priority host as defined by DNS first, then fail over to the lower priorty host, in order. If an MTA tried to connect directly to the secondary MX first it could be rejected with a temporary failure status code which a spammer is likely to ignore. It would require the SMTP receiver to keep a cache of who had connected to what IP addresses within a certain time period which would eat up some memory depending on traffic load. We already cache reverse DNS lookups and RBL lookups, so it could probably be done.
With this setup you would have two MX records for your primary mail server that your SMTP server would be active and listen on. It would just track the order of connections to ensure that the remote MTA was following the rules before it allowed the source to get past the greeting banner.
I for one... (Score:4, Insightful)
One of the worst Ideas I have ever read on /. (Score:3, Insightful)
This is one of the worst ideas I have ever read. Intentionally introducing a large and unpredictable delay into the receipt of all e-mail.
What's next, a recommendation to cut down on telemarketing by setting your PBX to automatically disconnect 50% of all incoming calls?
This doesn't work (Score:3, Interesting)
Re: (Score:3, Interesting)
That's what I thought, too. But then I thought, 'make your highest AND your lowest priority servers dummies.'
Re: (Score:3, Interesting)
I WTFA... (Score:3, Informative)
...and encourage readers to RTFA, where I've addressed many of the issues brought up in these comments. I also encourage people to try the technique, if they are in the position to do so (admins only, this is not a solution for endusers), and evaluate it for themselves. Or not. It's true that most new antispam solutions are dreamed up by crackpots. I might be a crackpot. If this possibility concerns you, don't be an early adopter. Wait and see.
It's true, in my experience, that Nolisting stops some spam with no false positives (in my experience). And that's a Good Thing. But it doesn't stop significantly more spam than a combination of other techniques, which I also implement. Some of those techniques use a lot of resources, such as content filters (often powered by perl) and virus scanners. Nolisting provides a way to free up some of those resources, possibly resulting in better performance and even hardware savings. These savings can be significant at large sites that currently scan each and every message that arrives.
Nolisting can be bypassed. I don't make any wild claims. Spammers can get past it easily by going directly to the secondary MX. Guess what? They already do that, and have been doing that well before greylisting was introduced. Nolisting significantly reduces the percentage of spam my MX processes, thereby freeing up resources. It's just one part of a layered solution.
I've limited secondary MX access by extending Nolisting into Unlisting (Port Knocking for SMTP): http://www.joreybump.com/code/howto/unlisting.html [joreybump.com]. It's wildly effective, except for one serious problem: A retry might originate from a different IP. This appears to be legal, and seems to be the result of load balancing strategies adopted by some important sites. For that reason I don't recommend it. It will randomly block messages from gmail, for example. You can't reasonably predict the IP a multihomed host will use for a retry, so be very skeptical of any approach that claims to have solved this problem.
Unwanted email is annoying. When it carries a payload, it is potentially dangerous. But I don't really view this as a security issue. I don't buy the argument that Nolisting is security by obscurity, and therefore bad. It's a form of access control, a gatekeeper, a prophylactic. It's an apple a day, not a cure for cancer. It's not addicting, fattening, or life-threatening. Try it, if you're looking for ways to improve the health of your mail system. Discontinue use immediately at the first sign of complications. Side effects include more sleep and time spent with your kids.
Nolisting rarely introduces delays. As I point out in the article, most relays retry immediately. Any relay that cannot get beyond Nolisting is seriously, seriously noncompliant. While I don't suggest Nolisting as a complete replacement for Greylisting, it is a viable alternative for sites that experience problems with Greylisting and find the delays it introduces to be unacceptable. As the name implies, Nolisting is meant to used without dependence on whitelists. Wider adoption and testing will determine if this ideal has been realized.
Like Greylisting, Nolisting breaks infrastructure to some degree. Many admins find this distasteful. I know I do. If Nolisting becomes widely adopted, logs will become fatter with "Connection refused" errors when the primary MX doesn't respond. I'm sorry for that. But our logs are already fat with 45x errors from Greylisting, RBL disconnections, SpamAssassin scores, etc. Nolisting might even help to make logs smaller, if you currently see a lot of these messages. Time will tell. Keep an open mind, and remember that we often make concessions to improve a system's overall health. Just reducing the possibility of another zombie being created on the Internet creates benefits for everyone.
Try it before you draw a c
SPF... (Score:3, Insightful)
And whats with the anti SPF sentiment? Its not like we've got a lot of more effective alternatives on the market and the only real argument I read is the rejection of real email, when softfail pretty much takes care of that (then leaving it to spamassassin to decide if the mail is legit).
We send an receive a good deal of email and I certainly wish SPF was more common. I'm tired of forged bounces and the *slew* of undeliverable responses 'dumb' servers return to our system every day.
Yet instead of taking any real action we bicker while spammers laugh all the way to the bank. Their is no magic bullet, but from my POV SPF is the closest thing yet (unless my DNS gets hi-jacked, but then I'm fucked anyway).
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Interesting)