Novel Method for Universal Email Authentication

MKaplan writes "Most spam is sent using spoofed domains. Email authentication schemes such as SPF attempt to foil spoofing by having domain administrators publish a list of their approved outgoing mail servers. SPF is sharply limited by incomplete domain participation and failure to authenticate forwarded email. A paper describes a novel method to rapidly generate a near-perfect global SPF database independent of the participation of domain administrators. A single email from an unauthenticated domain is bounced and then resent — this previously unauthenticated domain and the server listed in the return path of the resent bounce are entered into a globally accessible database. All future emails sent from this domain via this server will be authenticated after checking this new database. Mechanisms to authenticate forwarded email and to nullify subversion of this anti-spam system are also described."

Greylisting?

[mmcuh]

Isn't this the same thing as greylisting [wikipedia.org]?

Re:Greylisting?

[Anonymous Coward]

No, not at all. If you don't want to read the article, just keep guessing how it works, and we'll let you know if you are getting warm.

Re:

[flydpnkrtn]

You've been here a while, hmm? Next you'll be talking about Soviet Russia

Re:

[xtracto]

Haven't you seen his name? he is Anonymous Coward... this guys has been spamming the otherwise clever discussion threads since the inception of Slashdot...

Not exactly. I think.

[khasim]

He's talking about "bouncing" messages ... but I cannot tell if he means resending an accepted message or denying it at SMTP time.

Then he talks about having people install software:

Auto-Resend software will ensure that almost no one will see or be required to manually respond to the email seen in Figure 2. Auto-Resend software is a simple onetime update for webmail systems, email clients, and local mail servers.

Yeah, installing new software is a great solution.

That's the problem.

[khasim]

He does not CLEARLY explain what he is intending.

I believe he means denying at SMTP time, so the sender will try again after X minutes.

Which is kind of like greylisting. The FIRST problem is that the spammers have adapted to this and retry.

The SECOND problem with this is he's saying:

Unique sub-addresses are dispatched in the 'From' field with routine outgoing email. [e-mail] may send RIAuser^[e-mail] to one individual and RIAuser^[e-mail] to another individual.

Huh? So this is also about SENDING email?

Now if you could bounce the message, it would just go back to the original IP, so I don't see why that would help either though.

And it doesn't address the issue of "fast flux" where the domains are "legit" in that they exist and point to the IP address of the sending machine ... for a few minutes.

So he's talking about "bouncing" messages ... installing new software ... and altering the "From:" addresses on stuff YOU send ...

No fucking way is this going to work.

Re:

[SCHecklerX]

Which is kind of like greylisting. The FIRST problem is that the spammers have adapted to this and retry.

This is exactly why greylisting is effective. It pushes the cost of spamming back on the spammers. Now they have to have a semi-legitimate mail relay, vs. fire and forget. If everyone greylisted, then the spammer's mail queues would be huge.

Of course, all bets are off with zombies that start using legitimate SMTP servers, but there are solutions to that already in place:

1. Many ISPs volunteer their list

So?

[khasim]

This is exactly why greylisting is effective. It pushes the cost of spamming back on the spammers. Now they have to have a semi-legitimate mail relay, vs. fire and forget. If everyone greylisted, then the spammer's mail queues would be huge.

So? They don't care. They have, effectively, limitless bandwidth and limitless processor power.

Greylisting WAS effective ... before so many people adopted it. Now it only catches the dumbest spammers.

The only place this fails is if the spammers as part of their owning of zombie hosts begin to check for the proper SMTP server to relay through and configure accordingly. Admittedly, this is not too difficult to do, but they aren't doing it yet.

No. It fails when they implement (as they have) a process to resend any temp rejections after X minutes.

Greylisting had THREE features:
#1. It could temp reject spam and if the spammer never tried again ... success.

#2. It could temp reject spam and if the spammer randomized the "From:" username/domain ... success.

#3. It could temp reject spam and if the IP addresses was listed in a blacklist within the temp reject time frame ... success.

Now all that is left is #3. It costs the spammers NOTHING to upgrade the zombies. And if they get the spam through, the spammer wins.

Now, the zombie can appear MORE legit than a lot of the real mail servers out there.

Re:

[fossa]

Do you have any data on the exact date or extent to which greylisting became ineffective? I'm currently researching spamblocking techniques for myself, but my personal spam data [polycrystal.org] suggests that greylisting was fairly effective as late as May of 2007. I disabled greylisting at that time for various reasons; it would be dissapointing to find that greylisting is no longer effective. (Data includes spam from two-three personal addresses on a server that accepts most anything. Yes, I use client-side filters.)

Greylisting is effective for me

[baileydau]

Do you have any data on the exact date or extent to which greylisting became ineffective?

I don't know about the GP, but for me greylisting is very effective. I have a personal domain for my wife and myself. I have a catchall mail address.

Here are some stats for part of last week:

Start Date 23/09/07 04:02
End Date 28/09/07 17:00
                5.54 days

Total spam: 4624
Spam blocked with greylisting: 4478 (96.8%)

spam via backup MX: 69 (1.5%)
spam retried (got past greylisting): 77 (1.7%)

Total through to end user: 146
Identified as spam (SpamAssassin): 123 (84.2%)

backup MX marked as spam: 50 (72.5%)
direct marked as spam: 72 (93.5%)

Total to end user not marked as spam: 23 (0.5%)

NB. Up until about a month ago, ~25% of SPAM came via my backup MX, which doesn't have greylisting. I don't know why it dropped, but I'm happy it did.

Re:

[cas2000]

The only place this fails is if the spammers as part of their owning of zombie hosts begin to check for the proper SMTP server to relay through and configure accordingly. Admittedly, this is not too difficult to do, but they aren't doing it yet.

it's not difficult to do, but most spammers WON'T do this for two related reasons:

