Email on Alarm

[gidi-up]

Cheap and functional, awesome

Thanks

Jerry

[Cyclops]

has this been looked at any more? as this feature would be great for me.

[pngaudioguy]

What if you were to code it so that if a user wants to enable e-mail alerts, they have to provide an account to send from. Usually your own ISP will allow you to use their outgoing server for your personal use as long as you have an account. The end user would then have to set up on the e-mail alerts page not only the e-mail to send alerts to, but also to send alerts from (your_account@your_ISP), and the SMTP address, etc. A tiny bit more config, but that way your server doesn't have to be exposed, and users that want the feature could enable it. That's how our multifunction device at the office is configured.

[brahn]

What you describe is how I initially developed the email support. It gets more complicated when you start having to deal with SMTP authentication and ISPs that require SSL connections when storage is at a premium, which is why we made the design choice that we did. It's too late to do anything in the firmware for 4.0, but we'll see if we can get the server configuration worked out. Post-4.0 we'll be looking at other options.

[jward]

There are a couple of tricks one can use.

If you contact the SMTP server that delivers the email for the address being sent to then authentication and SSL are not required by SMTP specification. This would be useful if one is sending the alert email to an email address provided by their own ISP. I would specify something like myaccount@cox.net and SMTP.west.cox.net:25. Technically, the SMTP server used should be the host listed in the MX record for the recipient address domain and not necessarily the SMTP host one uses for outbound email.

Another trick you can do is move your hosted SMTP service to port 80 or another seldom blocked port. Of course you have to take measures to not become a spam relay.