I have been playing with email headers. I am trying to include a record identification number in the email header so that if I send an email and then it is replied to, the reply that I receive will be automatically allocated within my email client based on the record identification in the header.
When I have tried to do this, on reply to my email the original header including my record identification is deleted.
Is there are better way to do this? I was thinking I could just add it to the subject however I would rather the identifier be invisible to the user.
Address tags might be what you're looking for, if your email client supports it. You would put the tag in your reply-to address, not in an email header. I don't think you can expect your headers to remain in the reply.
Matching replies with the original message is exactly what the standard Message-ID: header is for. It's a unique string that identifies the email, and it's generally included in replies. You needn't -and shouldn't- invent any new headers nor any special processing of existing headers for this. (If you want to understand all the gory details, look at the email RFC documents.)
If they're not displaying for you, the problem is not that the information isn't there, but rather that your email-program isn't very smart. (Or maybe you have to turn on some option in the email program...)
Related
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.''')
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.
I'm writing an app which allows users to send out a text-only email to a bunch of recipients. I want to try and generate the subject of this email from the body of the message, to avoid the need for a subject field
Is it safe enough to do this? Are these emails likely to fall foul of spam filters?
I'm already scanning the entire email for spam words, so there won't be any in the subject
you could download the widely used spamfilter Spamassassin and search for 'SUBJ' in the *.cf files, this will give you many spamrules that trigger based on subject (like empty subject, all caps, bad words, bad encoding of non-ascii characters etc)
I would suggest that if the mail is from a trusted source then there is not a problem. On the other hand since the mailbox dosent know that the subject is generated automatically it does not matter to them. And the third thing is that you need to check the guidelines that the email filters follow. Check out some ope source mail filter.
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.
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.