Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
When building a list of files you'll exclude consider .zip files and all the other common compression extensions. One mail system I work with excludes them all -- like rar and so on. You have to rename the extension *and* put a password on it. Otherwise it will never get 'there.' MEG > -----Original Message----- > From: discuss-admin at blu.org [mailto:discuss-admin at blu.org]On Behalf Of > Derek Martin > Sent: Sunday, August 17, 2003 1:11 PM > To: BLU > Subject: Re: HTML to Text only emails... > > > On Sun, Aug 17, 2003 at 11:50:20AM -0400, Wizard wrote: > > A company that I do work for, in an effort to protect > itself from it's own > > lusers, is considering parsing emails so that any external > HREFs inside the > > email point to http://localhost. They are also going to > parse out all > > attachments to a central intranet location, where they will > be reviewed by > > admins for legitimacy before being forwarded to the > addressee. Can anyone > > see any problems with this strategy? > > Aside from making lots of sh!t work for the admins, there's one big > one: privacy. > > Everyone here knows that, regardless of who owns the computing > resources, etc., people who are at work receive personal, sometimes > very private, e-mail at work. If someone else is reviewing your file > attachments, potentially serious problems could result. Such > attachments could conceivably contain wage information, medical > information, job offers, confidential business details, etc. Having > attachments reviewed by persons other than the intended recipient > opens up a whole messy can of law-suit worms. > > Depending on how large the company is, I think it really is worth > pointing out that this scheme may require one or more dedicated people > to review attachments. And then, the person to who they were sent > still has to look at them anyway... In practical terms, the amount of > time having attachments reveiwed may end up being more than the amount > of man-hours spent cleaning up from a virus infestation. > > A better approach is something suggested here recently: identify > malicious attachments at the mail server, and remove them. You can > define malicious any way you like. The definition I favor is, "any > attachment which is likely to contain executable or interpreted code > which the target client is likely to execute." That would include > windows .exe, .com, .pif, and .scr files, as well as anything > containing Active X controls, or visual basic code. Did I get 'em > all? As we know from experience, it is not enough to look at the > extensions, or even the MIME types of such attachments. You must > actually look at the attachment to see what it contains. > > This doesn't solve the problem for word macro viruses. You'd still > need to resort to a virus scan or some other program capable of > identifying word macro viruses. Or just ban MS-Office attachments, > which is a solution I personally quite like, though you'll never sell > the marketroids on it... > > -- > Derek D. Martin > http://www.pizzashack.org/ > GPG Key ID: 0xDFBEAD02 > -=-=-=-=- > This message is posted from an invalid address. > Replying to it will result in undeliverable mail. > Sorry for the inconvenience. Thank the spammers. > >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |