Especially if one tries to interact with all marked messages there could be
the case that not all headers are fetched yet, hence the messageInfo is still nil.
This segfaults a lot of commands which in principle only need the uid to complete.
If we switch to uids, this issue can be alleviated for those commands.
This command uses the Postpone folder from the account config to save
messages to. Messages are saved as though they were sent so have a valid
'to' recipient address and should be able to be read back in for later
editing.
Due to headers being essentially free text, we constantly run into issues
with parts of the body being interpreted as headers.
Remove the ability to overwrite headers to avoid that, while keeping the ability
to specify headers in the template files.
Fixes#383
This adds the commands pin-tab and unpin-tab. Once pinned a tab lives on
the left of the tabstrip and has a configurable marker, defaulting to `
before its name.
- Add maildir flags to complement a messages imap flags
- Set the "seen" flag on sent messages when using the maildir backend
- Cleanup AppendMessage interface to use models.Flag for both IMAP and
maildir
The functionality was broken since the decoding changes.
This commit also simplifies the code (in my view) to make the application logic
easier to follow.
The docs are updated accordingly (the feature was poorly documented).
As far as I am aware there should be no breaking changes (and is certainly
still in the spec of the prior documentation)
Previously the workers returned a mixture of decoded / encoded parts.
This lead to a whole bunch of issues.
This commit changes the msgviewer and the commands to assume parts to already
be decoded
Hi!
This patch will fix missing filename if it is RFC2231 encoded with charset
different then ASCII or UTF8. Example how it looks like in mail:
Content-Type: application/pdf;
name="=?UTF-8?Q?Opis_przedmiotu_zam=c3=b3wienia_-_za=c5=82=c4=85cznik_nr_1?=
=?UTF-8?Q?=2epdf?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=iso-8859-2''%4F%70%69%73%20%70%72%7A%65%64%6D%69%6F%74%75%20;
filename*1*=%7A%61%6D%F3%77%69%65%6E%69%61%20%2D%20%7A%61%B3%B1%63%7A%6E;
filename*2*=%69%6B%20%6E%72%20%31%2E%70%64%66
Yes, this should be forbidden :-). Anyway, best solotion in such cases
is to failback to Content-Type name. I am not sure if it is guaranted to
be there, but probably it will.
Leszek
Hello guys,
on the hunt for bugs related to wrong encoding. This patch is fixing
reply to non-utf8 messages.
We were using global message headers instead of part specific. In
practice header were often something like:
multipart; boundry=...
where there should be:
text/plain; charset=...
Fixed also missing SubType.
Have great weekend!
Leszek
