HTML to Text only emails...

[mattg at theworld.com (matt galster)]

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.
>
>