Slashdot Mirror

There is already the SPF policy framework. No need to invent something new. http://www.openspf.org/

Microsoft actually started their own version of SPF (hijacking the previous use of spf records in dns) called SenderIP ( http://www.openspf.org/SPF_vs_Sender_ID.
Since they abused the previously established spf records, this of course causes problems. This is an amazing example of the standards work of IEEE and IETF's being undermined from within.

Huh? SPF implementations do not filter on a missing SPF record. A missing SPF records just means that, the sending mail servers of the domain are not specified. It never meant that the domain must not send any mails from any servers.

Quote from openspf.org :
"The domain does not have an SPF record or the SPF record does not evaluate to a result. Intended action: accept"

SPF means Sender Policy Framework. It is a method to specify and check the precise list of servers which are allowed to send mails in the name of a domain.

Receiving servers use it to check the validity of the reverse-path of the mail. Reverse-path is the address to where bounce messages should be sent.

It is nothing more, nothing less. It causes great confusion because many thinks that it is intended to be a final SPAM prevention method, when it is clearly not.

Alone, it makes sending SPAM only a bit more difficult. On the other hand it does make easier to catch spams with other methods. As more and more domains and receiving servers start to use it, it becomes more and more effective in this role.

The simplest benefit of setting up SPF for a domain that your domain name cannot be forged as the reverse-path of spam mails. So you will get less back-scatter spam and angry mails. SPF almost completely eliminated back-scatter spam for us, which was once quite an annoying issue.

Hells yes. I use postifx and reject connections that fail SPF with a 500 error. For example..

"550 5.7.1 : Sender address rejected: Please see http://www.openspf.org/Why?id=dassergey%40tadka.com&ip=103.22.182.230&receiver=mail.server.com%20:%20Reason:%20mechanism"

I have found that most senders just forward the bounce message to their administrator who (you would hope) have the skills to rectify the problem.

I also use DKIM http://www.dkim.org/ and DMARC http://www.dmarc.org/. They're worth checking out too.

People are forwarding mail now. Anyway, if a university can't find a mail admin who is able to implement this, that doesn't speak well for the university. And still, if they choose to burden the recipient and you can't follow a simple instruction to whitelist the forwarding server, you don't belong in an institution of higher education.

http://www.openspf.org/ has been down all week and it has all the instructions

3 Install postfix-policyd-spf-perl

Next we download postfix-policyd-spf-perl from http://www.openspf.org/Software to the /usr/src/ directory and install it to the /usr/lib/postfix/ directory like this:

http://www.openspf.org/ has been down all week and it has all the instructions

3 Install postfix-policyd-spf-perl

Next we download postfix-policyd-spf-perl from http://www.openspf.org/Software to the /usr/src/ directory and install it to the /usr/lib/postfix/ directory like this:

If you use SPF, you only succeed in getting your own email deleted.

When you send email to your buddy, let's call him Jim, with his own vanity domain, it gets forwarded to his ISP email account. Since his ISP is checking SPF records, it'll check your domain's, see that your email isn't coming from your own server (it's coming from Jim's vanity domain host) and block it. Like most vanity domain hosts, no message will be sent back to you to let you know your mail was blocked.

Congratulations, you just got your own legitimate email blocked and disappeared with no way for you or your friend Jim to know.

SPF makes incorrect assumptions about the way everyone uses email. It then attempts to make up for these incorrect assumptions by suggesting that everyone use SRS... which, of course, no one uses.

If you use SPF, you get your own email deleted. Don't use SPF.

If you're in business, or if you care about your domain's reputation, you should be implementing SPF to prevent others from sending mail (aka joe-jobbing) as your domain.

Even if you DON'T care about your reputation, your life will be easier if you don't have to deal with the back-scatter (complaints, threats, invalid postmaster replies, out of office messages, etc) from a massive joe-job/spamming effort which is spoofing your domain.

You CAN make a substantial dent in these types of attacks with SPF. There are levels of SPF "certainty". In order to be most effective, you need to list all your sending servers with a dash "-all" for example, a major financial uses:

text ="v=spf1 ip4:207.162.228.0/24 [shortened] -all"

On the receiving side, most SPF implementations will (and should) respect the certainty of the senders SPF record. In the above example the financial implemented the "-all" qualifier, so if mail comes in from a place not on that list, based on their assertion I can safely drop it as spam. If they used a "?all" or other, I might only increment the spam probability or tag it [maybe spam].

When implementing your DNS SPF record, it can take time to make sure you've identified all the legit sender's of mail with your domain name if you're a large company. Keep at it and come back here and let me know, I'll give you a pat on the virtual back for doing THE RIGHT THING.

http://www.openspf.org/

I was recently appointed a IT Manager and was told to stop the spam, as management was getting atleast 300 spam a day, each.
Our current email provider would NOT implement DKIM, but I did have control to my domain records.
SPF is too easy to implement; see http://www.openspf.org/
DKIM on the other hand took a while, i tried DKIMproxy but couldn't get it to sign messages outside the local network so i moved to amavis, see; http://www.faqforge.com/linux/how-to-enable-dkim-email-signatures-in-amavisd-new-and-ispconfig-3/
There is plenty of manuals and support on how to implement SPF and DKIM i do not see why (for the benefit of the provider) its not being implemented.
I have seen so many web hosts provide hosting and disable this feature its inexcusable.

SPF: proves an email should only be legitimised if the sender server matches the record; as many assume its not an anti-spam mesure but to ensure that the server you send from doesnt send spam through your domain.
DKIM: proves that the email sent WAS from your server by referencing the key generated in the email to the one on your public DNS record.

combining both ensures people receiving your email that you are the one sending it and that you sent it from your server.

By implementing SPF, DKIM and DNSBL (you should see the amount of spam that gets denied now) my boss' spam has reached to probably 5 a day with is a protection rate on 98.4% only issue i have is with china, since we communicate with manufacturers in china and they have a huge spam rate it can get complicated.

there are two methods, stop spam from sending to you (DNSBL) and stop spam from sending from you (SPF and DKIM) the latter ensures people will get your email, the former still blocks legitimate email from blocked IP's which is still a worry :(

SPF is the way to go. Most public email out there (GMail, Hotmail, Yahoo) will mark email as spam if an email is sent from a server that isn't listed on the SPF record.
Obviously this isn't the only technique to fight spam (You validate that the sender really belongs to X.com, not that X.com isn't a spammer), but it helps.