1. it destroys the scaling benefit they get from having many thousands of spam-spewing zombies. i.e. instead of having hundreds or thousands of zombine machines directly sending spam

Re:

[afabbro]

He does not CLEARLY explain what he is intending.
The SECOND problem with this is he's saying:
Huh? So this is also about SENDING email?

Ah, I'd wondered where Robert McElwaine had gone...

Re:

[canuck57]

No fucking way is this going to work.

That is what I thought when I saw it on firehose yesterday and marked it binspam. We do need to get the moderators to research this a little before posting self indulgence stories. As I suspect the posters of such crap are using firehost to notch up their stories.

And you only tipped the edge. What if I sent 5000 messages to 5000 domains with the same senders address... oh the fun.

And more, but I will not bore the /. users with the lengthly list of flaws. He got h

Re:

[FlyveHest]

I believe he means denying at SMTP time, so the sender will try again after X minutes.

Which is kind of like greylisting. The FIRST problem is that the spammers have adapted to this and retry.

Huh? When I take a look at how many mails are bounced on all my domains, thanks to greylisting, each day, and hold it against how much spam actually enters my mailbox, i'd say they haven't adapted at all.

When you are sending millions of mails, retrying is far, far more expensive than just ignoring it.

Random 450s

[flyingfsck]

Instead of greylisting, I have experimented with a system where my SMTP receiver would send '450 try again later' messages randomly to incoming connection attempts. It actually works. Since the vast majority of incoming mail is spam, a 50% rejection rate reduces spam by almost 50% since most spammers will not retry, while legitimate mailers will.

In the end, I settled for an even simpler approach, where I just throttle the receiver dramatically, so that it takes about 10 seconds to receive a message. Most

Re:

[Bogtha]

It seems to be greylisting, except instead of rejecting the message during delivery and relying on standard SMTP features, he wants to accept the message, send a bounce, have the other party install software to automatically re-send the message upon receipt of the bounce, and then add the sender's mail server to a whitelist the second time the email comes through. Awful idea for all different kinds of reasons.

Re:Greylisting?

[tacocat]

I don't know, I didn't get that far. The article and the concept is bullshit.

The 'From' field is the keystone of their identification process. Well, I got news for you if you bothered to read the RFC. 'From' does not have to represent the real sender. I can forge it up all I want into anything I want and you can't tell. I didn't get past section 3 where this is before I determined the rest isn't worth reading.

Once again we have another company trying to come up the next Big Thing and they don't know what the hell they are talking about. SPF is cute -- but relies too much on people setting it up and correctly. I suppose you could pay a service to act as a third party validator, but that's turning into a boondoggle too.

I don't think bouncing email at valid senders is going to win any friends.

Perhaps there is a way to do it successfully and with great accuracy. I would love to say I'm working on it. But quite frankly, if I do figure it out I probably won't mention to anyone since I really don't want the legal hassle of trying to defend my idea against someone else's billions. I can block spam. I can block spam to the tune of 99+%. The rest is trivial. I was even surprised to hear them say 94% was the average. Perhaps people would be better off if they stopped using SpamAssassin.

Sorry, my opinion is that statistical filtering is more than sufficient if it's managed well. I think few people are willing to do the work required of them to make them spam free. Kind of like locking the door to keep out the crooks.

Re:

[hedwards]

Once again we have another company trying to come up the next Big Thing and they don't know what the hell they are talking about. SPF is cute -- but relies too much on people setting it up and correctly. I suppose you could pay a service to act as a third party validator, but that's turning into a boondoggle too.

Validators help, but I thought that there was an official program to help set up SPF records.

The way that I look at it, is that an SPF record is a useful complement to statistical analysis. It is one more factor which can be used by the filter to decide whether or not it is legitimate.

A good implementation will take emails from gmail, Paypal, ebay or other SPF/Domainkeys domains and chuck them into the spam bin automatically if they don't have the proper records attached. While no admin on their own is goi

Re:Greylisting?

[MightyMartian]

How many times have we heard the "this will fix Spam real good" claim? First it was "close those open relays, ye bastards", and lo, that worked for about a week. Then it was "Well, we'll just keep these black lists, and that'll fix things", until of course the complexity of maintaining such lists and the harsh consequences for any poor bastard who somehow found himself the victim of a false positive tried to get himself off said lists. Then there was "We'll just tarpit consumer IPs based upon some nifty string-matching" and the matching "we'll check reverse IPs, and if they don't match, fuck ya!" which of course buggered up all those poor guys using their cable and DSL connections to run small personal mail servers, or anyone with a retarded or miserable provider who refused to alter reverse DNS entries. Then there was "Hey, you don't have an MX record for that IP, so down the shitter ye go!", which nailed anyone who might be sending from sort of a proxy, and didn't want their actual mail servers advertised as such so that they didn't become victims of joe jobs and distributed dictionary attacks. Then there came greylisting, which actually worked for a while, but seriously screwed with "immediate delivery" that all those in the post UUCP world had become accustomed to with email, not to mention the smart spammers learning from the trick and just retrying. SPF was then heralded as the end-all and be-all, but of course has its own problems (particularly with message forwarding, which requires rewriting the header), not to mention that everyone came into compliance with neutral records, so at least the big guys wouldn't jettison mail from their server due to lack of an SPF record.

At the end of the day, you're right. Statistical filtering, with the careful use of all of the above solutions (though I think whitelists/blacklists are as bad as the problem they attempt to solve) is the only way to reliably filter spam. You're never going to catch it all, but the ISP I worked at was catching, by my estimate, about 90% to 95%, which meant that a guy getting about fifty spam a day was down to three or four, and in many cases less than that. It does mean work, there's no solution that doesn't require monitoring, management and tweaking, because the spammers are smart bastards who learn the tricks as fast we can come up with them.

