Jump to content
minidomo

E-mail Notification Not Working in 8.2

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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,

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Scillonian

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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/

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 33rd 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.

Share this post


Link to post
Share on other sites

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.
  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×