OK, the "which MTA" question is a holy war topic. PPL here will wait for me to chant "qmail" until I fall down, so I won't. ;-)
However, your questions REALLY are NOT about the MTA, per se. You are asking about how to stop in the inbound flow of spam. This really ISN'T a function of the MTA, but is something that plugins/addons to the MTA do.
Your questions
#1) Which SPAM filtering software to use? SpamAssassin is the reigning king of this and it has a few additional layers that are optional that you can enable. Adding Anti-Virus (such as ClamAV) will stop a decent amount of crap incoming.
Your Q#2) Is the most interesting to me. Again, I don't know if the MTAs are the real issue. It's the resources you have available on your machine to have perl instances thrown for each incoming email to run SpamAssassin and then run the message past the anti-virus scanner too. This is NOT an efficiency that the MTA should be attributed to, IMHO.
Also, you seem to have some fear about being blacklisted for NOT accepting SPAM/Virii. I would argue that you would be regarded as quite the good email admin if you DID take a harder line on rejecting SPAM. Your users will thank you, your bandwidth cost/usage will thank you. Certainly your servers will thank you. I'm NOT aware of any blacklists that are derived from criteria in which the accepting MTA (you) were choosy about the kind of email ACCEPTED.
Two more thoughts....
First, there are MORE options to consider including the use of several Blocklist... Marsd mentioned the 'orbs' lists, but there are (many others), each with their own benefits and risks. You should consider using these to refuse connections from high-risk IPs/Network ranges before your poor server has to spawn a single instance of SpamAssassin
Next, there are other anti-spam technologies such as the use of the "SPF" proposals and requiring valid "PTR" (Reverse DNS) against the sending email server as requirements before you'll even accept an SMTP connection from them.
Finally, a practice I have now adopted on my serves is to stop sending bounce messages altogether. You can end up generating a hugh volume of email outbound from your network in "friendly" response to notices of virii found and unknown recipient messages. Since I found that 90%+ of the bounce messages were going back to fraudulent senders in the first place, I just /dev/null the delivery of these anomalies and sleep well at night. This posture puts a slight bit more responsiblity on the users in resolving "missing email" issues when the sender mis-types the "To:" field, but my users are not requesting "catch-all" accounts to solve this and they understand the benefit of NOT accepting hundreds of spam a day for this tiny extra bit of effort.
Hope that helps.
Hosting Solutions for Home or Business.
