Re: feature request: caching message arrival time

2019-06-04 Thread Daniel Kahn Gillmor
On Mon 2019-06-03 18:02:53 +0200, Örjan Ekeberg wrote: > 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).

Re: feature request: caching message arrival time

2019-06-04 Thread Daniel Kahn Gillmor
On Mon 2019-06-03 16:02:48 +0200, Ralph Seichter wrote: > 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

Re: feature request: caching message arrival time

2019-06-03 Thread Örjan Ekeberg
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

Re: feature request: caching message arrival time

2019-06-03 Thread Ralph Seichter
* 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

Re: feature request: caching message arrival time

2019-06-03 Thread Daniel Kahn Gillmor
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

Re: feature request: caching message arrival time

2019-06-03 Thread Örjan Ekeberg
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

Re: feature request: caching message arrival time

2019-06-01 Thread Daniel Kahn Gillmor
On Sat 2019-06-01 16:19:19 +0200, Ralph Seichter wrote: > I'm interested. Right now I frankly don't know what knowing when a > message was first seen by Notmuch might be useful for. That makes it > a bit difficult for me to contemplate your questions. Sure, thanks for asking! As i went to write

Re: feature request: caching message arrival time

2019-06-01 Thread Ralph Seichter
* Daniel Kahn Gillmor: > I'm working on Autocrypt integration for notmuch right now [...] Woot! :-) > I'm happy to explain more about my use case if people are interested > too. I'm interested. Right now I frankly don't know what knowing when a message was first seen by Notmuch might be useful

Re: feature request: caching message arrival time

2019-06-01 Thread David Bremner
Daniel Kahn Gillmor writes: > * i don't think we have a way to search properties by range (e.g. the >way that we can search date ranges). i don't need that feature for >my use case, but maybe someone will come up with a use case that >wants it? is there a way to store the

feature request: caching message arrival time

2019-06-01 Thread Daniel Kahn Gillmor
Hi Notmuch folks-- I'm working on Autocrypt integration for notmuch right now, and it occurs to me that it might be useful to know the time that any given message was first seen by notmuch. I'm trying to not get distracted by implementing such a feature, but I wanted to log this as a feature