As for the link to "SPF is harmful", that's about the biggest load of bull I've ever seen. It's inaccurate, and is an uncommon case (how often does mail forwarding happen these days with everyone using non-ISP-bound free email services?). It's like saying we should shutdown the internet because it's not completely accessible to devices with black&white screens.

As I said before, all the major free email service providers take SPF into account (test it out yourself - setup your domain with SPF, and send an email to your gmail/hotmail from an unauthorized IP).

That said, SPF is pretty easy to setup. Just a quick little txt in your domain and you're good to go. This site will help you with generating your SPF:
http://www.openspf.org/Tools

But hardly anybody seems to use it. Especially not to actually block mail.

See here and here.

No, no, no, no, no... No.

The proper solution is not for ISPs to block access between their clients and their client's mail servers. If I want to send a message from my computer at home through my companies mail server, I should be able to. If I don't want my ISP reading my email, I should be allowed to use ESMTP with auth and TLS. Your solution ignores this. It also complicates laptop setups something fierce. You're solving the problem in the wrong place by giving too much responsibility and authority to the wrong people.

The problem(1) is that SMTP is used as both a sending and a relaying protocol. There is no easy way to distinguish between an outbound SMTP connection being used to connect to a legitimate relay (work server) and as a spambot (forged headers).

The problem(2) is that SMTP servers blindly assume the sending address is legitimate. Thus, forging someones email address is easy. This is true even if the originating IP address reverse resolves to imgoingtospamyou.com or adsl-nn.nn.nn.nn.dsl.somewhere01.pacbell.net. This is what's broken, not what ISPs allow through their network.

