Emails don't thread very nicely / could use email headers

[npdoty]

I'm currently getting an email for every message (in settings) because I use email a lot and like the idea of using this like a group mailing list service. However, emails on the same topic don't thread very nicely in my mail client.

For example:

• A new topic was started that begins with "Hi Dan!" and the subject line for the email is "Hi Dan! We're looking at starting our own instan..."
• All replies to that topic have subject line of "Re: Hi Dan! We're looking at starting our own in..." which is not just Re: + the original subject line, so Mail.app puts them in a separate thread.

Some solutions, or general niceties:

• "Re: X" subject lines should use the same X as the original email subject, rather than ellipsing at a different point
• if emails had a specific Message-ID, then replies could also use the In-Reply-To header to indicate that a message is in the same thread as another message, rather than forcing mail clients to use error prone guesses regarding the contents of subject lines (e.g. "Re: Hello" can become a very large thread when actually it's all separate messages in different groups)
• if emails used the List-ID header with a reference to the group URL, then it would be easy to tag/filter messages based on which group or sub-group they're from
• if emails used the Archived-At header with a URL to the specific message on the Web version, that would comport with other email lists that provide URLs to archived versions of email list messages (and might one day obsolete the need for including the message link in the footer of every message)

Admittedly, supporting all of these would get organizer.network to be much closer to actual mailing list software (the next step, which I would also love, would be to have emails come from the sender's email address rather than a generic email address, but there may be privacy reasons to prefer the generic version), which may not be your goal.

[dphiffer]

Oh good catch. Yeah, I had thought it was using "Re: X" but it turns out it's "Re: X[:-4]".

[dphiffer]

FWIW I am tracking Message-ID and In-Reply-To to handle incoming replies, but I'm not setting the values of them on outgoing messages. Archived-At is new to me, but sounds like it would also be worth including. Lots of good ideas in here!

[dphiffer]

One feature I have thought about is having two different patterns for email addresses that would pass messages along to the right place:

• [person slug]@organizer.network
• group-[group slug]@organizer.network

And when you receive a new message sent to a group, the From would show the first address and the Reply-To would be set to the second one.

So far my DNS/SendGrid chops are lacking and I don't know how to get off of the mail.organizer.network subdomain, but I think handling the incoming email aliases could be fairly straightforward.

[npdoty]

GitHub's emails might be a good model to use for some of these features. To catch replies better, they customize the Reply-To header to include "reply+" followed by a long, message-specific identifier string before the domain, presumably so that even if the mail client doesn't use nice In-Reply-To headers the server can still figure out which thread to add a message to.

They also have the convention of not setting the To: field to the recipient's email, which is more appropriate because it isn't a private message sent to a single person. Certain email clients (including GMail) handle those differently. Instead, the To could be your group-[group slug]@organizer.network which makes it clear that it's a message to that group, and a user could even add that to their contacts and send new posts directly to that group.

[dphiffer]

Yeah, GitHub’s email pattern is worth learning from. I like that detail of using CC instead of To. Trying a reply-all to the email to see how it goes...

On Nov 13, 2018, at 11:38 PM, Nick Doty notifications@github.com wrote:

GitHub's emails might be a good model to use for some of these features. To catch replies better, they customize the Reply-To header to include "reply+" followed by a long, message-specific identifier string before the domain, presumably so that even if the mail client doesn't use nice In-Reply-To headers the server can still figure out which thread to add a message to.

They also have the convention of not setting the To: field to the recipient's email, which is more appropriate because it isn't a private message sent to a single person. Certain email clients (including GMail) handle those differently. Instead, the To could be your group-[group slug]@organizer.network which makes it clear that it's a message to that group, and a user could even add that to their contacts and send new posts directly to that group.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.