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 Ulli,

    there must be a misunderstanding at your side. The DebugMailPlugin worked in version 6 in the same way as in version 7 and we haven't changed anything in that area. The documentation also contains a hint that the mails will not be send if the task is running externally.

    What we did was, to change the execution type of the SendRichMail task to external with 6.0 SP1 and 6.1 in 2012 for the reasons i described in my post.

    Kind regards,


  • Hi Markus,

    let's summarize it: In
    one problem was solved by generating a new problem. The new one has been documented, so in 1IM opinion it's no longer a bug, but just a defect (what a quibbling). 1IM is not considered to solve the defect, as they think, it's not their main priority.

    Thank you, I learned something about how you think of customer satisfaction!
  • The report you mentioned describes a resolution starting with 6.1 which is to change the execution type as Oliver Paulzen proposed correctly.

    So I am unable to see why we do not care about customer satisfaction. Sadly, we are unable to fulfill any request with the same passion and priority.

    You are of course free to fill a RFE for you enhancement via our support team.

    Thank you

  • These days it does not make sense at all to implement the next smtp server or eml file simulator which is not exactly as close to real live as a real mail. For everybody who is docker aware it is easier, faster and closer to real live simply using:

    docker run -d -p 1025:1025 -p 8025:8025 mailhog/mailhog

    And configure the OneIM configuration parameters to port 1025 and connect with your email client via port 8025.

    From my perspective it makes more sense to removing the debugmailplugin from the job service instead of constantly trying to reinvent the wheel.
  • Hi Mattias,

    thanks for sharing your thoughts on this. In my world however, I would have a hard time to provide this solution to business users who do the tests and to train them on docker, tcp ports and mail client configuration...Not everyone is a developer of DevOps guy :)

  • I just repeating myself here but I propose to use a tool like PaperCut

    It is free, does not have to be installed, the source code is available (if somebody has any concerns) and it does support exactly the use case that is described here.


  • For those who are not Docker-aware, Markus' suggestion above is still a good solution. At least better than using the debugmailplugin.