Threading for email notifications

I'd love this as well :)

This would be nice for me too. And then, with one email thread per forum topic, it'd be simpler to implement Reply-via-email too (later if anyone wants this).

Thanks for the mockup, and link to the header docs — I didn't know about In-Reply-To and References. (I've been surprised by how my email client (Gmail) groups emails seemingly by looking at [server.addr] only but I suppose these headers help it to do the right thing)

Threading for emails — here's what's on my mind, implementation wise:

For each [new page notification] being sent, Ty generates a SMTP Message-ID, and includes in the email. Later, when notifications are sent about comments on that page, then, for each person being notified, [LKP:] Ty looks up all previous notifications s/he got, about that page, gets their Message-IDs, sorts by time, and includes in the References SMTP header.

The lookup [LKP:] above could be done slightly differently: Ty could look up only all ancestor comments, and include only those in the References: ... header. Instead of all comments on the same page. — That is, sub threads on the same page. I wonder what mail clients do then: different "threads", but all of them starting with the same Message-ID (for the Orig Post).

And Ty also sets In-Reply-To: ... to the Message-ID about the parent comment (which would also ... always? be last in the References: ... list), or the whole page's Message-ID if it's the Orig Post.

And the subject line would, I suppose, have to include the original title of the page, even if, later on, it got renamed, because apparently Gmail groups by email subject line instead (see: https://stackoverflow.com/a/23482109). — So, for each person getting notified, maybe Ty would need to remember the original title of that email thread ?

***

I wonder if there are security implications from generating these Message-IDs per post, or [per person getting notified]. If it matters if everyone who gets notified about a post, gets the same Message-ID. Or if it's somehow better, if everyone see unique Message-IDs. ... ?

Any thoughts?

One thing could be that if both person P and person Q got notified about comment C, then, Q could send a handcrafted email to P, with a Message-ID specifying comment C (if P and Q see the same ID). In this way, Q could try to inject Q's own email in the email thread as seen by P. Then, maybe maybe an email client shows Q's message as part of the email thread, and P mistakenly thinks that it got sent by the Ty server but it's from Q.

( @chrscheuer I'll do the may-@mention-me thing first, just nice to start thinking about this threading stuff now directly :- ))

Now threaded emails are live here at Ty .io, however, turns out that Amazon SES (which Ty uses) replaces Message-ID with its own id. So the SMTP headers I'm getting when testing, look like:

Message-ID: <010001848635c685-b8f4ebfa-13e3-4c69-a552-314db32215ba-000000@email.amazonses.com>
In-Reply-To: <123.1.273.1234@forum.talkyard.io>
References: <123.1.273.1234@forum.talkyard.io>
Subject: [forum.talkyard.io] Threads test 001

This breaks threading, at least in Gmail — Gmail even starts a new thread, per comment, even though the subject line is the same (when on the same page).

What's on my mind is to switch to Postmarkapp, which Ty uses already anyway for handling incoming emails.

Postmarkapp keeps the Message-ID (in addition to adding its own MessageID (without a -), like you noted. I wonder why they didn't choose a more different name).
But only if the sender includes an extra header X-PM-KeepID: true (so I'll make Ty add that extra header).

Now I've upgraded Prod. (Finally :- ))

Threaded emails are working great! It's so much easier to manage our discussions now.

I have a small request for a tweak. Is it possible to use a tag other than blockquote for the reply contents? In Fastmail (perhaps in other clients too), it thinks that blockquote tags are strictly for quoting text from earlier in the thread, so it collapses them by default: