not sure why did you try to install it as a smartapp instead of a device type..
it is not a smart app. it is a send mail device.. you install in in your drivers code then add a device for every server to email combo you want to use it for.. then you use it in apps as a notification device..
I get
2020-09-10 09:04:44.731 am [debug]got bad response = 501
2020-09-10 09:04:44.727 am [debug]in helo case
2020-09-10 09:04:44.723 am [debug]got server response 501 value = null lastCommand = (helo)
2020-09-10 09:04:44.720 am [debug]lastCommand = helo
2020-09-10 09:04:44.717 am [debug]in parse 501 Usage: HELO domain
2020-09-10 09:04:44.192 am [debug]helo
2020-09-10 09:04:44.188 am [debug]in initialConnect case
2020-09-10 09:04:44.185 am [debug]got server response 220 value = null lastCommand = (initialConnect)
2020-09-10 09:04:44.163 am [debug]lastCommand = initialConnect
2020-09-10 09:04:44.160 am [debug]in parse 220 omta02.suddenlink.net ESMTP server (InterMail vM.8.04.03.22.02 201-2389-100-169-20190213) ready Thu, 10 Sep 2020 09:04:44 -0500
2020-09-10 09:04:43.947 am [debug]Connecting to smtp.suddenlink.net:25
2020-09-10 09:04:43.941 am [debug]in sendmail deviceNotification
You say "works with any server, no authentication required" but I'm pretty sure my ISP server wants a password to go with the required username
thATS NOT the way email works.. maybe for reading email but for delivering think about it... if those servers asked for password no email would be delivered.. True email servers accept email from anyone.. walmart does not put a password in when sending you a message. you must be using an internal not outside facing email server
If your email server requires authentication, this will not work. It only works on servers that accept email with no authentication. That was (maybe still is?) common for sending via a server provided by your internet service provider, but not for other servers. I haven't used my ISP's server in decades; I have another email provider.
The username for authentication on a server is not the same thing as the "from" email address.
The outgoing email server I'm pointing to is the ISP external email server (smtp.suddenlink.net port 25). It doesn't require SSL/TLS but it does require a password. The username is my email address
Suddenlink Email Settings
Incoming Mail Server
Account Type: POP
Username: Your email address is your username
Server hostname: pop.suddenlink.net
Server port: 110
Authentication: Password
SSL/TLS: No
Outgoing Mail Server
Account Type: SMTP
Username: Your email address is your username
Server hostname: smtp.suddenlink.net
Server port: 25
Authentication: Password
SSL/TLS: No
Maybe I should approach this a different way. I'm not locked in to using my ISP's email server. If there are other servers out there that accept non-authenticated email senders, I'm more than happy to point to one of those if anybody can suggest one that works with this driver
If the smtp server requires authentication but doesn't support encryption, I wouldn't use it.
There are some other user apps for sending emails. One is by Cobra:
I ended up hacking some things (including this) to get my email sent with encryption to my smtp server through curl on another local linux machine via telnet.
It's a really nasty hack but it works for me.
give me the ip address or a range for your public ip from your hub and i will add a rule to allow you to relay through my email server.. send it offline in a pm
another ooption is if you have a nas ie qnap ,synology etc. you can easily setup an email server to use just for yourself.
1 Like
Good point. But isn't that how the HEmail driver works? Thats why I was trying to use Kahn's modified (no authentication) version. I'm just looking for a simple solution to sending email notifications from Hubitat.
Thanks for the tip. I'm looking into that one, but it appears he's recently had to restrict it more...
And it would be nice to not have to relay email to the UK and back just to get a simple text notification.
"...the usual." So, if I install your app I should expect my dogs barking insanely like when they see a plastic bag that has fallen to the floor that (evidently from their extreme distress) looks like a giant monster that is about to eat them? Well then no thanks, buddy, to your app!
This should motivate me to finally setup an email server on my Synology NAS to try this out. Want to send SMS notifications to my son and wife, and they just arent interested in installing the HE app.
2 Likes
There's a lot of email topics getting mashed around and mixed up.
As a former, but long time email administrator for an enterprise, this is all pretty near and dear to me.
-
All "good" email gateways SHOULD require authentication to send email to anyone OTHER than one of their own customers. This is to prevent "relaying" where spammers dump email through their gateway server and spam the world.
-
Anymore, there's increasing use of SPF records, DMARC, and DKIM to validate the source of an email. in combination, these allow the recipient to trust that the email was sent from a legitimate server and that the sending information is valid. They allow the sending domain to provide instructions to receiving email gateways about how to handle email that does NOT have the proper authentication. This is increasingly used to divert improperly sent email to spam/junk/trash folders.
-
Most residential internet service uses dynamic IP addresses which, while they often stay the same for quite a while, aren't guaranteed to. However, they are often in known ranges that are flagged by Spam checkers, etc. So, when they see an email coming directly from a residential domain, they might not even accept the connection attempt.
-
If a publicly accessible email gateway is accepting traffic from anyone, they are likely to end up on the "naughty list" and black listed. If for no other reason than they will become a prolific spammer.
Saying all that, if you are simply wanting to send email to a single, static, well known email address, you might be able to cheat a bit.
You can look up the recipient's "MX" record, which will tell you the email gateway server for the recipient's domain. This can, of course, be changed by that domain at any moment in time (within the limits of their TTL setting). With that server known, you should be able to initiate a no-password required SMTP session to that email gateway. IF they don't block residential IP addresses (or otherwise have restrictive policies in place). The other catch is that you need to make sure that YOUR OWN email domain does not have tightly restricted SPF, DMARC, and DKIM settings in place--or, again, your email might be dumped into the bit bucket. Obviously, if you control your own domain name, you are able to set this up to your heart's content. You'll need to manually update the server if it gets changed unless you build "MX" lookups into your process.
As for encryption, there's a growing push to use TLS encryption (this is "encryption across the internet", not "end to end" encryption) for email, but that's not a widely enforced matter. For the most part, senders and recipients only force this when they know each other and want to ensure email between their sites is protected--although most major gateways will accept a TLS email conversation (they just don't require it).
In most situations, when you send email, you are connecting to your internet service provider's email gateway. They are requiring you to authenticate so they can make sure that your sending name, email address, etc. are legitimate--and to stop spammers from abusing the systems.
Since authentication is involved, this really SHOULD be done over and only over an encrypted connection. Once your ISP's gateway has collected your email, it looks at the destination domain, then does an MX lookup, connects to that domain's email gateway, and passes the email along--adding the necessary DMARC/DKIM information (and, hopefully, abiding by their own SPF records by using a valid server!). This is the general process, understanding that several more hops could be involved on either side for their internal business reasons.
2 Likes
new version of my sendmail on the github..
V2
has optional authtentication..
You put the username and password in in base64 encoding.
Use port 587 normallly
If you dont check authticate works as it used to without it.
2 Likes
Thanks again for taking this over!
This will still not work with google.. They require end to end ssl.
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.
