| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently this function takes a list, splits into two lists based on
whether or not a function returns None, sorts the list that isn't None,
and then appends the list of None to the end. This creates 4 new
concrete lists on each method call, requires the use of 3 filter +
lambda pairs, and calls list.sort(). Pretty complicated and inefficient.
This patch replaces that with a single sorted() function call with a kay
function that replaces None with a value that is guaranteed to sort less
than what Message.get_date() will return, but will not cause a
comparison to None (which is an error in Python 3.x). This is all based
on iterators and avoids the need for filter or list concatenation. This
should result in only one new list being created.
|
| |
|
