Mail to self

[Leo Gaspard]

Hello,

I'm looking for a way to have notmuch consider, when it finds both an
unread and a read mail with the same Message-Id (eg. sending a mail to
self from a phone), that the mail is unread (because I'd rather have too
many mails unread than miss important mail, and it's also useful for
tests).

Do you see any way of having notmuch do this?

Cheers,
Leo

[David Bremner]

Post by Leo Gaspard
Hello,
I'm looking for a way to have notmuch consider, when it finds both an
unread and a read mail with the same Message-Id (eg. sending a mail to
self from a phone), that the mail is unread (because I'd rather have too
many mails unread than miss important mail, and it's also useful for
tests).
Do you see any way of having notmuch do this?

After a discussion on IRC, my understanding is the following. The
underlying behaviour that Leo is objecting to is that if any one file
with a given message-id has the ,S maildir flag, then when notmuch syncs
maildir flags to tags, it will remove the unread tag from that
message-id. After some back and forth and thinking about it, I think
notmuch's current behaviour is actually correct (given the constraint
that tags attach to message-ids). You could argue for different ways of
resolving conflicts for maildir flags in general, but the ",S" or "seen"
flag has fairly natural common sense semantics.

d

[Gregor Zattler]

Hi Leo, notmuch users and developers,

I too filter emails into different folders. And I used to filter
some emails in several folders in order to find them in different
contexts.

I can confirm this is my issue. My thinking is that if any file does not
have the ,S maildir flag, then I would prefer the mail to be marked as
unread, as a read mail that is spuriously marked as unread is a small
inconvenience, while an unread mail that is spuriously marked as read
can have huge consequences.

For me, when I filtered emails in several folders and read them
with mutt (1) it was the other way around: I wished for the
possibility to mark them as read in all folders if read in one.

I think your reasoning is also sound but only iff tags would
belong to files, but they belong to messages.

Actually, I just noticed while writing this mail that I had setup a
sieve filter for duplicate email that put them in a "Duplicate" folder
and automatically marks them as "read", so that at the same time they
wouldn't bother me in the thunderbird interface but I could still check
dovecot's duplicate detection didn't have false positives.
This behaviour of notmuch thus made me miss 9 emails in the 2 weeks I've
been using it, the oldest being 12 days ago, without any warning. Well,
now I know about it and can try to change my setup (except I can't
really touch this sieve filter as other people rely on it), but...

But why would you tag a message (as opposed to a file) as
"unread" because it's a duplicate?

If it's somehow important to you to know that a certain email
your read via notmuch is a duplicate, why not tag it as
"duplicate" instead?

I suppose you do this filtering in case you read those emails
with a file/folders based client. But would you actually "read"
emails in a duplicate folder? I too have a duplicate folder and
it was useful some times in order to investigate problems with my
processing of incoming emails, but I do not read them in order to
understand the meaning of some message a human sent me.

Since I also filter emails in folders my searches heavily relay
on the path the message is in with the "path:" search prefix.
These is true for all mailing lists, for instance.

For the specific case of the duplicates folder: It's simply not
in the same maildir notmuch indexes and therefore there is no
issue with them for me. My procmail scripts first do a backup of
an incoming email, later they filter duplicates in a duplicates
folder and when an email actually is delivered in the maildir
hierarchy notmuch indexes, then it is also backed up in a third
backup folder for post-processed emails. These three special
folders are directories under my ~/.procmail directory and are
not indexed by notmuch.


HTH, Gregor

[Leo Gaspard]

Hi Gregor,

Post by Gregor Zattler
For me, when I filtered emails in several folders and read them
with mutt (1) it was the other way around: I wished for the
possibility to mark them as read in all folders if read in one.

This isn't incompatible, and I'm not wishing that notmuch stop marking
as read per-message.

However, I *am* wishing that when some other tool marked one of the
message files as read and not the other, notmuch takes the safe route of
marking the overall message as unread in its database.

Post by Gregor Zattler
But why would you tag a message (as opposed to a file) as
"unread" because it's a duplicate?

Because usual folder-based applications display an unread marker with
the number of unread messages near the folder, and this is a useless
visual disturbance for the people for whom I administer the mail server.

Post by Gregor Zattler
If it's somehow important to you to know that a certain email
your read via notmuch is a duplicate, why not tag it as
"duplicate" instead?

This is not a problem in notmuch (notmuch anyway just assumes that
duplicates with the same Message-ID will never happen, which in my
opinion is a bit optimistic, but I guess this design point is not going
to change anyway and so am not going to argue further), but it is a
problem with folder-based applications.

When using a folder-based application, I don't want a Duplicates folder
always popping up in my folder list with new messages until I read them,
I want a Duplicates folder only to debug when things go weird and
messages appear missing.

Post by Gregor Zattler
For the specific case of the duplicates folder: [...]

Yes, now that I'm aware of this issue I can adapt my setup, likely by
not indexing the duplicates folder indeed.

However, I still think this is a big footgun, and take my missing 9
emails in the first 2 weeks of notmuch as proof of it.

Just to repeat it at the end so my objective is clear:

What I am wishing for is that when some tool outside of notmuch marked
one of the message files as read and not the other, upon
`synchronize_flags` notmuch takes the safe route of marking the overall
message as unread in its database.

[Leo Gaspard]

(sorry for sending twice, had the wrong From: line once again, hopefully
I have fixed my client by adding this address to `user.other_email` now)

Hi Gregor,

Post by Gregor Zattler
For me, when I filtered emails in several folders and read them
with mutt (1) it was the other way around: I wished for the
possibility to mark them as read in all folders if read in one.

This isn't incompatible, and I'm not wishing that notmuch stop marking
as read per-message.

However, I *am* wishing that when some other tool marked one of the
message files as read and not the other, notmuch takes the safe route of
marking the overall message as unread in its database.

Post by Gregor Zattler
But why would you tag a message (as opposed to a file) as
"unread" because it's a duplicate?

Because usual folder-based applications display an unread marker with
the number of unread messages near the folder, and this is a useless
visual disturbance for the people for whom I administer the mail server.

Post by Gregor Zattler
If it's somehow important to you to know that a certain email
your read via notmuch is a duplicate, why not tag it as
"duplicate" instead?

This is not a problem in notmuch (notmuch anyway just assumes that
duplicates with the same Message-ID will never happen, which in my
opinion is a bit optimistic, but I guess this design point is not going
to change anyway and so am not going to argue further), but it is a
problem with folder-based applications.

When using a folder-based application, I don't want a Duplicates folder
always popping up in my folder list with new messages until I read them,
I want a Duplicates folder only to debug when things go weird and
messages appear missing.

Post by Gregor Zattler
For the specific case of the duplicates folder: [...]

Yes, now that I'm aware of this issue I can adapt my setup, likely by
not indexing the duplicates folder indeed.

However, I still think this is a big footgun, and take my missing 9
emails in the first 2 weeks of notmuch as proof of it.

Just to repeat it at the end so my objective is clear:

What I am wishing for is that when some tool outside of notmuch marked
one of the message files as read and not the other, upon
`synchronize_flags` notmuch takes the safe route of marking the overall
message as unread in its database.