Steven> OK, now let's make it more in line with modern practice: Steven> Say a protocol more or less completely lacked server-server Steven> authentication, or a way to distinguish between client and Steven> server, and that then every day, for ten years, hundreds and Steven> [...] Steven> after accepting the submissions, rather than rejecting at Steven> submission time. Oh, and outbound connections aren't Steven> expected from the vast majority of those hosts. Are you saying that since you have never had to lock your door before you shouldn't be required to install one now? Steven> Yes, I think this a reasonable response to use everything at Steven> our disposal to refuse the majority of the unwanted Steven> submissions. Wouldn't "everything at our disposal" include developing and installing locks? Wouldn't that be an obvious first step? Would your first reaction to finding your house burgled be to phone all the builders of houses in your neighborhood and demanding they make it impossible for anyone else to leave their house? Steven> thousands of professional criminals used weaknesses in the Steven> monopoly OS to plant software completely under their control Steven> on fifty million (or so) of these vulnerable hosts, For email viruses the monopoly OS is not the only cause of blame (although its manufacturer helped a lot in other ways). If one allows someone to use an MUA that executes code in Turing complete languages one has already essentially done what our hapless hypothetical sysadmin did with authenticationless SSH. The only difference is that our hypothetical sysadmin will have implemented an interactive system whereas such MUAs will have implemented a batch system with an awkward JCL called MIME. Viruses (of the email type that is) spread so easily because we have not made it clear enough that using one of these MUAs has the same security implications as letting any user start an anonymous telnet server. Yet here too all sorts of strange recommendations are made[1]. Suggestions that would never even be considered if a sysadmin was actually faced with a user running an anonymous telnet server. Suggestions which by and large avoid doing what we all would do in an instant if we were faced with this problem in its telnet guise: requiring authentication. Does your security policy allow users to implement authenticationless command servers? If not do you prohibit the batch command servers that many MUAs have become? --------- [1] Suggestions like "we will filter mail for viruses". If an employee was running anonymous telnet at your place of business would your response be to attempt to write a filter that would delete any "bad scripts"? I'm pretty sure at most places the employee would be forced to stop.