E-mail Notification Not Working in 8.2

[David W Lee]

While we test new fixes on Mac, the latest Windows build 8.2.0.180 (with new fixes since 8.2.0.177) is available through Support so that we can closely track if it fixes specific email notification issues.

 

In general for Retrospect:

• For Gmail: On Windows, specifies port 465, i.e. smtp.gmail.com:465. On Mac, leaves out the port number and let Retrospect default to port 587.
• For Exchange: Configure Exchange to disable TLS and enable Basic Authentication.
• If port isn't specified and SMTP authentication is enabled in Retrospect's E-mail preferences, Retrospect defaults to port 587.
• When unable to connect to the email server, Retrospect logs an error and then automatically fail over to a different method to try to connect. The interim error may appear in the operations log even when email is successfully sent after automatically failing over to a second connection method. For future release (v8.3 for Windows and v10.3 for Mac), we will log interim errors only if both connection methods fail.

[David W Lee]

Switching to gmail as recommended has solved getting regular emails - but I now have another email issue. I have 2 email addresses defined to receive emails. One of them seems to receive all of the emails from the backup run. The other (second in the list) does not - it receives the startup message and then a resulting message that indicates that a -530 error occurred during the run, but none of the other messages.

 

I am using ; (a semicolon) as the separator between email addresses. I have also tried the semicolon with a blank and it seems to work the same. I do not have a separator character at the end of the email addresses - do I need that?

 

Separator isn't needed after the last email address. A few quick questions:

• Are you using 8.2.0.177?
• Are both email addresses (one receiving all emails and the other only receiving some) both on gmail?

• Are any emails held up by spam filters?

The Date field used by Retrospect is 1 hour ahead when daylight saving time is enabled. Due to that and along with another issue we are investigating, some email services are treating Retrospect generated emails as spam. We testing fix for the 1-hour ahead problem and working on fixing the other issue for v8.3 (Win) and v10.3 (Mac).

[David W Lee]

it does, if you use the "Send Test E-Mail" button. But if you actually let an automatic script run, the notification still fails.

 

In 8.2.0.180 (with new fixes since 8.2.0.177), we have reduced differences between sending test email and engine-generated email. 8.2.0.180 is available through Support so that we can closely track if it fixes specific email issues. For Mac, we are testing new fixes and will provide through Support a new 10.2.0.x build ASAP.

[JamesOakley]

The Date field used by Retrospect is 1 hour ahead when daylight saving time is enabled. Due to that and along with another issue we are investigating, some email services are treating Retrospect generated emails as spam. We testing fix for the 1-hour ahead problem and working on fixing the other issue for v8.3 (Win) and v10.3 (Mac).

 

David

 

If you look at the server logs I pasted in post #17 above, you'll see that the mail was never being sent through the outbound server - it wasn't a case of the inbound server rejecting mail that was validly sent.

 

So:

 

1. What's the other issue you're investigating - I'd like to know if that fits my scenario better

2. How do I get a copy of build 180?

[David W Lee]

1. What's the other issue you're investigating - I'd like to know if that fits my scenario better

2. How do I get a copy of build 180?

 

Regarding #1, only on Mac we are seeing one of the mail services treating the Date string used by Retrospect as invalid, while other mail services accept it. The consequence is that the email gets sent, but it may be treated as spam or the sent date is shown with the year 1969.

We aren't seeing this issue on Windows.

 

To get 8.2.0.180 for Windows, please email Support using http://retrospect.com/en/support/contact, specifying you want 8.2.0.180 for email fixes. This helps us track issues.

[David W Lee]

the latest Windows build 8.2.0.180 (with new fixes since 8.2.0.177) is available through Support so that we can closely track if it fixes specific email notification issues

 

The latest Mac build 10.2.0.207 is also available through Support.

[administratorprogressivedyn.com]

Separator isn't needed after the last email address. A few quick questions:

• Are you using 8.2.0.177?
• Are both email addresses (one receiving all emails and the other only receiving some) both on gmail?

• Are any emails held up by spam filters?

The Date field used by Retrospect is 1 hour ahead when daylight saving time is enabled. Due to that and along with another issue we are investigating, some email services are treating Retrospect generated emails as spam. We testing fix for the 1-hour ahead problem and working on fixing the other issue for v8.3 (Win) and v10.3 (Mac).

Hi David,

In answer to your questions:

1. Yes - I am using 8.2.0.177

2. The first is a private/pop account, the second is a gmail account, and the third is an AOL account.

3. Yes - I found them in my AOL spam box.

I look forward to getting 8.3 unless you have other suggestions.

Thanks.

[David W Lee]

