Email notifications not working

On Forris, under Maintenance, Notifications and Automatic Restarts is an option:

Notifications settings

I have configured these and tried to send a Test message, But the message does not arrive.

I have configured as follows:

Enable notifications: check
SMTP provider: Turris
Recipient’s email: my email address
Sender’s name: cerberus
Importance: Reboot or attention is required or update was installed
Send news: check

And I click Send testing message and it reports “Testing message was sent, please check your inbox.”

Nothing however arrives and I see nothing in /var/log/messages that looks like an error.

What’s wrong and where should I be looking to diagnose?

Bump. Surely someone can help out here? This is pretty frustrating at some level given how easy this should be to configure.

Hi, have a look into SMTP documentation: https://wiki.openwrt.org/doc/howto/smtp.client?s[]=msmtprc :wink: I use it regurarly without any problems.

Thanks for the tip jada4p. I admit I already read that page and am hoping for support from Turris staff to explain why out of the box a pricey router which offers notification, doesn’t do that when it’s turned on.

As it happens at least the up side is that it’s OpenWRT, open source and they have a support line that I will use because I have traced it as far as I can.

Essentially two shells scripts are central to this:

/usr/bin/create_notification
/usr/bin/notifier

The first creates message in /tmp/user_notify, the second is run by cron every 5 mins (strikes me as an odd thing to run on a schedule when it can be event triggered but hey, I didn’t write this).

Being shell scripts bash -x is really handy tod rill down into what’s happening and essentially nothing is going wrong on my router.

A mail config file is created a mail message file is created it is mailed using msmtp and msmtp returns 0 status code suggesting success. A simple test reveals the server is up and running (using a config file I that notifier created - I just paused the script immediately before it calls msmtp, copied it and and the message and set them aside for testing):

# msmtp -C msmtp.cfg --serverinfo
SMTP server at smtp.turris.cz (smtp.turris.cz [217.31.192.110]), port 465:
    smtp.turris.cz ESMTP Postfix (Ubuntu)
TLS certificate information:
    Owner:
        Common Name: smtp.turris.cz
        Organization: CZ.NIC, z.s.p.o.
        Locality: Praha - Vinohrady
        State or Province: Hlavni mesto Praha
        Country: CZ
    Issuer:
        Common Name: StartCom Class 2 Primary Intermediate Server CA
        Organization: StartCom Ltd.
        Organizational unit: Secure Digital Certificate Signing
        Country: IL
    Validity:
        Activation time: Thu Jun 26 02:48:26 2014
        Expiration time: Sun Jun 26 19:39:55 2016
    Fingerprints:
        SHA1: B1:4C:B3:C2:87:11:EA:7C:09:99:2A:64:9B:7D:85:37:96:6C:B3:70
        MD5:  6D:00:88:4B:68:13:AD:08:5F:B7:6E:79:DF:0F:89:03
Capabilities:
    SIZE 10240000:
        Maximum message size is 10240000 bytes = 9.77 MiB
    PIPELINING:
        Support for command grouping for faster transmission
    ETRN:
        Support for RMQS (Remote Message Queue Starting)
    DSN:
        Support for Delivery Status Notifications
    AUTH:
        Supported authentication methods:
        PLAIN CRAM-MD5 DIGEST-MD5 LOGIN 

And the conclusion is simple: The Turris mail server is accepting my email, reporting success and happiness and not delivering it. Go figure. So it’s time for Turris support staff to check their mail logs and tell me what is going on, and I’ll email them for that.

Dammit! Just as I started writing that support question, a string of notification emails arrived. Grrr.

Conclusion:

  1. Something went wrong first time, undiagnosed alas and uncertain what, but it left my test message marked as already sent. It does this by leaving an empty file named sent_by_email in the message folder.
  2. Manual runs of notifier subsequently did not send it for this reason. I found this out while drilling into the code.
  3. I deleted that sent_by_email and traced notifier finding it did send to the mail server but I received no email.
  4. I played around drilling down into it capturing configs and messages and such running notifier a good few times during these tests, had dinner, put the kids to bed and more, so time passed, but still always reported success but no email.
  5. I give up, post here, start a support email and then a string of notification emails arrive, my tests …
  6. Therefore conclude: Initial test failed for unknown reasons, unable to reproduce it because tests now work, but learned a lot in process, emails take time to arrive (surprisingly slow, as in hours not seconds, not minutes), but impossible to say if that the SMTP server to blame of my mail host (zoho).

Well it works, and sadly did not learn what caused this cycle of needless exploration and debugging alas because I can’t reproduce the failure, but it did not work, out of the box at all sadly. Grrr … one of those only mildly satisfactory diagnostic efforts, which yield a positive outcome but no understanding of what caused the initial problem and no immediate hope or even real desire of being able reproduce the original problem.

Hi, I suppose notifications are queued on the mail server and acted upon in server idle time :wink: I saw such a behaviour quite often :frowning: Delay could be couple of hours, unfortunately :open_mouth: and, as far as I think, there is no means how to force immediate delivery :frowning: We have to live with it :wink: Anyhow, you can use your own mail service, as documented :wink:

Oddly I did some more testing last night to polish off the format of my notifications (as I’m putting together some DDNS diagnostics for my LAN and it hotplugs into ifup logs a change in WANIP, emails me, and I have a way of checking propogation of the IP update coming I guess, but for now have some cool diagnostics).

Which are here if interested:

And yes, using any other SMTP server (Google and Zoho both provide) is an option, part of my drive was understanding why the out-of-the-box Omnia could not would not send email notifications when it offered to. Alas I did not find out why not, as in the process of diagnosing it came good and works. A diagnosers nightmare of sorts ;-).

Working well now, except that Foris has a bug that I logged here:

Turns out the Turris SMTP server has some ridiculously low upper limit of emails to send per unit time. All I did was test my evolving service, and I’m talking under 10 emails an hour for under 2 hours and it stopped accepting them complaining I’d gone over some limit. So I moved to the Zoho SMTP server and all is good ;-).