While that’s definately not a good thing, if you lock a programmer in an epic battle with user _INPUT_, it certainly sounds more interesting. I don’t agree that the programmer should see the user as the enemy. The programmer should be concerned with User Interface primarily, and handling “exceptions” should be a key element in the UI. Trust got thrown into the mix, because at heart, all us old school programmers worship the BOFH.

And email is broke. Email messages might benefit from checksuming at the client ends. Most spam today generates random content to skew Bayesian logic. So, if I require you to compute the SHA1 and MD5 sum of the email text with respect to each individual recipient, your processor has to do so some work. If I could block non checksummed messages, or bad checksums, I could force the spammers to utilize more and more processor power.

There are other ways: Autoblock any non RFC Compliant transfer, grey list, white list, use queueing systems with autoresponders linked to database employing captcha’s and other identity verification methods. Or cry.

If the programmer trusts the user not to do anything stupid (from a programmer’s perspective), then the user is not free to try things that may not make sense (to a programmer). A well-written, hardened program actually frees the user to do their job, and not have to think like a programmer.

Good computer security can do the same, allowing users to feel secure in what they can do and to keep them from doing anything really self destructive. The boundaries should be clear, explicit, and few. For instance, if you had an e-mail server that actually dropped all malicious stuff and informed you of what it did and why, then your users could feel free to use their e-mail to send stuff that wasn’t malicious, and to open things that came to them. Isn’t that a neat concept? Almost like it’s 1990.

Current mail screening implementations provide incomplete security, so the users still need to be wary, and we’re still spending a ton on mail cleaning anyway. Then the users probably get yelled at for sending things that get mangled by the “protection” for reasons they don’t understand. This is a partial solution to a problem, making the problem actually more difficult and expensive to deal with, and in essence isn’t a solution at all.

Not trusting the users is a crude, programmer-centric way of saying that users should be able to trust the products of programmers. It’s actually manners, kind of a programmer’s way of saying “here, let me make this simple for you.” IT needs to understand this in the same way.