I would agree with Eric that spam is an economic problem. The spammer, like any freeloader, criminal or otherwise, has found ways to *shift* his costs onto others, and is essentially getting something for nothing.
Spam is incredibly cheap to send. Fighting it is expensive, and supporting the huge explosions in infrastructure is also expensive, but the spammer doesn't see the costs. Honest users pay, adding some small percent to their Internet bill to pay for spam filters, extra sysadmins, more storage for the Junk folders, etc.
Now, I disagree that charging everyone for email is the answer. There are other ways to force the spammer to pay his own way. For one thing, if we had all the technology we need to correctly bill people for the email they send, we would already have the accountability tools in hand -- and we could easily block mails that don't track back to a real sender from the system. We wouldn't actually need micropayments; if we just had the technology to track every email back to a real person, we'd already be done.
One way to tip the economic scales back to being even would be to rate-limit accounts -- for example, deny access to email after 1000 messages have been sent in one day. That's more than enough for most users but low enough to cause spammers some grief. However, the zombie armies keep growing too, thanks to viruses, and soon spammers will be able to find 10,000 machines to send 100 emails each. *sigh*.
?all is valid in SPF. It basically means that the record can be used for whitelisting, but should never result in a rejection. Of course we want to encourage people to get to -all as soon as possible, but they may not know all the different places that their users send from. The records shown above at least give a Pass result when using the known mailers.
The script that reports this as an error should probably be investigated. Do you have more info on how/why ?all is considered to be an error? (DUNNO is probably not an error in this case... it just means that the result is not black or white, and other filtering or policies should still apply)
I don't believe this is true. But, if you feel strongly about it, feel free to propose another solution that covers everything you feel you need.
Hypothetically, if you were to PGP-sign all your outgoing email, would you also want to post something in DNS saying so? Would you want other mail admins to stop accepting unsigned mail from your domain? Would you sign the headers as well to keep others from taking your message and adding a spam to the top or bottom? Would that create forwarding problems, or problems with lists? Would a scheme like that keep people from using greeting card sites or "Send this article to a friend" type of sites?
SPF is being criticized from both sides: either it breaks things too much, or it doesn't go far enough to be useful. I feel like SPF is not a complete solution, but it's a good first step.
People who feel strongly enough to criticize SPF by saying "It's largely broken" or "SPF pretty much sucks" should probably step up to the plate and offer their own solution. Step up, or step off.
Do you know of any specific ones that do? Let me know if so...
I have heard it talked about in the abstract sense, like "Some ISPs block 25, what if they decide to start blocking 587?" I don't think there is any incentive for them to block 587, since it is supposed to be used only for Auth on the other end...
That would work, although I'm a big fan of making ISPs clean up their own network... if there are some hosts that shouldn't be sending outbound mail, then the cable or DSL folks should not be allowing crap mail to come out of that network. Also, some ISPs or companies will just list all IP ranges they own:) so you wouldn't be able to use it as a mask in that case.
The main point of SPF is to keep folks on totally foreign networks from impersonating you. Hopefully it won't be used by ISPs as an excuse to NOT clean up their own networks. But if used correctly it will help to shine a light on areas where crap forged mail tends to come from.
I think it's going to be hard for folks in your position, but not impossible, and there are benefits to it. I am a sysadming in IT as well so I am sympathetic to the problem of getting thousands of users to change.
Here are some ideas that may help.
1. Identify the networks you control and list those. If you know all the mail servers, great, list those... but if you don't, you can also get by with just listing the network ranges that you own and that allows any server in those ranges to send.
2. Offer mobile users an SMTP AUTH server. This will allow mobile/roaming users to send outbound mail back to corporate HQ to be sent out, rather than sending out through whatever DSL or cable ISP they happen to be on.
3. Phase it in slowly. Add ?all to the end of your record to allow sending from anywhere. There are additional optional things you can do to detect when mail is being sent from servers you haven't approved yet... You can do something like altavista.com does -- they use "exists:" in the record to trigger a second DNS query and then they can log those queries.
SPF will make it harder for spammers to hide their identity and masquerade as someone else. In the short term, they will forge stuff using unprotected domains, but as time goes on they will have to buy their own domains.
While SPF doesn't actually stop spam, it does take away some of the tools spammers use to hide their identities, and makes it slightly more expensive to send spam, and slightly easier to track and stop spammers.
I believe that getting some kind of accountability back into email is "necessary but not sufficient" to solving spam. That is, SPF is not the Final Ultimate Solution to the Spam Problem, but it makes some other spam-fighting techniques possible.
There really isn't a centralized resource for them to control. Domain owners can publish their own info using DNS (TXT records) and receivers can choose to check those records or not.
I think it's going to be similar to other RFCs that define email -- they tell you what you have to do to be compliant, but they don't limit you to a specific vendor or ISP or software choice. You can buy software that is compliant, get free software, or write your own:)
Here's some info that may help.
1. The domain owner has control. If you own your own domain, you can decide what networks or mailservers are allowed to send.
2. Using SMTP AUTH may help. Your ISP, ASP, or corporate IS folks might have a way for you to send stuff out through their server, even if you are dialing in from some other network.. If not, bug them about it:)
If there is no SPF TXT record published, there is nothing for receivers like hotmail to check or enforce. It really is an "opt in" kind of system - both the sender and receiver need to actively do something before it takes effect.
The DNS service providers really need to allow TXT records, but until they do, the mail coming from those domains should still be allowed through.
This is correct. You just need to create TXT type records.
There are plans on the table within IETF to create a new DNS record type just for this, but this will take a long time to approve and even longer to get everyone's DNS servers upgraded. So for now everyone should be creating TXT records, and when the world is ready to switch to the new type, that will happen. I predict TXT SPF records will be around for at least 5 years.
The decision to use or not use SPF is up to the owner of the domain name. The domain name has to publish, and then the receivers such as hotmail will have something to check against.
If you don't own your own domain name, keep an eye on your ISP so you know if/when they will be publishing SPF records. If you do own your own domain, you have a bit more control.
You are right, keeping the From: and changing Reply-To would work. Also, the change that MS proposed will check "Sender:" before checking "From:"... so you can actually keep From: as your permanent address and set Sender: to your mobile address.
ISPs and corporate IS folks should also provide SMTP AUTH servers, so that remote/mobile users can use the same server they would normally use. This is not new (RFC2476 is 5.5 years old) but SPF will put more pressure on folks to follow the SMTP AUTH scheme.
Re:how do I get all the server names?
on
SPF Design Frozen
·
· Score: 1
Not to worry, smtp is naturally confusing -- it's designed that way:)
Spammers definitely take great advantage of how confusing all those extra headers are, and the smtp transaction has a couple of steps to go through before the headers even arrive. Luckily most mail servers will record their part of the transaction, the HELO command is "received from", the Mail From is the Return Path, etc. But it's still kind of tortured.
Tradeoff between "simple" and "useful"
on
SPF Design Frozen
·
· Score: 1
Early versions of SPF actually had reverse lookups like 1.0.0.10._spf.example.com. I actually like the new TXT format better since it is more flexible and easier to write for most domains.
There is a careful tradeoff between "too simple" and "too complex". I have seen other similar proposals doomed by getting too complex, because they bow to what the users want and then nobody wants to write the code. At the same time I have seen proposals doomed because they were not flexible enough to handle most cases.
If you're looking for "something that describes where mail _comes_from_ so users with separate mail-clusters for outbound and inbound can identify themselves" - SPF is it, exactly. With SPF you CAN do reverse-IP style lookups like DNSBLs do, but for most domains it will be easier to just say "v=spf1 +mx +ptr +include:rr.com -all" which basically means "Allow from my MX, and anything with a verified PTR-DNS name in my domain, plus also allow from rr.com"
Anyway, I think SPF is a good compromise between simple and useful -- it is not too simple to be useless and not too complicated to get adopted. I think so far the plug-ins for SpamAssassin, Sendmail, qmail etc. have taken on the average "a few hours" to write.
Yes, it is similar to RMX, DMP, and MS. For my money, I don't care that much which proposal wins as long as we do SOMETHING. Cleaning up all forged mail is going to take a long time, so we should get started NOW:)
Re:how do I get all the server names?
on
SPF Design Frozen
·
· Score: 1
You can refer to your ISP in terms of "include=" (basically, this tells people checking your record that they should check SBC's record as well). You can add multiple includes for the ISPs you use.
Regarding headers, SPF is able to drop the connection based only on the SMTP commands, before you have sent any headers. Headers are part of the DATA step in the transaction which is like 4th, MAIL FROM step is 2nd.
If you're not adding it directly to the mail server, you can analyze headers after the fact, but you would only want to trust headers from your own server - your own server knows the other guys true IP since they have a two-way conversation.
Re:How does this reduce spam in any shape or form?
on
SPF Design Frozen
·
· Score: 1
It's going to be a long road, and I think SPF is just a first step, but it's an important first step. I would describe it as "necessary but not sufficient" to stopping spam.
Here's how I think things might go if everything works out. 1. Some key large domains publish SPF, and a few large ISPs start checking for it. 2. Some of the mail that is forged using the big names is downgraded or dropped. 3. Spammers start to spoof the addresses of other names instead. 4. Pressure is on for the owners of those other names to publish SPF. 5. Some key organizations stop accepting messages without proper SPF credentials, like private companies or universities, who would rather lose some mail than deal with forged messages. 6. More pressure is on for domain owners to publish SPF to get their messages through everywhere. 7. At some point it becomes a well-known standard like MX, and everyone just does it as a matter of course. 8. At some point, DNS registration sellers get involved and won't register your domain if the SPF records are not right, like they check your NS and SOA info now.
Of course there will be other important things that need to happen to stop spam, and stomping out all forgery will take a long time, but that just means we should get started right away!:)
There are some places that block residential IPs... usually this is based on the reverse DNS (feed your IP in and try to get back a name) - it contains numbers like d22-164-99 or whatever. One solution is to set up your home server to send out through your ISP's server which should have a proper reverse DNS without so much numbers. Some smaller ISPs will allow you to set up "real names" for your reverse DNS, most will charge a small fee for this since they need to issue static (dedicated) ip address to do it. Probably the best route is to relay from your home server to the ISP's mail server to be sent out.
SPF will probably help this problem, but it will probably be a long time before it gets to that point. People block IPs based on "dynamic looking reverse DNS" mostly because there really is no better way to tell "legit" from "spammy". If there is a verification scheme that can detect forgery based on DNS and it gets accepted widely, some ISPs might ease up on their other requirements, but that will take time.
With your small business servers, you might not need SPF yet... if spammers start forging your name and pretending to be from your domain, it can be added later as needed. It's about as easy as setting up MX records so hopefully people will just start doing it as a matter of course. If SPF gets accepted more widely, spammers will start to move off of the SPF-protected domains and spoof the other unprotected domains, so there will be a lot of shifting around before there is a noticeable impact on spam.
Spam is a difficult problem, and I don't think there is any one "right" solution. Multiple solutions will be needed before we get anything effective.
I have seen discussions about technical solutions and legislative solutions, but not a lot of discussion about economics. I receive far more spam than direct (postal) mail. Obviously the huge number of spam messages flooding everyone's inbox means that response rates must be abyssmal -- but since the costs of sending spam are virtually zero as well, people will continue to send them, despite laws, suits, technology, etc.
So why is it so cheap to send email and so expensive to fight it? Here are some thoughts...
Forgery is easy, tracing back to the real sender is hard.
Not all spam is forged, but most is, because if spammers lie about their identity, fewer complaints will reach the real ISP and they can send millions more spams in the extra time it takes to track them down. Analyzing email headers is difficult.
Forged mail also means extra cost for the domain owner whose domain is being forged. This adds to the cost of fighting spam, but the spammers don't have to pay for this. Forgery is just one reason that spamming is easy and cheap, and fighting spam is difficult and expensive.
Something like the RMX proposal [previously on slashdot] would help this problem, but will take a long time to get to full usefulness. That's a good reason to get started now!
Sending in huge volume is easy
Once you have a dialup account, you can send any number of messages, limited only by the bandwidth of your connection. Any node on the internet that can be used to browse the web (port 80) can also be used to send mail to other mail servers (port 25).
It would be easy enough for an ISP to block outgoing connections to port 25, but their users may have legitimate reasons for sending direct and not wanting to use the ISP's servers. This type of policy would make it harder for legitimate users to run their own mail servers (such as DSL users who have their own Unix machines and want to run their own domains) but they can still do this if they set up their sending server to always relay to the ISPs server (or just ask for an exception to the port-25 policy, if they are already a trusted customer).
Forcing mail to go through certain servers makes it easier to enforce other rules, such as limiting their sending rate to 10 messages a day, or something appropriate like that. This is another thing that some ISPs will do and others won't, but it is in their best interests to do so. The idea is to keep the spammers from coming back, and the only way to do that is to make it expensive on a per-message basis to send spam through their network. If you can pay $19.95 for the account and send 1 million messages, and get 100 to 1,000 sales, that might be worth it, but if that ISP limits you to only sending 100 or 1,000 messages before you get caught, you will move on to the next ISP. ISPs that do this will spend less on abuse complaints, and those that don't will get picked on more and more. If this keeps up, it becomes infeasible for the ISP to do business the old-fashioned way, and it becomes infeasible for spammers to spam compared to the cost of other legit advertising.
It is also possible to allow some connections to port 25 and just throttle back after a certain number, or do a rate limit (like one per second)... but the technology to do this is harder than just straight blocking.
Anyway... my personal preference would be to use a technology-based solution, that has no national borders. I don't really object to a legislative approach as well, but my gut feeling is that it will not be as effective if it is not global. However, neither technology nor legislation can be effective without some understanding of the economic and "social engineering" factors.
Slashdot Mirror
I would agree with Eric that spam is an economic problem. The spammer, like any freeloader, criminal or otherwise, has found ways to *shift* his costs onto others, and is essentially getting something for nothing.
Spam is incredibly cheap to send. Fighting it is expensive, and supporting the huge explosions in infrastructure is also expensive, but the spammer doesn't see the costs. Honest users pay, adding some small percent to their Internet bill to pay for spam filters, extra sysadmins, more storage for the Junk folders, etc.
Now, I disagree that charging everyone for email is the answer. There are other ways to force the spammer to pay his own way. For one thing, if we had all the technology we need to correctly bill people for the email they send, we would already have the accountability tools in hand -- and we could easily block mails that don't track back to a real sender from the system. We wouldn't actually need micropayments; if we just had the technology to track every email back to a real person, we'd already be done.
One way to tip the economic scales back to being even would be to rate-limit accounts -- for example, deny access to email after 1000 messages have been sent in one day. That's more than enough for most users but low enough to cause spammers some grief. However, the zombie armies keep growing too, thanks to viruses, and soon spammers will be able to find 10,000 machines to send 100 emails each. *sigh*.
?all is valid in SPF. It basically means that the record can be used for whitelisting, but should never result in a rejection. Of course we want to encourage people to get to -all as soon as possible, but they may not know all the different places that their users send from. The records shown above at least give a Pass result when using the known mailers.
The script that reports this as an error should probably be investigated. Do you have more info on how/why ?all is considered to be an error? (DUNNO is probably not an error in this case... it just means that the result is not black or white, and other filtering or policies should still apply)
>SPF is largely broken as a useful system
I don't believe this is true. But, if you feel strongly about it, feel free to propose another solution that covers everything you feel you need.
Hypothetically, if you were to PGP-sign all your outgoing email, would you also want to post something in DNS saying so? Would you want other mail admins to stop accepting unsigned mail from your domain? Would you sign the headers as well to keep others from taking your message and adding a spam to the top or bottom? Would that create forwarding problems, or problems with lists? Would a scheme like that keep people from using greeting card sites or "Send this article to a friend" type of sites?
SPF is being criticized from both sides: either it breaks things too much, or it doesn't go far enough to be useful. I feel like SPF is not a complete solution, but it's a good first step.
People who feel strongly enough to criticize SPF by saying "It's largely broken" or "SPF pretty much sucks" should probably step up to the plate and offer their own solution. Step up, or step off.
Do you know of any specific ones that do? Let me know if so...
I have heard it talked about in the abstract sense, like "Some ISPs block 25, what if they decide to start blocking 587?" I don't think there is any incentive for them to block 587, since it is supposed to be used only for Auth on the other end...
Thanks
gregc
Setting Sender: is one way around mobile/roaming problems, but not the only way.
Probably the best fix is to use SMTP AUTH to connect back to your home server, and it can send the mail out from there in the normal way.
That would work, although I'm a big fan of making ISPs clean up their own network... if there are some hosts that shouldn't be sending outbound mail, then the cable or DSL folks should not be allowing crap mail to come out of that network. Also, some ISPs or companies will just list all IP ranges they own :) so you wouldn't be able to use it as a mask in that case.
The main point of SPF is to keep folks on totally foreign networks from impersonating you. Hopefully it won't be used by ISPs as an excuse to NOT clean up their own networks. But if used correctly it will help to shine a light on areas where crap forged mail tends to come from.
gregc
I think it's going to be hard for folks in your position, but not impossible, and there are benefits to it. I am a sysadming in IT as well so I am sympathetic to the problem of getting thousands of users to change.
Here are some ideas that may help.
1. Identify the networks you control and list those. If you know all the mail servers, great, list those... but if you don't, you can also get by with just listing the network ranges that you own and that allows any server in those ranges to send.
2. Offer mobile users an SMTP AUTH server. This will allow mobile/roaming users to send outbound mail back to corporate HQ to be sent out, rather than sending out through whatever DSL or cable ISP they happen to be on.
3. Phase it in slowly. Add ?all to the end of your record to allow sending from anywhere. There are additional optional things you can do to detect when mail is being sent from servers you haven't approved yet... You can do something like altavista.com does -- they use "exists:" in the record to trigger a second DNS query and then they can log those queries.
SPF will make it harder for spammers to hide their identity and masquerade as someone else. In the short term, they will forge stuff using unprotected domains, but as time goes on they will have to buy their own domains. While SPF doesn't actually stop spam, it does take away some of the tools spammers use to hide their identities, and makes it slightly more expensive to send spam, and slightly easier to track and stop spammers. I believe that getting some kind of accountability back into email is "necessary but not sufficient" to solving spam. That is, SPF is not the Final Ultimate Solution to the Spam Problem, but it makes some other spam-fighting techniques possible.
There really isn't a centralized resource for them to control. Domain owners can publish their own info using DNS (TXT records) and receivers can choose to check those records or not. I think it's going to be similar to other RFCs that define email -- they tell you what you have to do to be compliant, but they don't limit you to a specific vendor or ISP or software choice. You can buy software that is compliant, get free software, or write your own :)
Here's some info that may help. 1. The domain owner has control. If you own your own domain, you can decide what networks or mailservers are allowed to send. 2. Using SMTP AUTH may help. Your ISP, ASP, or corporate IS folks might have a way for you to send stuff out through their server, even if you are dialing in from some other network.. If not, bug them about it :)
If there is no SPF TXT record published, there is nothing for receivers like hotmail to check or enforce. It really is an "opt in" kind of system - both the sender and receiver need to actively do something before it takes effect. The DNS service providers really need to allow TXT records, but until they do, the mail coming from those domains should still be allowed through.
This is correct. You just need to create TXT type records. There are plans on the table within IETF to create a new DNS record type just for this, but this will take a long time to approve and even longer to get everyone's DNS servers upgraded. So for now everyone should be creating TXT records, and when the world is ready to switch to the new type, that will happen. I predict TXT SPF records will be around for at least 5 years.
The decision to use or not use SPF is up to the owner of the domain name. The domain name has to publish, and then the receivers such as hotmail will have something to check against. If you don't own your own domain name, keep an eye on your ISP so you know if/when they will be publishing SPF records. If you do own your own domain, you have a bit more control.
You are right, keeping the From: and changing Reply-To would work. Also, the change that MS proposed will check "Sender:" before checking "From:"... so you can actually keep From: as your permanent address and set Sender: to your mobile address. ISPs and corporate IS folks should also provide SMTP AUTH servers, so that remote/mobile users can use the same server they would normally use. This is not new (RFC2476 is 5.5 years old) but SPF will put more pressure on folks to follow the SMTP AUTH scheme.
Not to worry, smtp is naturally confusing -- it's designed that way :)
Spammers definitely take great advantage of how confusing all those extra headers are, and the smtp transaction has a couple of steps to go through before the headers even arrive. Luckily most mail servers will record their part of the transaction, the HELO command is "received from", the Mail From is the Return Path, etc. But it's still kind of tortured.
Early versions of SPF actually had reverse lookups like 1.0.0.10._spf.example.com. I actually like the new TXT format better since it is more flexible and easier to write for most domains.
:)
There is a careful tradeoff between "too simple" and "too complex". I have seen other similar proposals doomed by getting too complex, because they bow to what the users want and then nobody wants to write the code. At the same time I have seen proposals doomed because they were not flexible enough to handle most cases.
If you're looking for "something that describes where mail _comes_from_ so users with separate mail-clusters for outbound and inbound can identify themselves" - SPF is it, exactly. With SPF you CAN do reverse-IP style lookups like DNSBLs do, but for most domains it will be easier to just say "v=spf1 +mx +ptr +include:rr.com -all" which basically means "Allow from my MX, and anything with a verified PTR-DNS name in my domain, plus also allow from rr.com"
Anyway, I think SPF is a good compromise between simple and useful -- it is not too simple to be useless and not too complicated to get adopted. I think so far the plug-ins for SpamAssassin, Sendmail, qmail etc. have taken on the average "a few hours" to write.
Yes, it is similar to RMX, DMP, and MS. For my money, I don't care that much which proposal wins as long as we do SOMETHING. Cleaning up all forged mail is going to take a long time, so we should get started NOW
You can refer to your ISP in terms of "include=" (basically, this tells people checking your record that they should check SBC's record as well). You can add multiple includes for the ISPs you use.
Regarding headers, SPF is able to drop the connection based only on the SMTP commands, before you have sent any headers. Headers are part of the DATA step in the transaction which is like 4th, MAIL FROM step is 2nd.
If you're not adding it directly to the mail server, you can analyze headers after the fact, but you would only want to trust headers from your own server - your own server knows the other guys true IP since they have a two-way conversation.
It's going to be a long road, and I think SPF is just a first step, but it's an important first step. I would describe it as "necessary but not sufficient" to stopping spam.
:)
Here's how I think things might go if everything works out.
1. Some key large domains publish SPF, and a few large ISPs start checking for it.
2. Some of the mail that is forged using the big names is downgraded or dropped.
3. Spammers start to spoof the addresses of other names instead.
4. Pressure is on for the owners of those other names to publish SPF.
5. Some key organizations stop accepting messages without proper SPF credentials, like private companies or universities, who would rather lose some mail than deal with forged messages.
6. More pressure is on for domain owners to publish SPF to get their messages through everywhere.
7. At some point it becomes a well-known standard like MX, and everyone just does it as a matter of course.
8. At some point, DNS registration sellers get involved and won't register your domain if the SPF records are not right, like they check your NS and SOA info now.
Of course there will be other important things that need to happen to stop spam, and stomping out all forgery will take a long time, but that just means we should get started right away!
There are some places that block residential IPs... usually this is based on the reverse DNS (feed your IP in and try to get back a name) - it contains numbers like d22-164-99 or whatever. One solution is to set up your home server to send out through your ISP's server which should have a proper reverse DNS without so much numbers. Some smaller ISPs will allow you to set up "real names" for your reverse DNS, most will charge a small fee for this since they need to issue static (dedicated) ip address to do it. Probably the best route is to relay from your home server to the ISP's mail server to be sent out. SPF will probably help this problem, but it will probably be a long time before it gets to that point. People block IPs based on "dynamic looking reverse DNS" mostly because there really is no better way to tell "legit" from "spammy". If there is a verification scheme that can detect forgery based on DNS and it gets accepted widely, some ISPs might ease up on their other requirements, but that will take time. With your small business servers, you might not need SPF yet... if spammers start forging your name and pretending to be from your domain, it can be added later as needed. It's about as easy as setting up MX records so hopefully people will just start doing it as a matter of course. If SPF gets accepted more widely, spammers will start to move off of the SPF-protected domains and spoof the other unprotected domains, so there will be a lot of shifting around before there is a noticeable impact on spam.
I have seen discussions about technical solutions and legislative solutions, but not a lot of discussion about economics. I receive far more spam than direct (postal) mail. Obviously the huge number of spam messages flooding everyone's inbox means that response rates must be abyssmal -- but since the costs of sending spam are virtually zero as well, people will continue to send them, despite laws, suits, technology, etc.
So why is it so cheap to send email and so expensive to fight it? Here are some thoughts...
Forgery is easy, tracing back to the real sender is hard.
Not all spam is forged, but most is, because if spammers lie about their identity, fewer complaints will reach the real ISP and they can send millions more spams in the extra time it takes to track them down. Analyzing email headers is difficult.
Forged mail also means extra cost for the domain owner whose domain is being forged. This adds to the cost of fighting spam, but the spammers don't have to pay for this. Forgery is just one reason that spamming is easy and cheap, and fighting spam is difficult and expensive.
Something like the RMX proposal [previously on slashdot] would help this problem, but will take a long time to get to full usefulness. That's a good reason to get started now!
Sending in huge volume is easy
Once you have a dialup account, you can send any number of messages, limited only by the bandwidth of your connection. Any node on the internet that can be used to browse the web (port 80) can also be used to send mail to other mail servers (port 25).
It would be easy enough for an ISP to block outgoing connections to port 25, but their users may have legitimate reasons for sending direct and not wanting to use the ISP's servers. This type of policy would make it harder for legitimate users to run their own mail servers (such as DSL users who have their own Unix machines and want to run their own domains) but they can still do this if they set up their sending server to always relay to the ISPs server (or just ask for an exception to the port-25 policy, if they are already a trusted customer).
Forcing mail to go through certain servers makes it easier to enforce other rules, such as limiting their sending rate to 10 messages a day, or something appropriate like that. This is another thing that some ISPs will do and others won't, but it is in their best interests to do so. The idea is to keep the spammers from coming back, and the only way to do that is to make it expensive on a per-message basis to send spam through their network. If you can pay $19.95 for the account and send 1 million messages, and get 100 to 1,000 sales, that might be worth it, but if that ISP limits you to only sending 100 or 1,000 messages before you get caught, you will move on to the next ISP. ISPs that do this will spend less on abuse complaints, and those that don't will get picked on more and more. If this keeps up, it becomes infeasible for the ISP to do business the old-fashioned way, and it becomes infeasible for spammers to spam compared to the cost of other legit advertising.
It is also possible to allow some connections to port 25 and just throttle back after a certain number, or do a rate limit (like one per second)... but the technology to do this is harder than just straight blocking.
Anyway... my personal preference would be to use a technology-based solution, that has no national borders. I don't really object to a legislative approach as well, but my gut feeling is that it will not be as effective if it is not global. However, neither technology nor legislation can be effective without some understanding of the economic and "social engineering" factors.