Nice update. thanks.
I have a suggestion for minor change to the code
input("Username", "text", title: "Username for Authentication?", required: false, defaultValue: "")
input("Password", "text", title: "Password for Authentication?", required: false, defaultValue: "")
change the User/Pass titles to include "(base64 encoded)"
you dont need this to stop relaying.. On my server you just specify which ip ranges are allowd to relay, and also if they login/authticate if relaying is allowed or not.
In addition, it checks the to address and doesnt mail if it is not hosted on the server..
so no this is not 100 correct.
thanks version 2.1 on slite.. added,, cleaned up debugging and version
I'm not sure why you took exception to my comment. My comments weren't directed at how you personally choose to operate your email gateway. My comments were posted to this thread in general and were intended to explain the general operation of email gateways. I stand fully behind what I wrote, as it was written.
I noted that authentication isn't needed by a gateway accepting email for the organizations own email addresses.
And, I didn't claim that authentication was the only way to stop relaying--only stating that authentication is performed as a way to prevent relaying. Which is true as written. Moreover, if you have a trusted IP address, that is a form of authentication.
As for restricting based on IP addresses, that works well for "internal" IP addresses/ranges that are static and trusted. It can possibly work in limited and very small environments for external/other/outside users. However, it does not scale well for "other entities", once you get past a small number of IP addresses.
Given that most residential IP addresses are dynamically chosen from very large IP address ranges and are subject to frequent changes, maintaining a "locked down" list of IP addresses rapidly becomes infeasible and unreliable. Moreover, allowing, say, a range that encompasses "All Charter Customers" isn't going to prevent relaying. Thus, using IP Addresses simply isn't an option for the vast majority of organizations with an email gateway (aside from internal IP ranges and those involving very specific business needs).
I didn't take exception. U was just commenting that it was not 100% correct.
So after experimenting with a few different options I've settled on HEmail and it works great.
I installed Synology Mail Server on my NAS and configured it to be an SMTP Relay (this is crazy simple to do) to my MS Outlook account. HEmail then uses it to email notifications to my Gmail account.
I tried using Gmail and Yahoo as SMTP relays but they won't allow it and I didn't bother trying iCloud.
Synology Mail Server Config:
HEmail Config:
Email User = Synology User Name
Email Password = Synology User Password
@erktrek Is it possible to add some sort of queuing to your driver or retry function? I'm occasionally finding emails just aren't being sent at all and there's nothing on my Mail Relay to indicate an attempt to send an email was even made.
I know the notifications I'm using work, because they also use push App notifications (from the same Notification rule) which work every time.
So the driver is pretty simplistic - establish a telnet connection and dump what is passed. A thought would be adding some sort of delay or retry and beefing up error trapping.
I have not really messed with the code since I started using Node-RED which has it's own email node that works with everything.
Ah, I think the issue is notifications sent close together. The first one always works, but the 2nd one fails if an email notification is still in progress.
Any chance you could add a delay function that waits for say 1 second after the IP email is being sent before sending the next one?
PS, I have no plans to use NR, it's very cool but now I have my head around RM I just dont see a need for it.
So each send is a separate thread I think. Best I can do is introduce a random delay before sending. Will look into..
Cheers.
Here is my issue. I have an internal Email server (Postfix) running on a linux box. My email notification all go through the postfix and work great as I have the Postfix box relaying to Gmail using a secure connection. So basically I just need this to send and email to my postfix server with only these fields:
This postfix server is at my house and behind a firewall. I use it for all notifications within my network. It only sends. All my apps that I have running or servers only require those 3 fields.
How can I make this work? I tried setting the other fields to false, but it still doesn't send.
This is how you setup postfix to relay to Gmail for those interested.
That's cool thanks for the link. I am doing exactly the same except I run my own mail server (postfix as well!) in a dmz but that will come in handy I think.
Have you looked at @kahn-hubitat's sendmail? He's been actively developing his version so that might be something to consider.
I am using Node-RED for my rules etc - it has built in email support so I can securely send and notify based on HE events.
I'm running a DMZ also. I looked at Kahn's app and it says no local server needed. I'm really looking for something that stays inside and let Postfix securely send the email through Gmail. I really thought this app would work. I think it's close I just don't know code or I'd fix it for my use.
I use sendmail as a relay. And my outgoing email is sent via Gmail - I have a specific Google username just for my Hubitat notification email. I had to decrease account security to get this to work. Specifically, turn on "Less secure app access".
Once you do that are you sure it's only turned on just for that one Gmail accoun? Would not want that enabled across regular personal accounts...
Is there any way to use some sort of global/process variable as a type of "lock"?
If it was set, that meant something else was sending--causing other threads to wait until they could get the lock variable?
It wouldn't likely be 100%, unless there is some sort of thread-safe locking in HE to check and set that variable in an atomic process.
Yes, I think there is.. something to look at maybe... mmmm
I just added a semaphore lock to the seqSend function. It's on github now. Have not really tested it all that much.
Download the Hubitat app
