From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23947 invoked by alias); 14 Mar 2012 15:24:50 -0000 Received: (qmail 23934 invoked by uid 22791); 14 Mar 2012 15:24:49 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Mar 2012 15:24:36 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id q2EFOW127554; Wed, 14 Mar 2012 15:24:32 GMT Received: from shurg.barn.ecoscentric.com (unknown [87.127.120.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id 92B903FE1; Wed, 14 Mar 2012 15:24:31 +0000 (GMT) Message-ID: <4F60B82E.6060405@jifvik.org> Date: Wed, 14 Mar 2012 15:24:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: "Frank Ch. Eigler" Cc: "Carlos O'Donell" , overseers@sourceware.org Subject: Re: Stripping multipart/alternative messages and accepting the text/plain part. References: <20120311183254.GA13084@ednor.casa.cgf.cx> <4F5D3A09.9090806@jifvik.org> <20120314145955.GE21927@redhat.com> In-Reply-To: <20120314145955.GE21927@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact overseers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: , Sender: overseers-owner@sourceware.org X-SW-Source: 2012-q1/txt/msg00099.txt.bz2 On 14/03/12 14:59, Frank Ch. Eigler wrote: > Hi, Carlos - > >> [...] >> I would like to reach the conclusion that either: >> >> (a) The lists will *not* support multipart/alternative text/plain, and why. >> >> (b) The lists *will* accept only the text/plain portion of a >> multipart/alternative. > > I'd be fine with (b). Note that you'll likely need the mimekeep > rather than mimeremove, so as to preclude not just text/html but > image/jpg etc. I have no problems with that in principle. However we also have to make sure that legitimate attachments can continue to work, especially patches. Based on mime types I've seen used over time, that would mean we should also permit: text/x-patch text/x-diff application/x-patch application/octet-stream Sometimes, collections of files are also sent as zip files, with type application/zip or application/x-zip (I note that application/x-zip-compressed is currently rejected in mimereject but not the other two forms). Are there any other mime types we'd need to consider permitting? Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine