[PATCH] emacs: cleanup commented archive services
MarkMail and Nabble both support https. I can no longer get any DNS
resolution for opensubscriber.com.
Signed-off-by: Daniel Kahn Gillmor
---
emacs/notmuch-show.el | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index e13ca3d7..cf759918 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -188,9 +188,8 @@ each attachment handler is logged in buffers with names
beginning
("Mail Archive, The" . "https://mid.mail-archive.com/;)
("LKML" . "https://lkml.kernel.org/r/;)
;; FIXME: can these services be searched by `Message-Id' ?
-;; ("MarkMail" . "http://markmail.org/;)
-;; ("Nabble" . "http://nabble.com/;)
-;; ("opensubscriber" . "http://opensubscriber.com/;)
+;; ("MarkMail" . "https://markmail.org/;)
+;; ("Nabble" . "https://nabble.com/;)
)
"List of Mailing List Archives to use when stashing links.
--
2.20.1
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: feature request: caching message arrival time
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 this down, it became a lot longer than i'd expected.
sorry about that! On the positive side, i may have convinced myself in
the process that the threat this mechanism would defend against is small
enough that it may not be worth the additional implementation (though if
the implementation were there, we'd certainly want to use it).
So, this is a story about Autocrypt state, out-of-order delivery, and
e-mails with suspicious date stamps ("from the future"). (if you're
reading this message haven't been following Autocrypt closely, you can
read up at https://www.autocrypt.org/)
--
When receiving an e-mail sent From: the peer f...@example.org, an
Autocrypt-capable client needs to update the Autocrypt state for that
peer's e-mail address ("f...@example.org"). This is the case for
messages that have an Autocrypt: header *and* for messages that *don't*
have one.
Both kinds of messages update the Autocrypt peer state, because if you
start receiving Autocrypt-free messages from someone who used Autocrypt
in the past, your client needs to make a note of that and consider it
when it makes its recommendation for new outbound messages to that peer.
Additionally, sometimes we receive e-mail messages out of order.
sometimes this is because we're suddenly running across a cache of old
messages, sometimes it's because we've just popped online after a day
off, and sometimes it's because SMTP had a hiccup (there are probably
many other reasons).
We also probably don't want to store state about everyone who has ever
sent us mail *without* using Autocrypt. At the moment, at least, that's
probably most senders, and it's both a waste of space and a potential
privacy concern to record a lot of empty state that just indicates that
you got mail from someone at some point in the past. So if we've never
seen an Autocrypt header from a given peer, there's no state to update.
So now consider the following set of e-mail messages all from the same
sender; mails with a * have an Autocrypt header, and the times
following the message indicates its Date: header in an abstract way
(higher numbers are later than lower numbers).
A: (time 1)
B*: (time 2)
C: (time 3)
Let's assume that i update Autocrypt state about the peer upon receipt
of each message, regardless of what order the messages were sent. We
want the Autocrypt state to be immutable, independent of the order of
delivery.
If i receive them at times 4, 5, and 6 in order (A, B, C) then i'll
think that the Autocrypt state for the peer is "we had an Autocrypt
header earlier (from B), but a more recent delivery (C) suggests that
they might not be using Autocrypt reliably" (depending on the actual
difference in time between the Date:s of B and C, the peer might end up
with an Autocrypt recommendation called "discourage"). This is the
correct state for us to end up in.
But now imagine that at times 4, 5, and 6 i receive the messages in the
order A, C, B. If i don't store Autocrypt state for the peer at times 4
and 5, because i've never seen an Autocrypt header for the peer before,
and there is none in messages A and C. Then my end result is that i'll
think that the Autocrypt state for the peer is just the Autocrypt header
from B.
But that's it's different from what we ended up with when we received
the messages in order.
Now, we can improve on this with the following extra technique: when a
peer goes from no Autocrypt state to having an Autocrypt state, we can
search the existing index for messages from that peer with a later Date:
header. If we find such a message, then we should include it in our
calculations. If we do that, then we end up with the correct state,
regardless of the order of delivery. good!
So far, we haven't needed the firstseen= property yet. There's one
final wrinkle that introduces the need for it: message Date: headers can
be wrong. They can even be grossly wrong -- they can be from the
future. This can happen when the sender's clock is bad, mainly, but it
can also happen through malice (someone wanting to forge a message to
mess with the receipient's state about a given peer, for example).
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.
Otherwise, one poorly formed e-mail without an Autocrypt header with the
Date: set to the year 3000 (the "bogus future message") would make it so
that the peer's recommendation would be set to "discourage" when
Re: feature request: caching message arrival time
* 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 for. That makes it a bit difficult for me to contemplate your questions. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: feature request: caching message arrival time
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 datestamp in a way that it can >be scanned the way that "date" can? or do we already have this and >i'm just unaware? you'd need to use a value slot to get (native Xapian) range searches. To quote the xapian docs For performance it is important to keep the amount of data stored in the values to a minimum, since the values for a large number of documents may be read during the search - the more data that has to be read, the slower the search will be. So it's definitely something that would need to be profiled. Probably the patches that added lastmod: are a good example for someone wanting to investigate this. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: forwarding multiple messages from notmuch emacs
On Sun 2016-04-10 15:26:35 +0100, David Edmondson wrote: > On Tue, Apr 23 2013, Daniel Kahn Gillmor wrote: >> 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 located, even if the current region covers more than one message. > > I believe that this is fixed in commit > a982773dfb6e8efe1bcee90e888f2560ad006fb5. Could you test and confirm, > please? Many years later, i follow up on this message -- yes, it does work! in particular, 'F' invokes notmuch-show-forward-open-messages, which is exactly what i want it to do. Thank you, dme! sorry for the lag in following up. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
feature request: caching message arrival time
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 request, along with a few thoughts about it. My idea is that the first time notmuch indexes a message, it would add a property to the message like firstseen=2019-05-31T23:15:24Z. Some nuances spring to mind: * This should *not* be cleared and reset on reindexing, so it doesn't belong in the index.* property namespace. * What happens when you delete a message? Maybe we should keep that value around for "ghosts" too -- can ghost documents have properties? Or is it bad to remember that we've seen the message if someone deletes it? * When even the ghost goes away (e.g. full thread deletion), presumably this property would go away. So If you deleted the message from your message store, notmuch would forget about it, and then the next time you ingest it it would get a later "firstseen=" property. I'm ok with this. * 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 datestamp in a way that it can be scanned the way that "date" can? or do we already have this and i'm just unaware? * What is the cost in terms of database size? It doesn't look like it would be expensive to me, but i haven't profiled it. * if we make such a change, how should we deal with already-indexed messages? Anyone have any thoughts, suggestions, or objections to this? I'm happy to explain more about my use case if people are interested too. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
