Message-ID's vs. Resent-Message-ID

Message-ID's vs. Resent-Message-ID

[Erik Quaeghebeur]

Hi,


I've become interested in notmuch. After looking at the documentation of the Python bindings, I have the following questions:

* Is it correct that a message's Message-ID used as its unique key in the notmuch database?

* If yes, is it correct that two messages with the same Message-ID, but with different contents/other headers, will have only one entry in the database?

* If yes, for resent messages (https://tools.ietf.org/html/rfc2822#section-3.6.6), does notmuch use (the chronologically last) Resent-Message-ID, or the Message-ID?


Best,

Erik

Re: Message-ID's vs. Resent-Message-ID

[Tomi Ollila]

On Sun, Jan 10 2016, Erik Quaeghebeur <notmuch@equaeghe.nospammail.net> wrote:

> Hi,
>
>
> I've become interested in notmuch. After looking at the documentation of
> the Python bindings, I have the following questions:

> * Is it correct that a message's Message-ID used as its unique key in the
> notmuch database?

yes

> * If yes, is it correct that two messages with the same Message-ID, but
> with different contents/other headers, will have only one entry in the
> database?

yes

> * If yes, for resent messages
> (https://tools.ietf.org/html/rfc2822#section-3.6.6), does notmuch use
> (the chronologically last) Resent-Message-ID, or the Message-ID?

the Message-ID

>
>
> Best,

likewise :)

>
> Erik


Tomi

Re: Message-ID's vs. Resent-Message-ID

[Erik Quaeghebeur]

Thanks, Tomi, for your quick response.

> > * If yes, for resent messages
> > (https://tools.ietf.org/html/rfc2822#section-3.6.6), does notmuch use
> > (the chronologically last) Resent-Message-ID, or the Message-ID?
> 
> the Message-ID

Hmm. Is this a conscious decision, or is the resending case just not taken into account?

What happens if I have both a message and my own copy of it after resending it to somebody else? I would like to have a record of whom I resent it to, as with forwarded messages (where the forwarded message does have a different message id). 

Are the Resent-* headers of the resent message merged into the database entry? I guess this last question is more general: with multiple messages with the same Message-ID but differences (for whatever reason), how will these messages be merged in the database?


Best,

Erik

Re: Message-ID's vs. Resent-Message-ID

[Tomi Ollila]

On Sun, Jan 10 2016, Erik Quaeghebeur <notmuch@equaeghe.nospammail.net> wrote:

> Thanks, Tomi, for your quick response.
>
>> > * If yes, for resent messages
>> > (https://tools.ietf.org/html/rfc2822#section-3.6.6), does notmuch use
>> > (the chronologically last) Resent-Message-ID, or the Message-ID?
>> 
>> the Message-ID
>
> Hmm. Is this a conscious decision, or is the resending case just not
> taken into account?

(most probably just) not taken into account

> What happens if I have both a message and my own copy of it after
> resending it to somebody else? I would like to have a record of whom I
> resent it to, as with forwarded messages (where the forwarded message
> does have a different message id).

Both of the copies are "files" of the same message; i.e.

notmuch search --output=files id:<Message-ID> will list both (all)
filenames

> Are the Resent-* headers of the resent message merged into the database
> entry? I guess this last question is more general: with multiple messages
> with the same Message-ID but differences (for whatever reason), how will
> these messages be merged in the database?

Database has fixed set of headers stored per message and (afaik) none
of the Resent-* headers are there (merged or separate).

(One thing to remember (for anyone perhaps planning to do something about
this) is that if we'd use Resent-Message-ID: as message identification 
if it exists, then Message-ID: of the message should act as In-Reply-To:
or References: -header...)

Tomi

> Best,
>
> Erik

Re: Message-ID's vs. Resent-Message-ID

[David Bremner]

Tomi Ollila <tomi.ollila@iki.fi> writes:

> (One thing to remember (for anyone perhaps planning to do something about
> this) is that if we'd use Resent-Message-ID: as message identification 
> if it exists, then Message-ID: of the message should act as In-Reply-To:
> or References: -header...)

It actually seems like one of the more benign cases of message-id
collision that currently exist in notmuch. The fact that by default you
see only one copy of a message that arrived two different ways is a
design choice; it's hard to get closer than the resent message case.  I
suspect any change would have to be configurable, since most existing
notmuch users would be pretty surprised to suddenly see lots of
duplicate messages.

d