Email Addon is using wrong port

Setup, Configuration and Use Beginners
,
1
  • Platform information:
    • Hardware: banana pi
    • OS: linux
    • Java Runtime Environment: openJdk 1.8
    • openHAB version:
      marker one: if logs were generated …
  • If logs where generated please post these here using code fences:

my real problem:
In PaperUI I installed the sendmail addon/service and configured it.
If I set ssl=true, the default port 465 will be used. Only on ssl=false my configured port will be used (not depending on tls=true/false)
the rest of my configuration-file:

hostname=****
port=25
username=****
password=****
from=some@mydomain.ending
tls=start
ssl=false
popbeforesmtp=false
#charset=

my log output:
2019-02-15 21:48:34.034 [ERROR] [rg.openhab.action.mail.internal.Mail] - Could not send e-mail to ‘****’.
org.apache.commons.mail.EmailException: Sending the email to the following server failed : ****:465
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1421) ~[?:?]
at org.apache.commons.mail.Email.send(Email.java:1448) ~[?:?]
at org.openhab.action.mail.internal.Mail.sendMail(Mail.java:157) ~[?:?]
at org.openhab.action.mail.internal.Mail.sendMail(Mail.java:89) ~[?:?]
at org.openhab.action.mail.internal.Mail.sendMail(Mail.java:67) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1086) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1061) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._invokeFeature(XbaseInterpreter.java:1047) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeFeature(XbaseInterpreter.java:992) ~[?:?]
at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:151) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:902) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:865) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:224) ~[?:?]
at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:204) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:447) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:228) ~[?:?]
at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.doEvaluate(ScriptInterpreter.java:226) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:204) ~[?:?]
at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:190) ~[?:?]
at org.eclipse.smarthome.model.script.runtime.internal.engine.ScriptImpl.execute(ScriptImpl.java:82) ~[?:?]
at org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl.lambda$2(RuleEngineImpl.java:341) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: javax.mail.MessagingException: Could not connect to SMTP host: ****, port: 465
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1934) ~[27:javax.mail:1.4.4]
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:638) ~[27:javax.mail:1.4.4]
at javax.mail.Service.connect(Service.java:295) ~[27:javax.mail:1.4.4]
at javax.mail.Service.connect(Service.java:176) ~[27:javax.mail:1.4.4]
at javax.mail.Service.connect(Service.java:125) ~[27:javax.mail:1.4.4]
at javax.mail.Transport.send0(Transport.java:194) ~[27:javax.mail:1.4.4]
at javax.mail.Transport.send(Transport.java:124) ~[27:javax.mail:1.4.4]
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1411) ~[?:?]
… 32 more
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:?]
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[?:?]
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[?:?]
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[?:?]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[?:?]
at java.net.Socket.connect(Socket.java:589) ~[?:?]
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:673) ~[?:?]
at com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:286) ~[27:javax.mail:1.4.4]
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:205) ~[27:javax.mail:1.4.4]
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1900) ~[27:javax.mail:1.4.4]
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:638) ~[27:javax.mail:1.4.4]
at javax.mail.Service.connect(Service.java:295) ~[27:javax.mail:1.4.4]
at javax.mail.Service.connect(Service.java:176) ~[27:javax.mail:1.4.4]
at javax.mail.Service.connect(Service.java:125) ~[27:javax.mail:1.4.4]
at javax.mail.Transport.send0(Transport.java:194) ~[27:javax.mail:1.4.4]
at javax.mail.Transport.send(Transport.java:124) ~[27:javax.mail:1.4.4]
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1411) ~[?:?]
… 32 more

2

Looks to me like if you set ssl=true the internal library needs to set sslSmtpPort to your port number instead of smtpPort. It only sets smtpPort, so when ssl is used the default is set instead.

Either that or it needs to expose both settings and have you set them explicitly.

Looks like a bug to me.

3

This sounds like exactly what the readme describes.

4

That’s true, now that you point it out.

It means you can’t use a custom port with an ssl-enabled mail server, though.

Wouldn’t it be better if the port option worked as you’d expect regardless of if you were using ssl or not? Changing the default to be the appropriate port, makes sens, but why override the user’s settings just because it’s ssl?

5

Presumably this was an attempt to make the binding “smart” by not letting the user make the mistake of asking for ssl but not changing the port number.

6

seems like the docu states this. So it is no bug.
Though/ but:

  • in times of fast reading documentations, I would prefer a second sentence explaining this statement at the variable “port”. There is only stated, that I can set the port, but this is wrong, as I can only influence its value on ssl=false;
  • why can’t I change the port on using ssl? My email provider does support this. A possible way out of this deadlock would be testing both ports (default and user input). The one working, will be used in future and written into the internal configuration, (There at the moment is still the correct user port written, though it is not used).
7

How do you define bug?

If you mean “Doesn’t do what it was expected to do” then this does as expected, according to the docs.

If you mean “Doesn’t let required and/or useful combinations of options work” then there is a problem.

Not sure if this is an actual “bug” or a “feature request” as how it’s talked about around here.

Personally, I’d say that this is the wrong way to handle the port command. If the user hasn’t specified one, then using sensible defaults is fine. But if the user gave one, ignoring it sometimes is confusing and means they can’t make some valid configurations work.

To fix it, there’s two choices: Add an ssl_port option, and pass that through to the underlying mail sending library, or just have the port option control the port used to connect for either SSL or unencrypted connections.

Personally, I prefer the latter. There’s only one port you need regardless of it’s SSL or not and specifying two is kind of an artifact of the underlying library.

Until the binding is changed, fabian727 can’t use it in their configuration.

8

I would define a “bug” like: in another way documented as behaving. So the documentation and behaviour is the same, so everything fine.

But yes, I cannot use ssl and the custom port, given by my provider. So it would be nice to get this combination working: ssl=yes + port=****

9

I guess then go to Github and file an issue so the developer sees this implementation leaves you stuck, and see if they’re active and/or will change it.

10

I thought I’d have a quick look and this problem seems to have been discussed in this thread: Sending mail does not work on Snapshot Release

And the fix for it has been made already: https://github.com/openhab/openhab1-addons/pull/5006

Although, I wouldn’t be able to say why the PR was put on-hold.

11

It’s been in that state for two years. I wonder why, and I wonder what can be done to get it moved forward?

12

I believe that #5006 was put on hold due to #4130.

If my reading is correct, 5006 will not work because of 4130.

@watou was heavily involved with these, so it’d be great if he could add his thoughts here.

16

This Email Addon is using the protocol TLSv1 which is very old an many servers do not accept only TLSv1.2 and newer. This will result in failing with the following error:
org.apache.commons.mail.EmailException: Sending the email to the following server failed : ****:465

Could we expect an updated version in the future?