I've experienced this with both the free and pro versions of XSIBackup. When using Gmail for the SMTP server, 9 times out of 10 the SMTP process is halted on:
220 smtp.gmail.com ESMTP y85-v6sm12493758oie.25 - gsmtp 451 4.5.0 SMTP protocol violation, see RFC 2821 y85-v6sm12493758oie.25 - gsmtp
I thought perhaps this was due to my using 2 factor for personal account (even though I was using an App password), so I created a new account without 2Fa and enabled access for less-secure applications. Issue persists.
I've tried this both using the --use-smtp command and listing out the command. Both are listed below:
--smtp-srv=smtp.gmail.com \ --smtp-port=465 \ --smtp-auth=yes \ --smtp-sec=TLS \ --smtp-usr=<gmailaccount>@gmail.com \ --smtp-pwd=<gmailpassword> \ --mail-from=<gmailaccount>@gmail.com \ --mail-to=<email@example.com> \ --smtp-delay=1 \
I saw in the documentation that the delay was only necessary for SMTP servers that didn't support proper pipelining, but I've only gotten Gmail to send an email successfully with the 1 second delay.
Is there a better solution that Gmail that I could use? If I could run a local SMTP server I'd be fine sending the data without encryption on my local network, but I'm not sure what software I could use that would be easiest and have the smallest footprint.
Please, read the documentation: https://33hops.com/xsibackup-smtp-client.html
The XSIBackup SMTP client manages GMail accounts in a different module and it adds some delay automatically.
We have tested it with GMail through the years and it works O.K., many users report it to work O.K. with GMail and have no problems in general. We have not had this kind of problems reported for a long time.
Do you have some special character in the password?
It looks like some error in the SMTP protocol conversation. As everything else is hardcoded, the issue must be caused by some of the variable strings. As most of the fields must follow a pre stablished format, like the e-mail addresses, most of the times a password with some weird unescaped characters causes this.
I double checked the documentation, but I'm not seeing anything that I haven't addressed. Access for less secure applications has been enabled. I've tried removing the smtp-delay flag to allow the automatic delay to be used, but it still fails with the same error.
The password consists only of upper/lower case letters and numbers. The username is all lowercase letters. The thing I don't understand is that I've gotten an email to send successfully, but I can't get it to happen again.
I've come up with a solution, though it's not ideal. I'm using hMail, a Windows SMTP/POP3/IMAP server, as a SMTP Relay. I send to the local server on my network, it relays to Gmail, and I receive it in my inbox. It works with either the 2Factor account or the non 2FA that has less secure app access enabled. This will work in the meantime.
Last edited by toxeia (2018-07-24 19:11:58)
This all seems like the GMail server you connect to does not support PIPELINING. The time you got it to work you probably connected to a different server. Your solution is O.K. if it works for you, but wouldn not have it been easier to just use a different account, yahoo.com, hotmail.com, etc... they support PIPELINING and do work as well.
I think because the documentation only mentioned Microsoft Office and Gmail I was focusing on those. I actually started experiencing issues with that relay as well, so I went with a free account at Mailgun.
A note on that though - they provide sandboxes for free, but it provides a very long subdomain consisting of a hex identifier. The user/from line ends up being 62 characters which seems to exceed what the GUI will accept. Using a text editor to edit the smtpsrvs file or inserting the smtp info into the job file directly bypasses the limitation. It also appears that the smtp-pwd entry from the gui is limited to 32 characters, and the default password provided was 50 characters. It might also be that the 33rd character is a '-' if the gui refuses special caracters.