The proper solution is for the receiving SMTP server to determine if the sender is allowed to send mail for that domain. This was not a consideration of the original email paradigm, but it is now. Sender Policy Framework If you're receiving spam from botnets, then your mail provider needs to tighten up their default SPF settings. (They may need someone to demand that they implement SPF.)

I know that SPF must be implemented everywhere for it to be fully effective, but good default policies will still block a vast majority of address spam.

It's a little tricky to see what you're getting at, but I think you want SPF.(more)

An SPF record is a DNS record that is roughly opposite to an MX record. MX says were to send mail for a domain; SPF says where mail is allowed to come from for a domain.

You can change the From: address in gmail to be your work email address, so the people you talk to wont even know it's being forwarded

For folk thinking of doing this, please make sure any SPF records for your domain list google as an authorised sender. Otherwise a lot of mail you send will be going to /dev/null

If you're going to go to the trouble to do that, go to a little more and sign your outgoing messages so you can identify legitimate bounces.

Using BATV:
    http://mipassoc.org/batv/

Or SRS:
    http://www.openspf.org/SRS

Since you are running your own SMTP server, you signed on to be a sysadmin. I am replying to you as a fellow sysadmin and I'll give sysadmin-style answers. Please don't take my response to be negative in any way, as I'm trying to help.

The logical solution is to configure sendmail on my server to do Sender Rewriting -- anyone have an easy FAQ to do this?

If you follow the link that you just gave for Sender Rewriting, it answers your question. "Implementation" links to modules, source, and configurations.

But many people/domains aren't doing this ... and my Email forwarding to gmail is quite common, so I'm surprised that this issue hasn't gotten more attention. Is there another solution?"

I say that you don't know how many people are implementing SRS, nor do you know how many forward e-mail to Gmail. Let's stick to the basics before giving up so readily. I take it that you absolutely do not want to give up carte blanche forwarding from your own SMTP server to Gmail; so I'll tailor my reply to that.

But since my friend has published SPF (Sender Policy Framework) records that say only his server is allowed to send Emails for friend@frienddomain.com, gmail apparently rejects (silently buries actually!) the Email since it is forwarding through my server.

Your friend has published an SPF record because he doesn't want people forging his domain in the envelope-sender field. This is a common spam tactic that ruins the reputation of someone's domain, either through spammer apathy or sometimes pure malice. Your e-mail forwarding (especially since you run your own SMTP) to Gmail is out of pure convenience to you and is unnecessary, so don't ask your friend to drop his SPF record.

There are two ways to solve this:
1) Have your friend add your SMTP server to his SPF record.
2) Implement SRS if you want to solve it once and for all. If you follow your own links, there are explanations, examples, and actual code. You haven't said which SMTP server you're running, so you've limited the responses people can give you for your situation.

I publish SPF records for my domains. There isn't anything "broken" about wanting to protect my domains' reputations from forgery. Very few people have a problem with forwarding that they didn't create themselves. This exception I'm talking about is people who have old university accounts (or similar) which only allow e-mail checking through a shell account and forwarding purely through a ".forward" file (or similar), with no POP, IMAP, or administrative access. This is not you. But for anyone who this describes, because of the draconian service policies, they shouldn't be giving out that e-mail address to new contacts, publish on papers, etc.

My SMTP server checks SPF, but not DK. With SPF, the forged domains are instantly rejected, requiring minimal overhead. DK requires reception of the entire message (because the headers are in the DATA phase) in order to validate the message, on every message -- this uses unnecessary network bandwidth, and it places an extra load on my system since it would have to calculate and verify signatures for every single message. Maybe that's not an issue for you if you only receive a handful a day, but I receive thousands. Spammers know that including fake DK info in a message and then sending millions of these is effectively a Denial of Service attack on the servers that indiscriminately check DK signatures.

