Capture email sent with outlook from browser - c#

I want to be able to capture a email that gets sent via outlook and initiated from a browser mailto link so that I can save a copy back to my web application.
I can get buy with c#, I am currently building a web application using c# but would ideally like it to be possible to do from a php application without needing to rely on a specific web browser.
So far it seems that my best option will be to build an add-in for outlook that can detect the relevant flag and save a copy of the email once sent back to the application via a webservice connection.
I don't have a great deal of experience dealing with Office add-ins and am interested to know if I can pass custom information through the mailto link and then read it using the add-in when new message is started.
I also seem to have an issue where I don't have access to certain information while the email is being composed and don't have a reliable way to match that particular in-composition email to the email that gets saved in outbox then moved to inbox.
I am working with Visual Studio 2010 and Office 2010 at the moment.

You can't do this normally because when you supply a mailto link you're actually requesting the default mail program on the user's computer to send the mail. Because you don't know (and shouldn't be willing to know) which program this is you have no control over the mail sent.
One solution would be to have a special page in you web application in which your user can compose it's email. After composing you could supply this format to the SMTP server for delivery and you could store it wherever in your webapp you like. The point here is that you want to stay in control and having a mailto link will send the control over sending an email to a different program.

Related

jquery ajax call not working inside gmail [duplicate]

Is JavaScript supported in an email message?
http://en.wikipedia.org/wiki/Comparison_of_e-mail_clients
Old clients, such as Lotus Notes, Mozilla Thunderbird, Outlook Express, and Windows Live Mail all seem to have supported some sort of JavaScript execution. Nothing else does.
It seems like a bad idea security-wise, so I would expect this to be a feature that won't always be around, even in these clients.
Short answer
No
Descriptive answer
It depends. But the email is not guaranteed to behave in the way you want it to. Different email clients handle JS differently. Most of the newer email clients do not support any of it since it is potentially very dangerous to support script execution in a desktop application which contains so much of your personal info.
I had a use case where I needed to use JS in an email. I tried out on the web client of outlook and desktop client as well, and it turns out outlook just wipes out the script part of your HTML email. There might be some other email client which does support JS execution, but given that you cannot control the client where your email would be viewed in the client machine, it's not a good idea to embed any scripts in the HTML email.
Its advised to keep your HTML email as simple as possible, no JS, and the least CSS you can do with (because, again, different email clients have varying support for CSS as well) eg: outlook's web client was not even recognizing an HTML button tag in the email. I had to use an anchor tag and some CSS on top of it to mimic the display of a button.
Bottom Line - Don't rely on Javascript when working with HTML email content.
No, generally speaking email readers do not allow javascript.
Other answerers have suggested that the answer is "No."
On the other hand, an html attachment will probably get opened in an environment that runs Javascript.
EDIT: It was suggested that I haven't properly answered the question so here goes a more complete effort.
Summary: I would expect that many or most users receiving an html-formatted email containing embedded Javascript will see it run and have run tests to confirm that this is true in some environments. But Javascript WILL be blocked for some users.
The protocols (specifically RFC2854) explicitly address scripting (within the text/html message body type) with the statement that:
In addition, the introduction of scripting languages and
interactive capabilities in HTML 4.0 introduced a number of
security risks associated with the automatic execution of programs
written by the sender but interpreted by the recipient. User
agents executing such scripts or programs must be extremely careful
to insure that untrusted software is executed in a protected
environment.
So the protocols do support Javascript, but which user agents do?
My (ancient) email reader uses a table to specify which viewer software to use for each mimetype, diverting html content to my favorite web browser. Almost all current web browsers support Javascript (and some issue dire warnings when you try to turn it off!) Do modern email agents include internal html interpreters and, if so, is the javascript turned on or off? I've checked documentation on Thunderbird and find that javascript seems to be turned on by default but can be turned off: http://codeverge.com/mozilla.support.thunderbird/simple-html-tags-reference-docume/2030160
I have noticed that some (?many?) users now access their email from a browser directly (webmail is one such platform) rather than running separate email software. All such platforms which I have tested so far do run any Javascript embedded in the html of the email message. However some such environments, depending on user security settings, do not automatically fetch external links (Javascript or pictures or other) and so can only run external Javascript from a file which is included as an attachment to the message. The same would be true of any offline email reader on a device without a current internet connection.
The above applies to javascript embedded in the main message part of the email body. One can also have html explicitly given as an "attachment", which if saved and then opened would be displayed in a web browser, wherein Javascript is available with very high likelyhood. Therefore, one might included a second copy of the javascript enabled email as an html attachement with an alternative text/plain main body and/or tag in the main text/html directing the user to the attachment.
I've been thinking about this because some of my acquaintances insist on sending me "email greeting cards" which consist of a text message directing me to a link which I've found so unsatisfactory that I refuse to even consider loading it just on principle. I have written and sent email greeting cards with interactive graphics and music and even games using embedded javascript and been satisfied with the result.
Therefore, I maintain that the correct answer is "Yes" both on the grounds that the protocols specifically address scripting and on the grounds that all the email agents I personally use ran the Javascript in my test emails.
You aren't going to get executable JavaScript onto a server and into a mail client. But emails DO support links, you can always link to your content within an email.
For most mail clients, no.
No email client support javascript due to security concern
Try to send a mail with this HTML content
<!DOCTYPE html>
<html>
<body>
<button onclick="this.innerHTML=Date()">The time is?</button>
</body>
</html>
It may be, but mail clients won't read it & mail servers may reject it. So leave it out.
Javascript is not supported in emails.
You can view an email with JavaScript working with Windows Live Mail, but can't add JavaScript to a new email you wish to send.
JavaScript also works with saved .eml files.
Mozilla Thunderbird version 60.7.0 can't view or add JavaScript.
(If you save an eml file with Thunderbird, the code will work if file is then loaded with Live Mail)
You can send an email with JavaScript using PHP code.
Some email websites may support it, but the few I used don't. (AOL, uk2.net, GMail)
Short answer: No it is not supported in an email message
Long answer:
I have tested it with two email readers. Outlook (online) and OE Classic. As OE Classic is very outdated (I use it on windows 7), it does support JavaScript and I tested it with an alert button. However, the newer Outlook does not even support buttons, which showed up as plain text. So to conclude JavaScript is only enabled on some, usually older, email readers but not on new ones such as Outlook.

Doubts about a Bug/Error sender via email

I'm developing a open source project. This project is getting bigger and may fail and crash as normal, so I tought of doing a crash sender to get the errors (if the user wants) via email.
But, since it's a open source project hosted in a easy to access site, I can't just hardcode the login and password of my software's email.
Do you guys have any better way to send crash reports (without having
a proper site, I'm using Codeplex) or a easy way to hide any password?
Instead of sending the email from the client program, create a web service (WCF or Web API) that it can call to send an email. Your web service will handle generating the email and will contain the login details for the email provider.
If you wanted to take the idea one step further, then your web service can hook into a database where you record various details about the crash (such as Windows Version #, relevant environment variables or registry settings etc). That'd give you an easy way to keep track of your crashes over time.

What is the best way to display an exchange mail message on an ASP.net web page?

I have a list of actions happend on an item listed on an ASP.net website. These actions are logged in a simple sql table linked to the item.
i.e.:
[2013-11-04 18:00]: Problem solved
[2013-11-04 18:00]: Called User
[2013-11-04 14:00]: Mail Received
For this, I will have to query the support mailbox for new mail messages. When a new message is received, a 'mail received' action is created. The 'mail recieved' entry should be clickable so the support user can see the contents of this message.
Question: How do I show this message to the support user?
Using Exchange Webservices Managed API 2.0 I can find this message and his body but the message body can have inline images and other layouts.
Options:
Show the message on the web page try to render the mail message the best way I can.
-> Are there any free plugins that do this? Something like this but that can be used in a web page?
Use Outlook to display this email message.
1&2 combined.. show a preview text-only message and click to see the whole message using outlook.
Since the support user will have Outlook 2010 or higher installed on his machine, the 3th option seems a logical choice but how can I display this message in outlook?
#{
HttpContext.Current.Response.AddHeader("Content-disposition", "inline;filename=message.msg");
HttpContext.Current.Response.ContentType = "application/vnd.ms-outlook";
}
#(new HtmlString(ViewBag.Body))
Obviously doesn't work.. a .msg file seems binary. Do I need an API for this?
But even when this works I will have these problems:
Every time you open a message you will have to click 'Open' to view this message.
-> Can I prevent this in modern browsers (primarily IE10 & IE11)?
-> Or are there 'inline outlook viewers' available?
When this support user answers this message using his outlook, this message will be sent 'from' his account. There would be no trace of this sent message!
-> Can anyone think of a way around this?
We are using an on-premise Exchange 2010 SP3 server that should be migrated to Exchange Online some time next year. Application is running on ASP.NET 4.5 using MVC 5.0 framework.
It could be solution to use this API to download messages as .msg file directly from Exchange server
Tinker with the different body types and retrieval methods. Info here:
http://msdn.microsoft.com/en-us/library/ee217562(v=exchg.80).aspx
See if any of them return something that's relatively easy to display, whether that be parsing the HTML body or showing the RTF body in the browser. I haven't mucked with this much and don't have an Exchange server handy or I'd check myself. If Exchange doesn't chew up the HTML when the message is send, you may be able to parse out the src="cid:contentIdOfAttachment" and replace it with a proper link to the attachment for display in the browser, but Exchange can do funny things to HTML and CSS.
And for clarification, by "support user", do you mean a support employee (ie, tech support) or someone who is receiving support and checking on the status of their ticket? If the message is to be shown and/or replied to in Outlook, would this person be accessing a single support mailbox (perhaps a public folder) or would the message be forwarded/copied to the person's individual mailbox?
If I'm getting this right, you'll be copying it to an individual mailbox, and from there it's "outside" the system, so the reply goes straight to the end user and skips the central support mailbox. You might be able to circumvent this by altering the message before it is sent/downloaded by changing the "from" to the central support mailbox. When the support user responds, it goes back to the central support mailbox, where you can have a secondary sync action (or even the same one that's fetching incoming mail) process it, change the to/from to send to the intended recipient from the central support mailbox, and send it off by using UpdateItems and saving it to the Sent folder. It's not pretty, but it should be possible. That's just off the top of my head, though, so there could easily be a better solution. And I'm operating on a few assumptions about the system you're working in, so maybe I have things a bit wrong.

Retrieving an imap account mail and then displaying the mail in asp.net

this is more of a sighter as to what i will need to complete this..
We have an intranet using asp.net, the idea is to retrieve mail and its attachments and then displaying this/these messages in a listbox/ or table of some description.
i will be using c# to compile this.
now the mail that is needed to be retrieved are faxes/from our fax account which we have setup in outlook atm,
-each of these faxes has an attachment.
-the attachment is a tiff file.
-so the end result is to get at the tiff file and to have it listed.
im aware that there are librays/class's out there tha will need to be attached/referenced, so this can work.
at the moment i have a brief idea of what is needed for this but i would like a list if possible the items/things i need to have.. a checklist if you will.
i have a very crude first attempt. im using the S22.IMAP set of librays from https://github.com/smiley22/S22.Imap
I take it this can be acheived someway or another.
If you're using Exchange >= 2007, you can retrieve data via Exchange Web Services (EWS) thus allowing your application to work without needing Outlook client on the system and all other issues with older-school approaches. I don't have any direct experience with EWS, but a co-worker tells me you can do whatever Outlook Web Access can.
EDIT
This other SO question addresses a similar issue, it's been answered with references to what I believe are the most popular libraries for IMAP.

Outlook Email via a Webpage

I have a web application developed with ASP.net and C# that is running on my companies' intranet. Because all the users for this application are all using Microsoft Outlook without exception, I would like for the the application to open up an Outlook message on the client-side. I understand that Office is designed to be run on the desktop and not from a server, however I have no trouble creating a Word or Excel document on the client-side.
I have code that instantiates the Outlook object using the Microsoft.Office.Interop.Outlook namespace and Outlook installed on the server. When I try to run the code from the server, I get a DCOM source error message that states "The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {000C101C-0000-0000-C000-000000000046} to the user This security permission can be modified using the Component Services administrative tool." I have modified the permissions using the Component Services tool, but still get this same error.
Is there a way to overcome this or is this a fruitless exercise because Outlook cannot be opened on the client side from the server-side code?
Mailto will not work due to the extreme length that the emails can obtain. Also, the user that sends it needs add in eye-candy to the text for the recipients.
You cannot open something on the client from server side code. You'd have to use script on the page to do what you're wanting (or something else client-side like ActiveX or embedded .NET or something)
Here's a sample Javascript that invokes an Outlook MailItem from an webpage. This could easily be injected into the page from your server-side code so it executes on the client.
http://www.codeproject.com/KB/aspnet/EmailUsingJavascript.aspx
(hint: formatting in your question)
I'm not understanding what's wrong with a mailto link or a formmail-type page.
If everyone in the company uses Outlook, then just using a standard "mailto" link should always open Outlook. It sounds like you're over-engineering this.
I'll just throw this out there cuz it's been asked.
Mailto has a lot of disadvantages; mainly size. Since the sender needs to do alot of formatting on the email text, the html code generated can take up a lot of space that fails when using mailto.
thanks for the suggestion though.
Do you want to open an existing E-Mail or create a new one?
Perhaps I misunderstood your question; could you provide a link like:
mailto:recipient#email.tld?subject=This%20is%20the%20subject&body=Hello%20there!
When the user clicks on that a link, a new Outlook-E-Mail will be opened and the:
Recipient: recipient#email-tld
Subject: This is the subject
Body: Hello there!
All these fields are already filled from the link.

Categories