That's already implemented with Spamcop

[no-body]

Mail servers are authenticated by Spamcop and forward spam automatically to Spamcop which adds it to their database. When using reject_rbl_client bl.spamcop.net SPAM is blocked.
Works like a charm!

Re:

[no-body]

&& that's IP based, not domain name based, so the SPAM originating IP is known and can be blocked

Re:

[John Hasler]

My ISP uses it. It frequently bounces my Debian mail. I'm moving my mail to Newsguy where I can turn the damn RBLs off and filter my mail myself.

Fails to account for SMTP farms...

[pathological liar]

So what happens when you receive an email from a big site like Sympatico, Hotmail, or any number of other places that have farms of SMTP servers, where your message isn't guaranteed to be resent from the same IP?

This also requires users to install software to use effectively, and features CAPTCHAs which are a usability nightmare and not nearly as impregnable as the author thinks.

All that effort instead of just adding a TXT record to their domains.

Re:Fails to account for SMTP farms...

[bennomatic]

So what happens when you receive an email from a big site like Sympatico, Hotmail, or any number of other places that have farms of SMTP servers, where your message isn't guaranteed to be resent from the same IP?

And OKing the receipt of any address at a domain from such an infrastructure seems less than ideal. I mean, if I send out all my email for "[e-mail]" from Hotmail's SMTP servers, I'm not sure I want that to automatically give the go-ahead so that anyone can send spam from "[e-mail]" and "[e-mail]", etc..., from those domains.

SPF, as I understand it, has some contexts in which it works well. But it doesn't cut with fine-enough a blade as far as I'm concerned. Automating the process so that I (if I haven't set up SPF records) could allow spammers to use my domain with more authority by responding to an automated message just doesn't sound like a good idea. I think this opens up the door for a lot more spam if people believe in it.

If it went a step further and tried to authenticate each time a unique USER@DOMAIN pair sent an email via a particular host, I could see that being useful. The protocol could be extended such that even the SMTP farms could conceivably use something to say, "if authorized at one of my servers, an email should be authorized at all of my servers". But it's a lot of work to get there, and the size of such a universal database would be ridiculous, and it seems that for there to be a single-source host for such a thing, there would have to be a lot of cooperation between some major corp^H^H^H^H sources of funding.

Re:

[MightyMartian]

Let's just try to imagine the resources required for this sort of a setup in the case of a distributed dictionary attack. The ISP I used to work at, which was small and had about a thousand email addresses, was, on average, getting nailed with about 500,000 such attacks per day (and with some days being double that or more). In fact, it got so bad that the crappy IMail server I was forced to use because it ran under Windows would actually become non-responsive. Putting in two old Pentium-233s with Linux

Re:

[bennomatic]

I totally agree, hence my quote of... "and the size of such a universal database would be ridiculous".

If bandwidth, CPU and data storage and access were infinitely available resources such that an attack as you describe wouldn't make my suggestion effectively impossible, I would push for my idea. However, my idea was simply to address some of the shortcomings of the original idea in the article.

Unfortunately, at this time, there is no magic bullet for spam. I use some heuristic filters, but mostly I j

Re:

[bennomatic]

No, no, no.

Everything is not a nail. But SPF is a hammer that does not even get the nail all the way in. What I am suggesting is that SPF is a very limited solution, and that may be why it's not universally implemented. And I'm saying that auto-implementing it will still leave the option of sending out some kinds of SPAM wide open.

I'm saying that if we really want to defeat spam, someone needs to intelligently integrate greylisting, SPF, heuristic filters and a number of other systems into a useful a

Re:

[eric76]

SPF is nearly useless. As far as I can see, the only thing SPF is useful for is to get a list of servers from which e-mail for that domain may originate. Then, if you regularly get e-mail from that domain, whitelist their servers and greylist everyone else.

I completely agree that the author's suggestion is a waste of time. Actually, it is worse than that since it will bounce the spam to the apparent senders. That means that someone other than the original recipient gets the spam instead.

Re:

[bennomatic]

Good point about the bounces. I hadn't even thought about that. With forged addresses, it's still a hassle for *someone*.

I could imagine a situation where someone gets hundreds of those authentication bounces in a day; who would think that person would appreciate the intention of the system?

Re:

[cas2000]

As far as I can see, the only thing SPF is useful for is to get a list of servers from which e-mail for that domain may originate.

amazing! you've cleverly deduced that SPF's sole function is exactly what it is documented to be.

many people think or claim or assume that SPF is supposed to be an anti-spam system. it's not. and never was. it has always and only been an anti-forgery system - a way for domain owners to list exactly which servers are allowed to send mail claiming to be from their domain.

whet

Re:

[Sancho]

The problem is where that effort comes from. Client-side spamfighting solutions put the burden on the client--I'm totally in control. Fighting spam with TXT records require that I reject all mail from domains that don't have a TXT record--which isn't really an option for everyone.

FUSSP

[Just some bastard]

Basically this guy is proposing an automated whitelist (for domains without SPF records) via a local database. At least I think what the paper is about, I gave up reading it earlier. It lacks a concise summary, doesn't read like a well researched paper and the diagrams don't even display without javascript.

The author may be an anti-spam kook [rhyolite.com] but the paper is so badly written I can't be bothered identifying which.

Re:

[adrianmonk]

the paper is so badly written I can't be bothered identifying which.

Thanks. I'm glad to get confirmation it wasn't my reading comprehension skills that caused me to give up after ever single word in the paper caused the mental fog to get a little bit thicker until in the end (actually somewhere in the middle), I had no earthly idea what the damned thing was about.

Cue form response

[bperkins]

I'm surprised I don't see it.

Re:Cue form response

[Epsillon]

Your post advocates a

(*) 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
( ) 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
(*) 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
(*) Features in MTA software that can be disabled, such as MDNs
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) 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
( ) 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
(*) 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:

