Subject: Attachment Stripped in Transaction

From: [email-masked]
Date: Tue, 24 Jul 2001 17:37:49 -0500

************* eManager Notification **************

This is an auto-generated message.  There was an attachment to this email message.  The NIST firewall has stripped it out due to the policy change that went into effect on May 5, 2000.  For further information, please refer to http://www-i.nist.gov/itl/div895/895.02/nist_firewall_email.htm

Source mailbox: "[email-masked]"
Destination mailbox(es): "[email-masked]"

******************* End of message *******************
From: Admin <[email-masked]>
To: [email-masked]
Subject: Paptuc
date: Tue, 24 Jul 2001 17:07:16 -0300

---

From: Greg Minshall <[email-masked]>
Date: Tue, 24 Jul 2001 16:09:16 -0700

i know we've gone spammed ourselves plenty on this in the very recent past, 
but i actually don't find the e-mail from the virus-strippers all that 
offensive and i think it would be nice if we could keep the IETF list from 
being an exploder of viruses.

i wonder if we shouldn't take vjs's (i think) suggestion and forbid all MIME 
mail on the IETF list (return it to sender with an explanation).

if the problem with that approach is international character sets (presumably 
mostly in people's names), then is there a single (going way beyond his 
competence here) MIME "type" that would be guaranteed to be (treated as) text, 
and we could reject any mail other than that?

(i think the secretariat probably is already thinking of something; maybe this 
request is for them to make some suggestion at the next plenary.)

---

From: Richard Welty <[email-masked]>
Date: Tue, 24 Jul 2001 23:58:49 GMT

> mail on the IETF list (return it to sender with an explanation).

i've been using a Perl tool named demime 
(http://scifi.squawk.com/demime.html)
to do this on lists i manage for quite some time now, with excellent 
results.
Demime is stongly recommended...

richard

---

From: [email-masked]
Date: Tue, 24 Jul 2001 20:42:30 -0400

> mail on the IETF list (return it to sender with an explanation).

If we do that, it's time to move the RFCs describing multipart/signed
to 'Historic' status.  Is that the message we want to send?

On the other hand, I could live with the filtering of active content and
executables (which is what the *real* problem is, right?)

/Valdis

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 25 Jul 2001 13:37:33 +0100 (BST)

> to 'Historic' status.  Is that the message we want to send?

The message is that the IETF's work in describing protocols is done
only in the basic protocol of text.

If it can't be described in text, it probably can't be implemented in
text as a computer program either.

Nothing stopping people posting on-demand URLs for 'smarter' content.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: [email-masked]
Date: Wed, 25 Jul 2001 11:43:47 -0400

> only in the basic protocol of text.

Correct.

> text as a computer program either.

The point I was trying to make was that if we simply filter *ALL* messages
that aren't text/plain, we're sending a message that we've given up on
multipart/signed messages as well.

Surely after almost a decade of MIME experience, we can do better than just
saying "Throw out all stuff that isn't text/plain".

/Valdis

---

From: Richard Welty <[email-masked]>
Date: Wed, 25 Jul 2001 18:40:07 GMT

> multipart/signed messages as well.

On the contrary, i think it's quite acceptable for any mailing list
to have a policy of "text only" submission. MIME has its uses, but
it doesn't need to go everywhere email goes; that's just insane.

I would further note that MIME is horribly incompatible with RFC 1153
("Digest Message Format") which may be listed as an experiemental RFC
but the format is in very common use.

> saying "Throw out all stuff that isn't text/plain".

i'm about this close to setting up "ietf-demimed", a demimed list that 
would
be subscribed to [email-masked], on my server, so folks can just try it 
out.

Richard

---

From: [email-masked]
Date: Wed, 25 Jul 2001 12:09:34 -0700 (PDT)

> multipart/signed messages as well.

More generally, the issue is that MIME is used for lots of things besides
"fancy markup format du jour", and if we require that all messages be
text/plain we end up banning things like signed text/plain messages, nested
RFC822 messages containing text/plain parts, messages consisting of
multiple text/plain parts, and so on. And there are perfectly legitimate
reasons to post these sorts of things to lists.

Heck, we even end up excluding Internet-Draft and RFC announcments, which use
multipart/mixed, multipart/alternative, and message/external-body to give
readers a convenient way to access the actual document. (It also is a 
mechanism I happen to use regularly, and I would hate to lost it.)

> saying "Throw out all stuff that isn't text/plain".

Exactly. Much better rules are possible, and in fact much better rules are in
wide use on other lists.

				Ned

---

From: Jon Allen Boone <[email-masked]>
Date: Wed, 25 Jul 2001 18:37:14 -0400

Richard Welty <[email-masked]> writes:

>    I'm about this close to setting up "ietf-demimed", a demimed list
>  that  would be subscribed to [email-masked], on my server, so folks
>  can just try it out.

    Go for it.  Let us know how it goes.  If it is successful enough,
  perhaps the administrator(s) of odin will follow suit.

-jon
-- 
------------------
Jon Allen Boone
[email-masked]

---

From: "Kory Hamzeh" <[email-masked]>
Date: Wed, 25 Jul 2001 16:39:22 -0700

> Exactly. Much better rules are possible, and in fact much better

Many lists:

A.) Reject posts from non-members.
B.) Don't allow attachments.

They don't have any of these problems that seem to plague the mailing list
of the brightest minds of the Internet.

Kory