Is ist possible for a user connected to Exchange Server via a client (Outlook Web App) to tamper with the e-mails in his mailbox (inbox, drafts, sent items ect.)?
Like modifying e-mail content (text, subject...) or properties (date, time, recipient...).
The core of the question is: If there is an e-mail in the user's sent items folder and this user did not have access to the Exchange Server (neither physically nor remotely, except for his standard user access), how sure (or probable) ist it, that this e-mail has really been sent on that date and time with exactly that text to exactly those recipients and that it had not been planted there at a later date?
Does it make a difference if that user only has access to his account via Outlook Web App or if he also has access via MS Outlook?
Outlook Web App is just a client so it won't allow you to modify a sent email or fake/import one as that is not a valid task for that client. You could do this at the API level using something like EWS or MAPI but that would require knowledge that most users won't have (but most likly they would have access to do it though). The Mitigation to this is if you have Litigation hold enabled https://technet.microsoft.com/en-us/library/ee861123%28v=exchg.141%29.aspx on the mailbox then any changes they did make to a message would be tracked and you would always be able to see the original version. Also if you looked at the message with a MAPI editor like MFCMapi or OutlookSpy there would be tell tails of somebody trying to fake a message like the Creation time not matching the sent time etc and other properties would most likly give it away.
One thing i would suggest is look at your Message Tracking log as they will tell you exactly what was sent and who is was sent to and the time https://technet.microsoft.com/en-us/library/bb124375%28v=exchg.160%29.aspx while these also aren't immutable it would take an administrative access to the server to modify.
Related
We have server-side synchronisation set up for our Dynamics 2016 on-premise instance, and it is correctly sending emails from a Case, and tracking replies from the customer. However, when an internal user replies using Outlook (without the CRM add in), their responses aren't being tracked. This means that the email conversation consists of an initial "outgoing" email, followed by only incoming responses.
The full scenario is:
Internal user sends an email from a CRM Case. Email tracked in CRM
Customer replies to email. Reply tracked in CRM and goes to internal user's Outlook
Internal user sends a reply from their Outlook. Reply is not tracked in CRM
Customer replies to email. Reply tracked in CRM and goes to internal user's Outlook
Is it possible to allow the Internal user's replies (point 3) to be tracked in CRM without installing the Outlook add in (i.e. so it also works from the Web/mobile versions of Outlook)?
I believe you cannot do this without Outlook client as per Jukka.
Without the CRM Outlook client you can’t get the information into CRM without copy-pasting it from one window to another in the aforementioned scenarios. No synchronization technology will help you here, since CRM is unaware of the item until it has been brought into its world. The “Track” button is a client-side feature that you can’t utilize with any server-side solution, which means there’s no way for a user to select an email, appointment, task or contact from the Exchange server that he or she would like to promote into a record in CRM. Since the the record wasn’t “born in CRM”, it just can’t find its way there.
Last resort would be Smart matching with Tracking token, which may help you in this scenario.
Update:
Customer reply is going to reach CRM through a monitored queue. You can read a lot & get clarity from the above link.
Deploying a solution like the CRM 2013 the server-side synchronization will take care of moving items like calendar appointments and contacts back and forth between the end-user client device and the central CRM database, but it only applies to items that already exist in the realm of CRM. What I mean by this is that the item was either originally created directly in the CRM application or it was received via a monitored location like an email queue.
Your expectation is right, it should be tracked. I would open a ticket with MS & solve this.
Once the item is in CRM, server-side sync can take care of tracking the subsequent updates to it. A re-scheduled tracked appointment will get updated with the new date, regardless of whether you change the date via CRM or your mobile phone calendar that’s linked to Exchange. An email thread with a tracked message and a tracking token ID injected into the email subject line will have the next replies automatically synchronized into CRM
I have heard back from our Microsoft Partner, and they say that this scenario isn't possible. By design, it'll only track incoming emails to CRM, or outgoing if sent from within CRM itself.
Note: This particular issue has significant impact on our customers, which translates to high business impact with direct consequences on revenue.
TL;DR.
How can our Office add-in for Outlook, when a user interacts with our add-in while composing an email draft, minimize the amount of time it takes before the EWS GetItem API will return an OK response for the itemId we receive from Office.context.mailbox.item.saveAsync()?
If it turns out that our add-in has no control over when the item will be persisted to EWS, then what could an end-user do to speed this up?
We are looking for either (a) a technical solution, or (b) messaging to instruct our customers on how to mitigate/fix/work around this issue.
End-User Impact
Some of our customers are unable to send emails using our Office add-in for Outlook, or have to wait an exceedingly long time (> 2 minutes) before their email will send.
Our Goal
We want all of our customers to be able to send emails using our add-in, without having to wait for an unreasonable amount of time.
Additional Context
Based on our logs and customer reports, this issue only exists in the Outlook 2016 for Windows desktop application. We have no evidence to suggest the issue is present in any other version of Outlook, including Outlook 2013 or Outlook for Mac, however it is possible that the issue may be present in those clients as well.
Overview of our add-in
Our add-in integrates with Compose mode to provide additional functionality while composing email messages, such as templates, follow-ups, open and click tracking, and scheduling.
Our add-in works in tandem with our SaaS product like this:
Our add-in sets EWS extended properties on the email message with metadata indicating which features are enabled on that message.
Our SaaS product, out of band, is configured to read from the customer's mailbox via the EWS API. When it encounters EWS extended properties our Office add-in has written, it triggers the code paths to satisfy the desired behavior.
Root Cause Analysis
The root cause of our problem is our interaction with EWS in Outlook 2016 for Windows. In order to successfully interact with EWS to read/write to a mailbox item, it must be aware of that item.
The documentation for Office.context.mailbox.item.saveAsync() says:
In Outlook Web App or Outlook in online mode, the item is saved to the server. In Outlook in cached mode, the item is saved to the local cache.
It goes on further to say:
Note: If your add-in calls saveAsync on an item in compose mode in order to get an itemId to use with EWS or the REST API, be aware that when Outlook is in cached mode, it may take some time before the item is actually synced to the server. Until the item is synced, using the itemId will return an error.
Thus, we have concluded that Office.context.mailbox.item.saveAsync(), although it does indeed return an eventually valid itemId, does not guarantee that any subsequent EWS interaction will succeed. So far, we have found no way to accelerate the process of the Outlook client actually making EWS aware of the mailbox item.
Mitigation
We have attempted to mitigate this problem by polling EWS GetItem to attempt to obtain a ChangeKey for the item with the itemId we receive from Office.context.mailbox.item.saveAsync(). While we have seen that this does eventually succeed, it may take a minute or longer before this occurs. That is simply far too much time for our customers to have to wait.
Understanding "online mode" vs "cached mode"
If the Outlook 2016 for Windows desktop client is in "cached mode", is there anything the user can do to:
…know whether the client is in "cached mode" or "online mode"?
…attempt to force the client into "online mode"?
There is no way to speed this up in cached mode. Unfortunately this is a limitation of saveAsync in compose mode. Some things of note:
1) The EWSId is only valid while the item is a draft. After it is sent, when the item is in sent items, it will have a new EWSId which is not obtainable from the Office.js
2) Could you save your information into the custom properties, instead of the EWS Extended Properties. (Office.context.mailbox.item.customProperties) https://dev.office.com/reference/add-ins/outlook/1.5/CustomProperties?product=outlook
These properties will be saved to the mail in the sent item, but will NOT be transmitted. Then could you find those properties
These are stored as a JSON dictionary on the item in Key/Value pairs. The name of the mapi property is "cecp-[extension id from manifest]" (in PS_PUBLIC_STRINGS)
https://msdn.microsoft.com/en-us/library/office/cc842512.aspx
3) It does kind of sound like a better way to solve this would be an Office.js function that gives write access to this? (though we don't completely understand your scenario). Request for new features should go through UserVoice:
https://officespdev.uservoice.com/forums/224641-general/category/131778-outlook-add-ins.
4) Being in Online Mode would greatly mitigate the time. A User can know whether or not he or she is in online mode, but an Add-in cannot.
https://support.office.com/en-us/article/Turn-on-Cached-Exchange-Mode-7885af08-9a60-4ec3-850a-e221c1ed0c1c
Additionally, the status bar will say "Connected to Microsoft Exchange" in cached mode, and "Online with Microsoft Exchange" in online mode.
Switching to Online mode, removes a lot of the benefits that cached mode has. Cached mode is default in Outlook 2016.
We have written an Outlook Add-in and it appears that when you add user properties to a MailObject while the user is composing it, and you then encrypt and sign it and the message is Sent, the message will end up getting sent as TNEF, despite imploring outlook to do otherwise through various settings and so on as described here: http://www.slipstick.com/problems/outlook-is-sending-winmail-dat-attachments/
So one of our clients has a contact who insists on encrypted communication and therefore our client now has an issue with this contact. Either they cannot use our Add-in to its full potential (having to avoid the functionality that adds those User Properties), or their contact complains about receiving mail with "winmail.dat" attachments.
I have since established a communication with our client's contact, and I am trying to establish what e-mail client they are using, and one thing I'm going to try is see whether they would be open to the idea of moving to another e-mail client that is TNEF capable, even if it's not Outlook. But my Google-Fu is failing me. I've googled "TNEF capable email clients" and many variations thereof "that can use" "able to" ... etc etc etc. Nothing gives me the result I am looking for, a simple list of non-outlook email clients that have native capability for handling TNEF e-mails they receive. Plenty of articles of tools to allow users to decode the winmail.dat attachments manually, sure, but no simple list of natively capable e-mail clients.
If anybody can help me with this one, it would be greatly appreciated.
Eudora used to support TNEF. Otherwise Outlook is the only one to the best of my knowledge.
I am trying to build a control that the user can use to send feedback to developer. I am using email as a delivery method and I leverage sendgrid email service for this. Now I want to know the users email address so I can respond back to the user's concern. I am not sure how to get the user's email in window 10. Any help or pointers please?
I would strongly recommend to use the sharing approach that has been introduced with Windows 8 - instead of writing and maintaining your own mail functionality and trying to access additional user data.
Have a look at the existing and built in e-mail functionalities. They make use of the user's connected mail accounts and the mail app. This way you don't need to worry about handling the message transmission or anything but rather hand the information over to the mail client. This way you also know how to reply back.
And as a bonus, the user can still access their message via the Sent Mails folder :)
There is a specific class for that, the EmailMessageClass (https://msdn.microsoft.com/en-us/library/windows/apps/windows.applicationmodel.email.emailmessage.aspx?cs-save-lang=1&cs-lang=csharp#code-snippet-1) as well as a dedicated guide with code example.
https://msdn.microsoft.com/en-us/library/windows/apps/mt269391.aspx
Essentially you can prepopulate the Mail fields with necessary app information where applicable. The user gets to choose which accounts he wants to send the mail from, but it will open in the mail client.
Is there a way to setup Outlook 2010 to run a script or some other form of sanity-check when you attempt to SEND messages from the client? My specific situation is that I use the same outlook client for multiple accounts (work, gmail, VPS server, etc) and I've found myself a couple of times sending emails "from" the wrong account.
In a perfect world I'd want to be able to write a script with logic something like the following:
when (I hit send)
if (the "source" account is "myuserid#gmail.com") then
if (there are addresses in TO or CC that match "work.com") then
pop up a dialog box that says:
"You appear to be sending email to work.com from gmail.com - do you really want to do this?"
if yes, then send it and return
if no, go back to the message compose window
that way, I'd have to actually very intentionally use a non-work email address to send email to the work people (which is rare in my particular case)
Try SendUsingAccount to read the "source" account in ItemSend.