2. The first is a private/pop account, the second is a gmail account, and the third is an AOL account.

3. Yes - I found them in my AOL spam box.

 

These fixes are in the upcoming 8.3 (and 10.3 for Mac):

• When unable to connect to the email server, 8.2/10.2 logs an error and then automatically fail over to a different method to try to connect. The interim error may appear in the operations log even when email is successfully sent after automatically failing over to a second connection method. 8.3/10.3 will log errors only if both connection methods fail.
• The Date field used by 8.2/10.2 is 1 hour ahead when daylight saving time is enabled. Due to that and along with another issue, some email services are treating Retrospect generated emails as spam. Fixes for both of these date issues are being tested.

[redleader]

I've got this in v10.2.0(201) for Mac OSX Server 10.8.latest.

 

I can send a Test email fine.

Script emails notifications do not send: '  E-mail notification failed: error -597 ( mail server not found)'

 

This error is nonsense, as all other programs on the same Mac can send emails using the same email account credentials with no problem : Mail, Outlook, CCCCloner ...

 

Is there a solution please?

 

Thx,

[JamesOakley]

First feedback on using 8.2.0.180:

 

Using a mail server that is running exim (cPanel): With no port number specified, e-mails are sent successfully both with the "test" button and after backup execution. Specifying ":465" on the end of the FQDN of the mail server causes nothing to happen with "test e-mail" or after automatic execution - it fails silently. Using ":587" causes it to work correctly.

 

So outgoing e-mails are now working for me - but not such that I can use SSL to connect to the mail server.

[redleader]

http://forums.retrospect.com/index.php?/topic/150436-error-597-mail-server-not-found-but-pref-e-mail-test-successful/

 

Seems the product is defect and it is NOT our fault or settings :-(

[JamesOakley]

First feedback on using 8.2.0.180:

 

Using a mail server that is running exim (cPanel): With no port number specified, e-mails are sent successfully both with the "test" button and after backup execution. Specifying ":465" on the end of the FQDN of the mail server causes nothing to happen with "test e-mail" or after automatic execution - it fails silently. Using ":587" causes it to work correctly.

 

So outgoing e-mails are now working for me - but not such that I can use SSL to connect to the mail server.

 

To add to this feedback: I've noticed that while e-mails are being sent (when I don't use a port number), I always get "E-mail notification failed: error -511 ( unknown service message)" in the operations log for each job.

[Scillonian]

To add to this feedback: I've noticed that while e-mails are being sent (when I don't use a port number), I always get "E-mail notification failed: error -511 ( unknown service message)" in the operations log for each job.

The probable possible reason for this is detailed in post #33 (Retrospect uses two methods to send and if the first fails an error will be logged even if the second succeeds).

Edited August 30, 2013 by Scillonian

[Mayoff]

The probable reason for this is detailed in post #33 (Retrospect uses two methods to send and if the first fails an error will be logged even if the second succeeds).

 

You are correct. 

[redleader]

Nope, this is one out of many installations on Mac Servers: Retrospect versions 6,8,9.

All work fine with exactly the same email settings.

 

It is only my one installation with Retrospect 10, that has this issue.
http://forums.retrospect.com/index.php?/topic/150436-error-597-mail-server-not-found-but-pref-e-mail-test-successful/

[redleader]

P.S. can I have a link to where 'this is detailed in post #33'

Not sure that will help as no emails are coming through expect for the TEST email.

And the TEST email is using the same emails settings, QED.

[redleader]

You are correct. 

..so the actual answer is please ... as it happen on v10 too (mac)... for us not so bright ones :-)

[Scillonian]

P.S. can I have a link to where 'this is detailed in post #33'

Not sure that will help as no emails are coming through expect for the TEST email.

And the TEST email is using the same emails settings, QED.

 

This is referring to the 33^rd post of this thread where it is noted that Retrospect uses two methods to send e-mail and where if the first method fails but the second is successful a failure is still logged.

 

Here is the relevant part of post #33:

These fixes are in the upcoming 8.3 (and 10.3 for Mac):

• When unable to connect to the email server, 8.2/10.2 logs an error and then automatically fail over to a different method to try to connect. The interim error may appear in the operations log even when email is successfully sent after automatically failing over to a second connection method. 8.3/10.3 will log errors only if both connection methods fail.
• The Date field used by 8.2/10.2 is 1 hour ahead when daylight saving time is enabled. Due to that and along with another issue, some email services are treating Retrospect generated emails as spam. Fixes for both of these date issues are being tested.

 

 

..so the actual answer is please ... as it happen on v10 too (mac)... for us not so bright ones :-)

 

