To answer
asqui: The problem is one of expectations. An end
user does usually not expect actions taken in his
mail user agent to be dangerous, and thus is not expecting his 'Preview mail' to actually result in
mail bombing everybody in his contact list, replacement of all his
mp3s and
JPEGs with viral code, or all of his
data being stolen.
Making this happen by default in order to support an operation that should be uncommon (executing non-authenticated code recieved through e-mail, the equivalent of lending your machine to a stranger for a day, without supervision) is in my opinion bad user interface design.
Guns are commonly designed with safety catches; if we were selecting a gun to give to everybody, I assume we would pick one with a safety catch, even though the catches aren't strictly necessary if the user is careful. We should go to at least the same level of protection for MUAs; though the consequences usually are less severe with a mailer mishap,
guns are, after all, designed to kill, while this is (hopefully) not a common design goal for MUAs. Thus, we can expect people to be somewhat more careful around guns than they would be around MUAs.
If I was to support executing content directly from the MUA at all, I would have done the following things to restrict damage:
- Default to not running executable content on double-click, instead displaying a requester telling about the dangers of executing code on your machine, about the ease of forging e-mail, that firewalls will not protect you against this, and of where the user can change the preferences to allow execution.
- Allow execution with or without a warning each time execution is attempted (after the above option has been changed to allow it at all.) I'd probably do this by allowing execution of the executable that triggered the last warning before enabling of execution, but coming up with a warning (with a disable button) each time afterwards (until the user disable the requester.)
- Allow execution in a sandbox, where the executing program does not get write access or access to create outbound network connections, and the output from the program is displayed in a controlled fashion, avoiding spoofing for passwords and similar.
- (If possible) Allow execution with other types of lowered access, e.g. popping up a requester before allowing writes to proceed.
This isn't enough to give perfect security, but it creates a much safer environment, and one where users are automatically taught about the dangers of their actions. The cost is at two levels - the user that actually know what she is doing lose 30 seconds disabling the protection, and the implementor of the program lose time implementing the security features.
I think this is a reasonable cost, and that not taking it is irresponsible.