I am writing a C# application to send emails with custom headers. If I send an email to someone with a custom header and they reply back, will it retain that custom header in the reply back?
Probably not.
The format or content of reply messages (as a special case of e-mail messages in general) is not standardized in any way; therefore, mail clients are free to include (or not) any part considered relevant. Headers are, in most cases, not preserved.
So: the header could be present in the reply, but it would be more of a coincidence than a certainty.
What you could do: embed some sort of identifier into the mail - e.g. into the Subject, the From address, or perhaps Reply-To, and save the specific headers you've sent on your side. Then, if a reply arrives, you'd be able to look up what they were for that particular message.
Related
I am trying to find a way I can use email headers to tie an email back to the database. Ideally, I would be able to send out an email and attach a custom email header with the ID of the database object, and then when I get a reply back from the email we would still have that header so we can match it.
Does anyone know if this is possible? I'm absolutely fine with the code side of how headers work it's just how they actually work in the real world.
It is possible, but whether it will work or not for a particular recipient is not under your control.
IETF RFC 822 stipulates the use of an X- prefix for vendor- and application specific headers, much like indie MIME types could be allocated.
Mail relays and mail clients will leave or remove such headers at their discretion. You have no means to force those headers to be retained in a reply or forward scenario.
In real-world applications that have the same requirement to refer to a database Id value (support ticket portals coming to my mind first), it is often seen that they include the GUID in the subject line and mention in the body text that the recipient should not remove or change that value lest they disrupt the automated processing of replies.
This approach is superior to the x-header in many ways:
it does not hide the fact that there is additional information transported on behalf of the recipient
it will not cause spam filters, mail relays and mail clients to automatically strip that information without the sender or the recipient noticing
it leaves the recipient free to decide if they want to forward or reply to a mailbox different from the sender's, including or excluding the Id as they see fit
If you're going to stick with the headers, look into Thread-Index and Thread-Topic. Here, as so often, Microsoft has introduced application-defined attributes without the standard prefix, and there is a chance that these are transported back with replies more reliably than x-headers just because they've been around for a longer time - ymmv.
i am working on an application which send email with custom internet header info in it which is used to identify mail type it has been sent.
for example, if i sending for option A it will be my custom tag with value 1 or if i send for option B it will be my custom tag with value 2.
if the customer reply or forward to that mail, i need to identify for which mail type is replied or forwarded (i.e., it is for option A or Option B). so i need to carry the custom internet header info in reply or forward mail also. any option available to carry the custom internet header in reply or forward mail or is there any alternative approach to do this
I assume that you have already developed the part where customer can select the options.
Reading mime headers you can try this: Get email Headers from an Outlook MailItem
I have difficulties implementing the following scenario.
Let's say you have a web site with ability to send and recieve messages between users.
User recieves an email with notification he has a new message on the software system (doesn't matter in what it is implemented). He can respond to this message by sending a reply via email or by logging into the site and replying to the 'message' using the site.
In case of the first approach if user simply replies to the email notification, how can you (as a developer) know what 'message' (ID) is the reply for?
I'm thinking the info would be stored in the MIME extensions. Are the MIME extensions transfered to the reply of the message? If yes than the solution could be to see the data of the original message notification for wich the user replyes to.
Any ideas? Thank you
The only “reliable” way would be to encode that information in the sender's address to which the user replies; you could also put it into subject or body of the message, and “hope” that the user doesn't tamper with it. There is an “in reply to (message-id)” header, but a lot of existing eMail clients don't set the header properly.
The usual mechanism is something like this: create an eMail alias prefix, and the append a message-id-code fragment to the end; for example, if this was for a purchase order confirmation, you could create an eMail alias handling addresses of the form po-*#example.com, where * is the unique message ID. Then, when you send your message out, you'd put the appropriate address in both the From: and Reply To: headers. EG:
From: "Purchase Order Confirmation (#1234)" <po-1234#example.com>
To: "John Doe" <jdoe#example.com>
Reply-To: "Purchase Order Confirmation (#1234)" <po-1234#example.com>
Subject: Confirm your order (#1234)
Depending upon your mail server, you should be able to define a “separator” character (typically - or +) that is used to split up the parts of the “local part” (left of #) of the eMail address; there is typically then another mechanism to map a prefix to a script to handle all addresses of a certain form. The script interface is often very much like CGI on the web, sending in some environment variables and piping the message itself in on the standard input. If your app is primarily web-based, you might find it more “comfortable” to gather the incoming eMail body, and POST it to a private (perhaps http://[::1]/getMailReply) handler. This may help you reuse existing code more readily.
We have set up a catch-all email address on our server - for example catch-all#myserver.com. When we send emails to users, we encode the message id and any other meta information we may need in the from address. You can obfuscate this or not, depending on what your needs are. So, for example, if the user has a new message in the system whose ID is 100, the from address of the email we send to the user would be something like reply-to-message-100#myserver.com. Make sure that whatever format you use for the from address would never generate a real email address on your mail server.
So, when the user responds to this message, it will get sent to the catch-all inbox you have set up. From here, you have a number of choices to make on how you process this email. In times past, we wrote a little scheduled service that would run every few minutes and check this inbox for new emails, process them as you like (insert into db, send more emails, whatever), and delete the message since you're done processing it. This is fragile since email clients all have slightly different ways of sending emails and it becomes difficult to parse the variety of client messages out there.
The second way we've done it is by integrating with http://postmarkapp.com/ - which has an incoming email api that should go public soon (we got in on the beta). You'd set everything up the same way only make your server's catch-all address forward to the postmark incoming address you'll set up with Postmark, and then Postmark does the message processing and calls a webhook you also set up to do what you like with the object received.
I highly recommend Postmark, but even the homespun method worked effectively, for the most part.
-M
Just a followup to the previous answer, Postmark Inbound is now live and public http://postmarkapp.com/inbound For each email sent to your specially formatted inbound email address, you'll receive a JSON formatted web hook API call with all the email components, headers, attachments sorted for you.
When sending HTML e-mail, I understand that it's a best practice to send a plain text version as well.
But my question is: Must you send a plain text version as well?
What are the repercussions?
At least as far as Outlook 2007 is concerned, there are no reprecussions. We have an internal app that sends out emails in HTML format only and Outlook doesn't complain and renders the HTML content.
Sending an email with a plain-text version is simply common courtesy to support email clients that either don't support HTML format, or have their client set to render plain-text only. It's actually more prevalent than you may think so if you can either ask the user their preference or send both.
You never have to. If the recipient however, is unable to receive HTML emails or their client does not support them then chances are the HTML will be displayed as plain text. Also, some email providers/clients like Verizon, GMail or Outlook will strip out certain tags so you HTML is malformed.
Ideally you should collect the user preference of email and send the email based on this preference, it is impossible to guess what they prefer. This is not so much a best practice thing as opposed to a user preference, though it is rare now that users have email clients incapable of rendering html content, this does not preclude however email clients blocking html content (like GMail, Outlook) unless explicitly allowed by the user.
On my humble opinion you must think on the receivers of the mail you are trying to send. I mean, if they have Mail User Agents that support a given format or not.
Also, you should be aware of making a compatible HTML e-mail otherwise it won't be interpreted right on every Mail User Agent.
Hope that helps,
Think that, for example, Gmail interface shows in the header the first lines of the e-mail, and Outlook does too, if you send an HTML e-mail without plain text version, the text won't be displayed, at least in my case.
What I've seen from dozens of e-mails is that they normally include a line that tells:
If your e-mail client doesn't support HTML go to http://....
Another thing that I can tell you is that, for example, the iPhone downloads first the plain text message, and later the html formatted one.
I am sending emails to clients in three different locations, using a common email address. Any errors/ out of office replies should go to local offices for them to deal with. So I use:
from: common#abc.com
reply-to: london#abc.com
from: common#abc.com
reply-to: newyork#abc.com
from: common#abc.com
reply-to: tokyo#abc.com
This seems to work well for email fails (wrong adddress, etc.) but Out of Office replies from Exchange always go to the sender address, common#abc.com. I need them to go to the local office, reply-to address.
Any idea how I can solve this? I am sending the email from c#, using the standard MailMessage:
MailMessage mail = new
mail.Subject = mailDetail["subject"].ToString();
mail.Body = mailDetail["body"].ToString();
// From
mail.From = new MailAddress(ConfigManager.GetSetting("MailSender"));
// Reply to (boucebacks / out of office etc)
mail.ReplyTo = new MailAddress(mailDetail["reply_to"].ToString());
mail.DeliveryNotificationOptions = DeliveryNotificationOptions.OnFailure;
Thanks for any help,
Ryan
It's an RFC/Standard.
https://www.rfc-editor.org/rfc/rfc3834
Where to send automatic responses (and where not to send them)
In general, automatic responses SHOULD be sent to the Return-Path
field if generated after delivery. If the response is generated
prior to delivery, the response SHOULD be sent to the reverse-path
from the SMTP MAIL FROM command, or (in a non-SMTP system) to the
envelope return address which serves as the destination for non-
delivery reports.
If the response is to be generated after delivery, and there is no
Return-Path field in the subject message, there is an implementation
or configuration error in the SMTP server that delivered the message
or gatewayed the message outside of SMTP. A Personal or Group
responder SHOULD NOT deliver a response to any address other than
that in the Return-Path field, even if the Return-Path field is
missing. It is better to fix the problem with the mail delivery
system than to rely on heuristics to guess the appropriate
destination of the response. Such heuristics have been known to
cause problems in the past.
A Service Responder MAY deliver the response to the address(es) from
the >From field, or to another address from the request payload,
provided this behavior is precisely defined in the specification for
that service. Services responders SHOULD NOT use the Reply-To field
for this purpose.
The Reply-To field SHOULD NOT be used as the destination for
automatic responses from Personal or Group Responders. In general,
this field is set by a human sender based on his/her anticipation of
Moore Standards Track [Page 12]
RFC 3834 Automatic E-Mail Responses August 2004
how human recipients will respond to the specific content of that
message. For instance, a human sender may use Reply-To to request
that replies be sent to an entire mailing list. Even for replies
from humans, there are cases where it is not appropriate to respond
to the Reply-To address, especially if the sender has asked that
replies be sent to a group and/or mailing list. Since a Personal or
Group Responder operates on behalf of a human recipient, it is safer
to assume that any Reply-To field present in the message was set by a
human sender on the assumption that any reply would come from a human
who had some understanding of the roles of the sender and other
recipients. An automatic responder lacks the information necessary
to understand those roles. Sending automatic responses to Reply-To
addresses can thus result in a large number of people receiving a
useless or unwanted message; it can also contribute to mail loops.
Use of the From field as the destination for automatic responses has
some of the same problems as use of Reply-To. In particular, the
From field may list multiple addresses, while automatic responses
should only be sent to a single address. In general, the From and
Reply-To addresses are used in a variety of ways according to
differing circumstances, and for this reason Personal or Group
Responders cannot reliably assume that an address in the From or
Reply-To field is an appropriate destination for the response. For
these reasons the From field SHOULD NOT be used as a destination for
automatic responses.
Similarly, the Sender field SHOULD NOT be used as the destination for
automatic responses. This field is intended only to identify the
person or entity that sent the message, and is not required to
contain an address that is valid for replies.
The Return-Path address is really the only one from the message
header that can be expected, as a matter of protocol, to be suitable
for automatic responses that were not anticipated by the sender.
It's up to anyone/thing that responds to the mail to choose which property is most appropriate to use. The reply-to property should of course be used if it's a real reply, but an error message might not be seen as a reply, so the from property may be used for that in some cases. As you see, you will get different results depending on who/what is answering, and why.
You can use the Sender property to specify the actual sender as an addition to the from property. If it's handled properly, that is where the error messages should go if the reply-to property isn't used.