[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-bugs-list
Subject:    [issue39771] EmailMessage may need to support RFC-non-compliant MIME parameter encoding (encoded wor
From:       "R. David Murray" <report () bugs ! python ! org>
Date:       2020-02-29 16:54:25
Message-ID: 1582995265.34.0.318578962463.issue39771 () roundup ! psfhosted ! org
[Download RAW message or body]


R. David Murray <rdmurray@bitdance.com> added the comment:

I actually agree: if most (by market share) MUAs handle the RFC-incorrect parameter \
encoding style, and a significant portion does not handle the RFC correct style, then \
we should support the de-facto standard rather than the official standard as the \
default.  I just wish Microsoft would write better software :)  If on the other hand \
it is only microsoft out of the big market share players that is broken, I'm not sure \
I'd want it to be the default.  But we could still support it optionally.

So yeah, we could have a policy control that governs which one is actually used.

So this is a feature request, and ideally should be supported by an investigation of \
what MUAs support what, by market share.  And there's another question: does this \
only affect the filename parameter, or is it all MIME parameters?  I would expect it \
to be the latter, but someone should check at least a few examples of that to be \
sure.

----------
stage:  -> needs patch
title: EmailMessage.add_header doesn't work -> EmailMessage may need to support \
                RFC-non-compliant MIME parameter encoding (encoded words in quotes) \
                for output.
type: behavior -> enhancement

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue39771>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/python-bugs-list%40marc.info



[prev in list] [next in list] [prev in thread] [next in thread]