This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DebugMailPlugin configuration


I'm having an issue with the DebugMailPlugin that simply does not seem to be working (with Q1IM v7.1.0).

I'm suspecting an issue with the way I configured it. I used the JobConfigurationEditor to enable the plugin and specified a folder for the plugin to drop the emails. I restarted the Service, but to no avail.

When a SendRichMail gets to my JobQueue, it's apparently attempting to contact the SMTP relay I configured in the Common/MailNotification parameters (it's failing because I purposefully specified invalid credentials, but the fact that it's even attempting to contact the relay makes me suspect that the plugin did not catch the email).

I tried disabling the Common/MailNotification configuration parameters but this led to another error, with the "Smtp Port", "Domain", etc. parameters empty in my step, which led to an error telling me that "Value cannot be null".

I might have an idea of what is problematic. According to the Configuration Guide, the plugin only works for processes executed internally in the One Identity Service. But when I look at the JobService log and find the moment I fired the event triggering the process that sends the test email, I see this :

2017-03-14 18:42:30 +01:00 - Process step parameter b6bc43fd-445c-4105-8c8d-ccc8f6559a3a:

The execution type seems to be external, which would explain why the is not working. This was with the Common/MailNotification configuration parameter disabled. I did not find any way to switch that ExecutionType to internal and check if the plugin is working better that way.

Any idea ? Am I on the right track suspecting that this ExecutionType is the issue ? Or is there somethig else I need to do to configure the DebugMailPlugin properly ? Any help would be appreciated !

Best regards,

  • Hi Robin,

    yes, you are. Details of this are outlined in In my opinion, this is a bug, but the vendor's view on this different and since they recommend customers to use separate SMTP servers and their assumption is that DebugMailPlugin is rarely used, they don't bother doing anything about it.

    You can switch the execution type of this process task in Designer > Process Orchestration > Process components > MailComponent > SendRichMail > Edit object > ExecutionType = INTERNAL

  • I prefer to use a tiny little tool called Papercut to help me to debug my rich mails. Papercut is a simplified SMTP server designed to only receive messages (not to send them on) with a GUI on top of it allowing you to see the messages it receives.

    Using this is way easier than using the DebugMailPlugin and it uses a Apache 2.0 license

  • Hi Olivier !

    That did help ! It works perfectly now.

    I didn't think of looking into the KB, my bad.
    Thanks a lot for pointing this article out.

    Best regards,
  • The suggestion from Oliver has to be taken with a grain of salt.

    It is not recommended to change the ExecutionType to Internal for the task SendRichMail. If a task is executed internally it is running inside of the process of the job service which could lead to performance degradation if the task behaves badly in terms of memory or CPU usage.

    So do not use this is in any production environment.
  • I'm absolutely not planning to. I'm using the Debug Mail plugin in my Integration environment only.
    Thanks for the tip about Papercut by the way ! I'll look into it.

  • Hi Markus,

    that's exactly why I consider the fact, that DebugMailPlugin only works with ExecutionType EXTERNAL, as a bug. You should either remove it from the product completely, replace it by a builtin form of something like Papercut or just get it fixed, IMHO :-)

    Ever tried to add unsupported "toy" software components like Papercut to large and complex (not technically, but organisationally) enterprise environments? Usually impossible. Even, and sometimes especially, in test environments.

  • Hi Oliver,

    providing a complete mail client just as debug helper is not our main priority in building an Identity and Access Governance solution.

    We will consider your advice in ending the support of the DebugMailPlugin instead.

  • Hi Markus,

    nobody really needs a complete mail client for debug purposes. Just dumping the mail text to a file "as it is", means with all HTML tags or rich text markers as plain text would be sufficient. Every developer should be able to re-format those text files to human reading ones using some helper tools. But looking into plain text files is much quicker and easier to use in large company environments than installing any new kind of software only for debug purposes. In that point I absolutely agree with Oliver.

    And removing the plugin is no solution IMHO. Then you can also remove SystemDebugger too and some other really nice features. ;-)


  • Hi Ulli,

    there is no need to install PaperCut if that is your concern. Installing a service is completely optional. But anyways, it was just a proposal.

    But i can just repeat myself, providing a mail debug solution that works in every situation is not our main priority in building an Identity and Access Governance solution.

    So the current plugin works as designed. Any additional features will be considered as enhancements and triaged.

    Thank you

  • Hi Markus,

    now we are at a crossroad. Formerly (before v7.x) it worked fine, but it does no longer! We are discussing here that you can use this plugin in v7.x only after switching it to INTERNAL, which is not recommended by 1IM. But leaving it as EXTERNAL, it does no longer work. So Oliver stated already that we think that this is a bug, as the behavior in v7.x is no longer the same as it was in < v6.x.

    So besides the discussion of PaperCut and what a IAM solution shall really do: How do you position due to the fact, that MailDebugPlugin does no longer deliver the same functionality in v7.x than before?

    Will you fix that, or do you no longer support that plugin?


    PS: Oliver corrected me, that it is changed "before bug fix 18256" and afterwards. So it seems to be changed there, not from 6.x to 7.x. Thanks, Oliver!