Background:
I'm working on an Outlook addin which adds an attachment to outgoing emails. Support is required for all versions of Outlook.
When a MailItem has been signed with a digital signature, adding an attachment to this mailItem generally fails unless you save the mail item. This removes the signature from mailitem. To me, this is somewhat expected behaviour. Nothing weird here.
The problem is when the user turns digital signatures on (whether through the UI or as a Outlook default behavior) and then turns it off again. The MailItem is no longer signed but it still behaves as if it is -- we're unable to add an attachment to this email.
I found a newsgroup post which might explain why; it appears that objects retrieved through the outlook API aren't the actual objects.
http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.messaging/2006-02/msg00000.html
At the moment, I've given up trying to fix this problem nicely; saving the MailItem to a temporary file appears to fix this however for performance reasons we'd like to only save when a MailItem has transitioned from signed to unsigned. Another acceptable alternative is to detect whether digital signatures has been enabled by default or not. Though there is a registry entry related to the default setting of a digital signature, it is merely a suggestion and does not reflect accurately whether the email would have been signed by default or not.
Any ideas?
You can use redemption api library to call that method from C#.
Also have you tried creating a PInvoke signature from the extended mapi dll?
Turns out that you can use EMAPI in C++ to call IMessagePtr->SaveChanges(), which seems to work quite nicely. Unfortunately, you can't access this in C#.
Related
My Outlook web add-in saves emails to an external application.Upon save, it will also write some custom information to exchange server using Office.js's customProps.saveAsync();. So next time the user open the same email, the add-in will look up the properties and if it is not null will remind the user the email has been saved.
Work like a charm in web browser(Office 365).
However in Windows Outlook desktop, the function performs strangely. If I save the email and then immediately move the email to another folder. The customProps.saveAsync(); will fail(nothing saved to exchange server). However, if I re-launch the add-in on the email before moving out to another folder, the custom info will be saved successfully.
Seems to me on Outlook desktop the custom properties will not be written to the exchange server immediately, instead, it will wait until it is being triggered(re-launch add-in etc I do not know the exact mechanism). However, if the email being moved to another folder right after being saved in an add-in, the pending function will be lost.
I found this describing seemingly similar behavior. So I then turned off the "cache" mode in outlook but the problem persisted.
I also tried using EWS's API to perform the "save custom properties", but the problem still persisted.
Am I missing somethinghere or it is Outlook desktop's bug?
You are not missing something - this is definitely a bug in Outlook Desktop. Thank you for reporting the issue. We are investigating and will work on a fix as quickly as we can.
As a workaround in the interim, you can switch messages within the same folder in order to trigger a save. The workaround you found of re-opening an Add-in may also work.
I am writing VSTO Outlook add-in that needs to save some items as msg files. The problem is, each time I call MailItem.SaveAs it causes Outlook to lag slightly and show processing cursor (blue circle).
I have tried moving it int a separate thread, but that does not help.
Saving item is quite fast (less than 100 ms most of the time), but still causes this annoying behavior.
I need to save an item to read it as MSG format, so if I can do this directly this would be even better, but as I found here:
Outlook MailItem as Stream
the only solution seems to use EWS for this. Are there other alternatives?
Maybe using RDO can help in this case?
Another option, as I understand, create msg manually from mail item properties. But maybe there is an easier way?
Unlike OOM, a low level API on which Outlook is based on (Extended MAPI) supports multithreading. So, you can run the code on a secondary thread without any visible impact to the Outlook UI. See INFO: Save Message to MSG Compound File for more information.
Also you may consider using third-party wrappers around Extended MAPI such as Redemption.
I am trying to access all the mails in a given folder via the ActiveX interface to Outlook 2013. I use the message API (MAPI) of Outlook to get the desired folder object.
However, when I go through all the items of this folder object, many messages are missing. Indeed, there are messages that are on the MS Exchange server that are not synchronized with Outlook because they are too old. (In Outlook, the folder ends with a link named 'Click here to view more on Microsoft Exchange'. When clicking on the link, the missing messages appear in Outlook. However they are not added to the folder object after this operation.)
How to access those messages? Is it possible via the Outlook ActiveX interface? If not, is there an equivalent interface to the MS Exchange server?
To access older (but not archived) emails, you can either
Set the Exchange account to sync all items in the Exchange account properties dialog. Outlook must be restarted.
Set the Exchange account to sync all items programmatically. You can do that using Extended MAPI (C++ or Delphi only), there is a flag that needs to be set in the MSEMS store profile section (the property tag is 0x66490003). Redemption (I am its author - any language) exposes the RDOExchangeMailboxStore.MonthsToKeepOffline / DaysToKeepOffline properties. Outlook must be restarted.
Open the parent folder in the online mode using the MAPI_NO_CACHE flag when calling IMsgStore::OpenEntry (Extended MAPI, C++ or Delphi only). Redemption (I am its author) lets you pass that flag when you open the folder using RDOSession.GetFolderFromID from any language.
I've tried to download a signed executable
( http://live.sysinternals.com/procexp.exe )
and modify it. I've thought it can't be done and Windows will somehow prevent me from running it (or warn me at least). But when I change a single character (for example in DOS stub or any other text data) it is still runable.
Before modification, when I run this app it splashes UAC warning showing it signed Microsoft and asking whether I want to run it. After modification, there is no such thing. Even when I revert changes back, it still won't show up. I've compared modified and reverted executable to the original (in total commander) and it shows no difference. But the original still splashes UAC.
Why is that?
I'm using Windows 7 and Firefox.
I've never tried to do it. Yet when you edited the file, you invalidated the digital signature, you should see it in the Properties of the file.
Windows usually does not check digital signatures. Digital signatures come into play when the file is marked as downloaded from the Internet (if the signature is valid, Windows will show its publisher in the confirmation dialog; otherwise, the publisher will be unknown), and UAC (in this case, the digital signature also confirms the file came from a publisher stored as part of the digital signature).
Whether to show or not to show UAC confirmation is not controlled with digital signature, it's controlled with the application manifest.
So in my understanding, UAC dialog should be shown. But since the modified file fails digital signature check, Windows may decide the file is unsafe to elevate. You could look for messages in Windows event log, there could be events explaining the behavior you see.
I have copied chrome.exe in other directory and started writing random bytes in the application.
I checked properties , the digital signature was there. I have changed the application. It was unable to execute (giving some king of internal error not windows error) but still showing valid certificate in properties. Its strange.
I think windows validates certificate of an application only once.
After you change the file it will still show a digital signature but if you click on the Details button for that signature I think you will find that it says the signature is not valid.
When i changed it back to exactly what it originally containsed it once again told me that the signature was valid. (But you have to use an editor that edits the bytes in place - not one that might add a line break or something unintentionally.)
When automating excel using the Excel Interop API, I can easily do a range search using the method Range.Find. I am passing through the LookIn, LookAt, SearchOrder, SearchDirection, and MatchCase options for the Find. This as noted by the MSDN documentation, persists the values passed into this method into the user settings, so the next time that the user opens the find form, the options will be selected which I used in the Range.Find method.
I need to persist the values of the find options before and after I do the programmatic find. So I want to capture the current find options, then do the Range.Find, and then set the find options back to the options that were set before my search. However, I do not see that the find options are publicly accessible. Any ideas on how to get these?
I'm basically looking to retrieve current find option values for LookIn, LookAt, SearchOrder, SearchDirection, and MatchCase.
Update
The most interesting thing I could find so far is that you can access the Excel Application dialogs - Dialogs Interface. So here, I can get access to the FormulaFind dialog, which is slightly different than the Find and Replace dialog, though may lead to some of the properties I'm looking for. I haven't had any luck, but perhaps there's a way to access the properties through this form using reflection. I'll keep trying something with this.
// xlDialogFormulaFind, xlDialogFormulaReplace
Excel.Dialog dialog = this.Application.Dialogs.Item[Excel.XlBuiltInDialog.xlDialogFormulaFind];
Well, I am not sure if you'd consider this approach, but I'll give a shot here in case it might be helpful.
What I would do is, I'd create a registry key holding the values you wanted to persist. I could then call RegistryKey.GetValue(valuename) to retrieve values, provided that there's no exceptions thrown.
As long as that registry key stays there, unchanged, and you have enough privilege to access registry key, you should be able to always get the same values.
Wish we could really use application settings here, which would make it easier, but, well, as you might have known, vsto add-in doesn't like it, according to this article.
You cannot use application settings in an unmanaged application that
hosts the .NET Framework. Settings will not work in such environments
as Visual Studio add-ins, C++ for Microsoft Office, control hosting in
Internet Explorer, or Microsoft Outlook add-ins and projects.
Hope this helps.