Fossil Forum

Suggestion: Duplicate original Message-ID for edit email notifications
Login

Suggestion: Duplicate original Message-ID for edit email notifications

Suggestion: Duplicate original Message-ID for edit email notifications

(1) By anonymous on 2023-03-17 06:55:50 [link] [source]

On the SQLite forum I recently turned on email notifications of post edits. I found I was occasionally missing some large parts of a message due to how some authors make large changes to their original message.

From an email point of view, Fossil currently delivers these edits the same way as new posts: The Message-ID is new, and there is no In-Reply-To field. This means that edit emails do not associate well with the rest of the thread - i.e. they cannot be sorted into their (in my humble opinion) logical place.

I would like to suggest that the original Message-ID be used instead. This would allow email clients to put all of the post emails together, where one can easily delete earlier edits and/or skip to the latest, before reading the rest of the thread. Some clients (e.g. mutt) even nicely mark duplicate Message-ID messages, for more visual clarity.

(2) By Stephan Beal (stephan) on 2023-03-17 11:36:22 in reply to 1 [link] [source]

This would allow email clients to put all of the post emails together, where one can easily delete earlier edits and/or skip to the latest,

i'm wondering if that won't just cause more confusion. Human readers won't know that there are edits until they've already read the first copy. That's not fundamentally different to what we see now, except that the edits arrive as separate mails so aren't immediately visible within a thread.

I would like to suggest that the original Message-ID be used instead.

This is just speculation, but is there not a risk that duplicating message IDs will increase the risk of the mails getting marked as spam, or even as duplicate traffic and therefore not processed at all by some overly-clever systems?

i also get notifications for edits and the way they're sent hasn't ever bothered me, but i'm not opposed to any changes in that if improves the experience for folks.

(3) By Kees Nuyt (knu) on 2023-03-17 16:59:21 in reply to 1 [link] [source]

I recognize your experience, but I don't agree on the solution.

Message-IDs are supposed to be unique, violating that requirement may disturb mail clients and mail exchange protocols.

To replace a message, a new message, with its own unique Message-ID, should be sent. It can use a Supersedes:, Obsoletes:, or Replaces: header, but I have no idea if most mail clients can properly handle those.

I would suggest that authors think more than twice before posting, and utilize the preview to not just proof-read but also rethink their message.

And perhaps it would be better to add later insights and additional info not by editing, but by posting a "reply to self".

-- 
Regards,
Kees Nuyt
no AI was used in composing this msg

(4) By Vadim Goncharov (nuclight) on 2023-03-18 14:32:35 in reply to 1 [link] [source]

This is wrong solution. RFC 822 explicitly states that Message-Id reflects "this version of this message", that is, it must be different for edits.

(5) By anonymous on 2023-03-20 11:26:41 in reply to 1 [link] [source]

(Responding to everything above in one message)

Just expanding briefly on the level of confusion I experience. Here is what mutt displays for a recent period on the SQLite forum:

  1 1/13   + Mar 16 Maik            ( 478) [sqlite-forum] Assertion violatio
  2 2/13   + Mar 16 Richard Hipp    (  17) ├─>[sqlite-forum] Assertion viola
  3 3/13   + Mar 17 Richard Hipp    (  35) ├─>[sqlite-forum] Assertion viola
  4 4/13   + Mar 17 Maik            ( 116) │ ├─>[sqlite-forum] Assertion vio
  5 5/13   + Mar 17 Maik            ( 111) │ │ ├─>[sqlite-forum] Assertion v
  6 6/13   + Mar 17 Maik            (  99) │ │ └─>[sqlite-forum] Assertion v
  7 7/13   + Mar 17 Maik            (   7) │ └─>[sqlite-forum] Assertion vio
  8 8/13   + Mar 17 jose isaias cab (   8) └─>[sqlite-forum] Assertion viola
  9 9/13   + Mar 17 Richard Hipp    (  33)   └─>[sqlite-forum] Assertion vio
 10 10/13   + Mar 17 Maik            (  10)     └─>[sqlite-forum] Assertion
 11 11/13   + Mar 17 jose isaias cab (   8)       ├─>[sqlite-forum] Assertio
 12 12/13   + Mar 17 Larry Brasfield (  19)       ├─>[sqlite-forum] Assertio
 13 13/13   + Mar 17 Simon Slavin    (   9)       └─>[sqlite-forum] Assertio
 14 1/1   + Mar 16 Maik            ( 652) [sqlite-forum] Assertion violation
 15 1/1   + Mar 16 Maik            ( 652) [sqlite-forum] Assertion violation
 16 1/8   + Mar 16 communy         (  20) [sqlite-forum] JOIN using IN opera
 17 2/8   + Mar 16 Keith Medcalf   (  31) ├─>[sqlite-forum] JOIN using IN op
 18 3/8   + Mar 17 communy         (  29) │ └─>[sqlite-forum] JOIN using IN
 19 4/8   + Mar 17 Keith Medcalf   (  38) │   ├─>[sqlite-forum] JOIN using I
 20 5/8   + Mar 17 Keith Medcalf   (  37) │   ├─>[sqlite-forum] JOIN using I
 21 6/8   + Mar 17 Keith Medcalf   (  65) │   └─>[sqlite-forum] JOIN using I
 22 7/8   + Mar 16 Keith Medcalf   (  43) ├─>[sqlite-forum] JOIN using IN op
 23 8/8   + Mar 16 Keith Medcalf   (  43) └─>[sqlite-forum] JOIN using IN op
 24 1/1   + Mar 16 Maik            ( 687) [sqlite-forum] Assertion violation
 25 1/1   + Mar 16 Maik            ( 686) [sqlite-forum] Assertion violation
 26 1/1   + Mar 16 Maik            ( 687) [sqlite-forum] Assertion violation

