SPF

The whole point of SPF is to enable postmasters to detect and deal with (read that: discard) messages that have an invalid point of origin.
It may not always happen but we should at least have the ability check if a message is valid before we spray the spam trap with backscatter.
When it's in my hands I'll always reject a message before accepting it for delivery if it fails SPF, BLACKLIST or other authenticity/deliverability checking. This leaves the what to do in the hands of the mail server that has already accepted the message to deal with and at least saves having to generate a bounce message later - one less problem is one less thing to do.

Right, the best thing to do is to ignore messages to be discard in such way that the sender does not even know whether the message will be discarded or not.

UCEProtect should set the SPF records to something, instead of setting it to no address, so the spammers do not get a clue to whether the domain is a spam trap domain or not.

If every mail server in the world used SPF, spammers would not be so successful.

It's not exactly easy to set up an SPF record, especially from within a shared server environment. WHM/CPanel et. al. could make it as easy as pushing a button, or entering a record automatically when a domain is created. Not something cryptic and geeky like "define an SPF record" but plain words like "Prevent Spam Sent from This Domain". So maybe the people to talk to are the ISPs and the server control panel developers.

Microsoft has a nifty little Wizard,
microsoft.com/mscorp/safety/content ...
but here again you only get the record itself and no clue what to do with it other than MS's usual advice to "give it to your network administrator".

I'm saying if you want to encourage adoption of a given technology, you've got to bring it to attention in layman's language and then make it easy to implement in layman's language. I'm a life-long geek, and still don't quite understand DNS because I can't know everything.

Joe, if you use shared hosting you are not the one to enable SPF support for discarding incoming invalid messages. That should be something that your ISP should implement on the mail servers that receive messages for the all the domains they host.

If you want to avoid that spammers forge messages with your own domains, you need to set the SPF TXT record in your domain DNS. That is a good idea, but that is not the problem with UCEProtect. They should be the ones to set the SPF records on the spam trap domains they handle.

In any case, if you want to learn more about setting SPF records for you domains, check out this site:

openspf.org/

... if you want to learn more about setting SPF records for you domains, check out this site:
openspf.org/
=======================================================================
The link above is no longer operational ...
I was able to access Google's snapshot of the page as it appeared on 8 Dec 2009 11:07:44 GMT.
74.125.153.132/search?q=cache:http://www.openspf.org/

I was also able to locate an active HOWTO - Define an SPF Record page at
zytrax.com/books/dns/ch9/spf.html

Thanks, that may be useful for those looking for that site too.