Mailman rejects multipart content from Gmail/android

Bug #1787690 reported by Jeremy Gregson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
Undecided
Mark Sapiro

Bug Description

With a mailman list set to apply content filtering, and with the default settings to pass_mime_types of text/html, multipart/mixed and multipart/alternative, mail sent from anyone using the Gmail app on an android device is bounced. The same user can send the same message from the native Mail client on an Android device, or from an Apple device.
The problem seems to be that the Gmail app includes a header in the form
Content-Type: multipart/mixed; boundary="===============8130305584729002058=="
...with no carriage return after the semi-colon.

The only way I've been able to get a list to accept mail from that client app (which is very popular) is to remove pass_mime_types altogether.

Revision history for this message
Mark Sapiro (msapiro) wrote :

Possibly the message does not have a text/html part. Have you tried the following in pass_mime_types:

multipart
text/html
text/plain

The fact that the Content-Type: header is not folded with a CR and whitespace following the semicolon is not an issue.

If adding text/plain to pass_mime_types doesn't fix this, please post a complete raw message. You can elide the actual MIME part contents, but we need to see all the Content-Type: headers and part boundaries.

Changed in mailman:
assignee: nobody → Mark Sapiro (msapiro)
status: New → Incomplete
Revision history for this message
Jeremy Gregson (lochacmasonry) wrote :
Download full text (4.4 KiB)

Hi Mark -

First of all, thanks very much for getting back to me. Secondly, there's something I realised I didn't mention in the bug report, which may count as a 'free pass' for you to handball the problem back - I'm running Mailman 2.1.20 on Ubuntu 16, not Mailman 3. I've put off upgrading because I understand the move to v3 is a major architectural change, and I have a lot of legacy lists and users to worry about.

Anyway - in the course of experimenting with the content filter settings, I tried a number of options. Finding a tip online from someone else who identified different subtypes of multipart, I tried adding multipart (without any subtype) to pass_mime_types. When that didn't work, I tried multipart* to see if there was such a thing as a wildcard (I think I tried multipart% and multipart/* as well), but I didn't try adding text/plain.

So, I've just done that - no dice. When I send to the list from the Gmail app on an Android phone with the pass_mime_types field completely clear, mail gets to the list. With the mime type set to your three options, nothing gets through and nothing appears in the vette log - which is consistent with the message having been so gutted by the filtering process that there was nothing left to pass or reject.

I've attached an example of a message that gets through to the list with pass_mime_types cleared, and is lost with the filtering turned on. In case the act of attaching it loses anything, the headers as received at the list were:

Return-Path: <email address hidden>
X-Original-To: <email address hidden>
Delivered-To: <email address hidden>
Received: by mail.jeremygregson.com (Postfix, from userid 500)
 id 52C2F4021C; Mon, 27 Aug 2018 13:47:18 +1000 (AEST)
Received: from mail.lochac.sca.org (vmx20482.hosting24.com.au [163.53.249.53])
 by mail.jeremygregson.com (Postfix) with ESMTP id 36B0440215
 for <email address hidden>; Mon, 27 Aug 2018 13:47:18 +1000 (AEST)
Received: by mail.lochac.sca.org (Postfix, from userid 500)
 id E453E481FD5; Mon, 27 Aug 2018 13:48:12 +1000 (AEST)
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
 vmx20482.hosting24.com.au
X-Spam-Level:
X-Spam-Status: No, score=-0.0 required=3.2 tests=BAYES_00,HTML_MESSAGE,
 MAILING_LIST_MULTI,MISSING_MIMEOLE,RDNS_DYNAMIC,SPF_HELO_PASS,URIBL_BLOCKED
 autolearn=no autolearn_force=no version=3.4.1
Received: from mail.lochac.sca.org (localhost [IPv6:::1])
 by mail.lochac.sca.org (Postfix) with ESMTP id 8B2F4481F89
 for <email address hidden>; Mon, 27 Aug 2018 13:48:12 +1000 (AEST)
X-Original-To: <email address hidden>
Delivered-To: <email address hidden>
Received: by mail.lochac.sca.org (Postfix, from userid 500) id 9BA8F481FD5; Mon, 27 Aug 2018 13:48:10 +1000 (AEST)
Received: from mail.jeremygregson.com (203-217-61-26.perm.iinet.net.au
 [203.217.61.26])
 by mail.lochac.sca.org (Postfix) with ESMTP id 36E9A481F89 for <email address hidden>; Mon, 27 Aug 2018 13:48:10 +1000 (AEST)
Received: by mail.jeremygregson.com (Postfix, from userid 500) id E964A4021C; Mon, 27 Aug 2018 13:47:13 +1000 (AEST)
Received: from [10.183.142.121] (unknown [1.144.228.246]) by mail.jeremygregson.com (Postfix) with ES...

Read more...

Revision history for this message
Jeremy Gregson (lochacmasonry) wrote :
Revision history for this message
Mark Sapiro (msapiro) wrote :

This is the correct tracker for Mailman 2.1 issues.

The headers at https://bugs.launchpad.net/mailman/+bug/1787690/comments/2 are only the message headers and only say that the message's Conternt-Type: is multipart/mixed. If I send a message from Gmail on my android phone it has the following MIME structure.

multipart/alternative
    text/plain
        the plain text alternative
    text/html
        the html alternative

I suspect the message you are looking at from the list has structure

multipart/mixed
    multipart/alternative
        text/plain
            the plain text alternative
        text/html
            the html alternative
    text/plain
        the list footer

I can download the https://bugs.launchpad.net/mailman/+bug/1787690/+attachment/5181125/+files/Selenetest%20Test%20subject.msg attachment, but I can't open it with anything that renders it properly. 'file' tells me "Composite Document File V2 Document, Cannot read section info".

Note that you can't use wildcards in pass_mime_types, but you can specify a main type without a subtype. I.e., this

multipart
text

in pass_mime_types will accept any text/* elemental parts within any multipart/* parts.

Also note that Content filtering -> filter_action controls what is done with a message from which content filtering removes everything and there should always be a Message discarded or Message rejected message in the vette log in any case.

Is there anything in Mailman's error log?

If you have problem posting a raw message, just send a message from your android gmail app with Subject: Bug 1787690 to <email address hidden>.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers