I actually think that the spamassasin/procmail combination above is nearly ideal on the MUA side,
It is not, because:
1. Bandwidth is used up by spam (which is fortunately usually not that big) and worms (which tend to be much bigger)
Bouncing these requires (at the MTA or beyond) requires examining them and applying tests to the entire message, generally, so bouncing at the MTA saves no wasted bandwidth -- it close to doubles it.
I agree that rejecting the message based on content during the session won't help here, but I wasn't arguing that doing it on the MTA is ideal, just that filtering on the MUA isn't an ideal solution.
If you reject the message during the SMTP session you don't need to generate a bounce message, the other side will do this. So the bandwidth waste is the same in both cases.
2. A lot of processing time is used on your system(s)
The processing power required, BTW, while non-trivial is easily within the reach of modern CPUs for up to perhaps a thousand users per server
Fortunately things aren't as bad as this (that means services like Hotmail would need mail server clusters of super computer proportions) but doing content based mail filtering is certainly "non-trivial", as you say.
3. Either:
3a. Legitimate senders who are tagged as spam are blackholed and are
unaware that you don't read their message
3b. You must manually sort through all messages that are flagged as spam
Instead you have legitimate readers who may be unaware that a message to
them was bounced or blacklisted,
Requiring that the intended recipient is informed of mail transmission problems doesn't make much sense since if the failure can be communicated, then the message itself could also have been communicated.
Anyway, I think it's more important to provide feedback to the sender as the sender knows how important the message is.
And you (the user) CAN'T sort through all messages that are flagged as spam because they aren't spooled, they are rejected!
I'm not interested in flagging messages as spam, I'm interested in rejecting a significant percentage of unwanted mail. If the mail isn't unwanted, then by all means, have it delivered, regardless of it being spam or not.
So there's the gauntlet. You propose that bounces are important. Are they important enough to justify bouncing 9 messages out of 10 to false return addresses?
I believe sending back feedback when a message is filtered for some reason is important, because this way a limited amount of false positives is acceptable as the sender gets to retry the communication in some way. However, I fully agree that sending back bounces to the "from" address does much more harm than good here. But rejecting the message DURING THE SMTP SESSION (sorry for shouting) doesn't have these drawbacks as you are by definition (still) talking to the actual source of the message.
(Ignoring the corner case where someone accepts a message with forged headers and then tries to deliver it to a third party here.)
I believe our current email systems and protocols are broken so fundamentally, given the current environment, that it's no use trying to fix them. We need something new.