On Thu, 19 May 2022 20:38:26 +0200 Camaleón <[email protected]> wrote:
> El 2022-05-18 a las 09:20 +0200, alfon escribió: > > > > 2. Configurar OAuth2 en Mutt y Fetchmail, si lo permiten, o buscar > > > alguna aplicación alternativa que sí tenga soporte. > > > > > > Seguramente, y para curarme en salud, haga las dos cosas (1 y 2) :-) > > > > > > > Las opciones son usar OAuth (no tengo claro que mutt lo soporte) o una > > > > contraseña de aplicación (pero Google no te las ofrece a menos que > > > > tengas activado el 2FA) > > > > > > Para Mutt he visto esto (no lo he probado): > > > > > > mutt integration with Gmail using OAuth > > > https://luxing.im/mutt-integration-with-gmail-using-oauth/ > > > > Yo tengo configurado mutt con Oauth2 y funciona perfectamente. Existe > > un script proporcionado por Google que automatiza en parte el proceso. > > > > Si tenéis problemas concretos configurándolo lo podemos resolver en > > este u otro hilo de la lista. > > Me parece especialmente interesante este tema, y creo que nos puede ser > de utilidad a todos, por un motivo u otro. > > He estado leyendo sobre OAuth en la página de la Wikipedia para empezar > a entender de qué va :-) > > Si no lo he entendido mal, se trata de un sistema/mecanismo/protocolo > por el que un servicio/servidor permite a un cliente generar un token > para permitir el acceso de terceros (o a él mismo) a sus datos/ > servicidos/credenciales. > > Es decir, en lugar de decirle a Gmail, «soy fulanito y este es mi > usuario y contraseña», habría que primero generar un token para > permitir el acceso a fulanito, y dado que ese token no contiene los > datos en sí de las credenciales, resulta más seguro contra ataques. > > Hum... sería algo así como decirle al cortafuegos que en vez de > permitir todo y después ir cerrando puertos, que primero cierre todo y > después ir permitiendo cosas concretas. > > Entiendo las ventajas que supone para la parte servidora usar ese > sistema, pero no para el cliente, y menos aún cuando se trata de correo > electrónico. El correo convencional (no el webmail) no es una API, no > es un servicio, y hacia eso lo quieren arrastrar (desnaturalizar la > esencia del coreo electrónico) pero preferiría que el servidor de correo > me pidiera en certificado digital para autentificarme que usar ese > sistema farragoso de OAuth; auguro problemas de todo tipo y máxima > incomodidad para los clientes. > > Ahora bien, lo que ya me pierde es la mezcla de OAuth con la > doble, triple o multi autentificación (2FA). Estos sistemas de doble > seguridad los entendería razonables para validar ciertas operaciones > críticas o autentificaciones ante servicios delicados, pero no para > iniciar sesión en un buzón de correo convencional (POP/IMAP, no > webmail), espero que no sean tan vacaburros de forzar también su uso o > derivarnos al webmail :-/ > > Saludos, > > -- > Camaleón > Pero seguro que tod@s intuimos qué es y hacia dónde vamos ;-) gracias. -- hubble <[email protected]>
