Scalix Forums

I am getting this error for a small select group of users who at a remote site to the server. They come in via an ADSL router and some of them have VPN connections to the mail server but not everyone has VPN. Whenever these users try to send mail from SWA the error below is generated in the catalina.out file.

avax.mail.MessagingException: Could not connect to SMTP host: mail.mater.com, port: 2025
at com.sun.mail.smtp.SMTPTransport.openServer(Unknown Source)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(Unknown Source)
at javax.mail.Service.connect(Unknown Source)
at com.scalix.swa.service.MailServices.getTransport(MailServices.java:130)
at com.oddpost.server.module.SoapMail.sendMessage(SoapMail.java:1596)
at com.oddpost.server.module.SoapMail.send(SoapMail.java:942)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.oddpost.soap.SoapModule.invokeMethod(SoapModule.java:231)
at com.oddpost.soap.SoapRequestImpl.execute(SoapRequestImpl.java:139)
at com.oddpost.server.HttpRequestHandler.handleRequest(HttpRequestHandler.java:228)
at com.oddpost.server.SoapServlet.doPost(SoapServlet.java:49)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.oddpost.server.filter.HttpConfFilter.doFilter(HttpConfFilter.java:174)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:684)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at com.sun.mail.util.SocketFetcher.createSocket(Unknown Source)
at com.sun.mail.util.SocketFetcher.getSocket(Unknown Source)
... 34 more

The smtpd.cfg file relevant lines:

EXTENSIONS=AUTH,DSN,8BITMIME
#LISTEN_PORT=2025
LISTEN=localhost:2025

RELAY accept 127.0.0.1
#RELAY accept .mail
RELAY accept .mater.com
RELAY accept 192.168.22.98
RELAY Log_Reject ALL

# extra rules added to prevent open relay usage
RECIPIENT Log_Reject *@*@*
RECIPIENT Log_Reject *%*
RECIPIENT Log_Reject *!*
RECIPIENT Log_Reject *#*@*

The name of the mail server is mail.mater.com but you can't nslookup this site you can nslookup the domain though.

nslookup mater.com
Server: 192.168.168.1
Address: 192.168.168.1#53

Non-authoritative answer:
Name: mater.com
Address: 2.3.178.92

