Other questions you need to ask: what is your acceptable false-positive and false-negative rate (how much legit mail are you willing to lose and how much junk are you willing to accept?)
What additional latency are you willing to accept? Some very effective low-falsing anti-spam techniques (e.g. greylisting) can delay mail. This can irritate some users who (unrealistically) expect email to be immediate communication.
Reflect on how much you wish to externalize your costs when planning an anti-spam system. For example, ipfilter-based blacklists are unforgiving but do not materially affect any other system. Greylisting conserves sender and recipient bandwidth but keeps mail in remote queues longer. Mail bounce messages and challenge/response systems can be (ab)used to mailbomb an unrelated third party. Techniques like tarpitting actively externalize costs by intentionally holding open SMTP connections for long periods of time. DNSBLs require you cede some amount of control to a third party (blacklist maintainers) but ultimately as a mail admin you are responsible for explaining your blocking policy to your users & management. The upshot is that there are ethical considerations that go along with each technology and it's important to be aware of your effect on others.
How tolerant will you be toward misconfigured external systems? (e.g. those without FCrDNS, broken HELO/EHLO strings, unauthorized pipelining, those that don't properly retry after a temporary failure code 4xx, etc.)
How much time, money, bandwidth, and hardware do you want to devote to the problem?
No single technique is effective, but a concerted defense-in-depth approach can substantially reduce inbound garbage. DNSBLs, URIBLs, greylisting, content filtering, and hand-tuned white- and blacklisting work well on my small domain, but I can afford to be more liberal in what I reject.
Unless things have changed recently, blacklisting IPs by country of origin is not terribly effective. I had the idea of using ASN and OS fingerprint (via p0f) to judge the quality of an inbound connection but didn't pursue it; the statistics would be interesting to look at but I'm not convinced it would be any more useful than the standard techniques already described. The upside to using GeoIP, ASN, and OS fingerprint info is that while they may individually be weak predictors of connection quality, they are available at TCP/IP connection time, long before you reach the SMTP layer (fsvo "long".) In combination, they may prove to be useful and that would be helpful because spam becomes costlier to block as it approaches the end user.
I'm not trying to be a naysayer; 'oddball' character encodings and GeoIP information probably correlate well to spam but may not be reliable enough to use as single criteria to block mail. However they may well be helpful indicators in a system like Spamassassin. The takeaway is that spam defense is a complex problem in cost-risk-benefit analysis and it's important to know what your values are before implementing or changing a system.
