locked Re: [owlperch] To Duane, Matthew, Shal & Tyger
On Fri, Jan 23, 2015 at 10:23 AM, Feathered Leader <featheredleader@...> wrote:
This is going to get a little technical. Every email has a unique 'message-id'. This is just a long string of characters, and the hope is that it's unique in all the world. It's generated by your email client or email server.
When replying to a message, the message-id of the email you're replying to is included in the headers of your email. That's how email clients know one message is a reply to another message. If someone then replies to your reply, they will have your message-id in the header to their message, and so on. But they will also generally include the message-id of the original email in the headers as well. You end up with a chain of message-ids. If you view the headers for an email, this is the 'References:' line.
One other thing to note, emails can arrive out of order. We can get a reply to an email before we get the original email.
So, if we get an email, with a message-id in the references list that we've never seen before, we think we've gotten an out of order reply, and that we should expect to see the original message at some point. We put a 'placeholder' message in the database that corresponds to this message we haven't seen before. It's empty, and it doesn't show up in archives, but it does have a message number. When we see the original message, we replace the placeholder with the original, and we're good.
So, there may be cases where message numbers jump without someone having deleted a message. This should be very rare.
What happened in this case is that Shal replied to an email in a different group. Therefore, his message had in the references a message-id that the group owlperch had never seen. We assumed we were seeing an out of order reply, and added a placeholder for the message we hadn't seen (and will never see, since it's from another group).
So, things are working as designed. It does occur to me that I can make the algorithm a little less 'anal' which would prevent a message number jump in this instance. It would increase the change of weird threading behavior, but I think the chance of that happening would be small.
More info than you wanted to know.....