[geeks] Gmail's attraction

[Dan Duncan]

On Sun, 5 Sep 2004, Mike Hebel wrote:
> Yes.  And I would do the same.  If we're talking Windows look at a
> program called WS-FTP.  It has an Explorer interface that "just works".
>   You set it for the corporate server for a particular username and they
> drag and drop files to it.  It asks for a password then transfers the
> file.

Yes, but then another layer has to manage it.  If Bob wants to
send a file to Sue, why should he need to involve another department
to do it?  Now someone has to set up an ftp account, give Bob the
password, and then he has to put the file out there and tell
Sue to go look for it.

> As for FTP servers signed on/off by security auditors - that's a
> "security management issue" not a technical one.

Security management is just as valid a concern as technical ones.

> Don't confuse having
> tight "managed" security with misuse of an improper tool.  Ftp and it's
> ilk are the right tool for the right job.  E-Mail is not.

How can you know that without knowing the company's needs?  If they're
using one of those horrid email systems like Notes or Exchange, they
handle file transfers within the company just fine.  Even for [more]
standardized email systems, file transfer is RFC supported.

> This is why education of users is important.  With more access comes
> more responsibility.  If they can't handle that then they have to ask
> someone else to send the file.

Don't you get tired of LARTing them?

> I know I'm going to get flamed here for "educating" users but I won't
> do it any other way.  The only reason I can get things done efficiently
> at any IT position I hold is because my user base is educated to handle
> certain issues - most of them common sense.

I admire your goal, and it used to be my goal, but I'm not as
idealistic as I used to be.  Too many PHB's I guess.

> If the sending server is logging.  If the receiving server is logging.
> If neither server strips receipts for some reason.  As for sensitive
> data internal to the message - that should be encrypted if it's going
> by e-mail at all.  If all e-mail were being encrypted I could accept
> your argument but that's obviously not true.

All of our internal servers store user mail and transfer it between
servers in an encrypted form, everything is logged, and receipts
are never stripped.  It's been fully audited and signed off on
as a secure method for an employee to send a confidential file
to another employee.

> So.  That means you employ one more person to do log auditing.  No harm
> in having another person.  The job market for IT people still sucks if
> I recall.  Give a fellow Geek a job.

Yes, it does suck, the budget is tight, and none of us really wants to
take on another full time set of duties.  If you'd like to volunteer
your services, great.

> Time to change jobs.  I'm serious here.  You should never be under
> threat of life while doing a job unless the job is inherently
> life-threatening.  IT shouldn't have the same potential hazard as say
> underwater welding.

We haven't lost a sysadmin yet.  Some of us shoot back.

> >>> You get a virus scan,
> >>
> >> Oh, that's part of RFC 2822 now?  I must've missed that part.
> >
> > Do you really propose a company not do virus scans on attachments?
>
> No.  What he's saying is that it's an added thing and not done in
> nearly enough environments because it's not an inherent part of sending
> e-mail.  Though you are half right that it should now be a part by
> design.

Since security is part of the discussion, assuming email is virus
scanned seems like a valid assumption.  If we don't assume that,
why do we care at all about any level of security in file transfers?

Just stick it out on gnutella and hope they'll pick it up.

> > Why are we even bothering to discuss security?
>
> Because you claimed that e-mail was secure and traceable.
> It is not.  At least not reliably so.

Email within a company can be secure and traceable.

> > How many SMTP servers does it pass inside the company?
>
> Exactly why it's not a realistically trackable option.  Too many
> variables.

Email within a company can be secure and traceable.

> > If you're worried about passing in the clear, why propose FTP?
>
> Because FTP is point-to-point for the most part.  On any system I've
> ever seen each transfer is logged on both sides.

Here, I'll let you answer this one yourself:
"If the sending server is logging.  If the receiving server is logging."

> Now FTP does have
> some security issues - SFTP would work better in my opinion.  There's
> truly less chance of an interception though between a unpredicted file
> transfer versus an e-mail server that you always have traffic on.

With FTP, they don't need to intercept the file in transit.  They
can just sniff for the password and then go in and get the file
and any other files sitting in there as well.

But when I email a file, there's no password to sniff.  They'd
have to sniff the entire file in transit, which might be made
even more difficult by other email passing through at the same time.

This becomes even more difficult if the company is using an
internal email system where the entire path from a user's client
to the server to the other user's client can be encrypted.

> Again, training users is not a bad thing.

It's not a bad thing, but it may not be feasible all the time.
You can't smack users around when they're in another city.  I've
tried.

> Limiting tools and not training users will only get you gumby users
> that cause you endless problems.  The dumber and less informed the user
> the dumber they will act.

I know.  It's very sad.  Wait, were we talking about using computers
or cars?

> > Is it ideal?  No, of course not, but it allows an existing tool
> > with existing security to be used by users with existing knowledge,
> > all of which saves time and money.
>
> Time and money between dealing with gumby users and lost information
> and clogged e-mail far outweighs the cost in time/money training users
> to use the right tool.

That depends on the company.

> It is my job as an IT person to make sure people can and do function
> efficiently on their systems.  That means training.

On what scale?  Do you really want to train 20,000 people in several
countries to use a new tool that isn't installed yet when they
already know how to use a system that is in place and does the job
quite well?

> > Let me ask you this:  The last time you sent out a resume, how did you
> > send it and why?
>
> I sent it by hand delivery.

Nice if the company is nearby.

> I did send one by e-mail and later found
> out that it was because the country was suit infested.  Needless to say
> I didn't want to work there.

Your choice.  Some of us like to eat.

> Your arguments do have some merit but to me they show that you have
> fallen into the trap of "stupid users" and "I have no say in anything".
>   Neither is true by default.  And if the second is true it's time to
> find another position.

Both are true in some companies, and in those situations email
is the defacto tool for the job.

-DanD

-- 
#  Dan Duncan (kd4igw)  dand at pcisys.net  http://pcisys.net/~dand
# Expressing anger is a form of public littering.  -Willard Gaylin