(hi list -- i'm new here; don't be afraid to explain things to me that
seem obvious to you, or correct my vocabulary if i'm using it wrong)
On 11/12/2010 08:11 PM, Carl Worth wrote:
But I suppose it's as simple a matter of creating a new top-level
message term in the database. The split
Thanks for the reply, David!
On 11/13/2010 06:40 AM, David Bremner wrote:
Are both the forward and backward pointers needed?
Technically, only the signs pointer is needed, i guess. I had
included the signedby pointer so that frontends which process the list
linearly know that a signed part
On 11/15/2010 05:23 AM, David Edmondson wrote:
i.e. the existence of the multipart/signed wrapper should be
explicit. In general, all MIME parts should be visible.
thanks, this makes sense to me.
Changing the JSON output in this way would not materially affect your
proposal, I believe.
On 11/15/2010 10:24 AM, servilio wrote:
And xargs -L1 ... will solve the issue in a nicer way. So the above would
be:
notmuch search --output=files tag:deleted | xargs -L1 rm
Assuming none of your mail filenames have newlines or trailing
whitespace, that is.
I'd like to make that kind of
On 11/15/2010 02:58 PM, Carl Worth wrote:
Should we perhaps add a -0 option so that one could actually reliably
handle filenames with newlines in a case like this? Or can we just
assert that such filenames are insane and *should* cause problems?
it's not just newlines. Without using the -L1
On 11/16/2010 08:38 AM, Jameson Rollins wrote:
On Tue, 16 Nov 2010 15:33:30 +0200, Ciprian Dorin, Craciun
ciprian.crac...@gmail.com wrote:
So my question is: is this behaviour (of deleting the file and
creating a new one) deliberate? If not, could it be fixed (I could
provide a patch) to
On 11/20/2010 06:23 AM, Matthieu Lemerre wrote:
On Thu, 18 Nov 2010 13:51:59 -0500, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
Re: Warning when GMime is parsing broken email addresses:
On 11/18/2010 01:37 PM, Matthieu Lemerre wrote:
The problem is solved in version 2.4.18 (current
On 11/24/2010 04:25 PM, Michal Sojka wrote:
(c-cleanup-list . (space-before-funcall))
This line makes my emacs prompt that it may not be safe -- it seems
impolite to ask users just opening up the code within emacs to execute
arbitrary emacs macros.
This sort of decision is what
hey folks--
the signature-verification branch on my git repo [0] contains functional
PGP/MIME signature verification if you supply the --verify argument to
notmuch show --format=json
It relies on gpg being in the path, and on the user having the signer's
key in their gnupg keyring.
The
On 12/21/2010 04:51 AM, Sebastian Spaeth wrote:
So what am I doing wrong, I pulled your branch and compiled/installed,
but I don't see any signature verification in my emacs?
Unless all work is still in the notmuch binary,
yes, the branch as it stands just concerns itself with the notmuch
Hi OpenPGP folks (and Cc'ed notmuch developers/users)--
Some recent discussion about verifying OpenPGP signatures for the
notmuch mail user agent got me thinking about different ways one might
interpret a negative result from a signature made over a message.
Most OpenPGP signatures i've seen use
On 01/28/2011 08:05 PM, Stewart Smith wrote:
I'm about at the point where I'm going to take my git mail store
experiments and get them really to work (and everyone will have to use
'notmuch cat' or the like to access the messages)
Would this hypothetical git-based mail store retain the
On 02/02/2011 08:18 PM, Jameson Rollins wrote:
Hi, all. I have pushed a new branch called crypto to my notmuch
repository [0]. This branch provides full support for PGP/MIME signed
and encrypted messages, including emacs UI support.
I have tested this, and am now using it. I'm very happy
Hi Micah--
just wanted to follow up on your points/questions:
On 02/03/2011 11:25 AM, micah anderson wrote:
1. I personally think notmuch-show-process-pgpmime should default to
true
note that with it set to false, you can still M-RET (instead of RET) on
an item in the summary window to have
On 02/03/2011 03:34 PM, Jameson Rollins wrote:
On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
You either want to fix this in your emacs config by putting your
fingerprint into mml2015-signers and setting mml2015-encrypt-to-self
Or you want to set gpg's
On 02/04/2011 11:59 AM, micah anderson wrote:
On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
when you say encrypted by do you mean encrypted to? do you have
access to the corresponding secret key?
If I open a message that was sent to me
i tried running
emacs -Q -f notmuch
and replying to a message.
Since i didn't have my emacs config, it wanted to create the default
sent folder in ~/mail/sent
if i told it no, don't create it when prompted (during the setup of
the reply message) then the body of the replied-to message doesn't
On 02/09/2011 01:02 PM, Jameson Rollins wrote:
On Wed, 9 Feb 2011 10:28:17 +0100, Sebastien Binet bi...@cern.ch wrote:
is there a way to modify this in the notmuch emacs interface so that
threads are ordered according to the *latest* message in a thread
instead ?
[...]
There is a variable
On 02/22/2011 02:42 PM, Albin Stjerna wrote:
On Tue, 22 Feb 2011 13:33:56 -0500, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
i think the correct solution would have nothing to do with text/html vs
text/plain, but would have to do with whether the message is
multipart/mixed or multipart
On 05/08/2011 09:03 PM, Jameson Graef Rollins wrote:
Hi, folks. I've pushed some more patches to the release-candidate/0.6
branch [0] (which should now be at commit id
89ca01b6104dd732903104e50777a7b4a211e1f4):
* support for decryption of parts with notmuch show --format=part
* emacs
On 05/09/2011 09:00 PM, Sebastian Spaeth wrote:
On Mon, 09 May 2011 09:20:41 -0300, David Bremner da...@tethera.net wrote:
On Mon, 9 May 2011 09:06:34 +0200, Anton Khirnov an...@khirnov.net wrote:
Now None is returned when those don't exist, which is inconvenient to
deal with.
I'm not using
---
notmuch-search.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/notmuch-search.c b/notmuch-search.c
index 794b145..26b24eb 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -116,6 +116,9 @@ sanitize_string (const void *ctx, const char *str)
{
char *out,
On 05/15/2011 01:23 AM, mu...@nawaz.org wrote:
1. How do I see *all* the headers using the emacs interface? It shows me
only 4 headers.
shift-v from within a notmuch-show buffer will show the entire source
of the message, including all headers.
i don't know the answers to your other questions,
On 05/16/2011 04:42 PM, Carl Worth wrote:
Meanwhile, I still can't tell exactly what the behavioral change
intended is. The commit message talks about fully recursing
and match[ing] the MIME structure of the message. Was it not
fully recursing before? In what way did
On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote:
So a message like this:
A└┬╴multipart/signed 355339 bytes
B ├┬╴multipart/mixed 353462 bytes
C │├╴text/plain 235 bytes
D │└╴image/jpeg attachment [foo.jpg] 352752 bytes
E └╴application/pgp-signature attachment [signature.asc] 1030 bytes
On 05/16/2011 05:20 PM, Carl Worth wrote:
Interestingly, this is not quite the behavior I get (with commit
373f352). With --format=text I'm now seeing:
2) C
3) D
4) E
--format=text should only show the parts that are readable in text.
the ultimate goal is to get the part numbers aligned
On 05/23/2011 01:25 PM, Matthias Guedemann wrote:
Hi all,
I found some problems with the multipart/mixed behavior of current
master. I have several multipart mails where the html part is not
displayed and a text/plain attachment is wrongly reported as text/html.
I have no real insight
On 05/26/2011 06:04 PM, Carl Worth wrote:
2. The hello screen is now lying a bit by saying all tags.
Perhaps if the user has the notmuch-hello-hide-tags variable set to
non-nil the text might change somewhat? I'm not sure to what exactly.
maybe all non-hidden tags ?
--dkg
On Fri, 27 May 2011 03:27:35 -0700, Jameson Graef Rollins
jroll...@finestructure.net wrote:
Ok. So I very much hope this patch series satisfies those who were
bothered by the part renumbering that was happening when PGP/MIME
parts were processed. For signed messages we no longer modify the
i'm CC'ing the upstream lead developer of gmime here to see if he has
any thoughts (and can correct any misrepresentations from me) -- Hi Jeffrey!
On 05/30/2011 02:43 PM, Jameson Graef Rollins wrote:
On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel hohn...@infradead.org
wrote:
CC -O2
I got the following response off-list from the gmime lead, which he's ok
with my re-posting here:
On 06/02/2011 08:53 AM, Jeffrey Stedfast wrote:
I don't know why Fedora 15 ships 2.5.x, that seems like a really silly
thing to do. I think I recall the Balsa guys bringing this up in the
past and
The notmuch binary is not in the business of doing interactive
prompting with the user. If credentials are needed for decryption,
they should be supplied to the decrypting processes some other way
(e.g. gpg-agent).
Previously, we returned a NULL function pointer for the
request_passwd()
On 06/03/2011 07:15 PM, Carl Worth wrote:
On Fri, 3 Jun 2011 19:03:08 -0400, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
The notmuch binary is not in the business of doing interactive
prompting with the user. If credentials are needed for decryption,
they should be supplied
Our use of GMimeSession was unneeded boilerplate, and we weren't doing
anything with it. This simplifies and clarifies that assumption.
If we want to do anything fancier later, the examples in the gmime
source are a reasonable source to work from in defining a new
GMimeSession derivative.
Since
This patch supercedes my patch from
1307142188-6551-1-git-send-email-...@fifthhorseman.net , and provides
what appears to be a much cleaner approach to achieve the same result.
--dkg
___
notmuch mailing list
notmuch@notmuchmail.org
On 06/21/2011 09:08 PM, da...@tethera.net wrote:
Here is my proposal, based on Clint's suggestion on IRC, and on the
sed hack from librhash, to hide all symbols that are not explicitly
part of the notmuch API. In particular it hides the various symbols
related to Xapian exceptions.
I like
On 06/27/2011 04:43 PM, Austin Clements wrote:
Just to clarify my understanding, --format=raw is only intended to
work on either the whole message (special-cased in do_show_single) or
a leaf MIME part, and in any other case, it will output nothing? The
raw output test cases seem pretty thin.
On 06/27/2011 06:07 PM, Austin Clements wrote:
Oh, right, of course. show_message_part will walk into the parts, so
format_part_content_raw will still be called on the leafs of a
requested multipart. Though, this approach results in each leaf being
transfer decoded and printed individually,
On 07/10/2011 08:53 AM, David Bremner wrote:
| The underlying issue is that the libnotmuch interface is not
| entirely captured by the set of exported symbols. In particular the
| query syntax can change without being visible to the linker at all.
This suggests to me that we may need to be
On 07/10/2011 10:36 PM, David Bremner wrote:
This suggests to me that we may need to be bumping the SONAME when the
query string format changes, no?
If we follow the same rules as with symbols, then only when it breaks
backwards compatability.
Right, but what breaks backwards compatibility
On 08/03/2011 06:01 AM, moabi2000 wrote:
1) How does notmuch detect the presence of attachments? I have some
messages that have attachments (which I can see and open when reading
the message), but for which the 'attachment' flag is not set (and
therefore don't show up in a search like
On 08/30/2011 02:22 AM, Jason Woofenden wrote:
[...]
[textconverters]
application/pdf=pdf2txt /dev/stdin
Sounds awesome. I'd love the feature, and this sounds like a good
way to do it. Or maybe we should use a mailcap file like mutt
does... it has some useful features like nametemplate
On 08/30/2011 06:03 PM, Jameson Graef Rollins wrote:
And we need something like:
jpg2thousandwords
heh.
Yes, i suspect there will be some mime types we will be unable to index
in detail with xapian in the foreseeable future. Even without that,
though, there's the possibility to store
On 10/24/2011 07:53 AM, Petter Reinholdtsen wrote:
The notmuch email frontend have a problem parsing email headers.
The problem is headers like this
From: =?iso-8859-1?q?=D8yvind_Normann?= oyvind.nor...@uio.no
which my mailbox got a lot of. The frontend show the address as
On 12/23/2011 11:40 AM, Dan Bryant wrote:
On Wed, 21 Dec 2011 06:51:01 -0500, Darren McGuicken
mailing-notm...@fernseed.info wrote:
When you make those changes to the gpg_context are you breaking gpg
signature validation? Or is the one a superset of the other?
The current assumption in
On 12/23/2011 10:45 PM, Austin Clements wrote:
Quoth Dmitry Kurochkin on Dec 10 at 3:25 am:
+ /* For some reason the GMimeSignatureValidity returned
+* here is not a const (inconsistent with that
+* returned by
+*
On 01/25/2012 12:45 PM, Jameson Graef Rollins wrote:
Here's a behavior that I think would be reasonable:
* notmuch reply outputs JSON encrypted flag
* emacs does a quick check to see if the needed key is available
* if key not available: give a nice mini-buffer prompt, something like:
hey notmuch folks--
those of you who run debian might be interested in the gmime2.6
packaging which i cobbled together for debian from the existing gmime2.4
packaging:
http://bugs.debian.org/657426
Those of you developing notmuch with the gmime 2.6 patchsets might be
interested in trying it
libgmime-2.6-dev entered debian unstable today. If 2.6 is available,
notmuch should build against 2.6 instead of 2.4, as 2.6 is the current
upstream stable version of libgmime.
---
debian/control |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/debian/control
On 02/10/2012 08:15 AM, David Bremner wrote:
I'm not necessarily opposed to migrating to the Debian packages to gmime
2.6, but I'd like to point out that your patch is might be more decisive
than intended, since the build daemons strip all but the first
dependency. This will cause the build do
On 02/10/2012 03:57 PM, Tomi Ollila wrote:
For the time being, should the order be:
- libgmime-2.4-dev,
+ libgmime-2.4-dev | libgmime-2.6-dev,
2.6 is available and functional in unstable. I think we should prefer 2.6.
This will enable (and encourage) us to approach S/MIME support too
On 02/16/2012 02:51 PM, Philippe LeCavalier wrote:
$ ~/notmuch/notmuch_addresses/notmuch_addresses.py
Traceback (most recent call last):
File /home/plecavalier/notmuch/notmuch_addresses/notmuch_addresses.py,
line 19, in module
import notmuch
ImportError: No module named notmuch
On 02/21/2012 11:49 AM, Tomi Ollila wrote:
I'm in favor of gmime = 2.6.5 requirement.
I tend to agree with Tomi here. I'm going to work on getting gmime
2.6.5 into debian later today.
--dkg
___
notmuch mailing list
notmuch@notmuchmail.org
On Tue, 21 Feb 2012 14:45:06 -0500, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
On 02/21/2012 11:49 AM, Tomi Ollila wrote:
I'm in favor of gmime = 2.6.5 requirement.
I tend to agree with Tomi here. I'm going to work on getting gmime
2.6.5 into debian later today.
gmime 2.6.6 is now
notmuch currently treats all messages with the same Message-ID as
the same message. I think this could be a vulnerability :(
If two messages have the same Message-ID, is there a guarantee of which
of these messages will be produced during a notmuch show?
Either way, it seems to create a
On 03/08/2012 12:04 PM, James Vasile wrote:
On Thu, 08 Mar 2012 11:37:09 -0500, Daniel Kahn Gillmord...@fifthhorseman.net
wrote:
Any ideas on how to approach this?
Treat messages with the same ID but different hashes as different?
Given that a message hash would include all headers,
On Tue, 06 Mar 2012 18:04:50 -0400, David Bremner da...@tethera.net wrote:
There seems to be something weird going on with gmime-2.6; maybe we
didn't catch some api change?
This does seem to be a regression in gmime 2.6. I've reported the bug
upstream, along with a simplified (non-notmuch)
On 03/08/2012 04:32 PM, Jameson Graef Rollins wrote:
I actually agree with this position. mbox files are not proper email
messages, so if gmime does not explicitly support parsing them then we
really can't expect it to parse them.
i think the point here is that gmime used to support parsing
On 03/14/2012 05:45 PM, Gregor Zattler wrote:
Hi David, notmuch developers,
* David Bremnerda...@tethera.net [10. Mar. 2012]:
We had a somewhat lively debate about desirablity of the following
patch. My decision is that for now, we avoid changing the behaviour of
notmuch, and do apply the
On 03/26/2012 11:21 AM, Jameson Graef Rollins wrote:
Does it make sense for the cli to canonicalize the content types to
always be lower case? Or should it continue to just pass the content
type exactly as it appears in the original message? Given that
consumers should parse it case
On 04/11/2012 12:58 PM, Olivier Berger wrote:
Dunno what happens. Anyone else ?
Are you running gpg-agent?
what do you get if you do:
gpg-connect-agent /bye
(please include the return code)?
if you are running on a debian or debian-derived system, do you have the
gnupg-agent package
On 04/11/2012 05:02 PM, Olivier Berger wrote:
So : if I launch emacs (23) from bash running in gnome-terminal in my gnome
(fallback) session, decryption works.
If I use Alt+F2 to trigger gnome's launcher, and type emacs, then
decryption won't work :-/
Both emacses run in X, but they don't
On 04/25/2012 08:31 AM, David Bremner wrote:
I'd like to have a feature freeze for 0.13 sometime in the first week of
May. What do people feel are priorities to try to get reviewed and
pushed for 0.13?
I'd love it if Someone™ would get S/MIME implemented, tested, and
reviewed, but it
On 05/17/2012 12:45 PM, Jameson Graef Rollins wrote:
I want them explicitly set for clarity, as well as safety. Code is
meant to be read by humans, not computers.
I sympathize with this sentiment.
It's much safer to explicitly set them to what you want
them to be rather than just assume
On 05/18/2012 04:20 AM, Jani Nikula wrote:
We have -Wextra, which enables -Wmissing-field-initializers, which
requires us to use full initialization of struct fields when doing
regular, non-designated initialization. The point is that you might
introduce subtle bugs if you added new struct
On 08/01/2012 12:26 PM, Andrei POPESCU wrote:
I'm at least one user that cares enough about the distinction to have
all list mails received via a different address, just to avoid Gmail's
feature of silently dropping my own messages received via a list.
IMVHO it should at least be
On 12/07/2012 07:19 AM, David Bremner wrote:
For specifying one-ended ranges, I find the current syntax OK-ish. It
would be reasonable to formulate a seperate TODO for supporting
things like date:2012-12-07
Out of curiosity, how does this syntax interact with timezones?
If i send a mail in
On 02/28/2013 04:10 PM, Jameson Graef Rollins wrote:
I think this point makes sense. I guess my main worry was that querying
the agent would have unintended consequences for someone who is not
expecting it or specifically does not want it to be queried. But maybe
the point is that if they
hi notmuch folks--
i'd like to be able to forward several messages from a given thread (up
to and including the whole thread) to someone else. I use
notmuch-emacs.
I don't think it's possible to do this at the moment;
notmuch-show-forward-message just forwards the message where the point
is
On 04/25/2013 02:12 AM, Jeremy Nickurak wrote:
Sigh. Premature posting...
Adam Wolfe Gordon on here gave me a tip for this. It's not perfect, but it
works:
Start forwarding each of the emails, and just cut-and-paste the
#mml../#mml sections out of the buffers into a new email. That'll
On 05/20/2013 11:59 AM, da...@tethera.net wrote:
From: David Bremner brem...@debian.org
I find this script pretty useful when figuring out who to blame for
MIME rendering problems. It currently isn't very widely known, so it
seems worth distributing with notmuch.
I'm happy to have this
On 05/23/2013 07:13 AM, David Bremner wrote:
OK, I've pushed the script with that line removed. Thanks for the
contribution,
great, thanks! I've removed my earlier git repo. the notmuch git repo
is now the canonical location.
--dkg
signature.asc
Description: OpenPGP digital
Hi Niel--
On 07/07/2013 07:14 AM, Neil Roberts wrote:
I've recently started using notmuch to try and read PGP-encrypted
email. However the trouble is I normally access my email remotely via
SSH and it's very difficult to get gpg-agent to work in those
circumstances. I've therefore made some
On 07/19/2013 08:10 AM, David Bremner wrote:
The attached message is edited from one I managed to convince notmuch-emacs to
send via some mishap with gpg-agent. It has an empty signature
part. Clearly this is wrong, but on the other hand, it should not cause
notmuch show --decrypt to
in testing out notmuch on a new user account, i just noticed that
bringing up notmuch mode in emacs chokes with an unhelpful error for
users who have never run notmuch setup. it seems like there ought to
be a way for the emacs mode to detect this error state and prompt the
user to walk through
Hi Simon--
On 09/04/2013 06:01 PM, Simon Hirscher wrote:
This is now the second time the following has happened to me:
[ decryption failure until adding sender's key]
Also, I should add that manually decrypting the message with gpg (i.e.
without using notmuch) already worked *before* I
On 09/10/2013 02:51 PM, Jani Nikula wrote:
As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]:
Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init()
*should* solve the decoding problem mentioned in the thread. This
flag should be safe to pass into g_mime_init()
On 09/10/2013 06:35 PM, Austin Clements wrote:
I haven't looked at exactly what workarounds this enables, but if it's
what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text
tokens), are there really subject lines that this will misinterpret
that weren't obviously crafted to break
On 09/23/2013 07:23 PM, Simon Hirscher wrote:
Now, in order for you to test that behavior I'm going to send you a
signed and encrypted message because that should exactly reproduce the
bug, as long as you don't import my key (id EBACABE5 /
http://simonhirscher.de/public_key.asc) for signature
On Tue, 23 Jul 2013, Franz Fellner alpine.art...@gmail.com wrote:
Thomas Lübking as one of the KWin devs comes in replies as
=?UTF-8?Q?Thomas=20L=C3=BCbking=20?=thomas.luebk...@gmail.com
if the above string is what bugzilla is emitting exactly (look at the
source of the message to be sure) then
Hi notmuch folks--
On oss-security recently, there was a discussion about recursive
compression and the ability to create infinite loops.
id:20131010013106.ga29...@openwall.com
After some discussion with amdragon on IRC, i believe that this is only
relevant to notmuch when actively decrypting
On 11/02/2013 09:08 AM, Felipe Contreras wrote:
Either way this doesn't make any sense to me. Each thread has a single origin
mail, why would anybody would like to show a message other than that while
displaying the summary of the tread? Even more, why isn't there an option to
fetch that
On 11/10/2013 11:21 AM, David Bremner wrote:
Although Jeffrey Stedfast fixed gmime bug 711305 amazingly quickly, it
looks like many people still have to live with a buggy version of
gmime for a while yet. Here is an opt-in fix that stops the test suite
from failing; this is a simple fix for
On 11/18/2013 05:17 AM, Ruben Pollan wrote:
If I have t[w]o identities, with two different gpg keys (key1 and key2), and
I set
'encrypt-to key1' when I send emails with my identity of key2 it will also
encrypt it with my key1 and will reveal to its receivers that I own key1.
Isn't
it?
i notice that in the current master, debian/notmuch-emacs.README.Debian
contains the following stanza:
* This package currently works only with emacs 23. Users of
pre-release snapshots of emacs 24 can expect problems.
I'm using notmuch (and notmuch-emacs) 0.16 with
On Tue 2013-08-20 13:03:27 -0400, Daniel Kahn Gillmor wrote:
I've been meaning to write this up more cleanly, but a summary here will
have to do for now:
The MIME Content-Type header for an inline-PGP-signed e-mail message is
not signed. This means that an attacker can replay a signed
Hi Baptiste--
On 03/03/2014 12:29 PM, Baptiste wrote:
I made a little |Emacs| advice for
|notmuch-show-insert-part-multipart/signed|
to deal with mails signed with /SMIME/ mechanism. It calls /openssl/ to
create
missing :sigstatus.
Here it is :
Hi Baptiste--
On 03/14/2014 06:58 AM, Baptiste wrote:
firstly, sorry for my previous mail, you are right, it was broken. This one
should be better.
i didn't mean to imply it was broken at all. i haven't tested it :)
Truly, it would be better to implement it directly in notmuch core.
i
On 03/14/2014 02:08 PM, David Bremner wrote:
Daniel Kahn Gillmor d...@fifthhorseman.net writes:
I agree that S/MIME support would be nice; i think implementing it in
the notmuch core is the way to go. fwiw, gmime already has a
cryptocontext that is supposed to handle S/MIME; it just needs
On 04/06/2014 05:15 AM, Guyzmo wrote:
I indeed agree with this view, and I think the best process would be
to have the MUA decrypt and index an encrypted mail when the user wants
it to be indexed. So the user do not get really highly secret messages
disclosable by the index, and for the
On 05/09/2014 11:19 AM, Wael M. Nasreddine wrote:
---
.travis.yml | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 .travis.yml
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..8d92cdc
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,10 @@
On 06/12/2014 09:46 AM, Daniel Patterson wrote:
Frequently I want to see more headers than just the couple default. For
example, I'd like to look at the various spam headers that are added
(with scores, etc). Most email clients I've ever used have some way of
viewing the original message - is
On 07/21/2014 09:03 PM, Jameson Graef Rollins wrote:
On Mon, Jul 21 2014, David Bremner da...@tethera.net wrote:
notmuch folks: it seems that in vagrant's message, and several others I
checked, it notmuch-crypto-process-mime==nil, then no signature button
is created at all.
Yes, this is
On 07/22/2014 12:30 AM, Daniel Kahn Gillmor wrote:
On 07/21/2014 09:03 PM, Jameson Graef Rollins wrote:
On Mon, Jul 21 2014, David Bremner da...@tethera.net wrote:
notmuch folks: it seems that in vagrant's message, and several others I
checked, it notmuch-crypto-process-mime==nil
On 08/30/2014 03:37 AM, Jani Nikula wrote:
I'm inclined to think this is a bug in message-mode.
I agree it's a bug in message-mode, not in notmuch itself.
As a workaround of sorts, I'd suggest not messing with the #secure tag
manually. Instead, you can use mml-secure-message-sign and
hi folks--
sorry to not have a clearer debugging statement right no (ENOTIME to
generate something nice) but i think notmuch-emacs was failing to render
a thread for me when one of the messages involved was either signed with
or encrypted using an algorithm that gpg didn't know about.
I ran into
On 12/04/2014 04:38 PM, Danny O'Brien wrote:
I use notmuch with a set of Maildirs, synchronised with a remote IMAP
instance using mbsync. One of the folders I sync with is a missed spam
directory, which is used by the remote server to correct its own anti-spam
system. The server deletes the
On Fri 2015-01-23 02:21:41 -0500, David Edmondson wrote:
Whilst I think that having this knob is a good thing, I don't think that
it's a solution to the 'text/html renderers access the network'
problem. I can't sensibly (and don't wish to) disable the display of
text/html parts by default
On Thu 2015-01-15 05:20:47 -0500, David Bremner wrote:
It seems no very recent system has gmime2.4. I guess several of these
gmime2.4 only code paths are both security critical (e.g. in crypto.c)
and mostly untested.
Is there good reason to keep supporting gmime 2.4?
gmime 2.6 is available
On Wed 2015-01-21 16:14:07 -0500, Austin Clements wrote:
I have a fix for this on shr buried deep in an old patch series that I
never got back to: id:1398105468-14317-12-git-send-email-amdra...@mit.edu
For shr, the key is to set shr-blocked-images to ..
I've just done this, but it doesn't
1 - 100 of 1501 matches
Mail list logo
