I think you are saying that you want the charset in the encoded filename to be GBK rather than utf-8?  utf-8 should certainly display correctly in your email client, though, so if it is not there is something else going wrong.  

As far as the 3 tuple not working to set the charset...I believe what is happening there is that a header created by the application gets "refolded" on serialization, and refolding doesn't keep the existing charset, it converts everything to utf-8.  This is an intentional part of the design: the library handles the gory details of MIME and uses utf-8 as the charset for application created content.  It is actually an accident of the implementation that the tuple form of the filename is even accepted; you will note that it is *not* documented in the contentmanager docs.

It wouldn't be crazy to ask for this as a feature, and it could even be treated as a bug that it doesn't work if we want to, but it may not be easy to "fix", because it goes against the design philosophy of the new API.