Servidor imap.gmail.com y mutt falla.
Al enviar o consultar el correo ya no funciona normal.
Presenta esta respuesta:
"No se encontró la dirección del servidor imap.gmail.com"
Parece que gmail canceló mutt y otros clientes de correo para favorecer su monopolio?...
Servidor imap.gmail.com y mutt falla.
Al enviar o consultar el correo ya no funciona normal.
Presenta esta respuesta:
"No se encontró la dirección del servidor imap.gmail.com"
Parece que gmail canceló mutt y otros clientes de correo para favorecer su >monopolio?...
***
Saludos.
--
La Razón en su sentido absoluto no es algo que esté en el cielo esperando a >ser descubierto, sino que está mezclada con la sinrazón, con lo irrelevante >y lo cotidiano.
Parece que gmail cancel� mutt y otros clientes de correo para
favorecer su
monopolio?...
Todav�a no, pero todo llegar� ;-/
On 2022-05-14 at 19:26 +0200, Camaleón wrote:
Parece que gmail canceló mutt y otros clientes de correo para
favorecer su
monopolio?...
Todavía no, pero todo llegará ;-/
Lamento traer malas noticias, pero a finales de mes (30 de mayo) ya no permitirá iniciar sesión en los clientes con la contraseña de Google:
https://support.google.com/accounts/answer/6010255?hl=es
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)
El 2022-05-16 a las 03:18 +0200, Ángel escribió:
On 2022-05-14 at 19:26 +0200, Camaleón wrote:
Parece que gmail canceló mutt y otros clientes de correo para favorecer su
monopolio?...
Todavía no, pero todo llegará ;-/
Lamento traer malas noticias, pero a finales de mes (30 de mayo) ya no permitirá iniciar sesión en los clientes con la contraseña de Google:
https://support.google.com/accounts/answer/6010255?hl=es
Sí, cierto.
He recibido el correo de Google avisando de las «buenas nuevas» (nótese
la ironía) hace un par de meses.
Actualmente para Mutt tengo configurada una contraseña de aplicación
pero me da la sensación de que Gmail ya no va a permitir ese sistema.
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/
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.
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
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,
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.
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 :-/
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 :-/
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 27:56:57 |
| Calls: | 12,106 |
| Calls today: | 6 |
| Files: | 15,006 |
| Messages: | 6,518,222 |