(I've changed names and ip addresses to protect the id of the site).

The ip address of the server mail.mater.com is 192.168.22.98 internal and 60.2.3.4 external.

swa.properties has the line:

swa.email.smtpServer=mail.mater.com

Now this site does not have mail directly delivered to them, they fetch it from an ISP. Up until the week before last week this was all working but then a nameserver somewhere in the world was turned off, this site was notified but didn't understand the meaning of the message so had done nothing about it. For nearly a week they weren't receiving mail. This was then fixed all was good until last week they had a power failure and the server had to be rebooted. Now this remote site can no long send mail with SWA.

I know it has been told to me many times that the reverse lookup has to work but how do I make this work when there is no FQDN but only a DN that can be looked up?

Is there a simple answer to this that I am missing?

[/i]

I can send if I use the mobile client - basically I think that is because it talks directly to ual and not smtp. Just thought I would add this to the equation.

deyjvu wrote:I am getting this error for a small select group of users who at a remote site to the server. They come in via an ADSL router and some of them have VPN connections to the mail server but not everyone has VPN. Whenever these users try to send mail from SWA the error below is generated in the catalina.out file.

avax.mail.MessagingException: Could not connect to SMTP host: mail.mater.com, port: 2025


The name of the mail server is mail.mater.com but you can't nslookup this site you can nslookup the domain though.

nslookup mater.com
Server: 192.168.168.1
Address: 192.168.168.1#53

Non-authoritative answer:
Name: mater.com
Address: 2.3.178.92

(I've changed names and ip addresses to protect the id of the site).

The ip address of the server mail.mater.com is 192.168.22.98 internal and 60.2.3.4 external.

swa.properties has the line:

swa.email.smtpServer=mail.mater.com

Now this site does not have mail directly delivered to them, they fetch it from an ISP. Up until the week before last week this was all working but then a nameserver somewhere in the world was turned off, this site was notified but didn't understand the meaning of the message so had done nothing about it. For nearly a week they weren't receiving mail. This was then fixed all was good until last week they had a power failure and the server had to be rebooted. Now this remote site can no long send mail with SWA.

I know it has been told to me many times that the reverse lookup has to work but how do I make this work when there is no FQDN but only a DN that can be looked up?

Is there a simple answer to this that I am missing?

[/i]

Is the adsl connection a static address?

swa will try and connect to mail.mater.com to send via smtp. What is in the servers /etc/resolv.conf? can you do an nslookup from the server for mail.mater.com and get the correct address?
if so can you "telnet mail.mater.com 2025" from the server and get an expected response?

it sounds like you have an internal name server working but maybe the servers no longer referencing it because of whats in resolv.conf?

If the internal nameserver has appropriate records then it should work.

make sure the hosts file doesn't have any odd entires either.

Hope that helps,

I checked /etc/resolv.conf and it is pointing to an internal name server and it does not appear to recognise mail.mater.com as I get nothing back from an nslookup.

So would the entry for mail.mater.com on this name server that is in /etc/resolv.conf be for the internal or external address?

deyjvu wrote:I checked /etc/resolv.conf and it is pointing to an internal name server and it does not appear to recognise mail.mater.com as I get nothing back from an nslookup.

So would the entry for mail.mater.com on this name server that is in /etc/resolv.conf be for the internal or external address?

/etc/resolv.conf is just the pointer to a nameserver. The nameserver can be anywhere. resolv.conf doesn't actually carry any records.

The entry for mail.mater.com must exist in the internal nameservers zone file, and it should have the internal address that the server has.

Scalix, should by default listen on the internal (eth0) address, whatever that may be, 192.168.xx.xx and it also usually listens on the external adsl interface address (ppp0 usually).

In this situation i dont think it will matter where you point mail.mater.com, as long as it can resolve.

DOH!! I should make sure I'm fully awake before working... the nslookup did work when I spelt the FQDN correctly. So the nameserver has the correct entries for the server.

I had added the ip address for the internal ip address to the smtpd.cfg file and restarted smtpd yesterday but that didn't make any difference.

I had added the port 2025 that smtpd was listening on, to the swa.properties line:
mail.mater.com:2025, I was able to restart all the services when I made this change as Scalix was down at that time. It didn't make any difference so I changed it back but as it was during their work day and I had restarted Scalix I was not able to restarted tomcat/httpd, so I did that early this morning and now I am able to send mail with the swa? Nothing has changed re the network setup on the site, however, I notice a change when I do a dig of the FQDN -

;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1177977374 1800 900 604800 900

So it could be this that is enabling this to now work? I don't think I've seen an entry like this before but I may have but not thought anything of it?

I'll change the swa.properties back to what it was just to test what did resolve this as there weren't that many changes made that I can't double check what works what doesn't.

Thanks for your inputs Les, much appreciated.

deyjvu wrote:DOH!! I should make sure I'm fully awake before working... the nslookup did work when I spelt the FQDN correctly. So the nameserver has the correct entries for the server.

I had added the ip address for the internal ip address to the smtpd.cfg file and restarted smtpd yesterday but that didn't make any difference.

I had added the port 2025 that smtpd was listening on, to the swa.properties line:
mail.mater.com:2025, I was able to restart all the services when I made this change as Scalix was down at that time. It didn't make any difference so I changed it back but as it was during their work day and I had restarted Scalix I was not able to restarted tomcat/httpd, so I did that early this morning and now I am able to send mail with the swa? Nothing has changed re the network setup on the site, however, I notice a change when I do a dig of the FQDN -

;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1177977374 1800 900 604800 900

So it could be this that is enabling this to now work? I don't think I've seen an entry like this before but I may have but not thought anything of it?

I'll change the swa.properties back to what it was just to test what did resolve this as there weren't that many changes made that I can't double check what works what doesn't.

Thanks for your inputs Les, much appreciated.

not sure about the dig, would have to see its full context before ascertaining whether it had anything to do with it.

it is more likely that perhaps the nameserver was not working properly, or there were dud entries in /etc/hosts or something like that.
Hard to say what made it all start working, but yeah take it back to original and change one thing at a time to see what was the fix.

good luck!