Thanks Steve,
The SPM list now has a maximum allowable email size of 50K.
Cheers,
-John
-----Original Message-----
From: SPM (Statistical Parametric Mapping) [mailto:[log in to unmask]]
On Behalf Of Steve Smith
Sent: Monday, October 30, 2006 11:47 AM
To: [log in to unmask]
Subject: Re: [SPM] Attachments
Hi John - yes, you can limit the attachment size - we have a 50K
limit on the FSL list - we have the following flag set:
Sizelim= 50K
Cheers, Steve.
On 30 Oct 2006, at 10:39, Ashburner John (PSYCHOLOGY) wrote:
> Does anyone have strong feelings on whether it should be possible
> to send emails with attachments to the SPM mailing list? I don't
> know of any way of limiting attachment size, but there are ways of
> stripping off certain kinds of attachments. The options that would
> be available to me are as follows:
>
>
> Full Description:
>
> Attachments= No[,Filter]
>
> Attachments= Yes[,allowed_content_types [,Filter]]
>
> Attachments= All[,allowed_content_types [,Filter]]
>
> LISTSERV includes a list-owner-configurable message attachment
> filter. This feature allows you to control the posting of various
> types of MIME attachments (images, audio, etc.) to your lists. It
> includes the ability to control the posting of inline uuencoded
> files to your lists on an on/off basis (off being the default if
> attachment control is enabled).
>
> NOTE:The ability of LISTSERV to filter or reject messages that
> contain MIME attachments is completely dependent on the ability of
> the poster's mail client to properly identify the MIME attachment
> when the mail is originally sent.Filtering/rejection is done based
> on the Content-Type headers found in the message--NOT by evaluation
> of the actual contents of the attachment. If for instance an
> executable binary (normally Content-Type: application/octet-stream)
> is sent by the client with a Content-Type of "text/plain", it will
> not be filtered or rejected by LISTSERV since (as noted below) text
> attachments are not covered by this keyword setting.
>
> A registry of allowable MIME types for attachments, maintained by
> the Internet Assigned Numbers Authority (IANA) per RFC2048, can be
> found at
>
> http://www.iana.org/assignments/media-types
>
> The options are:
>
> Attachments= Yes
> All types of attachments are allowed to be posted to the list (the
> default). Note however that other configuration options may still
> disallow the posting of certain attachments, and that "Attachments=
> Yes" does not override them.For instance, if you have
> "Language=NoHTML", setting "Attachments= Yes" does not override the
> Language= setting.Or if you have "Sizelim=" set to a value that
> precludes a file of x number of lines from being posted to the
> list, setting "Attachments= Yes" will not override the Sizelim=
> setting if the message with its attachment exceeds the number of
> lines specified by Sizelim=.
>
> Attachments= No
> All types of attachments are disallowed, other than plain text
> (always allowed) and HTML text (which is controlled exculsively by
> the "Language=NoHTML" keyword setting). With "Attachments= No",
> LISTSERV rejects messages containing attachments and bounces them
> back to the poster.
>
> Attachments= No,Filter
> Same as "Attachments= No", except that LISTSERV simply removes the
> unwanted material from the message and processes it instead of
> rejecting it out of hand. The removal of material is a silent
> operation, that is, the poster is not notified that the attachment
> was discarded.
>
> Note that in all three of the above cases, when a message
> containing one or more uuencoded files is posted to the list, the
> encoded file(s) is/are stripped from the body of the message and
> the remainder of the message is passed through to the list.
>
> Attachments= All
> This setting tells LISTSERV to allow inline, uuencoded files, such
> as are generated by Microsoft Outlook, overriding the default.
>
> One important restriction: UUencode filtering is strictly on/off.
> There is no attempt on the part of LISTSERV to guess file types
> when filtering is enabled (the default). This would be hazardous to
> begin with as support for these attachments is usually provided on
> a legacy basis in mail clients, that is client A and client B could
> have a very different opinion on the type of the attachment.
>
> It is also possible to allow certain MIME types to be passed
> through to the list while rejecting or filtering all others.For
> instance,
>
> * Attachments= Yes,image,application/*msword
>
> allows only the specified attachment types and rejects everything
> else. If you don't want to reject messages that contain other types
> of attachments, but just want to remove all other types of
> attachments, you add the ",Filter" parameter at the end of the
> line--for example:
>
> * Attachments= Yes,image,application/*msword,Filter
>
> This means, "Allow all image and application/*msword attachments,
> and strip all other attachments".Again, note that plain text
> ("Content-Type: text/plain") is always allowed and does not need to
> be included in the list of allowed attachment types.Likewise, HTML
> text is controlled exclusively by the "Language=NoHTML" keyword
> setting.Other text subtypes are, however, controlled by
> "Attachments=", so they need to be listed if you intend to allow them.
>
> Additionally, should it be desired to allow all inline uuencoded
> files but restrict the list to certain MIME types, you can specify,
> similar to the above, something like
>
> * Attachments= All,image,application/*msword
>
> or
>
> * Attachments= All,image,application/*msword,Filter
>
> In the preceding examples note carefully that "image" by itself is
> equivalent to "image/*"--in other words, when you code
> "Attachments= image", you are saying that all MIME image sub-types,
> for example, "image/jpeg", "image/gif", and so forth, are to be
> accepted. If only certain sub-types are acceptable, for instance if
> you want to accept only JPEG graphics and ensure that others don't
> go through, you must specify the types explicitly--for example
> "Attachments= image/jpeg".
>
> Note carefully that simply coding something like "Attachments=
> image" will not necessarily allow all image files through. This is
> highly dependent on the client being used by the poster. For
> instance, if your client attaches all binary files as "Content-
> Type= application/octet-stream", regardless of whether a given
> binary is (for instance) an executable image, a Word file, or a
> compressed archive, and you send a JPEG to a list with
> "Attachments= image" set in the header, it will be rejected since
> the image does not have a "Content-Type: image" tag. Specifically
> this appears to be the case with Eudora 3.x but may not be limited
> to that particular client.
>
> The rejection message sent by LISTSERV when ",Filter" is not
> specified is found in the BAD_ATTACHMENT mail template form. Note
> that the BAD_ATTACHMENT template form is a linear template and as
> such does not allow text formatting commands to be used.
>
> The reason HTML text is not subject to "Attachments=" filtering is
> to allow you to reject (bounce) messages with attachments, while
> silently suppressing HTML text in multi-part messages which also
> contain a plain-text alternative. Some mail programs send both HTML
> and plain-text versions of messages, and, even if you do not want
> HTML text on your list, there is little point in keeping out people
> who use it (who are often new to the Internet and aren't aware that
> their mail programs are sending HTML text) when you can simply
> remove the HTML part. At the same time, you may want to reject
> postings containing images out of hand, rather than removing the
> images and continuing. The same applies to Exchange attachments,
> which are filtered by default (see "Language=Exchange").
>
>
> There is more information on this in http://www.jiscmail.ac.uk/
> newsletter/issue06/issue2_04_files/page0003.htm
>
>
> Best regards,
>
> -John
>
>
>
------------------------------------------------------------------------
---
Stephen M. Smith, Professor of Biomedical Engineering
Associate Director, Oxford University FMRIB Centre
FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
+44 (0) 1865 222726 (fax 222717)
[log in to unmask] http://www.fmrib.ox.ac.uk/~steve
------------------------------------------------------------------------
---
|
