There are about 60 variables that are available for dynamically constructing these fields, covering the OS environment, app's properties (version, license, etc), backup config and the state of the last backup run. In the above screenshot, clicking on "Show variables" will expand the window with a full list of variables.

Incidentally, the same variables are now also made available to the pre/post-backup commands.

Mail server configuration

When it comes to actually sending the alert, the app can do it in two ways.

Direct delivery is the simplest to configure, but it will likely not work if you are to try it from a network address of a residential ISP. The reason for this is that it's a common way of distributing spam, so larger email providers refuse to talk to anyone from residential IP ranges. But do try it first. If it works - great!

Relayed delivery is when you are asking "your" server to take on delivering your email to whatever it needs to go. The app comes with a list of few dozen large providers (Gmail, Hotmail, Yahoo, etc), so it can help you configuring the host/port/security settings for them. But if in doubts, click on the "?" next to "How to send" and you'll get a quick guide on settings things up.

1. If an email alert cannot be sent (due to machine being offline, for example), it is *not* queued, but discarded. If you need reliable delivery for these scenarios, you will need to do it through a post-backup command with a custom script.

2. In direct delivery mode, the app connects to port 25 and it expects STARTTLS support on server's end. It's possible to adjust both settings. You guessed it - "via an .ini edit, ask me how".

All in all, this worked out to be a remarkably deep rabbit hole of a feature. Most likely it will require a bit of TLC and tweaking, but it should also be pretty functional right out of the box.

I just tried the mail notifications, however I can't get it to work with my GMX account (german ISP).
"Send to target mail server" doesn't work, but with my configuration for the server it even crashes the hole program.

Hostname: mail.gmx.net
Port: 465
Security: SMTP + STARTTLS

The test mail log stops at "Exchanging pleasantries" and when I cancel it, Bvckup 2 chrashes completly.
I tried the other security method, but then I get "Error talking to the mail server". Also I have a second port I can use (587), but then I get "Error securing the connection" for both security methods.

Thunderbird works just fine with my ISP. I'll try my Google account now and report back.

Alright, I got the crash, will release the patch in a second, but for this -

Port 587 -> Error securing the connection

Port 465 SMTP over TLS -> Error talking to the mail server

I really need to see your %LocalAppData%\Bvckup2\bvckup2-smtp.log. The log is re-created with every "Send test email", so can you just run first scenario and either email me the .log or post it here (the password is not logged, but you may want to edit out the account name).

A patch to resolve the crash issue is out. Please pull it down and install via Help / Check for updates.

The root of the issue was with how the SMTP connection was shutdown. The app tries to be polite and say QUIT when it takes the connection down, but then it hit an error trying to send this out, so in response it would start shutting down the connection again (even though it was already halfway through just that) and it looped, leading to the stack overflow. Rookie mistake. Not sure who would write such a nonsense.

... and "Revision 3" is out. One of the changes is that the app now uses Unicode (UTF16) version of DNS Resolver API, which is apparently better supported and documented than the previously used UTF8 version of it.

@baconmessy - on port 465 you must use SMTPS as the security option as this is effectively a TLS port. So the app first needs to establish TLS session and then start talking SMTP over it. If you make it talk SMTP first, it obviously won't work.

This means that the mail server wants the client to authenticate itself with a certificate. This is something that is simply not supported in current code, because frankly I assumed this is not going to be widely used in practice... How do you have your other apps configured in this regard?

Is there a limit to password length or special chars?

No.

I found a super secret variable in the engine INI that was set to noreply@bvckup2.com and changed it :)

My only guess is that it doesn't like "localhost" in EHLO. Or perhaps that it expects AUTH to be the first command after STARTTLS.

"localhost" can be changed by editing %LocalAppData%\Bvckup2\engine\bvckup2-engine.ini - "email.smtp.ehlo_host" line. Just make sure to exit the app before editing the .ini.

Port 465

The server gracefully closes the connection after completing the TLS handshake. I have no idea why it would do that :-/ ... and I can't test it from here, because apparently my IP is on their "blacklist" so it refuses to even talk to me.

If the destination drive is not there, there is a failure code. I have a backup job where the backup job's destination is a shared folder on a USB flash drive connected to my router (samba share).
Yesterday since I was away from home, I ran the job manually on my laptop and I got an email, content of which had status and failure condition:

Hmm, program would need to differentiate between scenario of the drive has not yet been plugged in or not yet available on the network vs the drive disappeared (unplugged or not on network).

I guess query for existence of device as the interval schedule is met but would need to be mindful if destination is a network device since you may not want frequent checks to add to the network traffic...

I am getting notifications from my 3 machines each night because they encountered errors. Somewhere between 10 and 200 files per machine couldn't be accessed for whatever reason.

This is normal but I am now getting 3 emails a night telling me this when there is effectively nothing wrong. When talk first came up about this I thought I read there would be 3 levels of tracking, 1. Send on every backup 2. Send on error or 3. Send on failure, such as the destination is missing.

Ideally I want just number 3. Have I got my settings wrong or does scenario 3 not exist?

Right, good point. I was basically deciding if to differentiate between file- and backup-level errors and ultimately folded both into a single option. I will add an option for sending alerts on critical failures only, will be out in the next R71 revision (probably mid- next week).

Changing the From address to something other than noreply@bvckup2.com has no effect. My SMTP server requires the From address to be one if it's authorized domains. The email notification feature won't work without this fixed.

The email notification feature is very good to have, but I was wondering if it is possible to post the same information as a text file to the user's folder of choice (Desktop for example), or a similar method that doesn't require the computer to be online?

I was just converting from a post-job email script to the integrated email feature and found this because I was sending to multiple recipients. I could probably set up a distribution list in Exchange if I had to, but it would be helpful to have the ability natively.

As a webmaster, I typically would set up one address to be used from within the app, and then froward that as necessary. That said, many people may not have the ability or knowledge to do that, so allowing a simple comma separated list of email addresses is a common and sensible option often found in apps. I would recommend limiting the number though, for instance, truncating after 5 or 10 at the most.

I have an issue with the email notification from one of my servers. Ive set it up and the test email is being received when its sent but im not receiving any mail on completion of the backup. All my other machines are functioning correctly and sending the mail, ive checked my mail server and they arnt going to spam. Any Ideas?

by the way your email addy isnt working, i get the following message:

----- The following addresses had permanent fatal errors ----- <support@pipemetrics.com>

For one, it will complicate matters quite a bit for the case when the mail server is looked up automatically - the app will potentially need to talk to multiple mail servers for each alert and while it's not rocket science, it's still something that I think shouldn't be a part of a simple backup app.

The option would be to allow multiple recipients only when sending over authenticated SMTP, but then we now have two email modes that are configured similarly but act differently. Again, this is not something that I'd like to have in the app.

So I mean ... I can add an .ini file override to enable multiple recipients for the authenticated mode, but that's as far as I think this should go. Would this work?

Yes, that would probably work ok for me, but it's truly not an imperative feature if it's a hassle for you. I can certainly work around it.

I'd like to just clarify my own point of view, because I forgot you even included the ability to send directly to target server in bvckup2. I will never use the option to send directly to target mail servers and I generally don't think it's a good idea. I always offload to smtp smart hosts and it is the duty of the smart host to do all of the MX lookups and relaying/delivering. I completely agree that the backup app should not have to do all of that work and in my case, bvckup will only ever talk to the 1 smtp server specified in the app.
Thanks.

I vote yes for multiple recipients for authenticated outgoing emails. I never assumed it wouldn't. Copying my client for their own bvckup logs as well as me seems appropriate. If you have to make an .ini exception to do so, please do.

Google is pushing everyone to never type their google passwords into anything that is not explicitly owned by Google. As such, they label 3rd party mail clients that speak standard authenticated SMTP as "Less safe software" and disable their access to Gmail account by default:

That said, I disagree that it's a basic need. If a setup involves email alerts, then it would normally be possible to send alerts to a mail distribution list that clones and delivers the alert as needed.