Re: feature request: caching message arrival time
Daniel Kahn Gillmor writes: > So Autocrypt defines the "effective date" of a message as the *earliest* > of two dates: the date that the message is first seen, and the Date: > header itself. So we want our augmented Autocrypt header ingestion > routine to search for all other messages we know about from the sender > that have both a later firstseen= property *and* a later Date: header. Would it be possible to use the earliest date seen in any of the Received: headers as a safeguard against future-dated messages? /Örjan ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-message-mark-replied
David Bremner writes: > In d9800c8 we deleted the function notmuch-message-mark-replied. > > Should we make a deprecated-alias for > notmuch-message-apply-queued-tag-changes? The two functions are not interchangeable, so it may not be appropriate to mark it as an alias. notmuch-message-mark-replied looked for a In-Reply-To: header while notmuch-message-apply-queued-tag-changes checks if the message has notmuch-message-queued-tag-changes set (it is set when composing a reply). On the other hand; if a user has code which explicitly sets the message-send-hook, the new function will serve as the natural replacement for the deleted one. /Örjan ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-message-mark-replied
Örjan Ekeberg writes: > David Bremner writes: >> In d9800c8 we deleted the function notmuch-message-mark-replied. >> >> Should we make a deprecated-alias for >> notmuch-message-apply-queued-tag-changes? > > The two functions are not interchangeable, so it may not be appropriate > to mark it as an alias. [snip] > On the other hand; if a user has code which explicitly sets the > message-send-hook, the new function will serve as the natural > replacement for the deleted one. So maybe just a NEWS snippet to point those users in the right direction? d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] doc: use separate doctrees for distinct builders
David Bremner writes: > It seems our previous attempt with order-only targets was not > sufficient to avoid problems with sphinx-builds doctree cache [0]. > Looking around at other people's approaches [1], using seperate > doctrees was suggested. I guess there might be a slight loss of > efficiency, but it seems more robust. pushed to release (soon to master), with Tomi's spellink fichs ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Release 0.29.
David Bremner writes: > I know there are several things "in progress", but we've also > accumulated a fair amount of change since 0.28. I am planning a feature > freeze for 0.29 on May 31 and (hopefully) a release on June 7. > > d 0.29_rc1 tagged, uploaded to Debian Experimental. All going well, I will release on Friday, so get any last minute NEWS patches in. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: feature request: caching message arrival time
On Mon 2019-06-03 10:57:15 +0200, Örjan Ekeberg wrote: > Daniel Kahn Gillmor writes: > >> So Autocrypt defines the "effective date" of a message as the *earliest* >> of two dates: the date that the message is first seen, and the Date: >> header itself. So we want our augmented Autocrypt header ingestion >> routine to search for all other messages we know about from the sender >> that have both a later firstseen= property *and* a later Date: header. > > Would it be possible to use the earliest date seen in any of the > Received: headers as a safeguard against future-dated messages? Sure, assuming that you trust the closest MTA in the chain of MTAs that handed the message off to you, since an adversarial proximal MTA could manipulate all the existing Received: headers as well. But I'm a bit uncomfortable with it: this sort of protection actually opens up a new attack vector that didn't exist before -- any MTA in the chain can now make the message seem like it was actually from the *past*, just by setting its own Received: header. Technically, of course, any MTA could munge the actual Date: header as well to perform this kind of attack, but that munging would at least have the potential to be detected by anyone who cares to verify DKIM headers; but Received: headers are impossible to cover with DKIM. If there was no expense to the indexing and storage, i'd say it would be good to just go ahead and index the earliest Received: header as well, to have that data trivially available as a data point in evaluating incoming messages. But since it sounds like there's a cost (in performance and storage) that would need to be profiled, i don't know that i can say it's worth the tradeoff. Since notmuch actually knows when it recieved the message, it seems like it would be simplest (and less vulnerable to manipulation) to just record that timestamp directly. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: feature request: caching message arrival time
* Daniel Kahn Gillmor: > Since notmuch actually knows when it recieved the message [...] Not meaning to complicate things, but Notmuch does not receive messages at all. ;-) One needs to rely on some software to populate the Maildir tree (Dovecot LMTP in my case, Postfix or some other MTA for local delivery in other cases). Any software transporting the raw messages can, and sometimes must, manipulate the header data, and the order in which files within the Maildir tree are created is also not determined by Notmuch. As an example: My nightly backup script disables local delivery for the duration of the backup process. Once reactivated, delivery of queued messages resumes, but it is not guaranteed to happen in the order of arrival. So even the local MTA, although trusted, might induce issues in terms of delivery time. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-message-mark-replied
On Mon, Jun 03 2019, David Bremner wrote: > Örjan Ekeberg writes: > >> David Bremner writes: >>> In d9800c8 we deleted the function notmuch-message-mark-replied. >>> >>> Should we make a deprecated-alias for >>> notmuch-message-apply-queued-tag-changes? >> >> The two functions are not interchangeable, so it may not be appropriate >> to mark it as an alias. > [snip] >> On the other hand; if a user has code which explicitly sets the >> message-send-hook, the new function will serve as the natural >> replacement for the deleted one. > > So maybe just a NEWS snippet to point those users in the right > direction? I have the following in my emacs config: '(message-send-hook (quote (notmuch-message-mark-replied notmuch-fcc-header-setup))) I'm wondering what if anything I should replace this with. jamie. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-message-mark-replied
"Rollins, Jameson" writes: > I have the following in my emacs config: > > '(message-send-hook >(quote > (notmuch-message-mark-replied notmuch-fcc-header-setup))) As far as I know it can be deleted. At least both marking as replied and fcc headers work OK for me without it. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-message-mark-replied
"Rollins, Jameson" writes: > I have the following in my emacs config: > > '(message-send-hook >(quote > (notmuch-message-mark-replied notmuch-fcc-header-setup))) > > I'm wondering what if anything I should replace this with. You should probably remove this altogether. notmuch-message-mark-replied used to be the default value for this hook, but has now been replaced by notmuch-message-apply-queued-tag-changes. notmuch-fcc-header-setup is called already when composing a message, so it no longer is needed to call is from the hook. /Örjan ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-message-mark-replied
On Mon, Jun 03 2019, Örjan Ekeberg wrote: > "Rollins, Jameson" writes: >> I have the following in my emacs config: >> >> '(message-send-hook >>(quote >> (notmuch-message-mark-replied notmuch-fcc-header-setup))) >> >> I'm wondering what if anything I should replace this with. > > You should probably remove this altogether. > > notmuch-message-mark-replied used to be the default value for this hook, > but has now been replaced by notmuch-message-apply-queued-tag-changes. > > notmuch-fcc-header-setup is called already when composing a message, so > it no longer is needed to call is from the hook. Great thanks. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: feature request: caching message arrival time
Daniel Kahn Gillmor writes: > Sure, assuming that you trust the closest MTA in the chain of MTAs that > handed the message off to you, since an adversarial proximal MTA could > manipulate all the existing Received: headers as well. > > But I'm a bit uncomfortable with it: this sort of protection actually > opens up a new attack vector that didn't exist before -- any MTA in the > chain can now make the message seem like it was actually from the > *past*, just by setting its own Received: header. As far as I understand the autocrypt protocol (i.e. not much;-) ), the vulnerability is that an incoming message with a later time-stamp than the locally saved autocrypt status can update the stored state (e.g. turn off encryption). Manipulating the time-stamp to make the message appear to be *older* than it really is should only mean that it is less likely to update the saved state? If this is correct, using the oldest of all the time-stamps seen in the Date-header and any of the Received-headers should be the most defensive. /Örjan ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [FEATURE] indexing arbitrary headers
It was <2019-05-30 czw 22:27>, when Daniel Kahn Gillmor wrote: > On Sat 2017-06-03 13:28:46 -0300, David Bremner wrote: >> Łukasz Stelmach writes: >> >>> I'd like to ask for a new feature: indexing of arbitrary headers. Not >>> all headers but a few selected by users. [...] > I just wanted to point out that this specific request has now been added > to notmuch, thanks to David Bremner! It will hopefully be part of the > forthcoming 0.29 release: > > NEWS currently says: > > Add support for indexing user specified headers (e.g. List-Id). See > notmuch-config(1) for details. This requires reindexing after changing > the set of headers to be indexed. Yay! Thanks a lot. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Message Id in search summary
Hi, I use notmuch search myWord for the search and the output seems to be the same as notmuch search --output=summary myWord So output=summary is the default, right? Now (on a user's klick) I would like to show the Message from the saerch result. The Problem is, that there's only the Thread-Id in the summary, not the Mail-Id! Is it possible to get the mail-id in the summary (instead of, or additional to) the thread-id? What's the way to go? Thanks a lot! -- Sent from: http://notmuch.198994.n3.nabble.com/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Message Id in search summary
On Mon, Jun 03 2019, meOme wrote: > I use > notmuch search myWord > for the search and the output seems to be the same as > notmuch search --output=summary myWord > So output=summary is the default, right? > Now (on a user's klick) I would like to show the Message from the saerch > result. > The Problem is, that there's only the Thread-Id in the summary, not the > Mail-Id! > Is it possible to get the mail-id in the summary (instead of, or additional > to) the thread-id? > What's the way to go? Look at: "notmuch search --output=messages ..." It's described in the notmuch-search(1) man page. hth. jamie. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Message Id in search summary
meOme writes: > Is it possible to get the mail-id in the summary (instead of, or additional > to) the thread-id? > What's the way to go? > Thanks a lot! Currently the summary output is not configurable. It would be nice to have some kind of "format string" or equivalent, but so far nobody worked on that. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
