Servidor imap.gmail.com y mutt falla.

Aristobulo Pinzon

unread,

May 14, 2022, 12:30:03 PM5/14/22

to

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.

Camaleón

unread,

May 14, 2022, 1:30:03 PM5/14/22

to

El 2022-05-14 a las 11:10 -0500, Aristobulo Pinzon escribió:

> Servidor imap.gmail.com y mutt falla.

Por aquí funciona correctamente.

> Al enviar o consultar el correo ya no funciona normal.
> Presenta esta respuesta:
> "No se encontró la dirección del servidor imap.gmail.com"

Ese error parece provenir del servidor de nombres.
Cuando tengas problemas con Mutt, ejecútalo en modo depuración para ver
más información (mutt -d 2) en ~/.muttdebug0.

Pero vaya, primero revisa que puedes resolver bien los dominios:

host imap.gmail.com

> Parece que gmail canceló mutt y otros clientes de correo para favorecer su
> monopolio?...

Todavía no, pero todo llegará ;-/

Saludos,

--
Camaleón

Zeque

unread,

May 14, 2022, 1:40:03 PM5/14/22

to

Hola! Ese error en particular parece que el dns no está resolviendo la dirección.
Fuera de eso cuando comience a funcionar recuerdo que para conectarse por imap/pop había que activar una opción de clientes no seguros o algo así.
Saludos!

Zeque

Ángel

unread,

May 15, 2022, 9:20:04 PM5/15/22

to

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)

Saludos

Camaleón

unread,

May 16, 2022, 2:50:03 AM5/16/22

to

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.

Las opciones que he barahado son:

1. Abrir una cuenta en GMX (o similar) y reenviar los correo que
lleguen a Gmail a esa cuenta (que dialoguen con toda la seguridad que
quieran los servidores de correo entre ellos mismos).

Esta opción no me termina de convencer por los bounces y demás, sé que
a la larga dará problemas :-(

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/

Para Thunderbird:

Using OAuth2 with Thunderbird and Gmail
https://www.supertechcrew.com/thunderbird-oauth2-gmail/

Y para mi querido Fetchmail... pues me parece que tocará instalar la
versión 7, aplicar el parche que hay para la versión 6... o buscar
alguna alternativa.

P.S. Si a partir del día 30 no me leéis por la lista es que mis
optimistas planes han salido mal :-P

Saludos,

--
Camaleón

Camaleón

unread,

May 16, 2022, 1:00:03 PM5/16/22

to

El 2022-05-16 a las 08:43 +0200, Camaleón escribió:

> 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.

(...)

Hum... no me queda claro, pero me parece que está opción (usar una
contraseña de aplicación que requiere tener activado la doble
autentificación) seguirá estando disponible en Gmail a partir del día
30-5.

Si es así, para quienes la tengan configurada no tendrán que hacer nada.
Veremos cómo va la cosa...

Saludos,

--
Camaleón

alfon

unread,

May 18, 2022, 3:30:03 AM5/18/22

to

> 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.

Saludos.

Camaleón

unread,

May 19, 2022, 2:40:03 PM5/19/22

to

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

hubble

unread,

May 19, 2022, 6:10:04 PM5/19/22

to

Pero seguro que tod@s intuimos qué es y hacia dónde vamos ;-)

gracias.

--
hubble <hub...@telefonica.net>

Ramses

unread,

May 20, 2022, 8:50:03 AM5/20/22

to

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

Alfonso García Rodríguez

unread,

May 20, 2022, 1:30:04 PM5/20/22

to

El día 19/05/2022, a las 20:38, Camaleón 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.

Por lo que yo he entendido es parecido a Kerberos: Es decir, hay un sistema
mediador entre el cliente y el servidor, que proporciona el acceso a este
último mediante tokens (vamos... códigos) Sería como si compro un abono
transportes que me permite acceder al metro hasta que caduque.

> 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

Yo creo que el correo electrónico es un servicio, ¿no?

> 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.

Un poco incómodo sí que es, pero también es más seguro que la contraseña
tradicional.

Mi problema es que tengo que actualizar el código de refresco cada x días.
Se supone que este no caduca, pero en mi caso sí que lo hace. Esto es
incómodo, porque tienes que obtenerlo ejecutando el script que proporciona
gúgol (oauth2.py) y obtener un código de autorización mediante el navegador
web. Para los terminalitas como yo esto es un atraso. Seguro que se puede
automatizar usando curl o algo por el estilo, pero esto complica más la
cosa.

>
> 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 :-/

Si eso sucede nos hacemos un servidor de correo para nosotros, que no?!!!
jeje... Yo estoy deseando hacerlo y dejar de usar gúgol.

Ángel

unread,

May 21, 2022, 7:20:03 PM5/21/22

to

On 2022-05-19 at 20:38 +0200, Camaleón wrote:
> 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.

No es una ventaja para los clientes de correo ni está diseñado como
tal. Ellos funcionarían mejor simplemente con una contraseña. Para los
usuarios, es una cuestión de que el cliente de correo de su elección
soporte este sistema.

> 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 :-/

El problema de fondo es que la gente utiliza contraseñas inseguras. Si
tu contraseña es «Camaleon1» el servidor de Gmail no podrá hacer
demasiado para proteger tu cuenta (y seguro que tienen clientes con
contraseña aún más ridículas y que se negarán a cambiarlas, pero que
les cuplarían si les entran en la cuenta).

Lo que consiguen con OAuth es dirigir al usuario al navegador, donde
tienen mucha más libertad: le pueden pedir un segundo factor (si lo
tiene configurado), reenviarlo a un servidor SSO, pedirle una pregunta
de seguridad, hacerle resolver un captcha, etc.
Una vez dado de alta (a través de ese acceso por la web) el cliente de
correo, este se conectará haciendo uso del token que le ha devuelto
para cuando necesite acceder.

Un saludo