From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29649 invoked from network); 30 Jun 2002 15:36:32 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 30 Jun 2002 15:36:32 -0000 Received: (qmail 28242 invoked by alias); 30 Jun 2002 15:36:18 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5133 Received: (qmail 28228 invoked from network); 30 Jun 2002 15:36:17 -0000 Date: Sun, 30 Jun 2002 11:36:58 -0400 From: Cameron McBride To: zsh-users@sunsite.dk Subject: Re: Closed list? (was Re: A new game) Message-ID: <20020630153658.GA13720@localhost> Mail-Followup-To: zsh-users@sunsite.dk References: <200206291805.UAA12831@mailbox-5.st1.spray.net> <20020629190414.GB7597@hq.newdream.net> <1020629192923.ZM9213@candle.brasslantern.com> <20020629194338.GE7597@hq.newdream.net> <20020629201340.GA20030@localhost> <1025424766.2794.3.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1025424766.2794.3.camel@localhost.localdomain> User-Agent: Mutt/1.3.27i > > I would be up for something that at least strips out the large mime > > stuff. > > No. I do not understand why MIME is still considered the root of all > evils. This is the most natural way of posting patches and patches can > be large. OK, reasonable argument -- and you are right. However, there does have to be *some* method of elimination before they get sent. Perhaps filter on content type from the mime attachments (say 'application/octet-stream', etc), which would eliminate a few. > that supports IMAP and kill these messages without even downloading > them. If you get reasonable mail client you can read test without > downloading the whole attachments. Heh. OK, so the argument here is to better enjoy the list, I change my provider and get a decent mail client. Nice response... At least it is a reasonable suggestion of things to try if I hadn't thought of them and had it available. > > If you wanted to do some limiting -- I think that non-members having to > > be 'approved' is the most severe that should be implemented. I guess I wasn't clear -- I was trying to say that I think the list should stay open, with the above choice as the most severe limitation to be chosen. For a support / informational ML, I do not see the point of limiting posts only to subscribers. Sorry for my lack of clarity in the previous message. If I am the only one annoyed, or represent a severe minority -- it shouldn't matter, as I can live with it. However, if there are other members that are as annoyed... Cameron