[Mailman-Users] URL of scrubbed attachments missing in the list archive

[kardan]

Hi,

On Wed, 26 Jun 2013 15:38:30 -0700
Mark Sapiro <mark at msapiro.net> wrote:

> On 06/26/2013 02:57 PM, kardan wrote:
> 
> > I deactivated the collapse_alternatives as this was not what I
> > intended.
> [...]
> > Basically I prefert text to html mails and would like to keep
> > convert_html_to_plaintext=yes as I know some members have quite
> > weird colour and formatting settings as default. So far none of the
> > list members complained.
> 
> If you prefer plain text to HTML or other fancy text, you probably DO
> want collapse_alternatives = Yes as that will normally select a plain
> text alternative in preference to an HTML alternative.
Sounds convincing.

> See <http://www.iana.org/assignments/media-types>.

I found, that rfc1521 shows an overview content and MIME types
http://www.faqs.org/rfcs/rfc1521.html

7.4.1.     The Application/Octet-Stream (primary) subtype
To reduce the danger of transmitting rogue programs through the mail,
   it is strongly recommended that implementations NOT implement a
   path-search mechanism whereby an arbitrary program named in the
   Content-Type parameter (e.g., an "interpreter=" parameter) is found
   and executed using the mail body as input.

I came to the conclusion, especially because I know that many users do
not care about security, not even about technology so much, it is my
task as listadmin to take most risks out of their way instead of leaving
the possibilities of harmful content with obligations they do not
understand.
Even if octet garbage is propably no harm for my system as it is
treated as non-executable I should not burden anybody with the
possibility of unwanted script execution.

> > However accepting application/octet-stream seems risky and I see no
> > way to handle that properly, except whitelisting all accepted types
> > like pdf, jpg, png and all documents. However odt with embedded
> > macros can be harmful as well. So there is probably no easy fix for
> > that.
> 
> Note that filtering/accepting based on file extension is not at all
> reliable as many inline images with media types like image/jpeg,
> image/gif, image/png, etc. will not have an associated file name and
> therefore cannot be filtered/accepted based on filename extension. The
> same is also sometimes true for application/pdf and many other media
> types.

I cannot take care of in which way a user sends attachments. I neither
want to filter them nor should they be forwarded, but stored aside. You
said "your settings do not pass multipart/related so the
multipart/related part including its text/html and image/jpeg
subparts were removed", which is not what I want.

> > The option to link attachments in the archive instead of
> > forwarding them sounds like the best solution in my eyes, while
> > accepting the above issues still.
> 
> If by the above, you mean the option (scrub_nondigest) to remove,
> store aside and link to attachments in individual messages and MIME
> format digests, then you are correct in what it does, however,
> attachments are always removed, stored aside and replaced by links in
> archived posts and plain format digests regardless of this option.
> The option only controls at what point in the process the
> removal/replacement occurs.

Summarizing i need to change the following options to make mailman
* send only plain text messages to the user
* strip all (inline) attachments, store them and link to it in both, the
  archived and the fordwarded version

pass_mime_types = <none>
collapse_alternatives = Yes
convert_html_to_plaintext = Yes

Is there anything I missed?

Thanks for all your help so far!
Kardan