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.
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 have searched and see many people asking about verifying weather or not an email address is valid - and the overall answer I am getting is 'this is not possible'.
This makes sense, seeing how spam companies would take advantage of it. However, I use MS Outlook client to send my emails manually, and if I send to an invalid email address, I typically receive a 'bounce back' email in response. What's the deal with this? Can't I use these bounce back emails to find the invalid email addresses I have in my system (I am already sending them emails for legitimate reasons and want to see if the email is still valid).
If that's the case, how can I do this in C#?
No, you can't. Not all email services send such a "bounce back" email in response to invalid email addresses.
Additionally, a "bounce back" email could theoretically be sent for reasons other than the provided email address not existing, and the fact that you received one doesn't necessarily mean the email address isn't there.
There really isn't a way to determine if a string of characters is a real email address (you can verify whether it is valid as an email address, but not whether or not it actually exists).
To answer the question you ask in your title, you would have to monitor the return address for incoming e-mail, and then somehow figure out if any received items are "bounce back" messages.
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.
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.
I have created a simple asp.net email form for a client, which is sending off emails using the SmtpClient class. It is very basic and works in most instances.
The form is used in a number of websites but it only works intermittently. The code always works and does not throw any exceptions, it just works correctly but intermittently and for certain clients, the email never reaches the To address. If changes to an external email (e.g. my personal Hotmail account) it works correctly.
We have asked the recipients to check their spam inboxes but to no avail. How would one be able to track this issue? How can I know that my clients asp.net server has sent the email (in which case the problemm is at the recipients end) or not?
Look at the headers in the e-mail you got in your hotmail account and see what the From: and Reply-To: fields are set to.
Then look through your source code to compare with what you're asking it to be set to.
You might be getting a bounce message from an SMTP server (yours or another one en route to the destination) and it might be sent to the From: address of the e-mail.
Check that you have code to handle exceptions, test with incorrect details and see what StatusCode returns.
Do you have control over the SMTP server, so you can access its logs and see what's going through it?
If not, can you set up an SMTP server that you can control, which just passes email on to the real server, but logs things.
Do you have the sender address set to something valid, so you can see if there are any failure messages coming back?
No answers, I'm afraid, but perhaps the questions will give you some ideas that may help.
If your clients are using Exchange server, then you can use message tracking to see what happened to the message. If they are using the built in IIS SMTP server, you can enable logging to see what is happening as well. Like the first post mentioned, check you message headers and make sure they are valid...
Can you access the mailbox that belongs to the From: address. Any delivery errors will be sent to that address.
If the From address doesn't exists, then that's a probable cause that the mail is not delivered. Some mail server check if the from address exists, in an attempt to block some spam.