Maik has made several edits (14, 15, 24, 25 and 26). Whether these were to the original (1) or the replies (4, 5, 6, 7, 10) I cannot tell. They are all sent by Fossil as unrelated to the thread. Therefore they appear after all thread messages and can even become interleaved with other threads.

I am primarily interested in the last edit and would prefer to read it before any of the replies. It is currently very painful reading the same message over and over again, often with minor edits I don't event notice, after I've already seen the rest of the thread. I can't imagine any delivery changes making this worse, but I'm prepared to be educated :-)

I don't think Kees' suggestion for changing user behaviour is realistic. The Edit feature seems to be a core, well-used feature of Fossil. Whatever (minimal?, administrative?) intentions the developers envisioned, it will be exploited to the maximum utility of the users regardless.

I agree that the language in RFC 5532 (which obsoletes 2822 and 822) is unambiguous on Message-ID uniqueness. Unfortunately the standard is somewhat incomplete: it provides no mechanism for actually indicating that a message should replace an earlier one. I find no official mention of Super[cs]edes:, Obsoletes: or Replaces:. Mutt certainly doesn't change its behaviour in their presence.

Whether the standard allows it or not, duplicate message IDs are a thing. There are misconfigured clients and systems, and they are not unusual in my inbox from other systems. I can understand if the project wants to remain conservative, but I don't in this case consider it a moral hazard not be standard conforming.

In any event, it should at least be acceptable to the Fossil project to use the References header on all messages? That is in the RFC, and it seems to do nearly the right thing as well, although I have not exhaustively checked.

(6) By Kirill M (Kirill) on 2023-03-20 13:37:41 in reply to 5 [link] [source]

Some systems, such as Cyrus IMAP (used by i.a. Fastmail), are configured to do duplicate delivery suppression, which discards newly arriving messages if they have a message-id which already is present in the folder. So reusing message-id sounds like a bad idea.

An edit is, really, kind of a reply by the author of the original themselves, where the author says how original post should be amended. So maybe use in-reply-to and references as with normal replies?

(9) By anonymous on 2023-03-21 08:01:49 in reply to 6 [link] [source]

Fair enough, thanks for the example.

I would like retract my request for dup Message-ID:. If I wasn't anonymous I would edit the title of the original posting (generating another email... :-) to the following request:

Suggestion: Add a References: header to email notifications

I'm not sure In-Reply-To: header should be used, unless the edit is to an actual reply.

(7) By anonymous on 2023-03-21 03:16:01 in reply to 1 [link] [source]

This is wrong. The correct way to indicate modified messages is to use a Supersedes: header with the message ID of the original message. (This is used in NNTP; I do not know how common this is for email, though)

(8) By Kirill M (Kirill) on 2023-03-21 07:59:11 in reply to 7 [link] [source]

Found a section in RFC2076 dedicated to Message identification and referral headers:

In Usenet News, however, Supersedes causes a full deletion of the replaced article in the server, while "Supersedes" and "Obsoletes" in e-mail is implemented in the client and often does not remove the old version of the text.

So, yes, Supersedes: seems most suitable.

(10) By anonymous on 2023-03-21 08:12:21 in reply to 8 [link] [source]

So, yes, Supersedes: seems most suitable.

Sort of. RFC 2076 combines headers from different systems. That particular header comes from (son of) RFC 1036 which was focused on:

This document defines the standard format for the interchange of network News messages among USENET hosts. It updates and replaces RFC-850, reflecting version B2.11 of the News program. This memo is

So my mail client (mutt) doesn't react to it, and I assume most others won't either. I see no harm in adding it, but I wouldn't expect it to materially improve the situation on its own.

(11) By Daniel Dumitriu (danield) on 2023-03-21 09:26:58 in reply to 10 [source]

The IANA registration for mail/MIME header fields is in RFC 5322 (Mar 2005); in particular, Supersedes is mentioned to have replaced (renamed) the previous Obsoletes through RFC 2156 (Jan 1998), so one would expect those two to be treated similarly by MUAs.

Perhaps that "not for general use" offers an explanation on the said behavior thereof.

