ietf
[Top] [All Lists]

Re: Eliminating Virus Spam

2001-01-04 00:10:02
    Date:        Wed, 03 Jan 2001 23:57:53 -0500 (EST)
    From:        James M Galvin <galvin(_at_)acm(_dot_)org>
    Message-ID:  
<Pine(_dot_)BSF(_dot_)4(_dot_)21(_dot_)0101032316360(_dot_)2147-100000(_at_)two(_dot_)elistx(_dot_)com>

Aside from what Donald said...

  | In addition to better managing resources on the server side I consider
  | it a service to the subscribers.

I don't.   This is like the kind of service you do for a battered
wife when you offer to drive her home from the hospital...   Much
better to do the harder work and convince the subscribers to get
rid of the cause of the problem, rather than offering band aids.

If that means excluding people till they learn how to participate
gracefully, then that might be what it takes to get the message
through.

  | As far as restricting the content of messages on the IETF elist to text,
  | I'm not opposed to it although I won't support it either.

On ietf(_at_)ietf(_dot_)org (as is already done on several other lists) this
seems like an entirely reasonable idea to me.  On ietf-announce on
the other hand, no, no need to restrict types (but there the list
cannot be generally accessed).

I can't think of a particularly good reason to send signed messages
to the ietf list, and I can't even imagine what use those vcard
things that keep appearing are (I have never found one... but I'd have
thought that if you want one from someone, you should send them
private mail and ask for it).

I can't think of any other reason that the ietf list would need
any kind of attachments in mail.

  | On the other hand, I think it's a feature to be able to send documents
  | (even text-based documents) as attachments as opposed to inline and I
  | further consider it a feature that Internet Draft announcements and RFC
  | announcements are multipart with functional pointers to the documents.

Yes, but none of that on the ietf(_at_)ietf(_dot_)org list.

  | but nonetheless I would consider it
  | short-sighted of us to explicitly hold back the advancement and
  | improvement of email (and MIME would be an improvement if more software
  | did it right), especially when it is our own standard.

There's a difference between holding it back, and directing it towards
proper, or considered, rather than simply universal, use.

  | I would, however, support the moderation of any message containing
  | something other than text,

That's probably more work than it is worth for the IETF list, as 99%
of the time, (probably more) "bounce it" is going to be the appropriate
response.

kre



<Prev in Thread] Current Thread [Next in Thread>