V12 and Email Notifications

[PGalati]

Not sure if others have experienced this but my email notifications started failing with a -597 error after updating to v12.  Once I removed the checkbox to require smtp authentication, the test email was sent successfully.  Reenabling authentication caused it to fail again.  Since I manage the mail server as well I am able to work around this issue, but wanted to know if others may have seen this.  Nothing changed in the email preference between 11.5 and 12 other than it stopped working as configured.  The user name is just the account name not including the domain and the password.

[Don Lee]

Those who run their own mail servers should have access to the mail server logs and be able to be more detailed in what is going wrong. What, precisely, is retro doing in v12 that is different, and is failing? Is this a situation where v11 is falling back to un-authenticated? It may be taht the AUTH never worked, and v12 is just catching the error.

 

It seems to me that there was something in the v12 release notes about this….

[PGalati]

Thanks for the reply.  Looking at the mail logs from Monday when Retro was still running 11.5, it does appear that Retro was properly authenticating with the mail server.

 

11:30:38.348 2 SMTPI-247735([192.168.1.99]) authenticated as postmaster@domain.com
11:30:38.348 4 SMTPI-247735([192.168.1.99]) rsp: 235 postmaster@domain.com relaying authenticated

 

Now after installing v12, I did not see a single reference in the mail logs referring to a connection coming in from Retro UNTIL I turned off smtp auth.

 

11:10:08.775 4 SMTPI-260476([192.168.1.99]) cmd: HELO ip99.domain.com
11:10:08.775 4 SMTPI-260476([192.168.1.99]) rsp: 250 domain.com we trust you ip99.domain.com
11:10:08.776 4 SMTPI-260476([192.168.1.99]) cmd: MAIL FROM:<Retrospect@domain.com>
11:10:08.776 4 SMTPI-260476([192.168.1.99]) rsp: 250 Retrospect@domain.com sender accepted
11:10:08.777 4 SMTPI-260476([192.168.1.99]) cmd: RCPT TO:<pgalati@domain.com>

 

As shown, no authentication was negotiated but accepted since ip99 is whitelisted.

 

I am gettng a "No Server Found at that Address (-597)" error, and it never initiates an outbound connection.  Again, turning off smtp auth fixes it.

[bdunagan]

@iCompute You're correct about the fallback. In 11.5 and earlier, Retrospect would attempt a secure authentication but fall back on an insecure authentication if the first failed. We added a new email checkbox to avoid that security issue. See our KB article for details. It's also listed in the Release Notes, but we've now updated those to include a link to the KB article as well.

[Don Lee]

I'm not clear on what's happening. "I did not see a single reference in the mail logs" ?? Does this mean that Retro did not (attempt to) connect, or is it that Retro did not connect with a SINGLE attempt (with AUTH)? The log excerpt above shows the un-AUTH v12 sequence, and only a smaller snippet of the AUTH (v11) snippet, without the preceding AUTH portion.

 

That said, I have no idea what might be wrong.

 

@bdunagan - The positioning of the checkbox, between the "requires AUTH" and the "supports SSL", especially on Mac, because it implies that the user/pass is an attribute of SSL, not of AUTH. I think the "supports SSL" should be first, and the "requires AUTH" should be second, next to the user/pass in the prefs. (or maybe after the user/pass, I suppose)

[PGalati]

I'm not clear on what's happening. "I did not see a single reference in the mail logs" ?? Does this mean that Retro did not (attempt to) connect, or is it that Retro did not connect with a SINGLE attempt (with AUTH)? The log excerpt above shows the un-AUTH v12 sequence, and only a smaller snippet of the AUTH (v11) snippet, without the preceding AUTH portion.

 

That said, I have no idea what might be wrong.

 

@bdunagan - The positioning of the checkbox, between the "requires AUTH" and the "supports SSL", especially on Mac, because it implies that the user/pass is an attribute of SSL, not of AUTH. I think the "supports SSL" should be first, and the "requires AUTH" should be second, next to the user/pass in the prefs. (or maybe after the user/pass, I suppose)

 

Retro v12 did not even attempt to make a connection to the mail server.  There is no evidence of Retro making a connection in the mail server's log file.  When I clicked "Send Test E-mail" it immediately brought up the error message, and no connection attempt exists in the mail server log.  Only after disabling authentication did it begin to work again.

 

UPDATE:  In my particalur case, it appears that it is not the authentication that causes it to fail, it is the SSL.  I have auth turned on but SSL turned off and it does work.  Having SSL on immediately creates a "No server found at that address (-597) when I click Send Test E-mail.  I did have Auth and SSL on in v11 and it worked as expected, now SSL in v12 does not like my username and password.  For the record, the outgoing mail server is listed as dotted IP and not as mail.domain.com, but again, the dotted IP and SSL on worked as expected in Retro v11.

 

I enabled debugging up to 7 in the secret preferences based on the KB article but it does not provide any more info about SSL failing when attempting to send a Test E-mail.  It simply provides the same error message listed in preferences.

 

Thanks,

Paul

[Don Lee]

SSL embeds the "name" of the server in the handshake. Using the dotted quad to access the server may well be a problem. The connection may be failing because the handshake fails - because the "name" is not "1.2.3.4". That would explain why there are no "connections" to the mail server.

 

If you *really* want to get down and dirty. Fire up tcpdump and filter on the retro server and the SSL port. I'll bet the dotted quad is doing you dirt. (and retro is not presenting the error helpfully enough)