Emails are being encrypted using No-Reply Plugin RRS feed

  • Question

  • Hi Team, our users have been using the No-Reply plugin for quite sometime.

    Recently, we have implemented a GPO that auto-enrolls users for an email signing certificate.

    When users have this certificate and use the No-Reply plugin, the emails are automatically encrypted.

    We have checked to make sure the check box for encrypting emails is not checked under trust center settings -> email security.

    There is a direct correlation using this plugin and not using the plugin.

    Only when the plugin is used with a user having the email signing certificate it will encrypt emails.

    Are you aware of this issue or heard of it?



    • Edited by jpalmos Tuesday, March 8, 2016 9:36 PM
    Tuesday, March 8, 2016 9:34 PM

All replies

  • That's... unexpected...

    When you say 'using the plugin' do you mean if it's installed (vs not) or if you select one of the disable reply, replyall, forward functions (vs just having the add-in present but not interacting with it)? Not that I have a solution to the problem - just wondering which bit of code to start investigating!

    The add-in manipulates 'Actions' on an email to enable/disable the recipient's ability to perform some, well, action. Clutching at straws, I wonder if the signing stuff has caused that collection of Action objects to be changed such that, for example, reply is no longer the first, or reply-all no longer the second, etc. (The list isn't very well documented so I've had to experiment and keep my fingers crossed.) https://blogs.msdn.microsoft.com/gsmyth/2011/08/06/outlook-object-model/ talks a little about the Outlook object model and about a third of the way down is a fragment of PowerShell which dumps the Actions list: if you have time, could you perhaps run that and see if the list is in the same order as given in that article.

    Wednesday, March 9, 2016 7:03 AM
  • Hi Gavin, thanks for fast reply.

    When we select the disable reply feature this issue occurs. This can be replicated on outlook 2010 and 2013.

    When the reply feature is not selected the issue does not occur.

    I am out of the office today, I will try and have my colleague attempt your request. If he's unavailable I will do this first thing tomorrow morning and reply back with results.

    Appreciate your support



    Wednesday, March 9, 2016 4:55 PM
  • Hi Gavin, my colleague ran the script.

    Here are the results

    PS F:\> $outlook = new-object -com Outlook.Application


    PS F:\> $item.Actions | select Name,Enabled


    PS F:\> $inbox = $outlook.Session.GetDefaultFolder(6)


    PS F:\> $item = $inbox.Items.Item(1)


    PS F:\> $item.Actions | select Name,Enabled


    Name                                                                    Enabled

    ----                                                                    -------

    Reply                                                                      True

    Reply to All                                                             True

    Forward                                                                  True

    Reply to Folder                                                       True



    Wednesday, March 9, 2016 5:14 PM
  • Well, that blows the only (admittedly not very promising) theory I had. Have you got any pointers to information about how this auto-enrolling happens, or the signing/encryption system? I know nothing about this sort of thing...

    Another thing to try, if you have the time: the add-in started off as a reimplementation of the VBA macros described in http://www.hanselman.com/blog/HowToEasilyDisableReplyToAllAndForwardInOutlook.aspx - if you remove the add-in and try the VBA method instead, does that have the same effect?

    Thursday, March 10, 2016 7:36 AM
  • Hi Gavin,

    I'm the colegue that manage all the autoenrollment process. I do not think the certificate auto-enroll process is related to the problem. Every user has a certificate in his personal store to allow to sign the emails. A domain GPO will impose the mail signing to the client and deny any kind of encription of the outgoing mail. For some strange reason, when the no-reply-all button is selected the client encrypt the sending email ovrerriding also the GPO settings.

    I will continue to investigate starting from the VBA macro

    Many thanks for the support


    Tuesday, March 15, 2016 11:21 PM
  • Hi Team,

    the problem seems related to the ActiveInspector object. Gavin, can you check the source code to see if you can explicitly avoid the message encryption. Naturally I think the source of the add-ins is not available to do some dev checks on the field.

    Please let me know

    Many Thanks


    Tuesday, March 15, 2016 11:31 PM
  • There's no direct reference to the ActiveInspector but, naturally, inspectors are touched when the buttons are activated: for example, https://blogs.msdn.microsoft.com/gsmyth/2011/08/20/more-about-buttons shows a snippet of the code I use. I have seen problems before when 'odd' things would happen in Outlook because I was hanging on to Outlook objects longer than I ought to, or releasing earlier than I ought to - due mainly to the mismatch between .NET object lifetimes and the COM-based lifetimes within the app, but I think I've balanced all of those (explained in https://blogs.msdn.microsoft.com/gsmyth/2011/08/06/outlook-object-model) so that might not be the cause of the problem.

    While the source for this plugin isn't available as such, you can find a description of most of it (certainly, all to do with reply, etc, disabling) at https://blogs.msdn.microsoft.com/gsmyth/2011/09/18/noreply-vsto-add-in-wrap-up and I also implemented a native C++ variant too, which would 100% avoid any possibility of .NET/COM discrepancies: https://blogs.msdn.microsoft.com/gsmyth/2013/10/13/noreplyall-lite

    Wednesday, March 16, 2016 7:23 AM
  • I was troubleshooting this issue for a while. I rev.engineered plugin src. code - it has nothing to do with plugin itself. The the same issue could be reproduced by using a simple VBA Macro as show below.

    My theory and the major problem is when those actions/properties are applied something screws the original settings that being set when new mail item being created (click on new email). Following settings being changed/ignored despite global settings:

    1) HTML mail format (being changed to TNEF/RTF) --- I were be able to find workaround (registry fix to disable TNEF forever)

    2) "Send clear text signed message when sending signed messages" --- haven't found a workaround yet how programmatically to set/apply this setting back

    That being said, obviously if 2) is not set correctly before message being created by Outlook, the message will be "encrypted" and not "plain text signed".

    I continue efforts and will keep you posted.

    *** VBA MACRO ***

    Sub NoReplyAll()
        ActiveInspector.CurrentItem.Actions("Reply to All").Enabled = False
        ActiveInspector.CurrentItem.Actions("Forward").Enabled = False
    End Sub

    Thursday, July 7, 2016 2:26 PM
  • That is indeed a weird interaction.

    I wonder if, rather than the actions per se, it's something to do with holding on to a reference - for example (and this is just speculation; I have no evidence), merely referencing the CurrentItem keeps some COM object alive such that something else that expected it to be released misbehaves. (I mentioned this possibility in an earlier reply: I found that if I didn't release COM objects explicitly, I'd sometimes see weird things like Outlook ghost windows appearing on the screen and not disappearing until I exit Outlook.)

    In the VBA macro, you could try something like 'let ci = ActiveInspector.CurrentItem' - ie, just reference the CurrentItem but not its actions, just to see if that causes encryption to be enabled incorrectly. Then try just referencing the actions without setting them. This ought to help narrow down exactly what it is that triggers the erroneous behaviour - though I confess that it's difficult to then work out what to do about it.

    Friday, July 8, 2016 6:15 AM