Hello, Josef Jurek was the first who discovered this Google misnomer in 2014, and i'm posting this because in the ArchLinux Forum the problem came up again just recently [1], and i think it would be nice to have a searchable Subject: regarding it. The problem should usually manifest as
smtp-server: 530-5.5.1 Authentication Required. Learn more at smtp-server: 530 5.5.1 ..[2].. XXXXX - gsmtp [1] https://bbs.archlinux.org/viewtopic.php?pid=1572399 [2] https://support.google.com/accounts/answer/6010255 I haven't tried it, but on top what follows below i have also found "Sign in using App Passwords" [3], which suggests that it should be possible to use any application without "less secure" turned on if you are willing to 1. give Google a phone number, 2. use 2-Step Verification, then 3. create a application specific password (16 characters) 4. use that password instead of your real Google account password in S-nail. [3] https://support.google.com/mail/answer/185833?hl=en The rest was the original response. The forum: Alyson Tiago Ferreira: Thanks for clarifying! So there is no way to authenticate due to missing support of SASL XOAUTH 2.0 by s-nail. Myself: Hm. Ok, looking into that again it seems it really made it in August 2015, as RFC 7628: The main use cases for OAuth 1.0a and OAuth 2.0 have so far focused on an HTTP-based [RFC7230] environment only. This document integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications using the integration into the Simple Authentication and Security Layer (SASL) [RFC4422]. So then S-nail could support OAuth indirectly if support for SASL would be added. Regarding Google: i said back last year that this is incitement of the people - i am maybe a "lesser secure app", but if i want to store my password in clear text on my local box then this is my decision. S-nail offers the possibility to load locally encrypted passwords, so the password is in clear text only in main memory of the users local host, the transport over to Google is encrypted with TLS1.2. Why is that lesser secure than using a browser with enabled Javascript and Flash and - short - HTML5? Google says: There are several ways to make this request, and they vary based on the type of application you are building. For example, a JavaScript application might request an access token using a browser redirect to Google, while an application installed on a device that has no browser uses web service requests. Some requests require an authentication step where the user logs in with their Google account. After logging in, the user is asked whether they are willing to grant the permissions that your application is requesting. This process is called user consent. If the user grants the permission, the Google Authorization Server sends your application an access token (or an authorization code that your application can use to obtain an access token). If the user does not grant the permission, the server returns an error. So this is the same mechanism that the decade-old GSSAPI uses -- the user requests a ticket, which is then available locally and grants permissions to - in this case S-nail. But ok, i'm fine with yet another authentication mechanism (let aside the trouble of the expert group which designed OAuth2.0, that is a different story). I'm not fine with being declared "lesser secure" because i want to store my password locally. That is my own choice, the freedom of being an unperfected idiot. Anyway, hacking in SASL support is one of the lesser good ideas at the moment. But since i want to sit back and let S-nail rest in 2016 (to come back with a clear mind, what i hope) i'm thinking about adding SOCKS proxy support for v14.9, which then would allow usage of and over TOR. So this might turn S-nail into a more secure app, then. So then i'm having a short look into RFC 7628 and i see +--------+ +---------------+ | | |--(A)-- Authorization Request --->| Resource | | | | | Owner | |Plain | |<-(B)------ Access Grant ---------| | |OAuth | | +---------------+ |2.0 | | | | | Client Credentials & +---------------+ | | |--(C)------ Access Grant -------->| Authorization | | | Client | | Server | | | |<-(D)------ Access Token ---------| | | | | (w/ Optional Refresh Token) +---------------+ | | | ----+ So this entire step is what kinit(1) is with Kerberos / GSSAPI unless i'm mistaken. That one is copyright 1985-2015, MIT. Then you have a local ticket, and | | ----+ | | +---------------+ | | | | | |OAuth | |--(E)------ Access Token -------->| Resource | |over | | | Server | |SASL | |<-(F)---- Protected Resource -----| | | | | | | | +--------+ +---------------+ | ----+ Figure 1: OAuth 2.0 Protocol Flow an application can transparently use that -- so-called "bearer token" in OAuth 2.0 -- repeatedly. The problem clearly is that in one-shot usage mode S-nail as a console application should not and will never request the ticket, a.k.a. bearer token whenever it is started up. So then, if that bearer token is laying around in a way that it can easily be sticked into the usual authentication mechanism maybe i can add support at a later time, or implement SASL like so. The latter will happen anyway once the I/O layer has been rewritten. Ciao, --steffen ------------------------------------------------------------------------------ _______________________________________________ S-nail-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/s-nail-users