(*) 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!

I didn't spend too much time looking through the options, so go easy if I got it wrong. Will that do?

oldie but goodie.

[djdavetrouble]

As soon as I saw a spam Item, I just skipped forward to this good old reliable post.
Funny because its true !
I really love this one...

Re:

[bennomatic]

This response is always funny, but, it's not exactly constructive.

Got a better idea?

Re:

[Epsillon]

I agree, it isn't constructive. The form was mentioned and I posted it. However, it does highlight a very critical issue that people just keep ignoring: Why does there have to be a technical solution to a social problem? Spam is a social problem: On the one hand you have the greed of the spammer and on the other is the stupidity of the user responding to it. No amount of blocking techniques, block|white|black|greylists, Bayesian filtering or even vigilante-type fightback is going to stop it whilst the users

Re:

[Antique Geekmeister]

VD is a social problem. Social changes are only part of the solution, some technology to protect the innocent is useful as well.

Re:

[Epsillon]

...only they're not so innocent, are they? Let's face it, most spams centre on something at least a little grey in its legality. If the users weren't gullible, greedy, shady and stupid enough to be drawn, spam would have no value. Let Darwinism run its course, please. Trying to protect people who really don't want to be protected is just prolonging the agony - for all of us.

And, yes, anyone who really thinks "love you long time" is all you'll get for ten dollah deserves every card life's dealer hands them

Re:

[cas2000]

...only they're not so innocent, are they? Let's face it, most spams centre on something at least a little grey in its legality. If the users weren't gullible, greedy, shady and stupid enough to be drawn, spam would have no value. Let Darwinism run its course, please. Trying to protect people who really don't want to be protected is just prolonging the agony - for all of us.

it's not just the idiots who respond to spam who are protected by technical anti-spam measures. in fact, the vast majority of spam r

No, I didn't RTFA..

[Anonymous Coward]

...but this had to be posted.

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
( ) 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
(X) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) 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
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook

and the following philosophical objections may also apply:

(X) 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
(X) Blacklists suck
(X) 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
(X) 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!

Another objection

[knorthern knight]

(X) and I don't trust ideas from an idiot who can't put up simple text web page with a few gifs that will display properly in browsers that have javascript disabled.

Re:

[MarsDefenseMinister]

That's the point of SPF. It detects when the header is fabricated, and the virus detector bounce messages can just be dumped.

Most of the million spams a month I see are from Norton or some other idiot company telling me that the message I sent to them contained a virus. No, if they'd just had the data (but they already do! I use SPF) they could see that my server has one valid mailing IP address, and it's not on a Korean DSL line.

Re:No, I didn't RTFA..

[ScrewMaster]

Which just continues to show that all sophisticated security systems can and will be defeated by morons. There is no force on the planet more powerful than human stupidity.

Re:

[nuzak]

Your reply indicates an attitude of:

[ ] "My approach is immune from all criticisms"
[X] "Doing SOMETHING is better than nothing!"
[ ] Willfull ignorance of founded criticism.

Yes, it's a worn out joke (and yes, the form is a JOKE, it applies to ALL current antispam approaches). Yes, moderators are stupid. You must be new here.

Re:

[Matt Perry]

Your reply indicates an attitude of ... "Doing SOMETHING is better than nothing!"

That's somewhat true. You have to form a hypothesis and see where it leads if you are going to solve a problem. I doubt that anyone is going to come out of the woodwork and say "I have the solution" and be correct. We have to try many different things to see what works and what doesn't. Dismissing things out of hand isn't going to help find a solution to the spam problem.

Re:

[nuzak]

Indeed, it's trying things that has led to the current set of antispam tools we have now. The mail admin space is a world of viciously skeptical and outright cynical people though, who have seen more than a fair number of pitch-men with their silver bullets, and kooks with their Wondrous Golden Hammers. Something called "3D CAPTCHA" seems to be the particular favorite of Mr Kaplan. I don't even have to tell you what's wrong with captcha authentication for email, do I?

So no, it's not that trying something

Re:

[plover]

What his joke is offering is the insight that every easy route (and most moderately complex routes) to blocking spam has already been tried and failed. Every "new" whiz-bang spam filtering idea these days is merely a rehash or mashup of previous filtering ideas that still retain the problems that plagued the original ideas. The method described in this paper is not novel -- it's a complex mashup of whitelists, CAPTCHAs, Bayesian filters, and new mail client software, each of which has been tried and has t

Re:

[alienw]

I think your post is quite silly. Think about this: a human operator can generally tell spam from non-spam with 100% accuracy and zero false positives. This means the problem is possible to solve. The real question is how to do it easily and efficiently, and this is where the real problem starts. Most of today's approaches are simplistic and, thus, unreliable. This doesn't mean a good approach is impossible to implement. With some tuning, a basic SpamAssassin setup can be quite good -- I get about 130

Re:

[Pseudonym]

What his joke is offering is the insight that every easy route (and most moderately complex routes) to blocking spam has already been tried and failed.

And that is completely beside the point.

The fight against spam is an arms race, as the form points out. The form gets trotted out every time the Side of Niceness gets a new weapon. Yes, it's good to keep perspective: while there's money in spam, there will be spam. And in the absence of herd immunity, there will be a lot of spam. But it's not true that

Major flaw in methodology

[Todd Knarr]

The proposed scheme ignores one thing: the majority of bounce messages today are false bounces caused by spammer joe-jobs, therefore they themselves get flagged as spam and deleted/ignored. In addition, it also increases the annoyance of greylist authentication schemes, since a spammer forging my address in the From field will cause every host participating in this scheme to send me a verification e-mail for a message I didn't send which I'll have to deal with. The proposed scheme makes a very fundamental mistake: assuming that you can trust the sender's address in a message to be the true sender's address. You can do that only after you've determined the message is authentic and not spam, at which point you don't need this scheme anymore.

