11 Replies Latest reply on Mar 14, 2004 2:12 PM by acoliver

    JMSMailListener and DomanGroup

    kabirkhan

      JMSMailListener maintains it's own copy of On Server Domains. I just wanted to check if it is OK to make it use the DomainGroup MBean instead, since I guess that is meant to be the central location for that sort of info?

      Cheers,

      Kab

        • 1. Re: TODO: TLS and JBossSX integration
          acoliver

          Hi Steve,

          My test works as well. My problem is that I am not able to get TLS working in a running server. AFAIK it the socket stuff is all meant to be working, all that is needed is to change the underlying security stuff.

          To enable tls, leave requireSTARTTLS as false, and add the tls-enabled attribute (it is not there already), so that your jboss-service.xml entry looks something like:


          requireSTARTTLSfalse
          requireClientCertfalse
          tls-enabledtrue




          I then build mail.ear and deploy in a running JBoss.


          Now when I try to connect using telnet (see previous example) it pukes out on the SSLSocketFactory.getDefault() line in CmdSTARTTLS. I think I lied a bit yesterday when I said it falls over on SSLSocketFactory.getDefault(), as the stack trace shows it to fall over on SSLSocketFactory.createSocket(). (Maybe it is throwing this error due to the telnet client not being SSL enabled, I need to read up a bit on SSL context :-) )

          17:34:05,205 DEBUG [CmdSTARTTLS] STARTTLS command handler called 17:34:05,205 ERROR [STDERR] java.net.SocketException: Default SSL context init f
          ailed: null
          17:34:05,215 ERROR [STDERR] at javax.net.ssl.DefaultSSLSocketFactory.createSocket(DashoA6275)
          17:34:05,215 ERROR [STDERR] at org.jboss.mail.smtp.handlers.CmdSTARTTLS.handleRequest(CmdSTARTTLS.java:52)
          17:34:05,215 ERROR [STDERR] at org.jboss.mail.smtp.SMTPProtocolInstance.handleRequest(SMTPProtocolInstance.java:151)
          17:34:05,215 ERROR [STDERR] at org.jboss.mail.ServerThread.run(ServerThread.java:221)
          17:34:05,215 ERROR [STDERR] at java.lang.Thread.run(Thread.java:534)
          17:34:05,215 ERROR [SMTPProtocolInstance] Handle IO Error 17:34:05,215 ERROR [STDERR] java.lang.NullPointerException
          17:34:05,215 ERROR [STDERR] at org.jboss.mail.ServerThread.run(ServerThread.java:223)
          17:34:05,215 ERROR [STDERR] at java.lang.Thread.run(Thread.java:534)
          17:34:05,215 DEBUG [ServerThreadPool] freeing org.jboss.mail.ServerThread@50078e


          When I connect using Thunderbird (set up to use TLS if available), I get a bit further but then it falls over when trying to call SSLSocketFactory.createSocket() - a different error this time:

          14:28:50,293 ERROR [STDERR] java.net.SocketException: Export restriction: this JSSE implementation is non-pluggable.
          14:28:50,293 ERROR [STDERR] at javax.net.ssl.DefaultSSLSocketFactory.createSocket(DashoA6275)
          14:28:50,293 ERROR [STDERR] at org.jboss.mail.smtp.handlers.CmdSTARTTLS.handleRequest(CmdSTARTTLS.java:59)
          14:28:50,303 ERROR [STDERR] at org.jboss.mail.smtp.SMTPProtocolInstance.handleRequest(SMTPProtocolInstance.java:151)
          14:28:50,303 ERROR [STDERR] at org.jboss.mail.ServerThread.run(ServerThread.java:222)
          14:28:50,303 ERROR [STDERR] at java.lang.Thread.run(Thread.java:534)

          (Note that the line numbers in my stack traces may be slightly of since I have been playing around)

          I don't see why it works in one environment and not in the other, since the unit test is connecting via a socket as well?!?

          So I think it may have something to do with the fact that I am outside the US and have a JVM running a restricted version of JSSE (Java Secure Sockets Extension) :-(, but then why is the unit test working since it effectively does the same thing?

          It would be great to know if anybody with a US JVM is able to run this with TLS enabled using a client. Also, if anybody has any hints about how to get around the JSSE issue?

          Thanks,

          Kab

          • 2. Re: JMSMailListener and DomanGroup
            acoliver

            Yes that was the intent. I was just not done yet.

            • 3. Re: JMSMailListener and DomanGroup
              acoliver

              oh so I meant to say: Yes please! :-)

              • 4. Re: JMSMailListener and DomanGroup
                kabirkhan

                I've just committed this. However, since I don't know that much about JMX yet and haven't got too into the FakeInitialContext stuff yet I was unable to get the DomainGroup set up for TestJMSMailListener. For now I have commented the code in out TestJMSMailListener.testSetOnServerDomains() that need access to DomainGroup :-(

                • 5. Re: JMSMailListener and DomanGroup
                  acoliver

                  The funny thing is that I don't think you need to know about either to fix this unit test. You really need to learn this stuff. We'll fall on our face without a sufficient testsuite. Work on fixing this so that you will know aobut JMX. FakeInitialContext is just a fake implementation of JNDI. I just over-ride JNDI with a jndi.properties using that FakeInititalContext so that I could put whatever I wanted in a hashtable. the only limitation is I haven't figured out how to override the java:/ context but I think I've gotten around that sufficiently.

                  • 6. Re: JMSMailListener and DomanGroup
                    kabirkhan

                    I know, I know. I will spend some time trying to get it to work.

                    • 7. Re: JMSMailListener and DomanGroup
                      acoliver

                      thank you :-). It will make your life and all of ours much better.

                      • 8. Re: JMSMailListener and DomanGroup
                        mikea-xoba

                        i actually thought the two different lists were there on purpose, in order to distinguish between primary and secondary domains --- meaning, high and low priority dns MX records. or 'OnServer' or 'OffServer' in jboss-mail terminology.

                        in that viewpoint, the DomainGroupMBean maintains the complete list of domains that the server would accept mail for, and the 'OnServerDomains' set would be those domains that can be locally delivered; the others then would be forwarded by another SMTP hop or by some other protocol (i.e., a 'secondary' mail server function).

                        seemed like it worked that way --- i may have misunderstood though.

                        mike

                        • 9. Re: JMSMailListener and DomanGroup
                          kabirkhan

                          Mike,

                          That is still how it is working. The way it used to work is that JMSMailListenerMBean used to maintain its own copy of the on server domains (used by JMSMailListeneMBean) to determine what queue to place the message on (onServer/offServer) for local/remote delivery, and DomainGroupMBean maintained a copy of the on server domains (used everywhere else apart from JMSMailListenerMBean).

                          The way it works now is that JMSMailListenerMBean no loinger maintains its own list of on serer domains, DomainGroupMBean now uses this.

                          Cheers,

                          Kab

                          • 10. Re: JMSMailListener and DomanGroup
                            kabirkhan

                            Aha!

                            There is a bit more to this than meets the eye, and I think I see what you mean now. Anyway, my changes only got rid of the onServer domains being duplicated in JMSMailListener, since they are already defined in the only DomainGroup defined so far. I am assuming that since it has name="jboss.mail:type=MailServices,name=DomainGroup,group=Local"
                            that this is for local delivery, and that later there will be different instances with a different group=XXX for defining other groups of domains?

                            The code for handling mails for on-/offServer is unchanged, but it should be trivial to implement the extra stuff you mention here.

                            Cheers,

                            Kab

                            • 11. Re: JMSMailListener and DomanGroup
                              kabirkhan

                              Got the test fixed...