I also use backup relays. For the relays that are not under my control and don't implement SRS, I simply bypass SPF checks from those IP addresses.

About Google silently dropping your e-mail: Keep in mind that with your carte blanche forwarding, you're also forwarding spam. You are essentially spamming Gmail, even though it is you simply forwarding e-mail to your own account. It is difficult for Google to know this without human intervention or implementing some co

FYI here's the link to the SPF document on Forwarding.

Do I have my terminology wrong? I thought forwarding sent an email with the headers from the forwarders server? In their example isn't forwarding redirecting and remailing actually forwarding?

That's outstandingly unhelpful. How about attaching a link to a decent SRS implementation? Or sending them to OpenSPF?

Randomly throwing down on people legitimately asking for some technical help is a big problem in the OSS community. Whether or not /. is the appropriate place to ask this question is debatable, but since it made the front page and there is no helpful SRS faq on this site, might as well direct them somewhere.

There's actually a fairly simple procmail fix right on the spf site: http://www.openspf.org/FAQ/Forwarding

> The real problem is really deciding what is a legitimate
> source of e-mail, without requiring a central registry of
> e-mail servers or some other sort of bureaucratic process.

Well that's the problem that SPF solves. Each domain owner
creates a DNS entry that specifies which mail servers are
permitted to send mail for that domain. When an MX receives
a HELO it checks that the originating IP corresponds with
the DNS entry; if not, the mail can be rejected or subjected
to further inspection and scoring.

Simple to implement, I've done it in 20 minutes for my domain
( 20 minutes from ``What is this project?'' to submitting the
DNS change ).

http://www.openspf.org/

SPF also breaks email forwarding; that's why I don't use it.
Reference

It seems like the solution to "backscatter" has been around for quite a few years (SRS). I'm surprised how few of the commercially available anti-spam solutions use or interpret it.

At my company, we just looked at Barracuda (PoS), Pineapp, St. Bernards ePrism, MX Force, Postini, and some other things. None of them understand SRS and only a few of the tech contacts had even heard of it. Sad Sad. But they all seem to have hand-rolled "backscatter" protection that partially works.

It seems like everyone has an SPF record these days. But it feels like relatively few actually check them and almost nobody goes the full distance and uses SRS.

However, it has existed for several years, and we still get lots of spam...

And you can only put in the encouraging restrictions once enough places use it, otherwise you just delay or block most of the email you need to see.

Spammers can't forge a MAIL FROM of "orders@amazon.com" for recipients that check SPF. Decent spam filters let users whitelist emails/domains. With decent anti-forgery like SPF and DKIM, the problem is solved for the immediate future.

PS. For nitpickers who note that the amazon.com sender policy has a default result of "neutral" instead of "fail", spam filters (like mine) that track reputation of each mailfrom.domain:SPFresult pair independently eventually start rejecting amazon.com:neutral anyway.

People typically don't have a good idea of all of the IPs that originate email for their domain. Sometimes they are overly restrictive, causing blocks to their legitimate mail. Sometimes they're overly permissive and indicate that lots of the internet can email as them. This is like having a firewall with policies that unintentionally permit and/or block traffic.

SPF is a pretty poorly designed framework. RFC4408 is almost comical in how many times it says "You should never do this, it's terrible. Here's how to do it..." If the designers realized what a bad idea the PTR check is, why did they include it? I now have thousands of useless reverse DNS queries per second, sent only because someone didn't understand what they were talking about and didn't read the author's warnings.

Finally, TXT records make for a fabulous DoS attack tool. Since they are typically larger than other RRs, adding TXT records to your DNS reflection attacks can amplify the amount of generated traffic with very little effort on the part of the attacker.

... but only if you use it.