Re:Major flaw in methodology

[Dan B.]

Not so, most of the backscatter is sent to [e-mail] which is either quietly dropped if you have smart filters that look for mailer-daemon@ etc as the sender, or passed to your 'no one by that name' catch all mailbox. Some mail systems will in fact be terribly misconfigured for backscatter, but then how is that different from what we have today?

The worst email storm I got was when some spammer decided to use my domain as the sender of all his junk and send all hi junk twice. I do have SPF entries in my DNS so ANYTHING that would encourage others to actually USE this system is a GOOD THING.

Now if there were just a few simple packages available that would give us the one-click (tm) ability to add SPF filtering to Sendmail/Postfix/Qmail/etc, and MS Exchange 5.5/2000, then I would guess that 50% or more of the domain spoofing spam would cease. That can only be good, as I only get UCE from real domains that I can't check for authenticity, from spammers who bother to follow RFCs and send twice after postgrey (greylist filtering) blocks them first time around.

Re:

[Jay L]

I don't follow your claim; if a spammer sends spam in my name, and it hits the RIA filter, what makes you say the backscatter is not also sent to my name? According to TFA, it is (assuming my name is "Stranger aat mysterious dotcom").

And no, I'm not automatically filtering out MAILER-DAEMON, because (to the increasingly limited extent that bounces are sent these days) it's useful if I make a typo on an outgoing e-mail.

This scheme seems every bit as awful as those "Hi! Before anyone e-mails me the first ti

I'm not sure you understand what SPF solves

[Degrees]

SPF only solves the problem of SpammerS sending mail to MailserverB with a forged header to make the message look like it came from MailserverA. The assumption is that UserB might open the message if it says it comes from UserA.

SPF causes MailserverB look up DNS data for the email domain for MailserverA, and compare it's SPF published IP addresses with the IP address of the incoming email connection from SpammerS. If the two don't match, then MailserverB hangs up on SpammerS with a 566 eat-shit-and-die er

The BIG issue

[Skiron]

Is MS windows boxes that are comprised and doing this - you can see this where the spam mails get 'chinese whispered from one box to another and end up incoherent (to say the least).

Any ISP should/could get suspicious of thousands of mails sent from one 'home user' source at anytime. But when you have thousands of 'users' doing the same thing, it gets lost in the noise.

One simple solution is:

if account == home user & running MS
      if mails sent > 10 per minute
          block it
      fi
fi

etc.

Very easy.

Re:

[crossmr]

I have a friend who works for a large ISP here in town and they do something like that but the thresholds are much higher. He told me a story about a woman who had been blocked multiple times but refused to clean the viruses off her computer but would call and bitch that she couldn't send any e-mail. I guess each time you trip the system and get blocked its a longer block. The last time she had called in he said it looked like she'd been blocked at least a dozen times based on the length of that block.

Participation in SPF

[Anonymous Coward]

"SPF is sharply limited by incomplete domain participation"

That's not a big problem. 99% of non-participating domains fit in default SPF record "a/24 mx/24 ptr -all", we use it in qmail for few years. Together with Spamassassin it results in 99,8% antispam accuracy (warning: one big exception is yahoo.com, you should use domainkeys or add ptr:yahoo.com to default spf rule)

Re:

[terminal.dk]

Any description on how you did this ? Sounds like something we might like to try.

Check out existing discussion...

[enbody]

A Google search revealed this intelligent discussion of the scheme.
http://www1.ietf.org/mail-archive/web/asrg/current/msg12403.html [ietf.org]

"Office Live" link

[hey]

Whats with the "Office Live" link at the bottom of the article?!
Suggests a Microsoft-owned site.

Mis-read

[johnw]

Am I alone in having read that as "Novell Method for Universal EMail Authentication"? Might have been more interesting.

Novell Method?

[The Monster]

Only because so many people misspell the name of Novell by dropping one of the doubled l's that most of us have to impute the true meaning by context.

By the way, the above demonstrates the only way in which an apostrophe indicates plural number in Standard English: when referring to the plural of the character itself, such as "Dot your i's and cross your t's."

email has already been replaced

[Chapter80]

The spam problems of email are causing people to migrate to trusted systems.

As I stood at a kiosk at a trade show this week, and waded through my spam-filled email on a few services (work email, hotmail, and gmail), the young woman at the kiosk next to me accessed her myspace and facebook accounts and responded to friends only.

She turned and said that only old people use email. And she was a VENDOR at the conference.... Things that make you go hmmmmmmmm......

Re:

[adrianmonk]

The spam problems of email are causing people to migrate to trusted systems.

As I stood at a kiosk at a trade show this week, and waded through my spam-filled email on a few services (work email, hotmail, and gmail), the young woman at the kiosk next to me accessed her myspace and facebook accounts and responded to friends only.

If you think myspace users don't get spam through myspace, you apparently haven't ever used myspace. And if you think myspace handles the spam that does exist well, you real

Re:

[Chapter80]

I am far from an expert on Myspace. I've only used it to research job candidates. My only MySpace accounts are courtesy of bugmenot.com. So don't interpret what I say as researched opinions.

I was more just stunned that she sat on that kiosk and "worked" away on facebook and myspace.

Maybe LinkedIn or some other "more trustworthy" business-oriented social network site will help address the spam problem, by only letting you communicate with people who are in your "circle of trust".

Not a perfect solutio

Re:

[hab136]

Maybe LinkedIn or some other "more trustworthy" business-oriented social network site will help address the spam problem, by only letting you communicate with people who are in your "circle of trust".

The spam I get on Myspace is from spammers inviting me to be their friend.

