[BETA RELEASE] HEmail - Simple Email Notification Device Driver, no RPi needed

Here is a very simple email notification driver that uses telnet to send email notifications to a (?local?) smtp server of your choice.

Note: It CANNOT handle SSL/TLS so is not suitable for GMail or other major mail providers etc. Also it is not very secure so plan accordingly.

This is a beta release so expect some bugs, confusion the usual...

7 Likes

You say no RPi needed but you would still have to have a local email server running, correct? Isn't that a bit of a higher bar than having an RPi?

1 Like

Any smtp server that handles a connection to port 25 (or other unsecured port) should work.

I still prefer the RPi approach but thought this might be something to try.

In the past I have used netcat and some other bits to send email directly to Gmail. I will see if I can find the old scripts. Most NAS devices should have NC and support telnet???

Depends on what you have I guess - but it's worth a look though..

New update, cleaned up code a bit - created new seqSend function to help serialize process in a more uniform way.

Checking this out, but looking at your instructions vs what comes up in the preferences section is different.

I have only 4 fields. DoNetStuff Email URL, From, To, Subject.
There are no options for Email Server, Email Domain, User, Password, Port.

That is my other driver for DoNS-Email... this one is HEmail.. see the link above. Also let me know how it goes!!!

DoNS-Email is for those who have an RPi or equivalent. It requires some additional setup including installing NodeJS etc.

HEmail is an attempt to use Telnet to communicate with an accessible smtp server directly. Limitations are no ssl/tls.

1 Like

I see what I did wrong. I went to the link and went to the instructions section and clicked the link code there. and that gave me the wrong one. But I have it now. Going to test now.

Ahh okay will change that in the readme. thanks!!

Everything seems to work. Found out my ISP is not going to allow SSL anymore.
This works great. To bad we can't get google api with SSL to work.

"As of April 23, 2019, SSL will no longer be a valid security setting. All customers with SSL enabled will need to disable SSL or will no longer be able to send or receive email."

I am thinking about changing my DoNS-Email to handle smtp "relay" and maybe other authentication types so that might be a future possibility.

1 Like

Not sure if this is my ISP or they driver, but at the bottom of every email i get
"X-CMAE-Envelope:" and then a very long string of random characters.

Try putting an extra empty line or 2 at the start of the message body ("\r\n\r\n") .. if that works I will see if I can add to the email body part in the driver.

("\r\n\r\n") comes out as text
"\r\n\r\n" comes out as text
('\r\n\r\n') comes out as text
'\r\n\r\n' comes out as text

Also noticed they dont always send. here is the log.

dev:1692019-04-19 10:31:40.225 am debugsetting state.lastMsg to 500 5.5.1 command unrecognized

dev:1692019-04-19 10:31:40.219 am debugparse 500 5.5.1 command unrecognized

dev:1692019-04-19 10:31:40.022 am debugsetting state.lastMsg to 250 OK

dev:1692019-04-19 10:31:40.005 am debugparse 250 OK

dev:1692019-04-19 10:31:39.983 am debugsetting state.lastMsg to 250-STARTTLS

dev:1692019-04-19 10:31:39.964 am debugparse 250-STARTTLS

dev:1692019-04-19 10:31:39.931 am debugsetting state.lastMsg to 250-8BITMIME

dev:1692019-04-19 10:31:39.913 am debugparse 250-8BITMIME

dev:1692019-04-19 10:31:39.886 am debugsetting state.lastMsg to 250-ENHANCEDSTATUSCODES

dev:1692019-04-19 10:31:39.879 am debugparse 250-ENHANCEDSTATUSCODES

dev:1692019-04-19 10:31:39.829 am debugsetting state.lastMsg to 250-SIZE 28672000

dev:1692019-04-19 10:31:39.797 am debugparse 250-SIZE 28672000

dev:1692019-04-19 10:31:39.760 am debugsetting state.lastMsg to 250-HELP

dev:1692019-04-19 10:31:39.741 am debugparse 250-HELP

dev:1692019-04-19 10:31:39.702 am debugsetting state.lastMsg to 250-eastrmimpo210.cox.net hello [70.173.135.57], pleased to meet you

dev:1692019-04-19 10:31:39.683 am debugSending AUTH PLAIN ************************

dev:1692019-04-19 10:31:39.679 am debugDomain Configured!

dev:1692019-04-19 10:31:39.660 am debugparse 250-eastrmimpo210.cox.net hello [70.173.135.57], pleased to meet you

dev:1692019-04-19 10:31:39.541 am debugsetting state.lastMsg to 220 eastrmimpo210.cox.net cox ESMTP server ready

dev:1692019-04-19 10:31:39.519 am debugSending ehlo cox.net

dev:1692019-04-19 10:31:39.514 am debugConnected to email server!

dev:1692019-04-19 10:31:39.500 am debugparse 220 eastrmimpo210.cox.net cox ESMTP server ready

1 Like

So part of it is the blank command at the end that is causing some mischief. I just removed it and added a delay parameter to the sendMsg method. See if that helps any. Not sure this will actually work for you but it's worth a shot.

The other thing you can try is manually attach to your smtp server via telnet or putty and enter the steps:

ehlo [YourEmailDomain]
AUTH PLAIN [your encoded user/pwd string]
MAIL FROM: [from email address]
RCPT TO: [to email address]
DATA
From: [from email address]
To: [to email address]
Subject: [A subject]
[body of email goes here]
.
quit

And see what responses you get.

I just updated again to add the "quit" command - thinking is to end the server session gracefully.

Upon further research that "X-CMAE-Envelope" is a CloudMark anti-spam thing that is added by the server so not sure I can remove it unless there is some other smtp command that has to be added..

Thank You - Thank You - Thank You

I'm testing this right now and am getting emails through to their destination with the Subject Line as typed...but I am not seeing the content line. In fact the email looks like not even a line feed or carriage return is interpreted (ooo, do those terms date me).

So based on what I found I question how the content is being interpreted by the mail reader. Maybe an HTML vs TEXT interpretation thing. Maybe nothing you can do about this on my side, but others in the future might wonder why they too don't see the content so I'm posting this.


Event log in reverse order; assume stated error has nothing to do with msg content line.

|telnet|Disconnected, email sent.
|telnet|Disconnected. receive error: Stream is closed
|telnet|Connected.

Looking at the Email Source info in mail reader I do see the text line:

X-Sender: me@ xyz.com
From: me@ xyz.com
To: me@ abc.com
Subject: HE Msg Relay
sending email from HE
X-CMAE-Envelope: long HEX string


I saw nothing in the more detailed system log that indicated what the posted error was for.


Would be cool if the Subject line was a dynamic variable for quick scan purposes. This might also avert SPAM blocking from seeing the same subject from the same sender repeatedly (Shouldn't matter at this volume of messages but it might).


One other question, what in your opinion is the security risk in using this facility. What is getting transmitted "in the open" other than the msg content ( ignoring what's sitting in the device field entries on the HE ).

Thanks again for your work. :+1:

You are welcome!
I am not sure why you are not getting the body.. maybe the issue is the "X-CMAE-Envelope" header at the end?

Download the Hubitat app