Sendmail - Send email and text notifications, (notification device) no local server needed

Designed to be used to send email to your Phone carriers email to text gateway to enable you to get text messges from hubitat.
But also can be used for any emailing as well.

It is actually installed as a device not an app,
It does need a server to gateway your email through like your isp, etc.
It will show up as a native notification device.
Create one device for every sendmail (email:to) endpoint that you want as a notification device.

Uses native telnet implementation on hubitat.

It is also hosted on package manager as well, recommend you get it from there if you can.

7 Likes

My minor suggestion is to add "email" or "mail" to the description, so that it shows up in HPM keyword searches under those terms. (searching for "mail" does not appear to match "sendmail").

1 Like

This could be very useful. Note that this is more likely to be successful if you have an SMTP server that you also control. It may be difficult to find ISP SMTP servers that would accept unauthenticated helo traditional connections.

No it can cause authentication by user name and password. See options

I just set this up (*) and tried to send email via the sendmail running on my FreeBSD server. I got this:

2020-11-16 10:53:50.400 am [debug](http://hubitat-hub/device/edit/385)lastCommand = helo
2020-11-16 10:53:50.396 am [debug](http://hubitat-hub/device/edit/385)In parse - 501 5.0.0 helo requires domain address

Sure enough, you are sending HELO without a hostname, and sendmail rejects that by default.

I changed line 101 to this and worked around it (it requires a hostname, but it doesn't check the value).

             def res1 = sendData("helo hubitat",500)

(*) You might add this instruction to the first post:

After adding this under Drivers Code (or using HPM), under Devices use "Add Virtual Device" and select this driver under "Type".

Ah, OK. I was looking at the comments at the top.

I came back to add that an ISP would have a better chance of accepting it if they are authoritative for the domain you are sending to. That is, if you are always sending your own email address at @contosa.com and you are using contosa.com's MX to send it. I'd only do this, though, if you can't relay through your own ISP. Reason: The MX is only guaranteed to be valid for its TTL. Another potential issue with talking directly to your recipient domain's MX arises if you have a dynamically assigned IP address (your external IP from your ISP, not your internal network).

it was optional in the original rfc.. and what you have is not allowed either and will cause problems.. if you do use a name it is required to be a fqdn (fully qualified domain name)
could just be something with your server as i have no problem with other servers..

as do some others that have tested it.. may try to change to the ip address in bracckets which is allowed?

probably best just to put an option as to what you want to use as the name. as if you use one like you are doing and the reverse dns does not map to the same ip many servers will reject the email, while many of those will accept if you DONT use a name.

does anyone know how to get your own ip address through code in a device handler?

Stupid question chit thrown down on the table...

Is this likely to work w/Gmail or Hotmail to send emails to my phone's text email address? Both have 2FA on them, I'm assuming that's a non-starter.

i dont know i image if you can log in with a username password on their server and you have an account it should work.

Ok new version put up. version 2.2

added an optional parameter for your hostname uses that in the helo command .
If it is blank uses your ip address in brackets which is what probably should normally be used. Ie most people should leave blank.

If this doesn't support TLS or some other form of encryption, then it should really only be used for a local (inside the house/LAN) type connection. It's not secure to send unencrypted "user" and "pass" commands through native SMTP, as that leaves your email account's userid and password potentially exposed.

If nothing else, you should obtain a "throwaway" account so that any such exposure doesn't compromise the id/password you use for important (beyond the Hubitat) email.

3 Likes

you will need to set this up . then it will work seems overly complicated

https://support.google.com/a/answer/176600?hl=en

1 Like

That seems to require that you have a static IP address (something not available for most "home/consumer" internet accounts.

And, it requires a higher level G-Suite subscription.

1 Like

no it doesnt require a static ip.. nobodies printers do.. but yes you will need to get the higher g suite .. probably just easier to use your isp's mail server.. most people have an isp and most let you send mail through them. unless they are requiring encrypted end to end.

Thanks...I haven't used any email through my ISP in a million years. :slight_smile: Not even sure if I still have an email address set up with them (Time Warner, now Spectrum)! I guess I'll have to go take a look.

Perhaps optional in the original RFC, but it's been standard practice for many years to reject server connections that don't properly identify themselves. Identification requirements generally include:

  • HELO with FQDN
  • Forward resolution of FQDN to originating IP addr
  • Reverse resolution of IP addr to FQDN (optional)

ISPs often have servers that are intended to only to serve clients. These will often depend upon client Auth rather than the above.

${device.hub.getDataValue("localIP")}

1 Like

Trying to set up my Spectrum (originally TWC) email address didn't work, using supplied settings from Spectrum:

image

Sits here and never updates.

Thank you, that works perfectly (I just left it blank).

That appears to have solved my problem as well - put in my public IP and it worked, I got a text using the Device Notification command on the Device page. :slight_smile:

I have duckdns setup for a fixed external address. Using that worked as well. :smiley:

I'll do a little more testing to confirm.

EDIT: Have tried this from an app as well and worked, so this is looking very good. This has to easily be the easiest way to enable text message notifications from Hubitat.

A couple of suggestions:

  • Publicity!! Can the thread title be edited/updated to include the word "texts" or "text notifications" to make it easier to find when folks are looking for info/options on that feature? Thinking about folks less technical who just want a way to send text notifications.
    E.g., Sendmail - Send email and text notifications, no local server needed Add a statement to the OP reminding folks that many cell providers allow you to send emails to your phone number that will arive as texts.

  • Rename driver - the leading "LGK" had me confused, I was looking for it in the "S" section of my driver list. Maybe "Sendmail by LGK" or similar?

Very happy!! Great work providing a key missing feature in HE in a simple way that many/most users, particularly those less technical, can use.

1 Like

If you have a Synology NAS, just install Simple Mail Server and configure it as an SMTP Relay server using an o365 account to send mail to any other address you want.