| Commit message (Collapse) | Author | Age |
|\
| |
| | |
py3k small fixes
|
| |
| |
| |
| |
| |
| | |
Implementing the comparison functions as a shared method rather than in
terms of each other (as functools.totalordering does) makes the
search interface much snappier.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Which is required in python3 when implementing the __eq__ method.
The implementation caches the hash method, since it's being called each
time the focus is changed in the search view. This doesn't really seem
correct to me, but I'm not sure it's wrong.
|
| |
| |
| |
| | |
Which is where python3 puts it's cached byte compiled objects
|
| |
| |
| |
| |
| | |
This wasn't caught by static checkers since it is used in the other
brach of the if statement containing this value.
|
| |
| |
| |
| |
| |
| |
| |
| | |
In python3 StringIO and cStringIO are gone. In their place are
io.BytesIO and io.StringIO. They are somewhat different in that they are
not separated on implementation, but on the type they emulated. BytesIO
works like the bytes class (str in python 2), while StringIO works like
the str class (unicode in python2).
|
| |
| |
| |
| |
| |
| | |
In python3 Exception doesn't have a message attribute, the only way to
get the string output is to call str() on the Exception. This also works
in python 2.7, so go ahead and make that change.
|
|\ \
| | |
| | | |
mark old options for encrypt_by_default as deprecated
|
| |/
| |
| |
| | |
Mark all values for [account]encrypt_by_default as deprecated
|
|\ \
| | |
| | | |
Simplify for loop and string building
|
| | | |
|
| | | |
|
|/ / |
|
|\ \
| | |
| | | |
polish the docs
|
| | | |
|
|/ / |
|
|\ \
| |/
|/| |
Add Github specific files
|
| | |
|
| |
| |
| |
| | |
Which explains better how to get involved
|
|/ |
|
|\
| |
| | |
Load default settings even if a user config doesn't exist
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is necessary even if the config file is None to ensure that the
spec file is loaded
Also mock out the setting.const module in the docs, otherwise they'll
fail to generate.
Fixes #1094
|
| |
| |
| |
| | |
Which fail, per #1094
|
| |
| |
| |
| |
| | |
SettingsManager sets it's _config attribute to the exact same value
twice in the constructor. This is wrong.
|
|\ \
| | |
| | | |
Fix issue with account selection
|
| | |
| | |
| | |
| | |
| | | |
This decorates test methods that internally call a `cmd.apply()`,
which represents asynchronous code that returns a `twisted.deferred`.
|
| | |
| | |
| | |
| | |
| | |
| | | |
instead of assuming that it already receives a string. The new
behaviour is in sync with the type documented for the superclass
`Account`.
|
| | |
| | |
| | |
| | |
| | | |
These test only check if get_account_by_address is called correctly.
All other parts of `apply()` are left out.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
This instantiates an actual Envelope object instead of a Mock object
for use in the tests for envelope commands. The tests then do not fail
when they hit implicit getters of the form envelope['From'].
|
| | |
| | |
| | |
| | |
| | | |
.. as read from the From-header directly, potentially including realname
parts.
|
| |/
| |
| |
| |
| | |
This allows to simply pass the content of a messages' From-header value
when determining an account to send/save/encrypt from.
|
|\ \
| | |
| | | |
Handle gpg signed and encrypted mail inside a multipart/mixed block
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | | |
This function is always passed a key to sign with, and not passing one
leads to the first available signing key in the keyring being selected
otherwise, which is problematic if one has two signing keys.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a missed difference between pygpgme and gpg, gpg signs by
default when encrypting with an attached signature. Since this isn't
being toggled it's bad, it's a kind of information leak, and increases
the size of the mail for no reason.
NOTE: This is the kind of signature proposed by RFC 2440, which we're
missing tests for.
|
|\ \ \
| | | |
| | | | |
Add another classifier to setup.py
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The full list of classifiers can be found at
https://pypi.python.org/pypi?:action=list_classifiers.
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
setup.py cleanups
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This field instructs tools like pip and setup tools about which versions
of python you support. In alot's case that is currently 2.7.x
Fixes #1118
|
| | | |
| | | |
| | | |
| | | |
| | | | |
These are advisory, and I've picked the ones that seem like they fit
best. We can bikeshed them to death though ;)
|
| | |/
| |/|
| | |
| | | |
This normalizes the indent of the file to be much more readable.
|
|\ \ \
| |_|/
|/| | |
document SIGINT handling
|
|/ /
| |
| |
| |
| | |
This adds documentation for SIGINT signals to the html and man pages,
and removes a "this is useful for.." comment on SIGUSR1.
|
|\ \
| |/
|/| |
alot: replace email.Utils with email.utils
|