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.
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.
What I am trying to do is, sending an email to one person but I want to add more email addresses in the TO field and don't want that users to get the email. Is it possible to somehow configure this?
Yes, this is completely possible. SMTP doesn't actually use the headers for anything; the envelope recipient list controls who actually receives a message (though many user-visible email programs will simply copy the To:, Cc:, and Bcc: headers into the envelope on submission).
Because you are not asking about any particular language, I won't post code which probably won't be useful to you anyway. In pseudocode, something like
s = smtp.connect(server)
s.ehlo()
s.from(envelope.sender)
for r in envelope.recipients:
s.rcpt(r)
s.data('''From: me#example.net
To: you#example.org
Subject: SMTP doesn't care
By the time SMTP transmits the actual message,
the recipient information has already been sent
separately.''')
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.
Just for knowledge purposes, I want to know if it is possible to know if email spoofing has been done successful or not . Suppose if I am sending an email from one's account, What if receiver doesn't exist? Means will i get any error as a spoofer that receiver doesn't exist and you cant send email . Thanks
There is no way to know for certain, but you can make an educated guess.
First, when sending an email to a non-existent recipient and the recipient's server is configured to report this to the sender (pretty much the default behaviour), this reporting can happen either:
1) During the email transmission. The SMTP conversation with the recipient's server may very well fail at RCPT TO: (i.e. when the recipient is specified) or at the end of the DATA or BDAT commands (i.e. when the email just have been transmitted and the server either acknowledges this or rejects the email). If you receive an 5xx-type response at either stages, or, well, anytime earlier in the conversation, you can be sure the recipient did not get the message. Validation during email transmission is common.
2) After the email transmission. Servers that don't do recipient validation on SMTP level will often accept and queue emails during the transmission, then generate a bounce report (also called a Delivery Status Notification/DSN or Non-Delivery Report/NDR) later and attempt to return it to the original message sender. As you have no access to the mailbox of the original message sender when spoofing, you will have no idea if such bounce report is generated. This method of validation is still fairly common.
Second, you can embed a tracking image in your HTML email to see if the email was opened. This works by placing a HTML <IMG> element in the email that points to e.g. http://example.org/tracking-1x1.gif?uuid=<id>. The idea is that you track whether that image was downloaded. Be aware that virtually all modern email clients will disable downloading images from unknown sources and some action is required from the recipient to enable downloading images.
Third, you can spoof the MIME sender only. Emails have two distinct set of addressee information: the envelope addressees and the MIME addressees. Emails are delivered based on what's written on the envelope, but email clients render the MIME information instead (what's inside the envelope). In other words, during the SMTP transmission you may specify a different sender address (MAIL FROM: command) from that in the email (From: header). The fun part is that bounce reports are sent to the envelope sender address, a.k.a. the Return-Path, so if you have access to the envelope sender mailbox, you can receive a bounce report no matter what stage it was rejected. Note that you will reveal yourself, either through the mail server logs or through the email header, where the Return-Path header will contain the envelope sender address.
Please use the above information for "knowledge purposes" only. Be aware that email spoofing is likely a crime in just about any country.
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.