If you can communicate with someone (even just to ask to be added to someone's "circle of trust") then you will receive spam over that channel.

Re:

[jez9999]

In Korea, only old people use e-mail.

Bounces Won't Work

[maz2331]

Many if not most mail servers now drop messages to invalid recipients at SMTP time and don't send bounces any more. I've had to implement this on every mail server I set up to keep the mail queues from backing up to several thousand messages to invalid "bounce" addresses.

It would work if bounce messages were still sent.

Not SPF, and similar to what I use...

[argent]

This is just an additional layer over automatic whitelisting of addresses using tagged responses.

Some years ago I set up for my family a pretty simple set of procmail rules and scripts that bounced messages that hadn't otherwise been classified as spam or been whitelisted with requests that they be resent with a certain keyword in the subject line. For example:

"Hello, you just sent me the following message. Could you send me the message again with the word 'leisure' in the subject line? You can reply to this message if you like, just be sure to add 'leisure' to the subject line."

Over a period of several years the only spam that's gotten through this has been from a 419er.

The advantage of a subject line token like this is that you can tell people the token to use, or put the token in the subject line when you send the message so it's usually there when the recipient replies.

Whether you take the resulting message and whitelist the sender address, or some other information in the header that you consider reasonable, that's up to you. It's not really the same thing as the SPF database, though, even if you choose to make the same kind of information the key you use for whitelisting. The point of SPF is that it's supposed to be authoritative for the organizations involved, and doesn't include things like "I sent something with my work address from Earthlink and now you're accepting mail from my work domain through Earthlink's servers".

And using this to whitelist the sender rather than their whole domain gives you a lot finer control.

Re:

[argent]

And thus you are spamming the people whose email addresses have been forged, well done.

That's true for pretty much any sender verification mechanism, or any mechanism that operates during the initial conversation exchange (like, say, SPF or DNSRBLs) because of secondary bounces. I got one of my domains forged a bunch, and by far the most common secondary spam isn't people running sender verification systems... it's bounces from intermediate servers that were rejected by the destination, and next come messag

Re:

[argent]

There is nothing that "makes it OK" for any mechanism you use to mitigate spam. Your choices are either throwing away legitimate mail without notifying the sender, or notifying some senders inappropriately. Neither of these are "OK". There's no alternative that's "OK". The responsibility for this situation belongs to the spammers, not the people who are trying to find a balance that minimizes the amount of "not OK" stuff they have to do to keep email actually functional.

Did you stop reading after the first

Re:

[argent]

I have yet to see a reasonable challenge-response system that handles the scenario where you fill out a web form and an automated process sends you a wanted email.

This isn't a challenge-response system. This is a token tagging system that uses challenge-response when the token's missing.

If you're filling out a form, you put the token in the "to" address.

If it walks like a duck...

[jumperboy]

This is clearly Challenge/Response with automated whitelisting. The following Wikipedia entry addresses every facet of this system:

http://en.wikipedia.org/wiki/Challenge-response_spam_filtering [wikipedia.org]

Re:

[eric76]

Bingo. You hit the nail on the head.

It's a Challenge/Response system that in and of itself adds to the problem instead of solviong anything.

My current approach

[eric76]

I've been using greylisting. For me, it really hasn't become less effective, but I have noticed that the mix of the spam has changed dramastically.

I'm getting ready to switch to two methods.

First, on one specific account that has become inundated with spam (probably because it is on just about every web page with registered IANA port assignments), I'm in the process of switching it over to the point where it will only accept unencrypted e-mail from a select list of whitelisted sources. If someone is not on that list of whitelisted sources, they are going to have to encrypt the e-mail using my public PGP key for the e-mail to be delivered.

Second, our mail server has something in the range of 100 to 200 users. I am generated thousands of additional e-mail addresses and aliasing them on the server to a single account. Those thousands of new e-mail addresses, initially 8,192 e-mail addresses, will be listed on various web pages for the spammers to harvest.

As e-mail starts to be delivered to those addresses, I will opt-out of all the e-mail so that they know the e-mail address is real and gets read. Once the spam reaches a certain level, I will then start blacklisting every incoming server delivering e-mail to one of those 8,192 addresses.

The length of time on the blacklist will vary. No IP address will be removed until a reverse DNS lookup for it exists.

If the reverse DNS lookup gives any idea that it may be a dialup, dhcp, or anything else that makes it look like it is probably a home computer (e.g. dialup-10-1-1-99.example.com), the IP address will be blocked for a month or more.

If the reverse DNS indicates that it is an smtp server (e.g. mta09.example.com), it will be blacklisted for maybe 24 or 48 hours.

Anything else will be blacklisted for one to two weeks. If additional e-mails arrive from a blacklisted IP address, the clock will start over.

I figure that with 8,192 spamtrap addresses and 100-200 user addresses, most spam zombies will be far more likely to hit the spamtrap addresses first where they may be automagically blacklisted.

Re:

[RonBurk]

I will then start blacklisting every incoming server delivering e-mail to one of those 8,192 addresses.

Ooops. As the trend of zombies that use the "normal" MTA of their infected owners increases, you will increasingly be blacklisting valid (and large) email servers. This will definitely eliminate a lot of spam. And a lot of valid mail as well.

I figure that with 8,192 spamtrap addresses and 100-200 user addresses, most spam zombies will be far more likely to hit the spamtrap addresses first where they

Re:

[eric76]

Ooops. As the trend of zombies that use the "normal" MTA of their infected owners increases, you will increasingly be blacklisting valid (and large) email servers. This will definitely eliminate a lot of spam. And a lot of valid mail as well.

Actual e-mail servers that we expect to receive legitimate e-mail from will be whitelisted. As for the rest, they will only be blacklisted for 24 hours.

If the use of real e-mail servers by spam zombies ever gets bad enough, it may become worthwhile to automatically ge

Re:

[eric76]

It shouldn't have that big an effect. That server has plenty of capacity to spare.

Only the first email will be accepted because the processing will occur after the e-mail arrives. If the recipient is in the list of prohibited e-mails, the IP address will be blocked by the packet filter.

If it is still a problem, part of the task can be offloaded to another server.

I have a perimeter firewall that handles a few specific tasks. I can generate the list of blocked IP addresses and ship them off to the perimete

Re:

[eric76]

I suspect that by only handling the original attempt from any one IP address and then blocking it with a packet filter, the bandwidth created by any additional attempts would be minimal. By refusing to even participate in the three way handshaking from the blocked IP addresses, I think we might not even notice 200,000 attempts a day.

Maybe I should create some new hosts and set up e-mail addresses on those. For example, mta.luser.example.com, mta.automagic.example.com, foobar.example.com, ..., and use e-ma

So many reasons it doesn't work

[Jay L]

This scheme seems every bit as awful as those "Hi! Before anyone e-mails me the first time, I make them go through these steps" filters

- It causes backscatter
- It doesn't work with mail from mailing lists
- It's not accessible

Additionally:
- It doesn't work well with sites that have many MTAs (requires one bounce/CAPTCHA per MTA)
- It doesn't work well with an SMTP server that sends for many domains (requires one bounce per MTA per outgoing domain)
- It merely confirms that "this server can send mail for domain X". If you've got a spambot and can determine your user's domain name (e.g. comcast.com), this won't stop anything at all.

The author brushes off concerns with bold (well, italic now) statements like:

Resend software is a simple onetime update for webmail systems, email clients, and local mail servers...Universal Distribution of Auto-Resend Software is a Surprisingly Simple Thing to Achieve

Hah! A simple one-time update for all servers and clients everywhere! Granted, RIA doesn't depend on that update happening, but it's clear even the author thinks it'd be a pain without auto-resend.

There is little disincentive to implement Auto-Resend software as it is a one-time upgrade that remains dormant until needed.

There is a huge disincentive; looking up a user's mailbox to see if he did, indeed, send the message you claim he sent is a ridiculously expensive operation, if it's even possible at the server level. It could also lead to a privacy leak if done wrong; people could forge RIA bounces to probe outgoing mail flows.

At best, it potentially doubles the volume of outgoing mail, which deepens queues, requires more disk space, etc. etc.

I'm guessing the author is unfamiliar with high-volume mail sites - the very ones he wants to implement this scheme first.

Suspicious Domains Will Be Neutralized By CAPTCHA Encoded Sub-addresses

Great. So now e-mail that's "suspicious" requires intervention from a sighted human, and all his "auto-resend" silver bullets are used up. He does imagine yet another client change that will "nicely reformat" a CAPTCHA. Yeah, right. Oh, and now he's e-mailing me graphics on my Blackberry.

In general, he seems to imagine that he personally runs the One True RIA list, and we all trust his determinations of what is and isn't "suspicious", with reputation scores, rate limiting, etc. That is, of course, ridiculous; the original MAPS RBL has splintered and grown to the point where there are over 200 DNSBLs available.

He talks about automatically e-mailing users that he has "detected" are running zombies. Right, because that's a good idea and isn't spam.

Domains commonly associated with phishing (e.g. Paypal.com, Citibank.com)

As if there's a way to create a comprehensive, or even useful, list of "domains commonly associated with phishing".

with the passage of time it will become difficult for spammers to purport that all of their spam is sent via increasingly obsolete or esoteric brands of software.
Of course it won't. I still get spam from "The Bat!". Before, he forgot about the big guys; now he's forgetting about the long tail. Spammers can make up any number of X-Mailer names.

Re:

[Jay L]

Forward Link Reverse Retrieve Mail Protocol - Is likely the answer, apparently can be implemented side-by-side with "standard" email protocols until adopted Internet wide. http://www.mollensoft.com/FLRRMaP_Protocol_V3.htm [mollensoft.com]

I dunno about "likely the answer". He's basically reinvented what Nathaniel Borenstein (father of MIME) called "rock mail" - I put a message under a rock, tell you where the rock is, and you go get it from under the rock.

AOL's mail system works this way, as do Exchange and other corporate

Another FUSSP, yes, plus added abuse possibilities

[Arrogant-Bastard]

Others have already explained at length how this is yet another
FUSSP -- and they're quite correct. It appears to be the product
of the same confusion that gave us SPF, Domain Keys, et.al.:
that is, mistaking the forgery problem for the spam problem.
Yes, they're related; yes; they're both abusive; and yes, they're
often seen together; but they are NOT the same problem and
it's a serious, fundamental error to think they are.

At this point in time, there is no solution to the forgery
problem available, because th

Sorry, no bonus - try again!

[e_AltF4]

This (not very well thought) suggestion has all the "features" to make it fail before it even starts

• captchas (yeah, sure - we all LOVE jumping through loops just to send some mails)
• requires new software on client and server (users AND mail server admins will tell you this: "I fart in your general direction! Your mother was a hamster and your father smelt of elderberries!" :-)
• relies on a central authority (why should all the world rely on one central system - possibly even run by Michael G. Kapla

done before, broken then, still broken now.

[cas2000]

challenge-response has been done before. it was broken then, and it's still broken now.

this seems to be a minor variation on the same stupid idea behind other challenge-reponse systems like TMDA - with the same problems (esp. backscatter to the forged addresses) that they all have.

the stupidity is further compounded by the author not understanding the difference between message From headers (which are just comments, not addressing information) and message envelope.

Re:

[nuzak]

I didn't read the entire paper, but after looking over the pretty pictures it looks like the sending party has to resend the message? That will only happen 50% of the time.

It could be greylisting, where the resend will be automatic. From the sender's point of view, there was just a delay. It's hard to say -- the article is not terribly well-written. The author's name is familiar, so googling on it turns up some other papers:

http://home.nyc.rr.com/spamsolution/UniversalAuthentication.htm [rr.com]

some discussion ca

Re:Still barking up the wrong f'ing tree...

[SCHecklerX]

I dunno. I've been pretty spam-free for the past several years using mimedefang, milter-greylist, and spamassassin.

The key is to reject the obvious nonsense before invoking your cpu-intensive analysis. I reject on the order of 90+% of everything that my mail server sees (even more at the last place I worked where they were using the same system). False positives on my home mail server are near 0. The ones that are mistakenly flagged, are simply flagged as spam, so I still see them, they weren't rejected or discarded. More at work got through, but that is because we have to be more conservative due to not having a good way to do bayesian filtering for individuals (I left before I had the time to run that project with the internal mail admins).

1. Implement Greylisting. Spammers don't retry
2. Reject if sending server is in zen.spamhaus.org or list.dsbl.org
3. Reject if helo is not a FQDN or IP Address
4. Reject if envelope sender claims to be an address from your domain (obviously our real users get through)
5. Reject if helo claims to be your own mail server
6. Reject if helo is an ip address from RFC1918 (again, short circuit on your own routing)

Then call spamassassin on anything that is left (SA will increase/decreas scores based again on RBLs that we don't outright reject, SPF records, etc):

1. use sa-update daily both with standard spamassassin rule updates, and, more importantly, the stuff at saupdates.openprotect.com
2. if you are able, create a way to easily train your bayes on false positives and stuff that wasn't rated high enough. I do this with specific courier IMAP folders that get checked once an hour
3. Tune your sa rules to taste. I had to decrease some things (lots of friends use yahoo mail), and increase others (Stock image spam. Ugh).

Re:

[Rich0]

Well, graylisting will always serve at least one purpose - delaying spam until you have rules to catch it. In theory if you have a fast-responding ruleset that is updated more frequently than the graylisting delay then spam will get caught by the rules update.

Re:

[Bogtha]

I'm frankly rather baffled at the lengths that people will go to in order to try to {filter / reject / stop transmission of} spam. We've already seen for years that such efforts are futile, because the same spammers will just adapt and find a way to pump out their crap anyways.

I receive approximately one spam email every 45 seconds. Constantly. Without spam filtering, I would go to bed with an empty inbox and wake up to 500 spam emails. Spam filtering, far from being futile, is the only thing that

Re:

[Bogtha]

I would say that indicates that filters are losing the war on spam, because the spammers just find new ways around them.

Spammers "just" find new ways around them about as easily as spam filters "just" adapt to new forms of spam. You can't consider one to be an insurmountable task that indicates failure while the other is an easy way of mitigating the progress of the other side. You are applying a double-standard here. Both pose problems for the other side and both can be adapted to.

Your filters

Re:

[Bogtha]

I merely used the term your to indicate that you have them. You created them is completely irrelevant.

Here's what you said:

And a working solution would have to remove the incentive behind spam. Your filters do nothing to remove the incentive.

The relevance is that "my" filters are not just mine, but are used by a hell of a lot of people, drastically reducing the efficiency of spammers.

Honestly, even if you have hundreds of customers, thats only a small drop in the bucket compared to how ma

Re:Still barking up the wrong f'ing tree...

[Anne Thwacks]

we need an economic solution

Nope. We need a solution involving cruise missiles though bedroom windows late at night.

We need Spam Assasin Ninjas clad in impregable black carbon-fibre capes with the knives of cutting edge technology and the deadly intent of artificial intelligence enhanced mania.

We need mountains of spammer bodies piled high on the forefront of technological .

We need chain gangs of spammers publicly televised chanting "The Only Good Spammer is a dead Spammer" to the sound of hammers hitting rocks.

IN Summary: Cruel and inhuman tortue is not enough for these guys

Re:

[UbuntuDupe]

Your post advocates a:

( ) technical ( ) legislative ( ) market-based (X) 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
(X) No one will be able to find the guy or collect the mon

Re:

[Xtravar]

We need a solution involving cruise missiles though bedroom windows late at night.

So... would you say this is a "War on Spam"?

Maybe our government could declare spammers as "enemy combatants".

Simple solution

[flyingfsck]

"Spammers will always look for a way to pump out their spam": So all one needs to do is prevent the pumping. I do that by slowing my SMTP receive process down deliberately. It sleeps 5 seconds before sending a banner in response to a new connection request, then it sleeps 1 second every step of the way through the SMTP protocol state machine. Most spammers give up in disgust and go away. The little bit that is left is easy to filter and legitimate mail is only delayed by about 10 seconds, which is reall

Re:

[Ant P.]

There's already hashcash, but nobody will use it.

Re:

[Epsillon]

I'm not really surprised. Would you trust someone who plonks an open relay on the net [hashcash.org] (1c) and then wonders why he ends up in an ORBL? I can understand if it was a mistake but, to further incriminate himself, he goes on to say he then set up SMTP_AUTH (which should have been done in the first place and also proves he could have done it correctly) and moans about "blacklist operators and ISPs... intentionally sabotag[ing]" his poor mail server. I would laugh if it wasn't so tragically typical.

Rearrange: Hi

Re:

[bobintetley]

I think you're referring to something like HashCash [hashcash.org]. Sounds interesting, but I'm not convinced it would work.

Re:

[nuzak]

The idea is called hashcash, which should help your googling. It's a very old idea, predating the current situation where spammers now have more computational power than anyone else can imagine and would laugh such a scheme away while everyone ELSE got penalized.

Re:

[Antique Geekmeister]

Welcome to zombie-land, where Windows boxes worldwide have their CPU time rented to spammers. It's a business, it continues to be profitable.