A forum-like app I'm working on will send an email notification to the thread starter when a new replied is received. It would be nice if the owner can just reply the email to add a new reply to the thread.
How can I implement the feature, i.e. "reply to this email to comment" like Facebook?
Option A: scan the subject line/body? I don't like it 'cause what if the user modified the subject line by mistake?
Option B: use a unique reply-to e-mail address that links to the thread ID. Is this a common function for mail server? like set up a *#addComment.domain.com ? Or does the app server needs to setup a new email account before sending the email with reply-to?
Any other options?
Thanks!
Using strings in the subject and body can be easily erased by a user of the system.
Use plus addressing (reply+UNIQUEIDENTIFIER#yourapplication.com) as the REPLY-TO address in the mail message. With CFIMAP you can retrieve the messages and parse the TO.
Wildcard domain (replyto#UNIQUEIDENTIFIER.yourapplication.com) is also an option, but if your email server supports plus addressing I would go that route.
You could stuff the thread ID or the parent message ID (the message that is being replied to) in the Msgessage-ID: header of the email, or a custom email header, and put the processing after accepting the message.
However, using custom Reply-To: addresses is quite common.
an option is to embed an identifier in both the subject and the body of the original email. something small, like bit.ly's 6-8 character code. that way, they're less likely to mess it up, and you have the safety of the email body, which most people leave in anyway.
Using a custom email header is not advised as there is no guarantee that any server along the route would not strip it off (or simply fail to pass it on). A friend who worked at a huge email data center for AT&T said the techs there warned him off that idea.
This may also be true of the Message-ID: -- don't know.
Related
I've implemented List-Unsubscribe (RFC 2369) for marketing emails we send. I am providing both an unsubscribe email address and an unsubscribe URL. An example of a generated header looks like this:
List-Unsubscribe: <mailto:unsubscribe#myserver.com?subject=unsubscribe>, <https://myserver.com/unsubscribe?email=recipient#email.com>
In the past few email campaigns we've done, it has worked great. There's only one problem. Sometimes we receive unsubscribe requests from email addresses we didn't actually send mail to. I think this happens when the user has multiple email addresses and the email we send is forwarded to some other destination. So we send to user-a#email.com, but the recipient opens it at user-b#email.com. When they click the "Unsubscribe" link provided by their email client, it generates an email to us telling us to unsubscribe user-b#email.com.
Sometimes we can find the intended address if the address we sent to was very similar, or if the user has a unique name, but sometimes it's impossible to determine which email address we should unsubscribe. That's frustrating because we know the user will be upset if they receive another email from us in the future.
I tried to fix this by adding a unique identifier to the subject line, so that a subject looks like unsubscribe_20934832034820348, but when we do that, email clients stop showing the Unsubscribe button. It's as if they will only show the Unsubscribe button if the subject line is exactly "unsubscribe".
I didn't see anything in the RFC about the subject line needing to take a particular form, and we are also taking care not to put the user's email address directly in the subject line. (It is a hashed combination of their email address and a portion of the original message, making it unique across all emails we send.)
Is there some sort of convention around this? If so, how can I reliably determine the original address we sent to when we receive unsubscribe emails?
It looks like there is no problem using this sort of subject line. However, it seems that each email client decides in its own proprietary way when and how to display the Unsubscribe button/link, and it does seem that that when you change from a simple "unsubscribe" to "unsubscribe" plus some unique identifier, some clients might subject you to some sort of test period before showing the link to users. In my testing, Gmail did not show me the link when sending small batches of test emails, but after I sent a large batch of emails, the link did start appearing, and I did indeed receive the generated unsubscribe mails properly.
I hope this helps someone out there.
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.
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.''')
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.
I'm working on a web application. A user will create an email message that will be sent to another person.
I would like the e-mail that gets sent to appear from the user's name and e-mail address of the user on my system. And if they reply to the e-mail then it should go directly to the sender's email address.
However I am worried about the email message looking like spam to email filters along the way.
Is there a proper way to do this?
I noticed on a "contact" page on a WordPress blog that something very similar is done. The e-mail headers look like:
To: email#domain.com
Subject: [Test Blog] =?UTF-8?B?aGVsbA==?=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From:=?UTF-8?B?aGVsbA==?=<sender#senderdomain.com>
Message-Id: <20090207234737.39C9522802F3#web7.sat.wordpress.com>
Date: Sat, 7 Feb 2009 23:47:37 +0000 (UTC)
Return-Path: donotreply#wordpress.com
What is interesting is that the display name in the "from" tag and the name that shows up in the subject line is encoded. I do not know if this helps with the spam filters or not, but thought it was at least worth mentioning.
Also, who would receive an undeliverable notification in this example? Would it go to sender#senderdomain.com or would it go to donotreply#wordpress.com?
Basically all you need to do is set the From header to the email address of the user sending the email. The value of From is what is displayed in a recipient's email client. Most spam detection systems in place today look only at the message content, not the email headers, so you currently wouldn't have that much of a problem based on what you set the From header to.
However, there are some systems which are gaining popularity which could prevent you from sending email with somebody else's email address - most notably SPF, the Sender Policy Framework Basically, a mail server that implements SPF will check the domain of the From address of each email it receives and check with that domain directly to see if it authorizes the email. For example, if your server is mydomain.com, the email address of the user is abcdef#gmail.com, and the recipient is blah#example.com,
mydomain.com contacts example.com via SMTP to try to send the email
example.com looks up the SPF records for gmail.com
example.com checks whether mydomain.com is on the list of domains allowed to send email with the domain gmail.com
If it's not, the email is blocked
Also, I found a forum post suggesting that Return-Path is the intended destination for undeliverable notifications. Apparently that header is set based on the value of the SMTP MAIL FROM command.
Setting email fields is generally trivial, but the exact method of doing so depends on the language and framework you are using, which you don't mention. Usually it is a matter of creating a new email object, and just doing something along the lines of:
email.from = "From Name <fromemailaddress#example.com>";
You can set the specific from address to your user's, if you like, it is not at all uncommon though I personally am not a fan. You could also set the from field to something like: "Sender Name (via Your Site Name) <yourresponseaddress#example.com>".
Don't do this.
It really depends on how your mail relay is set up, but actually just don't do it. From header should contain the email address that sent the email, in your case webmaster#whatever.com. If you want people to reply to a different address, you can always use the Reply-To header. Here are some notes.
If I understand the standard (RFC 822) correctly, this is exactly what the Sender header is for (see ยง4.4.2. SENDER / RESENT-SENDER). Still, I'd go with a different approach and use your sites official contact address in the From header and put the user's address in the Reply-To header. Maybe add some boilerplate text that clearly states where the mail is coming from.
One further advice besides the technical stuff: don't let anonymous users use this facility, you'd become a perfect platform for spamming. Also, out of kindness, you probably want to make sure that your (registered) users know that their email addresses are exposed to the recipients.
Be aware that doing this will make spam filters more suspicious of your email. Combined with suspicious looking content your email may get filtered.
Whoever is in the "From" header will receive the undeliverable notification.
For the filtering - it really depends more on the subject and body of your message than the From address. So with that said, a couple ideas....
Use HTML encoding rather than Plain Text with simple formatting (I know there's probably an argument going the other way but in my personal experience HTML gets through more often)
Always include a footer with ("This e-mail was sent to you from ... blah blah") to identify it; if you don't want people to know it's coming from your system (i.e. really impersonated from the "From" user) then you need to find a more legit way to take care of the requirement.
If at all possible, use a real address from your system as the "From" address with the address of the user as the "Reply-To".