| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
176cffcd ("refactor alot.db.utils.remove_cte", 2018-12-04) created a few
problems with 8bit quoted-printable e-mails, see #1291 #1360.
This commit restores the old libmagic fallback which did not cause this
problem.
|
| |
|
|
|
|
|
|
| |
The two main reasons are
- to run `python3 -m unittest discover` without specifying a custom
`--pattern *_test.py`
- to include the test files automatically when generating the MANIFEST
file.
|
| | |
|
| |
|
|
|
|
| |
this is now test_char_vs_cte_mismatch;
It checks if a mime part contains a character which is not encoded in
the encoding declared in the Content-Transfer-Encoding header
|
| |
|
|
|
| |
that tests if a message with unknown content-transfer-encoding header,
but otherwise correct ascii encoded payload, is warned about.
|
| |
|
|
|
| |
It now tests if malformed Content-Transfer-Encoding values are reported
in the logs
|
| | |
|
| |
|
|
|
|
| |
This adds a test for detecting a malformed content-transfer-encoding
(trailing semi-colon).
It also changes the raised exception to the more appropriate ValueError.
|
| |
|
|
| |
This does just call the final bit of code that throws the exception.
|
| |
|
|
|
|
|
|
|
|
| |
notmuch caches the OpenPGP session keys if configured to do so. See
index.decrypt on:
https://notmuchmail.org/manpages/notmuch-config-1/
Using the cached session key decryption of messages can be done without
the need of having the private OpenPGP key. There is some speed up on
decryption, mostly notable on long encrypted threads.
|
| |
|
|
|
| |
Which appears to be capable of doing all the same things, but is in the
stdlib instead of something we hand rolled.
|
| |
|
|
|
|
|
|
|
|
|
| |
In python 3 with the use of Policy objects (other than the Compat32
object which maintains the previous (python 2.x and <=3.2) API) change
the way headers work, and the old Header object is no longer used. This
is rather convenient in that python now implements many of the rules
required for sepcial header types, but it changes the API. This fixes
that by encoding the Header objects to strings.
Fixes #1289
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Python 3.3 added a new feature to the email module, policies
(https://docs.python.org/3.5/library/email.policy.html). Policy objects
allow precise control over how numerous features work when converting to
and from str or bytes. With the `email.policy.SMTP` the behavior of
email_as_bytes and email_as_string can be achieved using the builtin
`.as_string()` and `.as_bytes()` methods, without custom code or the
need to test it. Additionally these methods handle corner cases that we
don't currently handle, such as multi-part messages with different
encodings.
Fixes #1257
|
| |
|
|
|
| |
This adds a new TestCase for the database manager
and adds a test for saving/reading named query strings to the database.
|
| |
|
|
|
|
|
|
|
|
| |
Our message_from_functions decrypt PGP encryped parts in addition to
creating a message object (from bytes or file handles) and recognizing
the encoding in one way or the other.
Rename them before refactoring to make their function clearer and to
distinguish them from the email.message_from_ functions (which do not
decrypt).
|
| |
|
|
| |
They are not needed for python >= 3.0.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I had made the assumption early on that this would get bytes, but when I
added `assert isinstance(header, bytes)` alot would crash on startup,
changing `bytes` to `str` fixed that. I noticed this when trying to fix
the warning generated in the logging call.
|
| | |
|
| |
|
|
|
| |
There are a few that are still broken because of bytes to unicode
conversion, and this may not all be correct, but most of the tests pass
|
| | |
|
| |
|
|
| |
This makes drafts display correctly.
|
| |
|
|
|
|
|
| |
If the message doesn't have a sender, try to come up with one. If the
message has the draft tag we known that the user is the sender, just use
the default account as the from if we can't find one another way. If it
doesn't have the draft tag just set the sending to 'Unknown'.
|
| |
|
|
|
| |
These are just enough to look at the bug that will be fixed in the
patches that follow.
|
| | |
|
| |
|
|
|
|
| |
there are probably still some corners with mailcap handling (parameters
like copiousoutput) that are untested, but this covers a large swath of
the functionality.
|
| | |
|
| |
|
|
|
| |
There are a couple of pieces of this function that aren't covered,
including a bug. yay bugs.
|
| |
|
|
|
|
|
|
| |
Since a multipart/mixed can contain anything that a normal message
could, this should be allowed. The only case that I can think of this
actually happening is if an email server takes the original message,
puts it in a multipart/mixed, and then attaches it's own message, like
on of the annoying "this mail scanned for viruses by <product>".
|
| |
|
|
|
|
|
|
| |
It is possible (and actual mail clients such as kmail do) to embed a
multipart/signed within a multipart/mixed (this is briefly mentioned in
the acknowledgements of RFC 3156, and is perfectly valid according to
RFC 1341, which says that a multipart/mixed is exactly like a top level
message, except that the header may be empty.
|
| |
|
|
|
|
|
| |
It is valid to encapsulate the multipart/signed and multipart/encrypted
payloads in a multipart/mixed payload.
All of these tests currently fail.
|
| |
|
|
|
|
| |
The logic in the comment is faulty. There are perfectly legitimate
reasons to encrypt but not sign a message, some of them are fleshed out
in the previous commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class tests most of the function fairly thoroughly. There are a
couple of error cases that are untested, but could be tested fairly
easily with some mocking.
There is one test marked as expected failure. In this case I disagree
with what alot does, though there probably isn't a canonical correct
behavior. Specifically, if a message is encrypted but unsigned, we
generate a header that says the signature is invalid. This seems
incorrect for a number of reasons. First, since there is no signature,
it cannot be invalid. Second, the reasoning is that it "seems
suspicious" that someone would encrypt but not sign a message. This is
silly, there are plenty of people who encrypt but don't sign their
messages, since signing and encrypting have two totally different
purposes. Signatures verify who *wrote* the message, but encryption
verifies who *reads* the message. People who need some level of
deniability about who wrote the message, but not about who read it (like
a political activist or whistle blower) might encrypt but not sign.
|
| |
|
|
|
|
| |
Currently if a signature name has a non-ascii unicode character in it,
the thread will fail to load because a UnicodeEncodeError. This patch
fixes that by converting the str into unicode.
|
| |
|
|
| |
One of these tests is known to fail, and marked as xfail.
|
| | |
|
| | |
|
| |
|
|
|
| |
These are pretty basic, but they do cover most of the conditions, even
if they rely heavily on mocking.
|
| | |
|
| |
|
|
|
|
|
| |
Instead of manual parsing with regexp and manual string formatting the
functions from email.utils are used. This fixes some small
inconsistencies with addresses with empty realnames and with commas in
realnames.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
