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: