Slashdot Mirror

Before specifying how users would be supposed to confirm legitimacy, it is de rigueur to check the method against a number of classic anti-spam proposals.

And his co-author's site says he won't accept (or rather will silently roundfile) mail from users of gmail and other free mail providers. That's going a bit far.

There are tons of bosses who think that it's a good idea to send out emails about their product/services to thousands of people who never asked for them (hey their product is wonderful after all, etc etc).

And how many of those bosses would think to call him for his services PRIOR to sending that email?
http://www.rhyolite.com/anti-spam/that-which-we-dont.html

And there really are overzealous spamfilters. I've seen people here who think it's a great idea to block off entire IP ranges (not just for their personal systems, but at a corporate level).

Yep. The question still comes back to who hires him.

If Corporation X (not an ISP or email provider) is blocking email sent by Company A ... why would Company A hire this guy to talk to Corporation X?

Wouldn't the person at Company A who is trying to email someone at Corporation X call that person and tell them about the blocked email?

http://www.rhyolite.com/anti-spam/you-might-be.html#e-postage

I'm using spamassassin + exim on mail relay gateways of a 2000+ email installation. It works great.

You need to add the dccproc ( http://www.rhyolite.com/anti-spam/dcc/dcc-tree/dccproc.html ) and razor ( http://en.wikipedia.org/wiki/Vipul's_Razor ) plugins in order to use those "reputation" services, turn on bayes filtering, wait for 200 messages to be "marked" and there you go. If you have enough load, you might need to switch from the DB database backend to mysql. One thing you might be interested in is http://www.untangle.com/ ... looks interesting.

So block tpnet? Other than that you're well off topic and stuff...

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

Personally I dropped debian back in 2001. Their release-policy is completely insane. Not only when it comes to this drivel, but also when it comes to other stuff. Their 'stable' releases was so out of date that they were worthless, and their unstable releases was quite frankly way too unstable to use in production.

Although their release-pace has picked up, it seems that their stable releases are still having the same kind of inane problems as back then. I especially like Vernon Schryvers rants about Debian and their version of DCC, which should illustrate the problem:

http://www.rhyolite.com/pipermail/dcc/2007/003468.html
http://groups.google.com/group/news.admin.net-abuse.email/browse_thread/thread/643e0dda1dc20873/bfb14f7b095cd972?hl=en&lnk=st&q=dcc+debian+old+%22vernon+schryver%22&rnum=1#bfb14f7b095cd972
http://groups.google.com/group/news.admin.net-abuse.email/browse_thread/thread/602cb3d3677eacab/6e0f03195e004340?hl=en&lnk=st&q=dcc+debian+old+%22vernon+schryver%22&rnum=2#6e0f03195e004340

Debian is outright abusive towards DCC and other services. First they package and release software with old, outdated configurations - making sure that wrong servers get a lot of invalid traffic, then they refuse to fix it.

Now they refuse to fix timezone issues - and thousands of admins are stuck unless they give up running 'stable'.

Admins should stay well clear of Debian itself. It's a arrogant developers-only distribution. One should rather go for one of the several debian-based systems, or maybe an entirely different distribution - if one wants a real product. // disgusted ex.debian admin

They use DCC?

Anyone can use DCC.

Bayesian filtering is about learning what is interesting to you. If you average it over everyone's email, you'll actually get less effective at positively identifying the sort of ham (non-spam) mail that you get.

Every time there's a discussion here about spam, people talk about doing away with SMTP and replacing it with something enforcing certificates and signatures, the great white hope for email. Apparently, nobody's considered how this applies to one useful feature of email, namely the ability for people who've never contacted you before to send you email. Spammers can get themselves certificates just as easily as anyone else.

Paypal's idea is interesting. A quick look at news.admin.net-abuse.sightings shows a lot of Paypal phishing does purport to be from paypal.com, but as someone's already said, common mis-spellings are the obvious next step, at which point your certificates are useless (bonus points to the spammer who gets SPF, DKIM and whatnot up the whazoo for their paypa1.com domain).

Something that might be worth looking at is a format for out-of-band information to instruct mail clients to trust certain mail and distrust other mail which looks like it (the latter being where something Bayesian could come in). That way, when you sign up to Paypal on the web you get a blob of data which your mail client understands to mean that Paypal.com using this signing key may legitimately send you bulk email, and that mails which score highly for looking like Paypal mails but aren't should get flagged and filtered.

In any case, spam is a solved problem. Use DCC and Spamhaus Zen and then greylist (or just reject) connections from clients with no RDNS or with generic RDNS (4.3.2.1.isp.example.com for IP 1.2.3.4, say), and you're down to so little spam that it's not worth complaining about.

And don't worry, it's not spam because... (Pick one or many)

http://www.rhyolite.com/anti-spam/you-might-be.htm l

You Might Be An Anti-Spam Kook If... http://www.rhyolite.com//anti-spam/you-might-be.ht ml

DCC does what I think you are suggesting and it collects information from many different email servers around the internet.
http://www.rhyolite.com/anti-spam/dcc/

[Sigh] http://rhyolite.com/anti-spam/you-might-be.html FUSSP = "Final Ultimate Solution to the Spam Problem" senior-IETF-member-8 You think that a violation of an RFC by an SMTP client or server is good and sufficient reason to reject all mail from the system's domain. programmer-3 With standards, the implementation cost is about zero, so the FUSSP will be practically universally deployed within months of being documented in an RFC. knows-SMTP-4 You know that SMTP has no authentication and have never heard of SMTP-AUTH, SMTP-TLS, S/MIME, or PGP. knows-SMTP-5 You know that the failure of SMTP servers to authenticate the SMTP clients of strangers is a major bug in SMTP instead of an expression of a primary design goal. SMTP = Simple Mail Transfer Protocol. it looks like this for a reason. If you still think there is a silver bullet for SPAM, (other than one delivered between the eyes of anyone who's responsible for it) then you've never actually had to deal with SPAM on any level other than a personal mail account. Sorry for being harsh, but I'm having a bad day with SPAM, and I'm not prepared to let that slide without comment.

It's worth noting that the checklist applies to ANY anti-spam approach, and it was written that way. It's a satire, and it's for sending to people who believe they've come up with the Final Ultimate Solution to the Spam Problem (aka the FUSSP). No antispam solution is perfect -- the best we can do is provide a set of powerful tools that overlap each other to mitigate the problem into relative irrelevance. We're certainly not there yet.

I like this one better: http://www.rhyolite.com/anti-spam/you-might-be.htm l

The reason that nobody has come up with a viable solution to SPAM (and on a derivative, viruses) is well summed up here: http://www.rhyolite.com/anti-spam/you-might-be.htm l

The main problem is that NO ONE wants to replace email with something closed, that will necessarily require putting power in the hands of either governments (X.509 certificates need to be associated to identities, meaning passport / ID card validation, etc...) or private companies (I'm sure verisign would love to do this. Or Microsoft with Passport, etc...). Secondly it's hell: managing large trust hierarchies (PKIs for example) are difficult and cumbersome: they are administrative burdens that will need to be regulated. Otherwise, yes, it's easy to start from scratch. Everyone will have to go to their local town hall / post office / verisign representant / Microsoft Identity Office, present a valid passport, and voila, you've got a certificate (valid 1 year!) allowing you to send mail. Email systems won't receive anything else than known senders (validated through a hierarchical directory system -- maybe LDAP if we're lucky, or the DNS), and only if the signature on your cert. says you've agreed to the terms and conditions of using the Great World Email system (you wish, there will never be that level of cooperation).

So yes, it will be a process run by the private sector. And we all know that spammers will never be able to buy valid certificates, right ?

BULLSHIT.

From the article:

The only solution is to start from scratch. Develop a new email system and make it secure. Use existing, proven technologies and a few new and novel ideas ? starting with the latest encoding mechanisms, a reliable hashing algorithm, fast compression, strong encryption and signatures. Build an electronic identity. Encode, hash, encrypt, compress, sign, and provide a novel way to share keys when needed, for example. I don't know how this will all turn out, but perhaps yEnc, MD5, AES, H.264, and GPG are some potential technologies that could be used together

Ummm...
http://www.rhyolite.com/anti-spam/you-might-be.htm l
-sorry it had to be posted, even though I agree with the fight at hand :p

Now that the business of humour is out of the way; let's have a moment of silence in honour of someone who kicked a whole bunch of spammers in the huevos really hard :)

whee!
-m

Obviously spammers are trying to get through filters by making their email appear legitimate. The closer spam looks like legitimate email traffic the harder it is to block them without also blocking some legitimate email.

But the spammers are caught in a bit of a catch-22 situation, especially when it comes to distributed spam-blocking tools like Razor, DCC, etc. If a spam is obviously forged then it's easy to flag as a spam. But alternatively if a spam has non-munged contact information, whether an e-mail address, a URL, or even a phone number or snail-mail address, those are all strings that it's VERY easy for filters to test against.

MXPTR, SPF, Sender-ID, RMX, whatever, these schemes don't help stop spam -- they help stop (or at least identify) forgery. As it happens, a lot of spam today uses forged sender addresses. , so blocking mail that actively fails such a check does stop spam. Experience with SPF has shown us that spammers are perfectly willing to adopt this kind of record and just authorize the entire internet to send for their own domain. (On the plus side, since their SPF record says the domain is correct, you can safely blacklist them by domain.)

As a FUSSP, blocking all non-SPF/MXPTR/whatever labeled mail is going to require every single sender in the world to adopt this change before it will be useful. Not what I'd call "easy," by any stretch.

Never underestimate spammers. It may give you a warm and fuzzy feeling to assume that "spammers are stupid," but some of them are surprisingly sophisticated.

One reason we're still in an arms race against spammers is that some of them -- just enough -- have the expertise (or can hire a less than scrupulous developer to provide it) to counteract just about every technological measure we've thrown at them so far.

To assume that spammers are too stupid to work around something is to fall into the trap of being an anti-spam kook.

SPF is a failure. Unlike the submitter, its proponents don't even pretend that it's an anti-spam method (there are more spam messages with SPF than ham), focussing instead on its authentication promise. Now it seems even Meng has abandoned that as being worth anything if the FUSSP is whitelist-only. Imagine that - saving email by destroying it!

Email has been a phenomenal success because it costs close to zero to contact people with whom you otherwise would never easily be able to communicate. UBE is a problem precisely because it costs close to zero to contact people with whom you otherwise would never easily be able to communicate. Any FUSSP that destroys either of those two qualities, cost and ubiquity, is a cure that's worse than the disease.

I guess there's something for everyone to pick apart..

we have the spam problem (which can be traced directly to the lack of concern for security)

Pure bullshit - the spam problem can be traced to sociopaths who want something for nothing. It's impossible to design a communication system that's free to be used by anybody that can't be abused - because at some point, someone is going to abuse it.

http://www.rhyolite.com/anti-spam/you-might-be.htm l

Perhaps "sending" isn't the right word to use

Erm, right, because this actually is about receiving, not "sending". Like I said. Before.

You seem to be hung up on the fact that (usually) , the intended recipient of a message doesn't receive notification that a message was rejected. But the sender will get a non-delivery report from their own local system. The onus is on the sender to decide what to do about non-delivery. How can any recipient be under any obligation to ensure the delivery completes? To be forced to accept anything? To relinquish the ability to decide which traffic enters their own, privately owned equipment? That's absurd.

Furthermore, notifications to the intended recipient are worse than useless : almost all of the time they will be spam rejection notices. A spam rejection notice in my inbox (or even filtered into a junk folder) is no different than the spam itself. (cf those braindead mail systems that notify intended recipients that a virus was not delivered; or even worse, those that send the same notification to the purported (spoofed) sender; or, the piece de resistance, the system that sends a non-delivery report to the spoofed sender, and includes a copy of the original, virus-infected message as well. The latter is ignorance bordering on negligence).

So we have to wait until blacklists become significantly harmful before we'll change our ways?

Actually, from my own experience and that of other postmasters I talk to, over the last few years RBLs seem to be holding up pretty well in terms of a benefit/harm ratio. If anything, the harm is decreasing as postmasters become increasingly clueful in the ways they implement them. My last true false-positive incident was almost two years ago. I'm never going to say that RBLs are any kind of solution to the wider problems we have with unsolicited bulk email; they're one more tool in the bag of tricks. But they do work at least as well as any other technique we currently have.

I have been using Spamihilator for a while now, with the DCC plug-in activated, that checks a fuzzy check-sum of the message with servers that hold a list of other users who use this filter. I have found that it does block a number of newsletters that large numbers of people receive, however a simple list of newsletter definitions do a good job of preventing this problem. I just put this filter with a DNSBL filter that checks Spamcop and other blacklists, and a learning filter, with no spam reaching my inbox, and all real messages getting in fine. More Information: http://www.rhyolite.com/anti-spam/dcc/ http://www.spamihilator.com/

Are the freaking moderators on crack?

First of all this is a terribly written technical paper. What's with all these "theory" vs "implementation" sections!? I can't take any paper seriously that has an abstract with the sentence "...technology-specific implementations of the messages, task standards to define general needs, task detail standards to define task details, task implementation standards to merge tasks, task detail and the specific technology implementation and finally task implementors that implement task implementation standards and provide the functionality of this framework to a messaging system."

Please tell me this paper is a joke? Surely no normal person would actually write "task implementors that implement task implementation standards"?

Anyway you're not solving the problem. You're still sending requests to send email; these requests require just as much attention as email itself currently requires. What's the difference if the thing you're attending to is email or a request to send email? It's like the town that has a shortage of water but plenty of salt, so they decide to start calling salt "water", and start calling water "salt". Now they have plenty of water! But a terrible salt shortage.

Either way, you're proposing the same old solutions of whitelists, blacklists, etc.

Take a gander at potential signs you're an anti-spam kook. You've hit most of those points. Congrats.

What i don't get is that there seems to me to be such a simple, elegant solution to this whole spam thing.

You Might Be An Anti-Spam Kook If....

Not meaning it in a nasty way, but, well... your proposed solution has a lot of major flaws. For example, even if it were actually possible/plausible to implement (hint: it's not, not within the current SMTP), it'd rely on the sending mailserver implementing this limitation.

Large-scale spammers (hell, even small-scale spammers) run their own mailservers. Why would they use a mailserver program that implements such a restriction? Answer to rhetorical question: they wouldn't.

And when I mentioned that it wouldn't be possible/practical to implement - how could the server tell that the same message is being sent to ten people? Hint: spammers don't just put all their target email addresses in the To: header of one message, as an ordinary person might if they were sending a message to ten or twenty people.

My modest proposal: A email to Doom interface. (Remember the Doom job control UI for Linux a few years ago?) Spam filters could grade the email and represent it as a particular monster in Doom. Then you could just hit delete with a rocket launcher or BFG. Of course, if you're sloppy with your shots, there might be some collateral damage on real email -- but isn't there always?

Yep, an utterly point idea, but at least it's more fun than these FUSSPs.

http://www.rhyolite.com/antispam/objections/mperon e.html

I guess I should be surprised that this sort of nonsense made it to the front page, but that's nothing new. (To protest this sort of poor article choice, I encourage you to visit the Jihad.

I've never seen any evidence, in years of running my own mail server, that shutting down for several days stops any spam traffic at all. I run my email domain off my cable modem, so from time to time I will lose service for several days. After it comes back, so does the spam, every single time.

I don't think the author of this article gets it. The spam zombie software that exists on so many people's home computers is not intelligent. It's fire-and-forget. If the message bounces, they don't even issue a "QUIT" command. They just drop the connection. Same goes for 4xx "not right now" style messages. (That's why things like greylisting work so well.

It never gets old as long as people have Final Ultimate Solution to the Spam Problem (FUSSP) bright ideas.

Until there is a universal anti-spam framework in place across the internet, this move won't help anyone.

Of course! That's brilliant! It's astonishing that no-one has come up with this idea before! Please, tell us more about your final, ulitmate spam-solution

If they really did it right it'll reject most spam earlier than the DATA command, based on sender's IP address or RDNS, or the parameters of the HELO, MAIL, or RCPT commands. That way you don't waste bandwidth accepting the entire message (not such a big deal for spam, usually in the 1-4 KB range, but more important for worms, usually in the 20-80 KB range).

If you accept the spam for delivery (as most filters do) you've already lost. All the filter can do is categorize it; a human still has to check each message at some point.

My first reaction to this was "snake oil" and "FUSSP" but if this Matthew Sullivan is the same guy who runs SORBS then it's probably the real thing. (Not necessarily "first" or "revolutionary" but at least very efffective.)

I'd like it if there could be a database where if a subject header is reported as spam by one user it effects other users' scoring.

There are a few databases out there that take hashes of spam e-mails (either sent to spam traps or reported) and use them for spam tagging. SpamAssassin can use their client programs to help tag messages also - I don't know if there's an extension or anything for Thunderbird, I don't use it.

The three that come to mind are DCC, Razor and Pyzor.

All have their advantages or disadvantages, but you have to remember that you're relying on somebody else's judgement. I think it's DCC that you can easily configure to say that you need x reports of the message before you class the message as spam, which gives you more control. But you only need one person who doesn't use it correctly to ruin the system and introduce lots of false positives.

You could always set up SpamAssassin on your local machine and proxy messages through that.

You are confused.

Rather more confused are the slashbots who tout client-side content filtering as the end-all be-all "solution" to spam.

To block spam at the transport level is one thing; an algorithm for identifying spam without human intervention is another entirely.

The only catch: it's not possible to identify spam (unsolicited bulk e-mail) based on the content alone. Why? Because the two words in the definition, 'unsolicited' and 'bulk'. How can the existence of the word 'viagra' possibly tell me the message was unsolicited? Even if I'm not interested in buying Viagra, I can still receive important e-mail containing spammy words that's neither bulk nor unsolicited (like spam complaints about my users). The bulk criteria is even more difficult to predict using content filtering alone. About the only solution that addresses this point I know of that is the Distributed Checksum Clearinghouse.

I suggest you RTFA. Their method is actually pretty interesting. Lackluster is not the appropriate word for the novel idea they have come up with.

The method might be novel. The purpose (content filtering spam that's already been delivered) is not. Such methods simply don't address the costs of receiving and storing spam, only the perceived user inconvenience.

• The FUSSP assumes that your attention is so important that strangers will pay money to send you mail.
• Spammers won't ignore, subvert, or exploit the FUSSP if you publish it as an RFC
• The FUSSP won't be effective until it has been deployed at more than 60% of SMTP servers and that's not a problem
• You think that a violation of an RFC by an SMTP client or server is good and sufficient reason to reject all mail from the system's domain
• The FUSSP requires a small number of central servers on the Internet to handle certificates, act as "pull servers" for bulk mail, account for mail charges, or whatever, and that is good thing or not a problem
• The central servers required by the FUSSP to handle all mailing list subscriptions, digitial signatures for mail and so forth will be run by a non-profit organization. It will be easy to find or create a non-profit organization that everyone will trust
• The FUSSP requires that anyone wanting to send mail obtain a certificate that will be checked by all SMTP servers
• You know that certifying that a user legitimately claims a name and has never used some other name is cheap and easy

And I haven't even STARTED on the horrors of trying to run a free mailing list (with or without a confirmation email at signup).

So you ask, why not run spam blocking on all open source MTAs? Simple: it takes two to tango. Email is a communication medium, emphasis on that prefix "co-". Your new Final Ultimate Solution to the Spam Problem is useless if the other guy's server doesn't support your protocol. And I suspect most of us are unwilling to cut off all email with half of our friends/family/business just because their mail admin isn't as smart as yours. Anyone with that philosophy is already using SPEWS.

You may be an anti-spam kook if...

Click Here, it's funny in the so-true-it's-sad way

It gets better. Vernon Schryver, networking genius, is responsible for the Distributed Checksum Clearinghouse which does something similar, but as I understand it, is much more efficient for large servers. When our university turned on DCC filtering combined with greylisting, the daily spam to inboxes dropped from hundreds daily to ZERO (I kid you not). I am not aware of any false positives, at least on my account. DCC blew my mind.

SPF is the answer. Unfortunately, nobody's discovered what the question is to go with that answer

I'll take Spam Solutions for one hundred, please. Question : what FUSSP is an anti-forgery technique that doesn't address the underlying problem, breaks forwarding and is simply defeated anyway by using the null envelope sender?

Ironically, these and other reasons may be an argument that SPF should be adopted

Anti-Spammers have thought of this, too. Things like the Distributed Checksum Clearinghouses have "fuzzy" matching.

Google also has enough computer power to generate some sort of Bayesian filter to catch the most common spam system wide, and even a personalized filter on each account to catch the rest.

SEOUL - CRUCIAL TALKS here this week on Meng Weng Wong's SPF ambitions made modest progress but failed to bridge the divide on major issues concerning the 11-month tension.

Wrapping up their two hour negotiations Thursday, Wong, Danisch, Fecyk, Brand, Hardie and Fältström adopted a chairman's statement in which they agreed to set up a working group for detailed discussions and hold the next talks in August, at San Diego...

... if there were some P2P means of establishing how many individuals had received a particular spam.

There is - check out DCC.

It is also the best type of spam filtering I've ever used. Catches about 75% and only one false positive ever. Combine with the Bayesian & RegEx filters and you have an almost perfect system.

Each item in the following list was suggested by the words or actions of people who presented themselves to the IETF or elsewhere as having discovered the FUSSP. Some of the items may seem obscure to those who have not dealt with the IETF.

• You have discovered the Final Ultimate Solution to the Spam Problem (FUSSP).
• You are the first to think of the FUSSP.
• You started looking for the FUSSP after observing that it is impossible to filter more than 99% of spam with fewer than 0.1% false positives by currently available mechanisms.
• Despite being the inventor of the FUSSP, you are unfamiliar with "false positive," "false negative," "UBE," "tarpit," "teergrube," "Brightmail," "Postini," "SpamAssassin," "DNS blacklist," "HELO," "RBL," or "mail envelope."
• You plan to make money by licensing the FUSSP.
• You don't plan to make a fortune from the FUSSP, but you do expect fame as its generous and public spirited netizen inventor.
• You are deeply hurt and angry because you are not respected as "spam fighter."
• People don't see the value of the FUSSP because they have axes to grind, are jealous, or are too stupid to understand it.
• You learned how to stop spam during the more than six whole weeks you've been fighting it.
• The FUSSP assumes that your attention is so important that strangers, other than advertisers, from will pay money to send you mail.
• Despite having invented the FUSSP, you not only don't know the difference between the SMTP envelope and SMTP headers; you doubt there is such a thing as the SMTP envelope because email doesn't involve paper.
• Despite having invented the FUSSP, your SMTP header and DSN reading skills are so limited that when you send an objectionable message to two separate sites, you can't tell which of one of them rejected it.
• You cannot name several potentially fatal flaws in the FUSSP.
• All you need to do to get the FUSSP implemented and deployed is to publish an RFC or get a law passed.
• You don't recognize any significant difference between deploying and implementing the FUSSP.
• You plan to publish an RFC mandating the FUSSP but have never heard of RFC 2223 or RFC 2026.
• Inventing the FUSSP did not require that you know the difference between RFC 821 and RFC 822 or that they have been replaced by RFC 2821 and RFC 2822.
• You don't know the relevance of "consensus" or "IESG approval" to publishing RFCs.
• You think all RFCs have the same standing.
• Spammers won't ignore, subvert, or exploit the FUSSP if you publish it as an RFC.
• The FUSSP depends on spammers or mail recipients changing their behavior without any immediate gain.
• The FUSSP won't be effective until it has been deployed at more than 60% of SMTP servers and that's not a problem.
• The FUSSP is easy to implement and deploy, but you have done neither.
• Your job is done after having explained the FUSSP to the IETF or The Industry.
• Programmers will drop everything to implement the FUSSP.
• You think that a violation of an RFC by an SMTP client or server is good and sufficient reason to reject all mail from the system's domain.
• You know that SMTP has no authentication and have never heard of SMTP-AUTH, SMTP-TLS, S/MIME, or PGP.
• You know that the failure of SMTP servers to authenticate the SMTP clients of strangers is a major bug in SMTP instead of an expression of a primary design goal.
• Despite discovering the FUSSP, you don't know the meanings of MTA, MUA, SMTP server, SMTP client, or su

I think you need to read the proposal more carefully and to look at the less formally worded materials at Spamhaus regarding the plan for use of the TLD. It is inaccurate to look at this as a means of fighting spam, much less a FUSSP because it is in fact a way to address the issues of legitimate mail getting caught by various imperfect approaches to spam detection.

Because it is designed to provide a sort of 'bus lane' for mail servers whose operators are willing to meet the rather stringent conditions and the hefty price of a domain in the TLD to get their mail servers into the TLD, it does not require universal acceptance. It also has literally NOTHING to do with SMTP headers , is designed to be useless as a pure whitelist (eliminating the related objections,) does not depend on spammer honesty, is totally unrelated to the lack of a central controlling authority for email, and is significantly resistant to 'joe jobs' and identity theft for the entities with .mail domains because any mail not coming from their .mail machines would be readily repudiable.

In short, your comment might have deserved the 'funny' moderation if you were the first person to come up with a checklist response, but all you have really shown is that you did not bother to dig any deeper than the rather misleading /. blurb.

This is, indeed, yet another Final Ultimate Solution to the Spam Problem.

Using a fuzzy checksum tool like DCC to block similarly worded messages. It will catch both spams and viruses.

Most viruses spread so quickly that the AV tools' databases are inevitably out of date and ineffective.

here is a fine guide to build a Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new, SpamAssassin, Razor and DCC.

You can follow the steps and build it with Linux too. This entire procedure has been developed with security as a primary focus. These are the main tools it shows:

• Amavisd-new (www.ijs.si/software/amavisd) is the main filter which processes email from postfix and ensures that we don't lose any mail. Amavisd-new is an huge improvement over the original amavis which was a simple virus scanner, and I think it is the best way of implementing SpamAssassin (www.spamassassin.org). SpamAssassin is the main anti-spam component which works by comparing messages to a ruleset and by using a statistical analysis that is custom built based on your email. In addition to the SpamAssassin spam detection software, we will be using 2 online SPAM databases: DCC (www.rhyolite.com/anti-spam/dcc) and Vipul's Razor (razor.sourceforge.net).

Innocent? Like Open Relays are innocent?

By "innocent" I was referring to the joe-job victims whose addresses are faked by spammers. As for open relays, surely you're aware that they represent only a small percentage of spam sources these days - most of the big spam runs are injected using armies of trojanned PCs (think about how you might use such an army to defeat SPF).

I think it's fair to characterise AOL's involvement with SPF as "experimental" rather than "adopting" at this point. And the reason for this is obvious - so much spam has a faked @aol.com address (I know of some mail admins who simply reject all mail "from" aol.com; others will weight against aol.com in spamassassin). Note that adopting SPF does nothing for AOL users *receiving* spam.

What you describe as a problem with SMTP - lack of sender authentication - is actually a design feature. Think about it this way - why should I have to be authorised by some corporation in order to send email? Are you arguing that one shouldn't be permitted to send email if you don't pay money to an ISP? Of course, the big ISPs *would* love this and are arguing about the method, but that's because who ever "owns" the method owns email and a potentially lucrative revenue stream (viz your example of the certificate proposal).

I'm trying hard not to sound like I'm throwing my hands in the air and wailing that we can never fix the spam problem, and obviously (I hope!), I loathe spam as much as anyone. But I also recognise that this is a *difficult* problem. Lots of very bright people have put considerable effort into thinking about solutions, and no-one has yet been successful. Even reverse-DNS type methods are nothing new. I'm not suggesting that you're an anti-spam kook (and I certainly am not), but if you haven't seen it already, check out the "You Might be an Anti-Spam Kook If..." page to get a flavour of the kind of difficulties and subtleties involved in coming up with a Final Ultimate Spam Solution.

So, we have a bet. Actually, I'm going to go crazy and offer a dollar on non-uptake of SPF and another dollar on non-uptake of TMDA. If or when I'm proven wrong, I'll start arguing over your criteria of "50% of the domains with MX records", which leaves me some wiggle room ;)