Hi,

Quoting Jani Nikula (2015-10-18 13:58:01)
> On Tue, 06 Oct 2015, David Bremner <david@tethera.net> wrote:
> > These broken now, but will be fixed in the next commit
> > ---
> >
> > The first test is OK, but the second one currently fails. It isn't
> > clear to me if content dispositions permit RFC2047 style
> > encoding. GMime does not decode them automatically (hence this test is
> > failing). What is true is that the RFC states "Unrecognized
> > disposition types should be treated as `attachment'". So maybe the
> > logic in patch 1 should be reversed to check != 'inline'.
> 
> > +Content-Type: text/plain
> > +Content-Disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9ImJlZ3LDvMOfdW5n?=
> > + =?utf-8?b?LnBkZiI=?=
> > +Content-Description: this is a very exciting file
> 
> Did you handcraft the example, or did some program actually produce
> this? I don't think this is [RFC 2231] compliant. IIUC only the content
> disposition parameter values may contain encoded words with
> charset/language specification. Like this,
> 
> Content-Disposition: attachment; filename="=?utf-8?B?cMOkw6RtaWVz?="

I'm using alot as my MUA and that produced the Content-Disposition line I
quoted.

Thanks!

cheers, josch