Add SPF to your domain, and whatever subset of ISPs / mailservers that use it probably won't bug you. The only downside of using SPF is that you may have to change your DNS records if you want to use a new mailserver, but most people that I know only use one or two servers for outgoing mail for any one domain.

One DNS line to potentially stop a joejob against you - it's a no-brainer, even if you "have [your] dobuts". Go to the SPF Setup Wizard, fill in your servers and copy the IN TXT line.

See if it works, and proceed from there. If it doesn't, go back to the ISP and complain.

If you set up SPF (or some other form of server verification) and only send confirmation messages to addresses that pass, you can be almost certain you're not causing backscatter.

The unfortunate part is you don't get to verify senders for domains that don't use SPF, but it does provide a way for legitimate senders to avoid their message being filed as junk.

Basically, what the parent is talking about is SPF - Sender Policy Framework

Your own link states that your assertion is incorrect. Only the Microsoft implementation is under restrictions making it Non-Free.

Use OpenSPF in order to remain unemcumbered.

Since not all recipients check SPF, you may also wish to sign your mail from. This adds a timed hash token to the local part, and bounces must have the proper token in the RCPT TO or they are rejected. I use sendmail and the pysrs package from the pymilter project for this purpose.

1. Blacklisting is generally done on the originating IP address, not the allegedly originating domain name. Its unlikely that your forged from address will be picked up by any filters. The forgery problem is, of course, why blacklisting is not generally done on the allegedly originating domain name.

2. You can mitigate the bounce problem with Sender Policy Framework (SPF). Many of the larger mailers will drop messages where the SPF records indicate that the sender address is forged. Many more will suppress bounce messages as a consequence of SPF failure. See http://www.openspf.org/ . SPF is not universal by any stretch of the imagination, but using it will decrease the number of bogus bounce messages you receive.

If the sender is forging your From address, chances are they're not using your mail server. Most decent blacklists (e.g. SpamCop, Spamhaus) will blacklist the offending server's IP address, not your mail domain.

Consider implementing SPF (home page wiki) so recipient mail servers can drop the message if it wasn't sent from a server authorized to send mail from your domain.

Most bounce messages will not include your outgoing server's signature. You can consider dropping those messages using the techniques described in the Postfix Backscatter Howto.

The first thing they should do is change the "~all" to "-all" at the end of their SPF records.

paypal.com. 3600 IN TXT "spf2.0/pra mx include:s._sid.ebay.com include:m._sid.ebay.com include:p._sid.ebay.com include:c._sid.ebay.com include:spf-2._sid.paypal.com ~all"
paypal.com. 3600 IN TXT "v=spf1 mx include:s._spf.ebay.com include:m._spf.ebay.com include:p._spf.ebay.com include:c._spf.ebay.com include:spf-1.paypal.com ~all"

This is the problem Sender Policy Framework (SPF) tries to address.

I wonder whether the intended the confusion.

Are you new here? MSFT have ways of dealing with things they can't embrace, extend and extinguish. If they see a standard emerging, they'll create a competing standard that is technically unsound and then frantically splash around to muddy the waters. With standards groups and consortia, they'll do a buy-out to get their own way. Funding for the Internet Society (IETF) or W3C (Microsoft to chair new HTML WG) buys them enormous influence and they can also afford people greasing palms at all the conferences (Microsoft have to buy their friends).

The OOXML name is a deliberate and cynical ploy to make it easier for MS reps to mislead corporate decision makers. It's all about hijacking the idea and it's why their desktop OS is called "Windows".

make sure you have implemented SPF on your mailservers DNS and your EHLO is correct for your domain (eg mail.yourdomain.com) after doing this i can send mail to Hotmail/AOL without any problems (and my server is on a cable connection with a dynamic ip (tho the IP hasnt changed in 3 years))

Gmail does the same but it ignores the results even if it fails (now getting 300+ spam a day in my gmail account vs 5 a day on my hotmail account)

SPF breaks email forwarding.

There is a section on this in the spec

It's not like there aren't solutions for this "problem".

For now I'll stick with SPF and old fashioned spamassassin (milter).

And whats with the anti SPF sentiment? Its not like we've got a lot of more effective alternatives on the market and the only real argument I read is the rejection of real email, when softfail pretty much takes care of that (then leaving it to spamassassin to decide if the mail is legit).

We send an receive a good deal of email and I certainly wish SPF was more common. I'm tired of forged bounces and the *slew* of undeliverable responses 'dumb' servers return to our system every day.

Yet instead of taking any real action we bicker while spammers laugh all the way to the bank. Their is no magic bullet, but from my POV SPF is the closest thing yet (unless my DNS gets hi-jacked, but then I'm fucked anyway).

SPF is what you need - use the wizard here http://www.openspf.org/ then add it to your dns servers - you might need to contact your registrar for that

I keep seeing variations on this idea, and while it's perfectly sound in the abstract, in practice it simply will not happen.

The problem is that certification is useless until the vast majority of email servers are certified.

I know, you said this isn't true, but I don't think you understand the situation. Spam filtering at the client level doesn't affect spam -- the suckers who the spam targets are NOT configuring filters at home. Yes, the geeks will get their family server in the basement certified in their spare time, and all their friends will send them certified messages. The spammers won't give a damn, because they're perfectly happy if the geeks and antispammers don't read their spam (they don't buy anyway).

So -- can you imagine an ISP filtering out email at the server level based on certification? No -- because all grandma cares about is getting Junior's emails, and when they stop coming (because his ISP's servers are in the 95% still uncertified) she gets on the phone and starts costing them money... and don't forget the time/money they spent implementing the filter, testing it, rolling out with hopefully no glitches/downtime, monitoring it, etc..

They might put a flag in the subject line of uncertified emails... okay, but it shows up in the emails from the bank, from the kids, from work... the complaints roll in. Cash flows out. So filtering is a liability.

But what about their own outgoing mail? Certify? Well, again it'll cost a chunk of time (money) to learn, setup and maintain 24/7/365 with the occasional confused complaint, it'll possibly cost their users some downtime particularly if they screw it up, and it'll gain them *nothing* for now, because no one is filtering yet (see above).

No brainer decision when your staff is already stretched thin.

The last link is the upstream access provider. They would need to implement the system and hire the staff for accepting complaints (online? via phone?), filtering out the sabotage from the real complaints, collecting evidence of abuse, dealing with angry ISPs on the phone, establishing/expiring/revoking certification, etc..

Will they go for it? Again, big cost, big headaches, and no gain until that magical day when everyone is on board.

Seriously, there's a positive push because no one likes spam, and everyone would gain from a plan that would actually curb it... but people need to come up with something that will work on the low level.

The SPF system is one that DOES help incrementally more as implementation spreads. It mitigates joe-jobs and backscatter for all domains with a SPF DNS record, and is trivial for server admins to implement. AND it doesn't cost anything if mail servers reject mail that fails the test: valid email will come from the server listed in the DNS record, OR the server may have no SPF record yet (let it through). Spammers can only spoof addresses without SPF records, since they can't set up their own SPF record -- they'd be easily traceable when they spam, since the domain registrar would have credit card info, etc..

Even at early stages, there's benefit for server admins to filter (removes spam safely from any domain with an SPF record), and there's benefit for adding the SPF record (please, filter out spam that pretends to be from me! my customers don't like it).

It's not perfect... forwarding email and badly created records can cause issues, plus while AOL has implemented basic SPF filtering Microsoft is involved and trying to mix XML into the record format somehow....

Personally I feel the BlueFrog approach is the strongest for non-stock-pump spam... but obviously a decentralized approach is required to avoid Blue Security's fiery downfall. The main problem with this system is that human analysis is required to analyze spam and write scripts for leaving complaints.

> in addition to Sender ID.

WTF are you checking against? My SPF records were published long before Microsoft announced their intent to misinterpret them using technically unsound PRA nonsense. So please don't check Sender ID - check SPF.

The secret is that I reject all but a few hundred of those 11000 spams in SMTP envelope. Correspondents must have some form of id, currently one of:

1. a valid rDNS
2. a valid RFC 2822 HELO that resolves to connect IP
3. an RFC 4408 sender policy (SPF) with a PASS

That gets 3/4 of the garbage. Next, SPF FAIL is rejected, including for HELO. You'd be surprised at how much spam has my own domain for the HELO! For SPF SOFTFAIL, since the sender is requesting debugging info, I send a DSN to the purported sender reporting the SOFTFAIL. For senders with no SPF, I match domains with HELO and rDNS, and look at MX to try to get a match - which is then treated like and SPF pass. For SPF neutral, I do a CBV, and blacklist the sender if it fails.

This reduces the spam from 11000 to several hundred. The content filter is auto trained. A honeypot mailbox provides spam training. Messages from (verified by SPF PASS) senders that users reply to provide ham training. Users have a web interface to the quarantine.

The false positive from content filtering is extrememly low. The biggest problem is VIP correspondents with clueless email admins who are unwilling to educate or fire them. (E.g. one admin insisted I didn't know what I was talking about and "JUPITER" was a valid HELO name...) In these cases, I have extensions to the sendmail access database to provide policy exceptions. I can also provide local SPF records for correspondents to get them a PASS.

One customer had to resort to spamsoap.com because they were getting 2 million spam connection attempts a day, and my python based filter could only process 80000 or so on his 400Mhz server.

• Ensure sending mail servers have valid mx or a record for the sending IP address
• Sending IP of mail server should have a valid reverse dns record (PTR) and should match the A record for the IP.
• The information in the HELO/EHLO portion of the smtp session should be a valid hostname and should resolve to the sending IP address or PTR.
• SMTP Authentication for outbound
• Published SPF records for the sending domain. http://www.openspf.org/
• Domain Keys
• plus more that I can't think of at the moment.

I run a small mail server for friends and family and have been trying to tackle the recent rise in spam. Here is an article detaling some of the causes.

http://www.eweek.com/article2/0,1895,2060235,00.as p

I believe it was also listed as a slashdot story.

I was trying to think of solutions concerning this particular problem. (spammers utilzing ip addresses from virtually anywhere in the world where there are virus infected machines)

One partial solution that aol, microsoft have been putting forth is
http://www.openspf.org/dns.html

but this is mainly for dealing with spoofing the mail from of the email. The other problem is it works best if everyone buys into the system.

I had an idea for a similar tactic that would apply to eliminating spybot emailing nets.

What if, when you registered a domain, you had to also put in an record that identified your mail servers. It would be very similar to how you put in DNS servers that handle a domain.

Then it would be trivial to have receiving mail servers to do a DNS check to see if the ip address of the mail they just received was in the DNS records.

Now, granted, this would not prevent a spammer from buying a domain and setting up their own servers. Or from hijacking someone elses servers. But it would go far from eliminating people that have had their computers infected with a virus and are unknowingly sending out spam.

The problem I see with this solution is it would be additional work for the registrars and their is little monetary incentive for them to set it up. And all the design implemntations that would have to be worked out.

Throw an SPF entry in your DNS zone record, that helps keep spammers from using your domain as a FROM address. Worked for one of my domains.

It is just too easy to spoof header info now.

That's the main reason for SPF.

My problem is different. Botnet spammers have not only harvested addresses of mine already, but they're also sending out spam under my domain, so I'm getting their bounce messages from non-existent, full, and filtered addresses.

You should set up SPF records for your domain. These days, it really does make a difference on the number of stupid bounces you get back: A lot of well-managed servers will not accept the spam pretending to be from you in the first place, so they won't try to bounce it to you after they realise they don't want it.