I'm not sure if I fully understand the question with the part about providers permit sending mail to the Internet without authorization. If you mean internet users using the server to send to other internet users, that's bad. It would be considered an open relay and yes you'd get most likely filtered by other ISP's.
If you mean your internal users sending to the Internet, it's not necessarily bad it's just a policy decision. You can do that by securing the server to only relay mail for your IP ranges.
We aren't an ISP but I have worked with them. While there we only allowed sending from our own IP range, and if you were outside the network you had to authorize to the mail server to send messages and/or use the web interface to use email.
Mail servers were throttled in how much they could send per message so people couldn't email huge attachments.
The mail server was monitored for unusual traffic spikes...no home user should be sending a constant stream of mail.
The router locked out port 25 for any server that wasn't designated as the mail server, so home users couldn't run their own mail servers.
Filtering outgoing mail with something like bayesian filtering can be a pain in that false positives create a bad user experience. Users don't like it when their webbertubes act like magic and that magic won't work for them, especially if it fails seemingly at random. Your tech support won't appreciate the angry calls either. Or you may lose users who just get fed up if they have a bad experience with things "just not working" (unless these are people you want off your network, I don't know).
In general you want to prevent unauthorized access to your server. SMTP authorization can be somewhat annoying for the users to set up, but it usually isn't too bad. Beyond that locking it down to whitelisting your own IPs for relay and limiting message size should be fine. You may or may not want to also add a block on sending executable attachments as well (bat, pif, exe, com...), but that's a policy decision.
Either way you need to make it clear on your website and instructions for home users how and what is allowed for your mail server. You'll still get the phone calls about why something didn't work or what a bounce message means since users usually can't read the message with "attachment too large" written in it, but the slightly more tech savvy will appreciate the ability to look up your policies and errors without dealing with your help line.
For just you? Probably not; For your company's mail server? Not unless you want to get fired.
Almost all mail these days is sent as multi-part with an HTML alternative.
I personally have my mail client set to use the plain-text version first, and there's a lot of stuff that's legitimate mail that's just junk as they don't create a useful plain text version.
For example : someone sending you stuff from Google Reader -- you get a blurb, and NO URL to follow. Some go overboard with URLs -- the spam filter at my work gives a link to select allow/ignore/etc. for each message that's quarantined with a 120+ character URL for each one.
Best Answer
You can set up SMTP servers of your own, block SMTP (and submission) traffic outbound from the web servers to anywhere but that SMTP server, and compel your clients to configure that as their outbound MTA. Then, run a spam filter on that SMTP server (spamassassin under postfix might work, though I would disable the RBL filters as they would be useless), and have it drop anything which appears to be spam.
This has a number of severe drawbacks, such as that you might unintentionally silently drop some of your clients' legitimate mail, and that some spam will probably still get through.
Assuming the servers that are spamming are actually supposed to be sending mail at all, the only way you are going to prevent this is by securing the hosts so that they don't get owned. This may prove extremely difficult depending on the exploitability of the versions of the software you're running at each point, and how readily you can patch.
Chances are that if you are getting owned that often, you're being owned by an automated process employing a public exploit. In this case, patching will likely greatly reduce the incidence of this issue.