I missed a message on a sourceware mailing list from yesterday. I.e. I only subscribed to the list today and found a message regarding the same problem I was having that was posted yesterday (through the search function).
Is there any way I can reply to that message, as if I had been subscribed to the mailing list yesterday?
I know there is an In-Reply-To header field for e-mails, but I think I need some sort of message id to use it.
Depending on the mailing list, there may be a web interface that lets you reply to a message (e.g. gmane allows this).
If not, there may be a web interface to view the message's ID, which you can then use in the In-Reply-To header.
If not, I doubt there's a way to do what you want.
Related
Like many web apps, we use Postmark to send all notifications for server side events. Many of our events are grouped and related by something simple and logical (think multiple replies to the same issue, like in GitHub).
Right now, every email sent for these related events is it's own email thread. My question is: how do I send these emails so that related ones get pushed into the same thread?
I'm not sure if this is something at the Postmark level (like include a previous message ID) or if this is something I do with SMTP (like I should format my subject better and inline previous responses), so that's why I'm seeking guidance. Also, every Google search about: "Postmark email threads" returns concerns over the thread safety of the Ruby Gem.
For more information, the app is written in PHP and right now we are znarkus/postmark-php for sending emails and jjaffeux/postmark-inbound-php for parsing inbound ones. However, I am more than willing to add any extra packages if they help me in my quest.
Thanks in advance!
You can add a few SMTP headers with the original Message-ID that most clients use to link together replies. If the original email had a Message-ID header of <123#mail.example.com> the new email you send out should keep the subject line the same and add headers of:
In-Reply-To: <123#mail.example.com>
References: <123#mail.example.com>
And that should inform clients that the two emails should be threaded.
Edit:
The value for these headers should be the SMTP Message-ID header, which is slightly confusing because it is a separate concept from the Postmark MessageID value, which is just a UUID for the email.
The SMTP Message-ID header is always in the form an email address, because that's how it's supposed to be formed, but doesn't have to be related to the from address.
I would like to create a "thread view" from emails that are on an IMAP server.
To achieve that, I fetch the list of emails in the INBOX and other folders but I need to know which email is answering which. Is there such a link between emails in IMAP?
For example on an IMAP server each email has a unique ID: if email B is an answer to email A, is the ID of A stored inside email B?
If your IMAP server supports the "thread" capability as described in RFC 5256, you can just ask the server to thread the messages for you.
Otherwise, you'll have to fetch the relevant information and do the threading on the client. The RFC describes two algorithms to do that. The simpler one, ORDEREDSUBJECT, just groups messages by subject and then sorts them by date. This gives a flat threading structure. The more complicated one, REFERENCES, looks at the In-Reply-To and References headers of each message, and considers messages with such headers to be children of the message with the given Message-Id.
The classic way is to retrieve the message-id and references fields. If two messages contain the same message-id in either message-id or references, then they are in the same thread.
Gmail has a new and IMO better way: each thread has a numeric ID which you can retrieve using x-gm-thrid. Google has published example code in various languages for using that (there should be links near that code).
Story is simple: one user creates a new discussion, and system sends out email notification to other users about that. When these users reply to a notification, their replies should be properly routed as comments to the particular discussion.
When system sends out email notification, it includes routing code in the subject. For example, subject of a notification may look like this: 'Discussion "Lets Talk" has been started {123}'. Since all email clients use Re: ORIGINAL SUBJECT we get {123} back as part of the subject, parse it and know where to put the comment.
We have this working already (had it for years actually), but current implementation looks a bit dirty (especially when codes become longer) so we would like to explore alternatives if there are any. Is there are a more elegant way to approach this, that works reliably across most email clients? Email header that we might be missing? Something similar?
Thanks so much
Since you didn't mention it I'm not sure if you looked into this:
There is a field in the email header called In-Reply-To which should contain the message id(s) of the email(s) that mail is replying to and one name References which should specify a thread this mail belongs to:
"In-Reply-To:" field may be used to identify the message (or
messages) to which the new message is a reply, while the
"References:" field may be used to identify a "thread" of
conversation.
According to the rfc the In-Reply-To field should contain the "parent"-message's Message-Id while the References field will quote the parent-message's References field.
The problem with this fields is that there is no guarantee that there is something useful in them because they are not required to be filled correctly for mail delivery so some mail clients might not fill them correctly or maybe not even at all.
I found this article about building a threading algorithm using the In-Reply-To field and claiming to be robust against garbage and malicious input in these fields.
As the title says, I would like to send a welcome message when a user subscribes to a bot.
However, as I understand it, presence subscribe stanzas should not contain a from-JID that includes resource (and my testing with Adium indicates that is also the case). That is, welcome message could easily be sent to the bare JID but is that really the right way to do it? It feels like it should be sent to the actual instance where the subscription originated.
Perhaps I'm seeing a problem where there is none? If not, any ideas on how to solve it?
Do not fear sending a message to a bare JID. Almost all the time this is what you want. The user may already have a fantastic system in place using priority to get the answer at the right device, like a blackberry, their home jabber client, the one at work, and so on. Heck, they may have sent the request from their blackberry that has a 0 priority, and they want to get the answer back at their desk.
Just send a message stanza with a type of headline, since you don't want them to reply to the notice.
The things said about messages are all right.
If you care about whom to send presence subscribe stanzas to, I wonder whether you really know resources at that time. IIRC, resources are stripped off before forwarding presence subscribes and I assume that you are responding to them. Furthermore, the bot wants to be informed about all presences, so subscribing to the bare jid is the right thing to do.
Am trying to determine the best way to persist information from an originating email, through to a reply back.
Essentially, it is to pass a GUID from the original email (c#), whereby when the receiver replies back, that GUID is also sent back for reference.
I have tried setting the MessageID, whereby using Outlook, the In-Reply-To value is set with the original ID, however using some webclient email systems, that value is not created on reply. Is there another way to sent this info through email headers?
Some variation on VERP is probably the most reliable...
http://en.wikipedia.org/wiki/Variable_envelope_return_path
Specifically, instead of having all your replies coming to the same address, encode the information you want to persist into the From address for the email.
For example, in the case of a helpdesk ticket, you could use something like:
From: Helpdesk <support-ticket-123#example.com>
To: End User <user#example.org>
Subject: Ticket #123 - problem with computer.
That way, regardless of what the user edits in the subject or text, you know what ticket is being referred to by the receiving email address.
I don't think you'll be able to do anything that is perfectly reliable by headers alone -- the number of clients that would have to cooperate is immense.
Most systems that do this work by including something in the body of the email that is sent that allows it to identify the message, and including text instructing the recipient to include that block of text in the response. You could also try including it in the subject (and including text in the body to leave the subject unchanged). That's how some mailing list managers I've seen do it.
I stumbled upon this question, and it's been very informative. This, however, leaves me with one question: Will using VERP, or a variation of editing the 'reply-to' or 'from address', cause the messages to be locked up in spam filters?
I have read that spam senders often change the bounce address to prevent their servers from getting clogged with bad email address bounces. Is it a spam risk to assume this approach?
The most reliable way is to put the ID in the subject, which should be preserved throughout replies.
(It doesn't hurt to tell your users that they should keep the subject intact.)
RT, a popular ticketing system, does this. They use a simple subject format like "[Ticket #123]" and key off of 123.