<feed xmlns='http://www.w3.org/2005/Atom'>
<title>notmuch/gmime-filter-headers.c, branch 0.22</title>
<subtitle>thread-based email index, search, and tagging</subtitle>
<id>https://git.notmuchmail.org/git/notmuch/atom?h=0.22</id>
<link rel='self' href='https://git.notmuchmail.org/git/notmuch/atom?h=0.22'/>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/'/>
<updated>2013-08-17T07:06:08Z</updated>
<entry>
<title>reply: Use RFC 2822/MIME wholly for text format template</title>
<updated>2013-08-17T07:06:08Z</updated>
<author>
<name>Austin Clements</name>
<email>amdragon@MIT.EDU</email>
</author>
<published>2013-08-16T15:35:43Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=dc51bf0ad4ce84414e79d2f30752502f7c0d46c0'/>
<id>urn:sha1:dc51bf0ad4ce84414e79d2f30752502f7c0d46c0</id>
<content type='text'>
Previously, reply's default text format used an odd mix of RFC 2045
MIME encoding for the reply template's body and some made-up RFC
2822-like UTF-8 format for the headers.  The intent was to present the
headers to the user in a nice, un-encoded format, but this assumed
that whatever ultimately sent the email would RFC 2047-encode the
headers, while at the same time the body was already RFC 2045 encoded,
so it assumed that whatever sent the email would *not* re-encode the
body.

This can be fixed by either producing a fully decoded UTF-8 reply
template, or a fully encoded MIME-compliant RFC 2822 message.  This
patch does the latter because it is

a) Well-defined by RFC 2822 and MIME (while any UTF-8 format would be
   ad hoc).

b) Ready to be piped to sendmail.  The point of the text format is to
   be minimal, so a user should be able to pop up the template in
   whatever editor they want, edit it, and push it to sendmail.

c) Consistent with frontend capabilities.  If a frontend has the
   smarts to RFC 2047 encode the headers before sending the mail, it
   probably has the smarts to RFC 2047 decode them before presenting
   the template to a user for editing.

Also, as far as I know, nothing automated consumes the reply text
format, so changing this should not cause serious problems.  (And if
anything does still consume this format, it probably gets these
encoding issues wrong anyway.)
</content>
</entry>
<entry>
<title>notmuch: Fix off-by-one errors if a header is &gt;200 characters long.</title>
<updated>2010-06-01T23:09:29Z</updated>
<author>
<name>David Edmondson</name>
<email>dme@dme.org</email>
</author>
<published>2010-04-28T10:45:41Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=1671eaecdb69133bc88fd212c77b68122fa27600'/>
<id>urn:sha1:1671eaecdb69133bc88fd212c77b68122fa27600</id>
<content type='text'>
If a single header is more than 200 characters long a set of 'off by
one' errors cause memory corruption.

When allocating memory with:
     a = malloc (len);
the last usable byte of the memory is 'a + len - 1' rather than 'a +
len'.

Fix the same bug when calculating the current offset should the buffer
used for collecting the output header need to be reallocated.
</content>
</entry>
<entry>
<title>Decode headers in reply</title>
<updated>2010-04-13T16:23:54Z</updated>
<author>
<name>Michal Sojka</name>
<email>sojkam1@fel.cvut.cz</email>
</author>
<published>2010-03-03T07:50:56Z</published>
<link rel='alternate' type='text/html' href='https://git.notmuchmail.org/git/notmuch/commit/?id=452fbedcd5db101378b01c957a7f0574eb708afc'/>
<id>urn:sha1:452fbedcd5db101378b01c957a7f0574eb708afc</id>
<content type='text'>
When headers contain non-ASCII characters, they are encoded according
to rfc2047. Nomtuch reply command emits the headers in the encoded
form, which makes them hard to read by humans who compose the reply.

For example instead of "Subject: Re: Rozlučka" one currently sees
"Subject: Re: =?iso-8859-2?q?Rozlu=E8ka?=".

This patch adds a new GMime filter which is used to decode headers to
UTF-8 and uses this filter when notmuch reply outputs headers.

Signed-off-by: Michal Sojka &lt;sojkam1@fel.cvut.cz&gt;
</content>
</entry>
</feed>
