©XSIBackup-Free: Free Backup Software for ©VMWare ©ESXi

Forum ©XSIBackup: ©VMWare ©ESXi Backup Software


You are not logged in.

#1 2021-06-05 01:59:01

Slyler
Member
Registered: 2021-05-10
Posts: 4

SMTP broken after upgrade to XSIBackup-Pro 1.5.0.6

Hi I purchased a license today and upgraded to 1.5.0.6.

SMTP notifications used to work with the trial version of 1.5.0.3 (i think that was the current version on May 18th)

I ran my job with --verbosity=10 and I see this error at the end of the log.


REGEX check failed for 1;smtp.domain.ca:587;backup-logs@domain.ca;1234567;abcdef123456789;none;TLS;0 with pattern ^([0-9]{1,3});([0-9a-zA-Z.-_]{1,70}):[0-9]{2,3};([0-9a-zA-Z.-_]{1,70}@[0-9a-zA-Z.-_]{1,70});.{1,70};.{4,70};[a-zA-Z]{3,4};[a-zA-Z]{3,4};[0-5]{1}$

My SMTP user id DOES NOT contain an @ sign, it is an API key of 32 characters [0-9a-f]

Thank you

Offline

#2 2021-06-05 10:28:53

admin
Administrator
Registered: 2017-04-21
Posts: 2,055

Re: SMTP broken after upgrade to XSIBackup-Pro 1.5.0.6

It is the mail-from address that is required to contain an @ sign. The username field is much more permissive, it requires 1 to 70 chars of any kind.
There is indeed an error in the REGEXP pattern which is that the hyphen or dash character needs to be at the end (or at the beginning) of the character class to be interpreted literally. We have fixed that and will be published as 1.5.0.7. We have also extended the port to allow using up to 5 digits, in case somebody wants to use some non-standard port.

We checked your server with grep regexp, which is very similar to the one we used, and it passed the test.

echo "1;smtp.domain.ca:587;backup-logs@domain.ca;1234567;abcdef123456789;none;TLS;0" | grep -E "^([0-9]{1,3});([0-9a-zA-Z._-]
{1,70}):[0-9]{2,5};([0-9a-zA-Z._-]{1,70}@.*{1,70});.{1,70};.{4,70};[a-zA-Z]{3,4};[a-zA-Z]{3,4};[0-5]{1}$"

This validation had to be added, as well as some others to prevent spurious characters in the smtpsrvs.conf file breaking execution and causing segfaults.

(*) Please note that the hyphen issue is resolved in the pattern we used. This could break behavior of the REGEXP test. Please try with 1.5.0.7 available since 2021-06-06. In fact, if you move the hyphen from the last position to the previous one in the two character classes where it is used, this very same server line will not pass the REGEXP check, thus, that is proof that the hyphen misplacement is the source of your issue too.

Offline

Board footer