Today, when connecting with a secure socket with TLS to the Gmail SMTP server I get this response:
534-5.7.14 <https://accounts.google.com/ContinueSignIn?sarp=1&scc=1&plt=xxxxxxxxxxxxxxxxxxx
534-5.7.14 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
534-5.7.14 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
534-5.7.14 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
534-5.7.14 xxxxxxxxxxxxxxxxxxxxx> Please log in via your web browser and
534-5.7.14 then try again.
534-5.7.14 Learn more at
534 5.7.14 https://support.google.com/mail/answer/78754 az6sm29224181wib.12 - gsmtp
I have replaced my encrypted account data. IS there any solution to that?
Yesterday I experienced the same problem (and got the same link) when getting mail.
So I followed the <534 5.7.14> link and accordingly disabled the strong security (or something called like that), and things went back to normal.
But I ask myself: what will the users of my apps do? I fear they’ll think that the app got corrupted.
Yes, I went to https://www.google.com/settings/security/lesssecureapps and I have activated access for low security apps :-/
It is a page with this text ‘Access for less secure apps’ and two choices, ‘Turn off’ and ‘Turn on’. Above it says: “Some apps and devices use less secure sign-in technology, which makes your account more vulnerable. You can turn off access for these apps, which we recommend, or turn on access if you want to use them despite the risks.” More info here: https://support.google.com/accounts/answer/6010255?hl=en
After doing that it works indeed but what is all that? I read somewhere Google was switching from SHA1 to SHA-2. In Wikipedia it says: ‘The Google Chrome team announced a plan to make their web browser gradually stop honoring SHA-1-dependent TLS certificates over a period from late 2014 and early 2015.’ But it is Chrome… Any relation with SMTP and POP services?
I’d add that of my three gmail accounts, only one got blocked. Apart from address and password, the three accounts are the same. Only difference is that the account affected had been created one year and a half ago, while the other two were created years back.
So I ask myself, why does my Xojo created app, when addressing my three accounts, get the warning for one of them only?
[quote]@Thom: Shouldn’t you be able to generate an app-specific password and leave the high security mode on?
[/quote]
I dont have any knowledge about app-specific password; in my first attempt to solve the above problem I changed the password, but the warning kept coming up. Google support (see the above link) speaks of apps using low security standards like Thunderbird etc. So, as I already said: if my Xojo-created-app is one of them, why only one account gets blocked?
If an account has two factor authentication enabled, I’m pretty sure an app specific password will need to be generated. Another requirement could be TLSv1.2.
You should compare what is different about the account that gets blocked, but I’d put money on the 2FA issue.
I tried all SSL/TLS options but the error message always pops up.
@Thom If an account has two factor authentication enabled,[quote][/quote]
SecureSocket has one factor auth only. But I see that Xoio.securesocker has got two. Never tried it.
All my test have been done with TLSv1, SSLSocket.ConnectionType=3
I haven’t tried with TLSv11, SSLSocket.ConnectionType=4 nor with TLSv12, SSLSocket.ConnectionType=5
I really don’t know which socket you refer to. HTTPSocket includes a realm parameter, but this is not the same thing.
Two factor authentication is an account-level setting with Google. IMAP, POP3, and SMTP - the whole protocols - don’t support 2FA. This is mostly because everybody supports it differently. There isn’t a standard, and I’d be surprised if there ever becomes one.
So if you have 2FA enabled and want to use one of these protocols, you use Google’s control panel to generate what they call is an app-specific password. It’s just a random password that can be used with “old fashioned” security systems - like these protocols - that is not your account password and can be revoked without resetting your account password.
However, since you didn’t say something like “oh that’s right, I forgot I turned that on” I bet you don’t have 2FA enabled. So it’s probably something else.
[quote]I really don’t know which socket you refer to. HTTPSocket includes a realm parameter, but this is not the same thing.
[/quote]
If this was addressed to me, then:
looking for “2FA”, I noticed that xojo.net.SSLSettings added a new boolean property (validateCertificates), something not present in classic SSLsocket; and I thought that this new property was the 2FA you spoke about.
Yes, sorry, that was to you. Those SSL settings will have no impact on 2FA. Authentication is handled at the protocol level, SSL is transport level. ValidateCertificates is something you use to verify that you are connecting to the server you expect with no “man in the middle” attack.
I did some Google searching, and I’m still coming to the conclusion that 2FA is enabled. With it disabled, I can’t see any reason for the rejection that you’re seeing.
If it really isn’t 2FA, then it is probably issue #2 or #3 in the list in Google’s error response. It does say “please log in with your browser first” in the error.
Apart from App password (I skipped it), I went through the various steps, but the only way to get gmail work has been to disable 2FA in Account settings.
If you have 2FA enabled (or had) then app password is absolutely the issue. You cannot use your account password with IMAP, POP3, or SMTP when 2FA is enabled.
Yes, that now is clear to me. But my original concern was about the users of my app, who all at once, as it happened to me, not being able to access their gmail accounts, may think that the fault is with app.
Thank you for your suggestions. Greatly appreciated.
I just had an email from a customer who was having trouble with Gmail not dealing with email sent from my Xojo app. The solution was an option on his account to reduce the security level so “older” apps could send email though his account. I’m not sure where we go from here to make our apps work correctly with Gmail.
Google wants logins done with OAuth now, so “traditional” logins are now blocked by default. You can (as you’ve done) allow “less secure” apps to sign in.
However, the “better” way to handle this is to enable two factor authentication then generate an app specific password.
Google’s goal here is to prevent you from giving your Gmail password out to anybody who isn’t Google. Although you know your app is not harvesting the user’s password, nobody else can be certain. So OAuth or 2FA allow access to the account without the user having to give up their real password.