El 19 de mayo de 2022 20:38:26 CEST, "Camaleón" <noela...@gmail.com> escribió: >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, >
Pues imagina la que se va a montar con los sistemas de los vehículos que usan, por ejemplo, Android Auto, para conectar el teléfono con el coche y poder usar el navegador, las llamadas,... Miedo me está dando... Sistemas inservibles por los que se paga una pasta cuando compras el coche... Saludos
