On 08Jul2012 18:32, Jack M <[email protected]> wrote: | Wrote Cameron Simpson [07/09/12 @08:18:11 +1000]: | > I would start by using: | > set sendmail=~/my_sendmail_wrapper.sh | > and making a small shell script "my_sendmail_wrapper.sh" that takes a | > copy of the input as received by mutt. [...] | | I use mutt's built-in SMTP to send with. I have no idea how to configure | sendmail, so that will be a big project.
You could install ssmtp, and use it to dispatch directly to the same SMTP service you're currently using with mutt. Then call ssmtp instead of sendmail in the script. | However, I do keep copies of my sent | mail in $record, and when I look at the saved copy, it is not QP-encoded. | Also, the mysterious QP only happens on *some* mails that I send, indeed, only | on *some* of the mails with non-ASCII in them. This makes me think mutt isn't | the culprit. It does sound that way. Is it associated with particular target addresses? That would involve particular mail systems in the transport. Also, for a message that _was_ QP encoded badly, can you show us the exact headers as they are in your copy in $record? Mutt may not be doing the QP, but it may be releasing text that is open to wrong QP markup (I really mean the charset labelling here, not the bytes). Um, one more thing. UTF-8 includes bytes with the high bit set for some data, including your example problematic character. Mail systems _are_ allowed to rewrite content into 7-bit safe forms for transport, and that is probably what is triggering the QP encoding. Can you reliably reproduce the issue? If so, maybe you can convince mutt to use UTF-7 or something to avoid the encoding problem. (Though it would be better to figure out that precise causes first instead of working around stuff.) Cheers, -- Cameron Simpson <[email protected]> I have seen all the works that are done under the sun; and, behold, all is vanity and vexation of spirit.
