Slashdot Mirror
To Allow or Not Allow E-Mail Attachments?
t0pper311 asks: "I work for a pretty large utility company in the midwest and of course, security is a big concern. We use Trend Micro as a mail gateway to basically scan for virii and strip off most attachments like executables or VB script. Now with the Sobig.E virus on the loose, we need to ask ourselves if we should be blocking ZIP files. We got lucky this time and were not effected, but what about next time? What are other companies doing? If you do block ZIP files, how do you give the people who need to sends files the ability to do so? Do you allow any attachments at all?"
Why do you make so many accommodations for the failures of the OS? Isn't the OS supposed to work for you, instead of you working for it? How many features do you have to shut off before it's not worth the considerable cash you paid for it?
--
$tar -xvf
I think if people insist on running software that is vulnerable to these kinds of attacks then yes, you do need to stop these people using attachments completely.
If we do need to send files to each other as part of our business then surely that's a major feature that our application environment needs. If our chosen solution doesn't let us do that without an enormous amount of hassle and risk, then maybe it's time to make other tradeoffs and choose a client that does.
And if we have to choose between an email client with nice scheduling/calendaring and one that lets us receive file attachments safely, then that's a *decision* that must be made based on business needs. Which is more important to your task? Is there a way to have both? Will we accept the risk and hassle of virii to get nice calendaring, or will we use clumsier calendaring and have safe file attachments?
Only when people start making these conscious decisions en masse will we start seeing applications (including OS/hardware/whatever) that provide all the features we need to do our jobs.
The current climate of "how do we shore up the inadequacies of our chosen software?" isn't helping things improve.
Nice calendering *or* safe file attachments. Choose. If someone offers a product that does both. Cool. We all win.
- Muggins the Mad
I think that if a user opens an attachment from a random source, that came with no explanation, with a funky name like the ones in the write-up (see article link), then that's their own fault.
Filtering out legitimate attachments is not very good policy to protect against virii. You'd be -much- better off spending a few minutes educating employees in a "Virus Prevention" seminar or something. Show them that opening emails like that is not intelligent, and that way, it's not as much of a problem.
IMHO, email is not a file transfer medium; sure you can send little things with it, but it's just not useful for any real kinds of file transfer.
Personally, I think you should set up an FTP that is open anonymously to everybody in your company, and then disable attachments so that people have to upload to the ftp, then email the link around.
This is an important point. Why should running an executable be dangerous at all? is it really that difficult to set up a sandbox (a la the JVM) for users to run untrusted executables in? There may be some more hassle involved, but it could be implemented fairly transparently.
Don't knock HTML email. It makes my life easier, since I
evil
Are all of the virus scanners going to recursively extract all those zip files?
Bleh!
You should make sure that your bounce messages go to the right place. I've received countless messages informing me that my attachment was stripped because it contains the Sobig virus. The second thing you should do is to make sure that the full headers of the message get inserted into your bounce.
The funny thing is that I run only Linux on my domain, and I never e-mailed those people anything. It's very unlikely that Sobig can run on Linux. And I can't do anything about it because I don't have any headers to track down the source of the mails. Nobody's answered my requests for them either.
If tits were wings it'd be flying around.
This, and similar issues, have cropped up at a few of our customer sites over the years. There are situations where bringing in (documents/zip files/spreadsheets/etc.) are an essential part of making organisation function.
Whilst you can implement technical countermeasures to reduce your security risk somewhat, such as installing virus checkers that are able to unzip/unarj/unrar, keeping virus signature definitions up to date, quarantine incoming attachments.. etc, you really need to compare your security risk profile, with the business risk associated with NOT receiving these attachments.
This would normally be the function of your organisational risk assessment - it would compare the likely harm of virus infection, against the loss of capability as a result of not receiving the documents/zip files in question.
Which way you go, really depends on the threat/risk/harm/countermeasure equasion, which is unique to your organisation. However, a quick 'cheat' check:
* How badly is it going to hurt your organisation overall, if attachments don't come in?
* Do you have the resources to quickly clean up a virus attack if one makes it through?
- If you're a small organisation, with adequate IT staff numbers, and receiving attachments is pretty essential to your normal business... it's probably worth allowing things through.
- If your IT staff numbers are limited such that a virus attack would be a major cleanup effort, or attachments aren't all that critical, then block them, or quarantine them by redirecting them to technically literate help-desk users (who can forward them internally after checking them out).
However, make sure that you make it relatively painless for users to get their files. If you're really anal about things, they'll just open up a hotmail/yahoo/whatever account, ask people to send attachements there instead, and download just like a normal web link.
Red.
Yes, sometimes translation will be disappointing, but you probably didn't need the formatting junk anyway. Besides, once it's in an OpenOffice format, you can file it in a system with a search engine.
Google ought to sell something like this as a product, since they already do most of those translations.