Subject: Re: filtering active content

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 25 Jul 2001 13:39:54 -0400

> From: [email-masked]

    > On Tue, 24 Jul 2001 16:09:16 PDT, Greg Minshall <[email-masked]>

    >> i wonder if we shouldn't take vjs's (i think) suggestion and
    >> forbid all MIME mail on the IETF list

I would go along with that.

    > If we do that, it's time to move the RFCs describing multipart/signed
    > to 'Historic' status.

OK, so we can make an exception for those MIME types (until someone
figures out how to embed a virus in them too :-).

    > I could live with the filtering of active content and executables

The problem with that is that it's not always easy to be sure what is and
what is not active content that's potentially harmful (in addition to all
the usual things like .VBS, etc). E.g. I'd have thought a .DOC file would
be pretty harmless - but it turns out they can have macros in them, and
there are .DOC macro viruses (like Melissa). Then, of course, there's
always a 'first time' when some bright spark figures out how to stick a
virus in something that *used* to be thought of as perfectly harmless,
and wasn't on your "do not pass through" list.

I really don't see any need for MIME content on this list (or any most
any IETF-related list - IETF-Announce excepted), and would support
automatically filtering it all out.

    > From: William Allen Simpson <[email-masked]>

    > At least we could filter messages greater than 32K. ... Nobody
    > really has any reason to bombard us with more than 32K....

Ah, make it 128K and I'd agree with you, but I think I've probably
exceeded the 32K limit occasionally... :-)

	Noel

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 25 Jul 2001 21:03:50 -0600 (MDT)

> From: Keith Moore <[email-masked]>
> To: Vernon Schryver <[email-masked]>
> cc: [email-masked], [email-masked]

> > Having them not able to receive their re-directed copies of virus
> > warnings is a feature, not a bug.  
>
> and presumably having them not be able to receive any mail from the
> IETF list is a feature, also?  or didn't you bother to read what I wrote?

If you had even read what you quoted, you would have seen that I
did mean that.

>s > If they can't run their forwarders
> > right, or find people who can, then they should be spending time fixing
> > those problems instead of reading this mailing list.
>
> what makes you think it's *their* forwarders that are causing the problem?

The error of using precedence:bulk for loop detection would be a problem
in "*their*" forwarders or the forwarders of "*their*" human agents.
It's not as if any other forwarders in the path might be using
precedence:bulk for loop detection in the situation we're talking about.

> > In other words, it's not naivete to say that if you want to play with
> > the big kids, you ought know what you're doing.
>
> and perhaps, so should you.
>
> > > p.s. perhaps you should see if Microsoft is hiring. it sounds like you'd 
> > > fit right in :)
> > 
> > You first, given the 8 copies I've received and the 7 that everyone
> > else has received of your <[email-masked]>
>
> perhaps you should read RFC 1047 before you start pointing fingers.
> but since you mentioned it, the message was still in my mail 
> queue with "error waiting for reply from DATA".  I removed it.

That's another place where you might take your good advice about reading,
and discover that I later made essentially the point of RFC 1047.

In addition, given the timing of the duplicates of your messags and
what you say you found in your queue, you (or rather, the rest of us)
might profit by your reading RFC 1047 and applying some of the suggested
countermeasures.  How short are your timeouts?

> p.s. in case you missed it the point of my original message was:
>
> it's fine to make suggestions for how to solve problems, but you might
> consider that you don't understand enough about the problem to  say for 
> sure that you know the fix.  people have looked at using precedence: bulk
> before and found problems with it.  conditions do change, so maybe 
> it would work well enough now.  but it has done harm in the past.

I got that point.  Since today is not the past, and since you mention
no current problems, I don't see it's relevance besides chest thumping.

Vernon Schryver    [email-masked]