We are experiencing a problem with Rich Text Emails that are forwarded as attachments having the ContentIDs being stripped from the attachments, which prevents us from correctly rebuilding the email message.
Here is an example response from EWS for a Rich Text Email with a picture
<t:ItemAttachment>
<t:AttachmentId Id="AAMkAGRlNWE5MTc1LTUyODktNDRjNi05NTcwLWZjZGM1ODNkMmUxYwBGAAAAAABtOoJbAYfVSZzEDvklEbbPBwBBckyCi9TiT4cjPa5DHYwwAAAAemCwAABBckyCi9TiT4cjPa5DHYwwAABknfz6AAABBgAEAAAAAAA="/>
<t:Name>Message with Attachments</t:Name>
<t:Size>97993</t:Size>
<t:LastModifiedTime>2014-06-10T13:19:25</t:LastModifiedTime>
<t:IsInline>false</t:IsInline>
<t:ContentId>F4880FA606E4DC9BBC5143C97C52AC554A3AE55B#1</t:ContentId>
</t:ItemAttachment>
Here is the same Email that is forwarded as an attachment:
<t:FileAttachment>
<t:AttachmentId Id="AAMkAGRlNWE5MTc1LTUyODktNDRjNi05NTcwLWZjZGM1ODNkMmUxYwBGAAAAAABtOoJbAYfVSZzEDvklEbbPBwBBckyCi9TiT4cjPa5DHYwwAAAAemCwAABBckyCi9TiT4cjPa5DHYwwAABknfz6AAACBgAEAAAAAAAGAAQAAQAAAA=="/>
<t:Name>Picture (Device Independent Bitmap)</t:Name>
<t:Size>5210</t:Size>
<t:LastModifiedTime>2014-06-10T13:19:25</t:LastModifiedTime>
<t:IsInline>true</t:IsInline>
</t:FileAttachment>
Of Note - Exhange 2010 SP2
EWS API v2.2 (also happens in 2.0)
My Questions are:
Is this intended behavior? (if so why?)
Is this configurable on exchange (not the correct forum - but still)
If it is configurable on exchange what are the implications of said configuration.
I'll be opening an MSFT Support Incident here shortly.
Steps to recreate:
New Message
Set Message to Rich Text
Attach Image
Send Email
Open Email
Forward as attachment to another Rich Text Email (this can also be done by saving the msg to disk and then attaching it manually)
I've delt with exchange alot when building an outlook addin. I'm talking about older versions of exchange and outlook but I have painful memories dealing with custom email sending and rebuilding. Especially with RTF.
Is this intended behavior? - my guess is yes and most likely because if exchange doesn't strip the ContentId, it might present a security issue or cause unintended behavior on the client. It would be difficult for the exchange developers to support tracking exchange emails attached to other exchange emails. It doesn't consider it an exchange item any more when it's an attachment, to exchange it's just another block of data.
Is this configurable? - I'm not sure as I haven't dealt with any of the newer versions of exchange lately but based on my answer to number 1, probably not.
If it is configurable on exchange what are the implications of said configuration? - see answer #1, my guess is security related and/or development difficulty.
You need look at the RTF contents of the message. But take note that in many cases the RTF body content is usually compressed with base-64 so you may need to decompress it first.
-
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 come into ownership of a ASP.NET MVC site that utilizes Biztalk 2013 to handle tasks like sending emails. I am completely new to biztalk so forgive obvious mistakes in this post.
Quick overview
The service is called through the application and then the orchestration calls a stored procedure in a sql db to populate some of values for the email (including html for the email) and then sends the email out.
I now want to add a pdf attachment to the email.
As a test, I added a pdf file to the server and then I have tried adding ActualEmailMsg(SMTP.Attachments) = "C:\\PDFs\\test.pdf";
ActualEmailMsg(SMTP.MessagePartsAttachments) = 2; to the message assignment expression shape as suggested in this post to no avail. (I also tried the physical path with only 1 "\" like "C:\\PDFs\test.pdf" and that didn't work)
I have ruled out the possibility of a lack of permissions from the service account to the PDF folder. The email sends correctly but no attachment is present. I am getting no errors in the code or in the event viewer on the server so at this point I am at a loss for what it might be.
After lots of googling I found the issue was related to the send pipeline. This thread got me on the right track.
In the send ports section of the BizTalk Admin Console of the app, the send pipeline was using a custom pipeline I believe was made by the previous owner. I changed it to the 'Pass Thru Transmit' type in the dropdown and it is now working.
I use the following pattern for sending Emails. I’m not sure but maybe you need to use the ActualEmailMsg(MIME.FileName) attribute for message in email.
ActualEmailMsg(MIME.FileName) ="Report_{"+FullFileName+"}.xml";
ActualEmailMsg(SMTP.CC)=ReportNotificationEmailAddress;
ActualEmailMsg(SMTP.Subject)="Report Notification Email";
ActualEmailMsg(SMTP.EmailBodyFile)=#"C:\...\ReportNotificationBody.htm";
ActualEmailMsg(SMTP.Attachments)=#"C:\..\ReportNotificationBody.png”;
ActualEmailMsg (SMTP.EmailBodyTextCharset)="UTF-8";
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.
Well, for my program(s) I'd like to let the user send me an e-mail with any errors. Instead of relying on a forsaken SMTP server, I decided to let the user use his very own e-mail client to send an e-mail to a specified address.
So what I need is:
A sender (should not be changeable) (example: mysupportemail#gmail.com)
An attached file (should not be changeable) (example: "C:\a file.log")
(Optional) A body (changeable)
I hope it is possible!
You can use the mailto command for this. See http://msdn.microsoft.com/en-us/library/aa767737(VS.85).aspx for more information. Some mail clients support attachments on this. See the comments of the MSDN page for some information on this.
The mailto protocol has limitations, such as not being able to specify an attachment (some mail clients support it, but it's not in the official protocol). Your best option is probably to use the MAPISendMail function to let MAPI do the hard work. See this article for details:
Sending files via the default e-mail client
I used this technique in the past, it seems to work perfectly.
Using mailto directly from you application cause potential problems. If you have specified mail account for receive e-mails you can be sure, that someone will use it somehow to sent you spam or thousands unwanted emails. In our company we struggled with this problem many times - at last, we decided to allow our customers to report problems in any other way - web page form.
Now, when customer click 'report problem' this option displays a form for reporting bugs in default web browser. Opened link include some additional information which causing partial fill of the form opened by customer. Now, we have an intermediate layer and absolute control on server side who report problem (ip) and we can limit reporting for specified users. Next advantage of these solution is that you can forward emails to different departments depending on what form fields are marked/filled with.
Well, I have found the perfect solution!
For those who want to see it...
http://social.msdn.microsoft.com/Forums/en/netfxnetcom/thread/a75533eb-131b-4ff3-a3b2-b6df87c25cc8
http://www.eggheadcafe.com/community/aspnet/2/10019665/email-through-gmail-in-c.aspx
Hi all (before closing based on the title, please read the bottom parragraph),
I'm having some small issues with emails being sent out from the C#/ASP.Net webapp that I'm currently developing.
We don't send emails out on mass, only to a single address, sometimes with a CC address.
The emails we are sending out contain one attached file, which is a single page PDF file (They are actually invoices in PDF format).
It's happened a couple of times that our emails have been flagged as spam. The content of the email is HTML without any images, and the HTML itself is not very complicated at all (Simply 4 p tags and an a tag with a mail to).
We have a company domain set up using the Gmail smtp server, and the email account with we use to send this email is called automated.emailer.
When created the System.Net.MailMessage, I am adding a simple name to the which is "XXX invoicing" (XXX is substituting our company name) using the MailAddress constructor which takes a display name, a replyto address of Invoicing#example.com and the from address is automated.emailer#example.com. The content has been checked against many sp
These emails are fairly important, so we need to do all we can to avoid them being caught as spam. I would appreciate any ideas on why these emails would be considered spam? It may be that, in order to make sure the IP of our domain matches the IP of the mail server, we need to install an exchange. This seems like a strong approach and I'd be keen to see if anyone has solved this problem in another way.
I have tried to ask this question with as much info as possible, to avoid this question being closed, since i've seen many questions regarding email spam closed with a reference to the below question, which I read, but didn't find an answer to my question.
How do you make sure email you send programmatically is not automatically marked as spam?
Probably better on superuser.com rather than here. But have you tried looking at SPF records? Might boost your credibility to spam filters.
I use the free service over at Port25. You send an email to their verifier address and get a reply with a pretty detailed breakdown of your ham score:
http://www.port25.com/support/authentication-center/email-verification/