Are you using the publicly released version (8.2.0.177) or the later test version (8.2.0.180) available from support? The 8.2.0.177 release works with my e-mail provider so I have not had to use the 8.2.0.180 release.

[redleader]

Thank you Scillonian,

 

Test email sends, no other emails Send :-(

We are not using the later test version (8.2.0.180) available from support

 

Here is the setup details:

https://dl.dropboxusercontent.com/u/5485939/retrospect/2013-08-07-retrospect-leeds-ha.png

[Scillonian]

Thank you Scillonian,

 

Test email sends, no other emails Send :-(

We are not using the later test version (8.2.0.180) available from support

 

Here is the setup details:

https://dl.dropboxusercontent.com/u/5485939/retrospect/2013-08-07-retrospect-leeds-ha.png

From your screenshots you appear to be using the Mac version of Retrospect; the version I am referring to is the Windows version. A test version for 10.2 for Mac is apparently being development to address the continuing e-mail problems for some users and will be made available through Retrospect support. Try contacting Retrospect Support to see if it is available yet.

[redleader]

Cheers Scillonian,

 

I've sent a contact to Retro Support :-) √√

[mrogerson]

Hi Folks,

 

Can confirm that the problem was solved for us after updating to  8.5.0 (136), both with or without authentication

[JamesOakley]

See post #35 in this thread.

 

I've now upgraded to 8.5.

 

I still cannot specify port 465, which means that all outbound mail has to authenticate without SSL, sending SMTP passwords in plain text. (If I put ":465" after the mail server name, the "test mail" feature does not send a message).

 

I appreciate that not everyone may share this view, but using SSL to STMP is (IMO) essential for securing e-mail services from those abusers.

 

This aspect of e-mail notifications was reported as not working long before 8.5 was released. It's a shame that 8.5 was released without the fixing the ability to specify a server port to connect to. This always used to work pre 8.1.

[Scillonian]

See post #35 in this thread.

 

I've now upgraded to 8.5.

 

I still cannot specify port 465, which means that all outbound mail has to authenticate without SSL, sending SMTP passwords in plain text. (If I put ":465" after the mail server name, the "test mail" feature does not send a message).

 

Are you seeing any Schannel errors in the Windows Event Logs when Retrospect is trying to send any emails using port 465? When email wasn't working for me in 8.1 any email attempt generated an Schannel error.

 

Also, is the email server you are trying to use a private one (e.g. your conpany's) or a public one (e.g. GMail, ISP)?

 

I appreciate that not everyone may share this view, but using SSL to STMP is (IMO) essential for securing e-mail services from those abusers.

Remember that all this secures is the exchange of credentials and message between you and your SMTP mail server. Once the message has reached the server it is back to plain text again for transit over the internet. (The only exception I know of is GMail where the message will remain secure/encrypted when the message is between two GMail addresses.)

[JamesOakley]

Are you seeing any Schannel errors in the Windows Event Logs when Retrospect is trying to send any emails using port 465? When email wasn't working for me in 8.1 any email attempt generated an Schannel error.

 

No.

 

I do get Schannel errors when Retrospect sends over the default, unsecured, port. I presume this is for the reasons discussed earlier in this thread - Retrospect tries two different ways to send the e-mail, but only logs a failure if both fail. It seems that Schannel (whatever that is) is logging an error on the first attempt even though Retrospect does not.

 

 Also, is the email server you are trying to use a private one (e.g. your conpany's) or a public one (e.g. GMail, ISP)?

 

I've tried with both.

 

If I try with my own private server, the "send test e-mail" button fails silently. Nothing appears to happen when I click the button and port 465 is used. Actually, something happens. The exim_mainlog file on the server shows a connection from my computer, and then it shows that connection instantly (<1s) terminated by QUIT. No authentication or attempts to send mail occur.

 

If I try with Mandrill, who advertise port 465 as the correct port for SSL, it attempts to send a test message for about 10 seconds. It then fails with "E-mail notification failed: error -519 (network comunication failed)." Still no Schannel error log though.

 

I know that both these servers are capable of sending mail on port 465, as I use both in my Outlook setup without any problem.

 

Remember that all this secures is the exchange of credentials and message between you and your SMTP mail server. Once the message has reached the server it is back to plain text again for transit over the internet. (The only exception I know of is GMail where the message will remain secure/encrypted when the message is between two GMail addresses.)

 

I know. But that's enough to prevent sniffing of plaintext passwords.

 

Regardless of whether I should want this to work, SSL on port 465 is an e-mail standard so it should work, and it used to work on 8.0 and earlier. This is still a regression bug.