Moqui - Connecting to an IMAP server over an SSL connection? - email

Question

I am trying to poll an email server in Moqui 1.5.4. I am using org.moqui.impl.EmailServices.poll#EmailServer from the 'tools' application.
The email server is set up as follows:
<moqui.basic.email.EmailServer emailServerId="testEmail" mailUsername="test.account#xxxxxxx.ie" mailPassword="xxxxxxxx" smtpHost="" smtpPort="" smtpSsl="" storeHost="Webmail8.xxxxxxxxxxx.ie" storePort="993" storeProtocol="imap" storeDelete="N" />
All entries, passwords have been tested on Outlook and connect no problem to the server.
I get a javax.mail.AuthenticationFailedException.
Additional Information:
In initial tests I received the following error message, so I removed the 'static' modifier from the indicated line in the code. (I was not sure yet if it was an issue or if I may be doing something wrong.)
--- 98330 [ndlerThread[15]] WARN moqui.impl.context.TransactionFacadeImpl
Transaction rollback. The rollback was originally caused by: startup failed:
classpath_//org/moqui/impl/pollEmailServer_groovy: 28: Modifier 'static' not allowed here.
# line 28, column 1.
final static Logger logger = LoggerFactory.getLogger("org.moqui.impl.pollEmailServer")
Some things I tried to see if I could resolve the problem include:
setting storeProtocol="imaps"
including the smtp details in the EmailServer entry (note I only need to poll, not send mail).
adding the following line to pollEmailServer.groovy (having looked at the com.sun.mail.imap package).
sessionProperties.put("mail.imap.ssl.enable", true)
Full Authentication failed error message is:
Error running service [org.moqui.impl.EmailServices.poll#EmailServer] (Throwable)
javax.mail.AuthenticationFailedException
at javax.mail.Service.connect(Service.java:306)
at javax.mail.Service.connect(Service.java:156)
at javax.mail.Service.connect(Service.java:105)
at pollEmailServer_groovy.run(pollEmailServer_groovy:47)
at org.moqui.impl.context.runner.GroovyScriptRunner.run(GroovyScriptRunner.groovy:50)
at org.moqui.impl.context.ResourceFacadeImpl.script(ResourceFacadeImpl.groovy:337)
at org.moqui.impl.service.runner.ScriptServiceRunner.runService(ScriptServiceRunner.groovy:49)
at org.moqui.impl.service.ServiceCallSyncImpl.callSingle(ServiceCallSyncImpl.groovy:260)
at org.moqui.impl.service.ServiceCallSyncImpl.call(ServiceCallSyncImpl.groovy:137)
at ServiceRun_xml_transition_run_actions.run(ServiceRun_xml_transition_run_actions:10)
at org.moqui.impl.actions.XmlAction.run(XmlAction.groovy:99)
at org.moqui.impl.screen.ScreenDefinition$TransitionItem.run(ScreenDefinition.groovy:659)
at org.moqui.impl.screen.ScreenRenderImpl.recursiveRunTransition(ScreenRenderImpl.groovy:223)
at org.moqui.impl.screen.ScreenRenderImpl.recursiveRunTransition(ScreenRenderImpl.groovy:217)
at org.moqui.impl.screen.ScreenRenderImpl.recursiveRunTransition(ScreenRenderImpl.groovy:217)
at org.moqui.impl.screen.ScreenRenderImpl.recursiveRunTransition(ScreenRenderImpl.groovy:217)
at org.moqui.impl.screen.ScreenRenderImpl.recursiveRunTransition(ScreenRenderImpl.groovy:217)
at org.moqui.impl.screen.ScreenRenderImpl.internalRender(ScreenRenderImpl.groovy:301)
at org.moqui.impl.screen.ScreenRenderImpl.render(ScreenRenderImpl.groovy:164)
at org.moqui.impl.webapp.MoquiServlet.doScreenRequest(MoquiServlet.groovy:71)
at org.moqui.impl.webapp.MoquiServlet.doPost(MoquiServlet.groovy:37)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at net.winstone.core.ServletCotion.execute(ServletConfiguration.java:270)
at net.winstone.core.SimpleRequestDispatcher.forward(SimpleRequestDispatcher.java:290)
at net.winstone.core.listener.RequestHandlerThread.processRequest(RequestHandlerThread.java:212)
at net.winstone.core.listener.RequestHandlerThread.run(RequestHandlerThread.java:143)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at net.winstone.util.BoundedExecutorService$1.run(BoundedExecutorService.java:81)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Addendum: Processing the messages once polled with Email ECA Rules.
I can see when I turn on logger info in EmailEcaRule.groovy that the condition in my Email ECA keeps evaluating to 'false'. But it shouldn't be?
======== EMECA Process Received Email conditionPassed? false My condition: TestEmail fields:
(Note that I inserted "My condition: ${fields.subject}" into the logger info to double check my condition expression was as it should be.)
My emeca is:
<emecas xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://moqui.org/xsd/email-eca-1.5.xsd">
<emeca rule-name="Process Received Email">
<condition><expression>fields.subject == 'TestEmail'</expression></condition>
<actions>
<service-call name="org.moqui.impl.EmailServices.save#EcaEmailMessage" />
</actions>
</emeca>
</emecas>
I have tested and re-tested this. I don't know why it is evaluating to false. Please let me know if any additional information is required.
Still no luck in solving this. I must be doing something stupid. I commented out if (conditionPassed) {} in the EmailEcaRule.groovy to bypass my condition in the Email ECA rule and just run the action, but now it gets hung up with a "Cannot invoke method get() on null object" error in org.moqui.impl.EmailServices.save#EcaEmailMessage, presumably on headers.get('message-id'). But I can see in the log information that the message Id is in the headers information, and successfully converted to lower case.

Answer 1

There were a few issues with this. First is that Moqui was using an old version of JavaMail (now updated to 1.5.4). Another was how the password was passed through, and more generally there was lots of room for improvement in how the script for poll#EmailServer service was using the JavaMail API.
There are various changes in place as of commit #bf0f872. I was able to connect successfully using storeProtocol=imaps, storePort=993, etc.
To answer your question: without these code changes I don't think connection via SSL would be possible. In other words, this ended up being more of a bug report than a question.