it wont work for everyone as some isp servers require their app which has embedded ssl or tls and as far as i know that is not avail. in the telnet implentation on hubitat.
Does this support any form of queuing? One issue I found with HEmail is if HE tries to send a 2nd email before the first is complete, the 2nd fails entirely.
dont agree at al.. it does support encryption for your user name and password which is what is mostly needed.. end to end encryption is really not all that important for general email\
no it doesnt.. same thing happens with alexa text messages if you send them too soon either you get an error or the first is stopped mid stream or totaly skipped. But my server keeps track of each email independently as each comes from a different source port.. A server should be able to do that.
I must be missing something. Where is that encryption handled? I don't see anything in your code other than sending a line of data via Telnet; nothing specific about username and password. If you start an SMTP conversation with helo instead of ehlo, how would the server and client have any idea that the other could handle the encryption?
I/we don't mean to beat up on your contribution here. I think it is a great contribution. But it is important to understand the workable use cases. A simple SMTP conversation has a lot of challenges post the spam era, and those that are trying to use this may get frustrated if they don't understand some limitations.
2 Likes
TLS and SMTPS aren't "end to end" encryption. They are only transmission encryption for the next hop--ensuring that the id/password are encrypted as they go across the public internet (but not any farther).
End-to-end encryption involves having the private certificate for the sender and the public certificate for the recipient--and sending an S/MIME packet encrypted all the way to the end-user's email client.
I'm not sure how this process ensures the encryption of the userid/password if it isn't using TLS or SMTPS. I thought I'd read that the Hub doesn't support the libraries needed to perform encryption.
4 Likes
you encrypt it your self and put it in the username password field that is why i say base64 in the description.. use a site like this
1 Like
I don't see any encryption. FWIW, there have been several email senders for Hubitat written, and they all use the same unencrypted telnet approach. Most recommend using an intermediary local server to relay the email in a secure fashion.
4 Likes
Base64 is an encoding method, not an encryption method.
3 Likes
you are correct sorry.. so not encryption
it should be possible to do it in hubitat as mqtt now supports tls ... but i dont believe the telnet implentation does.
Not if it's a Simple Relay Server. I just ran some tests and sending a 2nd email while the 1st one is IP breaks both emails and neither is sent successfully.
i am not suprised.. i was just saying my server can handle it.
It's not the email server. The code has a global variable (lastCommand ) which holds the progression state of the current connection. A second simultaneous connection will overwrite the state of the first connection. One or both will fail based on timing.
3 Likes
interesting.. you are right not sure why my test worked.. just conincidence... or timing.. anyway i am not bothering to change that as i don't fire off a bunch at a time anyway.. you are welcome to take a
look.
1 Like
Regarding the hub slowdown we were talking about on the other thread, HE staff noticed that I have broken browser connections in my logs (the logs they can see on their end using my Hub UID that I gave them to look into this). They said:
I see a bunch of org.eclipse.jetty.io.EofException, which is indicative of broken browser (any HTTP client, really) connections.
Could the Sendmail virtual devices I set up be related to this?
i dont think so as it does not use http .. but telnet. but try disabling them and see. it could be something with the new firmware not closing cleanly after disconnecting.. even though disconnect is called in the code.. ie could be bug. if so reboot would fix this.. if stil bad after reboot no.
can they check what port the connections were to? what port are you using in your email.. i noticed it was not 25.. it is not designed to goto other than an smtp server? and you description was showing imap which is not correct above. was suprised it was working but didnt say anything if you had it working.
After rebooting there is still some lag in the system for Z-Wave devices w/GH commands, but from the device pages it's instant again. So reboot fixed the HE side of device control. I'm going to leave Sendmail disabled for now as HE staff is looking at the Telnet and EOF issues...thanks for your help.
I'll ask them to check the port. My settings are the SMTP port for Spectrum, taken from their site directions. It is currently (or was until recently) set to 587. The 993 I posted above was a "typo" on my part.
regardliess if that is the case it is a bug.. as long as the socket is closed it should not be an issue .
and how many emails are you sending.. i cant image even leaving open 50 sockets would be an issue either.
also if they think that is the issue they need to test the telnetClose command to double check it is working because i checked the code and there is no issue there.