(12) By Kirill M (Kirill) on 2023-03-21 10:40:53 in reply to 10 [link] [source]

So my mail client (mutt) doesn't react to it, and I assume most others won't either. I see no harm in adding it, but I wouldn't expect it to materially improve the situation on its own.

Apparently Mutt has some understanding of superseded messages, as Mutt has the ~S search pattern to find superseded messages... Never tried it, though.

(13) By anonymous on 2023-03-21 12:16:59 in reply to 12 [link] [source]

Mutt has the ~S search pattern to find superseded messages...

Ah, good find! The ~S selection does indeed do what it says.

So the Supersedes: header would be a (standard-ish) helping mechanism after all. With that specified by Fossil I could select such messages and delete them relatively easily. I also just checked Thunderbird, which even enables users to create automatic filters that put superseded messages in the Trash or wherever.

Since I'm not a regular forum visitor and I don't think this feature request can be improved much more, I'll leave the discussion here. Thanks to all for the helpful inputs.

(14) By anonymous on 2023-03-21 20:19:50 in reply to 13 [link] [source]

Supersedes:, nice.

Using Keith Medcalf as an example, his edited message could be marked as:

Message-Id: <ae49298964022f5c7555e97f2c112dd1@sqlite.org>
In-Reply-To: <1973e7d91177900e8bab9fd88ef27ee0@sqlite.org>
References: <2bac991e655d8e806fdc76ae6549911c@sqlite.org>
 <0415988cead64f818a4686d26dd289c7@sqlite.org>
 <047ef2f21a9b1bca65fcfa9b93fe96cd@sqlite.org>
 <8c5e4fdee8085c1d2483aeb3973eb12e@sqlite.org>
 <4d499113c5b954464d264e5e4dbe5747@sqlite.org>
 <b04cd05608e6f02d3474dc1ff6873fea@sqlite.org>
 <d8720f0ecae3ef3c5c5eff6284c2a67a@sqlite.org>
 <ae6eac43619d2cf495f44ce3983d2817@sqlite.org>
 <ec465077cb4dfe5cfa2a18c15a39cc04@sqlite.org>
 <98f2b1e7f53618d231f3d0b6923fe87e@sqlite.org>
 <1973e7d91177900e8bab9fd88ef27ee0@sqlite.org>
Supersedes: <1973e7d91177900e8bab9fd88ef27ee0@sqlite.org>

Relevant commit.

(15) By anonymous on 2023-03-21 20:40:53 in reply to 14 [link] [source]

Assuming POP3, one can query the above directly:

# { echo 'user sqlite'; echo 'pass 10'; echo 'uidl'; echo 'top 9 0'; } | nc pop.textprotocol.org 1110
+OK
+OK
+OK
+OK
1 RRVW04ae6eac4361
2 RRVWBMec465077cb
3 RRVXMN98f2b1e7f5
4 RRVXRW3479328d04
5 RRVY1X417d3a0175
6 RRVY6Sae153dfd5c
7 RRVYTY9b805ffb60
8 RRVZA21973e7d911
9 RRVZBPae49298964
10 RRVZGC932327a4d6
.
+OK
Return-Path: <>
From: kmedcalf <noreply80249ac13@sqlite.org>
To: SQLite Forum <sqlite-forum@sqlite.org>
Date: Tue, 21 Mar 2023 19:55:01 -0000
Subject: Re: [ANN] SQLite in the Cloud: The Future of Lightweight Databases [edit]
Message-Id: <ae49298964022f5c7555e97f2c112dd1@sqlite.org>
In-Reply-To: <1973e7d91177900e8bab9fd88ef27ee0@sqlite.org>
References: <2bac991e655d8e806fdc76ae6549911c@sqlite.org>
 <0415988cead64f818a4686d26dd289c7@sqlite.org>
 <047ef2f21a9b1bca65fcfa9b93fe96cd@sqlite.org>
 <8c5e4fdee8085c1d2483aeb3973eb12e@sqlite.org>
 <4d499113c5b954464d264e5e4dbe5747@sqlite.org>
 <b04cd05608e6f02d3474dc1ff6873fea@sqlite.org>
 <d8720f0ecae3ef3c5c5eff6284c2a67a@sqlite.org>
 <ae6eac43619d2cf495f44ce3983d2817@sqlite.org>
 <ec465077cb4dfe5cfa2a18c15a39cc04@sqlite.org>
 <98f2b1e7f53618d231f3d0b6923fe87e@sqlite.org>
 <1973e7d91177900e8bab9fd88ef27ee0@sqlite.org>
Supersedes: <1973e7d91177900e8bab9fd88ef27ee0@sqlite.org>
Archived-At: <https://sqlite.org/forum/forumpost/ae49298964022f5c7555e97f2c112dd1>
List-Archive: <https://sqlite.org/forum>
List-Id: Discussion board for SQLite <sqlite-forum@sqlite.org>
List-Post: NO
Importance: low
Precedence: list
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="10XF05511989294EADABF2=_"

.