Autor: Jan-Peter Koopmann Data: Para: Exim User's Mailing List Assunto: RE: [exim] Securing Email for the prying eyes of any government
On Thursday, January 13, 2005 11:41 PM Greg A. Woods wrote:
>> Ease of use for many people.
>
> That's a B.S. argument, pure and simple.
I did not say ease of use I said "Ease of use for many people". It is not up to you to decide this is a b.s. argument. Sending executables (and most other files) via mail is bad and unnecessary from your point of view (and mine as well btw). If some pointy-haired boss who finally realized how to use at least 10% of his outlooks capabilites wants to send/receive those files from someone else, he will probably decide otherwise. And if your job is to make this guy happy no matter what, this is a valid reason. Technically bullshit: yes. Still a valid reason. There is more to life (and IT) than pure technical reasons.
> There is no legitimate reason for sending executable code
> between systems, especially between end users. Never, Ever.
> Your "ease-of-use" crutch is because those who lean on it
> have chosen inappropriate technology.
Or are unwilling to learn since they have better things to do with their time.
> There are many, easy to use, alternatives that provide the
> same functionality and meet the same needs, and which may
> even be more powerful than the tools which might cause
> someone to think they need to move executable code between machines.
Agreed. I never said anything else.
> Until you, and Microsoft and other big corporate software
> vendors, understand this very simple idea, there will be
> viruses and worms running rampant in M$ client systems.
First of all: Really read my statements and think about them. You will see that I never said that sending executables is a good idea or that I tell people that it is. On the contrary. I merely stated the fact that for many people ease of use (which is their decision to make not ours) is _one_ reason for doing so. I do not like the reason and in all of my setups sending EXEs is not possible, neither incoming nor outgoing.
It is not important that I or Microsoft or other big corporate software vendors understand this idea. It is important that the user understands this idea. BTW: Microsoft has understood this idea pretty well by now. They are the only software company I dealt with over the past months that do not send large files (or executables) via mail when I talk to their support people. Their support staff creates case-based HTTPS storage areas over which you communicate with them. Most other software vendors always try to send me their patches via e-mail. When I tell them that this will only be stuck in my quarantine all they say is "Don't worry, I will ZIP it!". After I finish laughing about that I try to educate them. Does not work.
Another point: If you try to send/receive executables with Microsoft products they will warn you or simply not allow it. This leads me to believe that they do understand this at least a bit.
> I don't expect Microsoft, as a corporation, to ever "Get it"
> (since doing so would not be good for their shareholders),
> but you as an intelligent individual should be able to figure
> this stuff out.
I have figured it out and you would have noticed if you stepped down from your arrogant "I know it all, you know nothing" attitude for a change. Technically we agree on most terms. I simply will not agree to the "This is the only way of doing it and everything else is bullshit" point of view. The most important thing for me is that my customers are happy. Secure communication is one key point in this task of course and I will teach/tell them everything necessary to avoid the scenarios we are talking about. But if your customer is pointy-haired (or even 10% as bad) they will not follow your recommendation 100%. And then it is my task to make the rest of the system as secure and good as possible under that conditions. If you decide to dumb the customer since he does not fit your view of the world that is of course your decision to make.
> Indeed -- no system alone can be secure, especially not when
> it's connected in any way to a public network. Security
> requires a good security policy, and external controls as well.
Correct. But a security policy (and control of it) alone will not solve any problems at the moment.
