Hi, On Wed, 26 Jun 2013 15:38:30 -0700 Mark Sapiro <m...@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 ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org