Email alert does not work @ RAIDiator 4.2.21

This evening I put a wire tap between my NAS and the router/firewall.

1) When using the internal mail engine, I can see (presumably) exim querying and resolving the recipients mail exchanger IPs, but no SMTP traffic is observed. The mail is kept under /var/spool/exim and according to logs it seems like exim is on regular basis (I believe I saw a cronjob entry for exim) trying to deliver the mail, but to no avail.

The exim log file becomes filled with messages similar to the ones I reported yesterday.
T=remote_smtp defer (113): No route to host

Frontview returns with a success message... :(


2) When using gmail I believe sendmail is used and now I can see some outgoing SMTP (after address resolving).

Regardless if I use default (with TLS) or custom (with/without TLS enabled) settings, TLS handshake takes place after the initial unencrypted SMTP handshake (EHLO -> At your service -> QUIT). I can't tell what takes place in the TLS part that follows, but a moderate number of encrypted bytes are sent back and forth (just as if a message is forwarded).

Connection made to 173.194.71.109 (one of the two IPv4 address behind smtp.gmail.com)

220 mx.google.com ESMTP somehash
EHLO localhost
250-mx.google.com at your service, [my.external.ip.address]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES
QUIT
221 2.0.0 closing connection somehash

Connection is closed and then reestablished with 173.194.71.108 (the other IPv4 address behind smtp.gmail.com)

220 mx.google.com ESMTP somehash
EHLO localhost
250-mx.google.com at your service, [my.external.ip.address]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES
STARTTLS
220 2.0.0 Ready to start TLS

A few TLS encrypted telegrams are now exchanged before the connection is closed.
Then a new connection is established (again) with 173.194.71.109 (the IP used in the first connection)
After some more TLS encrypted telegrams the connection is dropped.

Now Frontview returns with an error message "Failed to contact SMTP server."

What can be wrong?

Why is exim not able to route itself out of my box (ping can...)?

Why does the sendmail/TLS session fail even when gmail seem to "talk"?

/f

I am surprised that it isn't working. Did you have this working before?
(were there any changes?)

I made an initial attempt to configure alerts shortly after buying the unit (soon a year ago) that ended with negative results.

Some time ago I upgraded to the most recent RAIDiator FW and I have now given the alerting another round with a network sniffer in between to see what takes place and not.

Are there any known "no-nos" like using the same gmail account for both sending and receiving the alert?
Why does the box remain silent on SMTP when using the internal mail engine?

As "junk" is piling up @ /var/spool/exim/..., is there any idea to "flush it" to get a clean start?

I see no older messages than these two days of failed attempts so I guess the unsend mail expire or the FW upgrade some time ago erased the unsent mail from my first attempt almost a year ago?

However, there are two files from my first attempts a year ago (2011) that must have survived the FW upgrade.

/var/spool/exim/db:
total 48
-rw-r----- 1 mail mail 24576 2012-09-13 22:08 wait-remote_smtp
-rw-r----- 1 mail mail 24576 2012-09-13 22:08 retry
-rw-r----- 1 mail mail 0 2011-09-17 21:57 wait-remote_smtp.lockfile
-rw-r----- 1 mail mail 0 2011-09-17 21:56 retry.lockfile

Any ideas folks?

/f

Nope, cleaning exim's stuff on /var/spool including the one year old files did not help.

Same problem remains; alerts attempted via builtin mail agent stockpile on /var/spool/exim due to "no route to host" and alerts attempted with gmail engine do result in outgoing SMTP traffic, but nothing gets through.

Telnet to gmail server port 587 does give a response:

NAS:/var/log/exim# telnet 173.194.71.108 587
220 mx.google.com ESMTP somehash

/f

Finally I got it to work!!! :D

While flipping & turning every stone on the NAS's harddrive I finally stumbled on this log file:
/var/log/frontview/msmtp.log

Each time when using the gmail engine, the following was logged:

Sep 14 13:08:33 host=smtp.gmail.com tls=on auth=on user=bla.bla@bla.bla from=bla.bla@bla.bla recipients=bla.bla@bla.bla smtpstatus=535 smtpmsg='535-5.7.1 Username and Password not accepted. Learn more at\n535 5.7.1 http://support.google.com/mail/bin/answ ... swer=14257 somehash errormsg='authentication failed (method LOGIN)' exitcode=EX_NOPERM

I then found another file that stores the email account settings when using anything but the internal engine:
/etc/msmtprc

All looked good, but my 20+ years of experience of UNIX troubleshooting made me wonder if a blank space in my email password could cause trouble?
After trying to escape it (\) and embrace the setting with quotes, etc. I resorted to change my email password and eliminate the space character...

Voila...


Ergo: RAIDiator 4.2.21 is unable to properly submit alerts if the email account password contains a space character. It even corrupts password containing space characters once the settings are "reapplied". If you touch some other setting, e.g. a recipient name (leaving the hidden, bullet formatted password unchanged) and push "Apply" the password will now be "chopped" after the first space character.

Still, I wonder why the built-in email engine (exim) does not "find its way out of the box"?
It would have been very nice to be able to skip the gmail settings leaving my dear password in plain text on my NAS drive.

/f