Subject: Stray question, (a little bit) (What's the best practice on this?)

From: [email-masked] (Dan Kolis)
Date: Wed, 4 Jun 2003 13:56:39 -0400

Hi,

A little off the center of the road, but that's nothing new here.

As users tend to use HTTP email accounts; (for privacy, flirting, whatever)
in enterprises this makes it hard to snag viruses to some extent. 

If the preferred solution in some server farm of linux and NT's.... whatever
is snagging virus attachments at SNMP and/or POP3 interfaces, this is great
and can work really well.

But on the HTTP side (even worse? https), all sorts of GETs and PUTs can
move items to and from on 80. To Java apps... whatever. Like attachments
carried by hotmail and Yahoo, etc.

Trying to tackle people in the hall and tell them what to do or not do just
doesn't work, for one thing. You can't or don't want to generally encoumber
abstract use of http and/or port 80. And, programs scanning the file system
are very robust / reliable for a host of reasons.

Any option on that? In tribute to the main purpose of this list: This is a
problem which might have a protocol solution of sorts. I'm not use I like
it, but seemingly the trasports could maim attachments by altering there
MIME type. Bad way to solve a problem is to make somebody elses
program/process crash though!

Regs to all,
Dan

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jun 2003 14:57:10 -0400

Dan,

A partial solution to _part_ of this problem lies in the 
receiving MUA. To oversimplify quite a bit, there are three 
things a receiving MUA can do with an HTTP body part:

	* Discard it because it _might_ be dangerous.   This is,
	obviously, not a good general solution, but might well
	be rational if the mail were suspect for other reasons.
	
	* Hand the attachment off to a general-purpose browser,
	which would be likely to be configured to process almost
	anything.
	
	* Have a browser available that was, by implementation
	or configuration, able to process HTML mail without
	executing code or following links without explicit user
	involvement and information.

The second seems to be the norm.  The third can avoid a _lot_ of 
trouble.

This doesn't, of course, address the risks of sending malware 
out, but recipients need to defend themselves regardless.

    john

--On Wednesday, 04 June, 2003 13:56 -0400 Dan Kolis 
<[email-masked]> wrote:

> As users tend to use HTTP email accounts; (for privacy,
> flirting, whatever) in enterprises this makes it hard to snag
> viruses to some extent.
>
> If the preferred solution in some server farm of linux and
> NT's.... whatever is snagging virus attachments at SNMP and/or
> POP3 interfaces, this is great and can work really well.
>
> But on the HTTP side (even worse? https), all sorts of GETs
> and PUTs can move items to and from on 80. To Java apps...
> whatever. Like attachments carried by hotmail and Yahoo, etc.
>
> Trying to tackle people in the hall and tell them what to do
> or not do just doesn't work, for one thing. You can't or don't
> want to generally encoumber abstract use of http and/or port
> 80. And, programs scanning the file system are very robust /
> reliable for a host of reasons.
>
> Any option on that? In tribute to the main purpose of this
> list: This is a problem which might have a protocol solution
> of sorts. I'm not use I like it, but seemingly the trasports
> could maim attachments by altering there MIME type. Bad way to
> solve a problem is to make somebody elses program/process
> crash though!
>
> Regs to all,
> Dan
>
>
>
>
>