On 08Jul2012 16:16, Jack M <j...@forallx.net> wrote:
| > I know nothing about the details of quoted printable (apart from
| > what I've just read on wikipedia). Certainly, that message isn't
| > latin1, it's UTF-8. I suspect that the key is to find out *why*
| > that message has been sent as quoted printable latin1.
Well, let's be precise. The byte content was an UTF-8 byte stream. The
QPer is correctly encoding stuff, but incorrectly _labelling_ the
encoding as latin1.
| > Certainly,
| > your post here is text/plain utf-8 and reads fine.
|
| Yes, this is the other half of the mystery. Now I need a list of possible
| suspects for who is the mystery QP-er. I don't know enough about how mail
| works to make a complete list, but surely mutt itself and my SMTP server are
| possible suspects?
|
| >From the manual, as far as I can tell, the only way mutt would QP-encode my
| message for me would be if I have $encode_from set, which I do not.
|
| Is QP-encoding something that SMTP servers might ever do? I'm totally in the
| dark on this.
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. Untested example:
#!/bin/sh
tee -a $HOME/mutt.sendmail.output.log | /usr/sbin/sendmail ${1+"$@"}
Adjust the sendmail path to suit, etc.
That should get you the raw bytes that mutt in sending out. Then we will
at least know if it is mutt or a mail system, and exactly what mutt is
saying about the content.
I believe (could well be wrong) mail systems are permitted to rewrite bodies;
QP is perfeclty undoable and should be safe if done correctly.
If you keep a copy of your sent email ($record) it would be interesting
to look at that, too.
Cheers,
--
Cameron Simpson <c...@zip.com.au>
This disk pack is sold by volume, not by wait. Crammed full by modern
automatic computer equipment, it causes full net wait timeouts. If device
does not appear full when opened, it is because file contents have been
lost during transfering.
