tag 539737 +moreinfo tag 539737 -pending thanks Hi Sandro, I'd like to know more about this use case.
The way mutt works is that -H is used to pass a 'draft' to mutt, that means that it needs a message draft that contains headers like From, To, Subject and so on (and obviously the content of the message). The problem is that mutt doesn't accept Content-Type or Content-Transfer-Encoding as part of that draft (otherwise we could have specified Content-Transfer-Encoding: decode-printable). It is correct that you're following the RFC in generating those headers but mutt is also correctly decoding those messages when it comes to receiving them with the proper COntent-Transfer-Encoding. The problem is that you want to send those messages with the charset encoded in the headers, that in mutt is not possible because the way mutt works is that it will *always* transcode your message to the charset determined with an heuristic based on the locale and some other environment variables. You could pass the charset wiht mutt -e 'set charset=yourcharset' but that doesn't cause mutt to accept your headers, that will only cause mutt to transcode your header in that charset so that they will show up exaclty as you wrote them. It seems to me that this model is pretty correct and it is following the practice of MUA that says 'be conservative in what you do and be liberal in what you accept form others'. I can follow up this with upstream but as you may understand the best we can hope is to get an option to prevent the transcoding of messages. We had an almost infinite discussion about $send_charset with upstream and they are pretty strict with the fact that they want to send the message in a certain way and leave the user only the minimum amount of flexibility so honestly I don't think that we can get much. My suggestion would be not to q-encode those headers because mutt will do the transcoding for you, if you want to q-encode then you should pass the message directly to sendmail and not use mutt as an editor (fire up $EDITOR instead). Does this make sense to you? Please let me know how you do want to proceed. Cheers Antonio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
