On Thu, 2004-06-10 at 08:20, Peter Hinchliffe wrote:
I showed her how to scan
several pages into a single stand-alone executable Paperport document,
which could then be sent as an email attachment. A fine idea on the
surface.
She tried emailing it to a colleague sitting at the desk next to hers.
He received the message alright, but his Outlook proudly announced that
it was protecting him by refusing to allow the download of this
dangerous attachment. No choices, no arguments, you just can't have
it! And there is no obvious way overriding this behaviour without going
back to Exchange Server.
That's how my mail server is configured, too - and for good reasons, in
my opinion.
First, I think emailing around executables is an inherently dodgy idea
at best. No matter what platform you're on, the security implications
are rather bad. Like many things on the Internet (like every server
being an open relay) it's kind of cool and rather handy, but just not
worth the problems it causes. In almost all cases, a non-executable
non-scriptable document and a viewer download from a trusted source is a
much safer approach.
Second, the remote (and it is remote) risk of accidentally blocking a
genuine attachment is massively outweighed by the volume of viruses not
making it into the users' mailboxes and mail spools. No amount of user
training can save you from ooh, what's this, *click* *click*.
Our mail server quarantines stripped attachments for a week before
chucking them out, so users have a chance to get them back if they want.
This is made clear in the removal notice. I've never had a user ask.
If you think that Outlook server is draconian, though - I just added
.zip to the list of attachment extensions to be automatically stripped.
Again, it's worth it and we can retrieve them if we need to. It's been
in force for a month, and ... no user requests.
Sure, it's stupid to have to do this sort of thing - but in the end,
it's really not that bad. Also, if Macs were widespread, I expect I'd be
wracking my brains trying to figure out how to block AppleDouble encoded
Mac executables instead. I already block some UNIX script file types,
just in case there's a flaw with our Linux desktop mail software.
How this stuff continues to survive, and how people continue to put up
with it, is increasingly amazing. Yet when you suggest that Macs might
be an option to consider the shutters come crashing down.
Sadly, macs aren't always the ideal solution to Windows security issues,
despite their other attractive qualities.
Price (OS upgrades, anyone?), staff familiarity, etc are all issues.
Change is expensive, too. Then there's your network and servers to
consider. Especially if people are locked into an MS network
architecture, it can be quite expensive to change - and there isn't much
confidence in MacOS X active directory support etc outside mac-user
circles yet (at least, not in my experience). Remember that many
sysadmins still hear Macintosh and think arrgh, AppleTalk, getitaway,
getitaway!
Some sysadmins will have also had one too many mac users telling them
that macs will solve all their problems, when they /know/ they won't.
Linux users tend to be much, much worse when it comes to this problem
though.
On the flip side, NetATalk 2.0 is _really_ nice if you have a Linux
server, and makes looking after macs on your network considerably less
painful (I'm comparing to Services for Macintosh on WinNT4, by the way).
IMHO it's finally almost up to the standard set by Samba. For us, it
meant that we didn't need to buy an XServe and could use our current
SATA RAID storage server instead, so we should probably send those folks
a thank-you cheque.
--
Craig Ringer
