Is it possible to reply to an email that I previously sent the user using AWS SES? I don't see anything within the documentation that would accomplish this.
So I want to:
(1) Send email to email address X
(2) Reply to email thread from (1)
With more complicated mailing schemes, filling the "References" and "In-Reply-To" headers of the proceeding message with the "Message-ID" generated by SES for the first message can nudge email clients to keep both messages in the same thread.
For instance, my use case was Alice referring a client to Bob. First, I wanted to send a message from Alice to Bob with the client's info (not seen by the client); then a message to the client, from Alice, CC'ing Bob, introducing the client and Bob.
I think it will not be possible, as a reply is nothing more than a new message that email clients decide to group by some criteria (eg: title and sender). You can try to send a new email with "RE:" before the original title and test if your most common clientes (corporate email, gmail, outlook, etc.) group as you expect.
Using the same subject counts as a reply within gmail.
Related
I am building a ticketing system where users can raise a support ticket and agents can reply to the particular ticket and when the agent replied to a particular ticket I will send the reply to respective user email (email service using SendGrid).
My question is when the user replied to the agent email I will fetch that email with SendGrid inbound parser but I am stuck that how to uniquely identify for which ticket user has replied. I have two ideas attaching JWT in the header or unique email address resemble ticket id (ticket-id-2654654#example.com) but I don't what will work
You could send a custom Message-ID Header (RFC 2392) with your E-Mail. Responses to your E-Mail should then contain a References and/or In-Reply-To header containing the Message-ID of the E-Mail that was answered.
Edit: Just tested it with Zendesk and Zammad. They both seem to identify responses in that way.
You mention having a unique email address, not unlike a VERP (Variable Envelope Return Path) address. VERP is most pertinent if it's dealing with bounces, since it refers to the address used for the SMTP MAIL FROM:,
MAIL FROM:<ticket-id-2654654#example.com>
in particular it is helpful to identify which emails bounce - the email likely never arrives in a mailbox at the remote end. Note that the address used during the SMTP conversation like this will be recorded at the top of the received email with a 'Return-Path:' header.
Assuming an email doesn't bounce then how to ensure an email with a recognisable identifier comes back:
MysteriousPerson's custom Message-ID: header suggestion is excellent; also specify a VERP address in a Reply-To: header - so one or both of the identifiers you put there should be found in the reply to decode which ticket/user the original message was sent to. You have the choice of using the same VERP address in the From: header or something more human-friendly, depending on what you want the recipient to see. Since Reply-To: is specified, client software will use that for replies.
The main RFCs on SMTP and message format are likely to be helpful if you're not already aware of them.
We send an automated email whenever someone signs up for our app.
The subject is always the same for every user.
Let's say the subject is 'Welcome'.
The problem is that whenever someone replies, it always end up in a single giant thread in gmail.
So the emails from various users are interleaved with each other, which makes it very difficult to manage.
What we want is a single thread per user (i.e per recipient email address) so that we can keep the conversation with each person separate.
I'm aware that gmail has its own way of grouping messages into thread based on the subject line by default.
However, we noticed that some support tools (such as Zendesk) have somehow find a way to keep each email separate even though the same subject line is used. They seem to have a work around.
What I mean is that we have received multiple emails from the Zendesk email sender with the same subject and somehow they end up in multiple threads in our gmail.
They don't seem to use a uniquely generated email either. The from and reply-to address is simply support#domain.com
How do they do it?
We experimented with the 'Message-ID' and 'In-Reply-To' SMTP headers but were unsuccessful.
Sending emails with different Message-ID still end up in the same thread.
See example of a Zendesk email received to my gmail address below:
Since I can't post in the comment, will add to the answer here. Sample headers in an email I received from Zendesk. Note that they use the support email address + the ID of the support ticket as the 'Reply-To' address.
I tried to send an email through sendgrid. I have a custom domain myself#contoso.com. If i try to send an email to user1#gmail.com with the from address as myself#contoso.com,then,the email is delivered to gmail with "via". When i try sending email to myself#contoso.com with the from address being myself#contoso.com the activity says the email is delivered however, in outlook client i have not received the email. What is it that I can try or do?
I have tried whitelisting contoso.com but it did not work
This is not an answer, as it doesn't help work out why the emails that are "Delivered" have not been received, but this is SendGrid's note on why Email messages with the “Delivered” status are not received:
Twilio SendGrid posts the Delivered event after the destination server accepts the message with a 250 OK response. Once an email is accepted by the destination server, we are unable to see what happens to the message. The receiving server could send it to the inbox, queue it for later delivery, put it into the spam folder, etc.
Often times, a recipient domain will initially accept a message for delivery, and then apply additional filtering afterwards. In this situation, we would have posted the Delivered event, but not have any insight into the additional filtering. Any additional Twilio SendGrid events for your email message would be triggered by recipient engagement (i.e. open/click events, unsubscribes, etc.).
Also note that at the time of writing, that answer had 26 downvotes (and zero upvotes) on the SendGrid website, probably indicating that many other users have experienced this problem.
I had several issue solving this problem. The most important part is to set "Sender Authentication" from sendgrid to your domain dns. There is a instruction here. I'm using godaddy, so the link to set dns is https://dcc.godaddy.com/manage//dns .
I have a service that sends out emails and listens to replies. I need a way to reliably pair each incoming reply with the correct outgoing email. Is there any way to embed some key in the outgoing email that will persist, so that when the recipient clicks "Reply to" in his email client, his reply will retain this key?
So far, my best bet is "faking" the from address in the outgoing email, so that the username is an ID (e.g. from=41541#domain.com) and the reply comes to this email. However, the obvious downside is that I have the added configuration effort of forwarding all incoming email from those non-existent email addresses to the one real email a, e.g. incoming-mailbox#domain.com.
Every email has a unique mail ID. If you didn't give it one when you sent it the next mailserver will do it. See http://en.wikipedia.org/wiki/Message-ID
The response has that message-id in the In-reply-to header. Example - see here.
Best reference is the RFC 5322 "Internet Message Format", section 3.6.4: https://www.rfc-editor.org/rfc/rfc5322#section-3.6.4
This depends on all parties involved doing the right thing, but for the most part they'll do so these days. Of course, some software or human could send a reply without correctly set in-reply-to header, but that's the exception. When I write a reply to an email and use "New Mail" instead of "Reply", for example, my email of course won't have the in-reply-to header.
We have an application that allows users exchange messages, and delivers the message through email. But we don't reveal sender's email, instead; every time a message is sent out a new email address gets generated for the "From" field. Something similar to the way Facebook or LinkedIn send out messages.
Everything works fine, except the recipient's email client caches all these email addresses.
For instance, if Jack sends two messages to Jill, the sender's addresses can be: a123#FakeEmail.com and a456#FakeEmail.com, so next time Jill composes a new message and starts typing Jack's name, the email client suggests two addresses for Jack.
So my question is, how we can prevent email caching on client's machine? Is there something similar to HTTP header Pragma: no-cache for SMTP?
Thanks
Nivresh
OK, here is what I ended up doing. To prevent Outlook and other mail clients from suggesting several dummy email addresses generated for the same contact name, I add a special character to the beginning of the sender's name. This can be a space or if you use Unicode, you can add a zero-width space (\u200B) to the beginning of the name.
So in my example, the email is sent from "\u200BJack" which will be shown as "Jack". The dummy email address will be saved in mail client under the name of "\u200BJack" and when the recipient later on tries to send an email to Jack, email client won't suggest this address.
Hope this helps someone.