On Fri, Feb 19, 2016 at 03:23:15PM +0100, Olaf Hering wrote:
> Its Friday, so I ran it in gdb. The bug is in mutt_decode_base64. After
> the base64 stream ends, a newline comes. Then the '-- ' and the
> remaining msg.
There's a reason all three mail clients got this wrong...
AFAICT, the bug is i
On 2016-02-17 10:02:33 -0800, Kevin J. McCarthy wrote:
> On Tue, Feb 16, 2016 at 03:58:56PM -0800, Kevin J. McCarthy wrote:
> > It looks like the main steps that are skipped by postpone/resumed emails
> > but done for draft files are:
> > 1. user recipient headers. e.g. my_hdr "to/cc/bcc"
> >
On Fri, Feb 19, Olaf Hering wrote:
> How does mutt decode and display base64 parts of a message?
Its Friday, so I ran it in gdb. The bug is in mutt_decode_base64. After
the base64 stream ends, a newline comes. Then the '-- ' and the
remaining msg. Initially each ch yields -1, which should trigger
* Olaf Hering [02-19-16 06:57]:
>
> How does mutt decode and display base64 parts of a message?
>
> My xterm running mutt, and also ThunderBird, shows garbage like this:
>
> ...
> #
> # Regards,
> # NormanN?r??y隊Z)z{.ۚ?맲??r??z?^?ˬz??N?(?֜??^?
> ޭ隊Z)z{.ۚ??0???Ǩ
> #
> ...
>
How does mutt decode and display base64 parts of a message?
My xterm running mutt, and also ThunderBird, shows garbage like this:
...
#
# Regards,
# NormanN?r??y隊Z)z{.ۚ?맲??r??z?^?ˬz??N?(?֜??^?
ޭ隊Z)z{.ۚ??0???Ǩ
#
...
The input looks like this:
# Content-Transfer-Encoding: ba
