Banda Ancha EU

Comunidad de usuarios
de fibra, móvil y ADSL

Bug en el software del servidor POP3 de Yahoo (JPOP) con el comando top

NetSpot

TL;DR lo que pone en el asunto y no hay forma de reportarles el error; al final pongo el procedimiento por si queréis probarlo.

Venga, vamos a desahogarnos, porque ir a contárselo a ellos no ha servido de nada.

Mira que anoche, cuando me dí cuenta, dije, voy a perder el tiempo. Y sí, he perdido el tiempo. Como hablar con un muro. Tienen un error en su implementación de software de servidor y su respuesta literal, en un esfuerzo de no entender, ni querer entender, "no damos soporte a programas de terceros". ¡Pero si el problema es suyo!

Vale, sí, que los de las redes sociales son unos mandados y no tienen ni idea de la misa a la media, pero es que no entender que tienen un problema en el servidor. Y como todas las empresas hoy día, ni medios de contacto ni leches. La dirección postmaster, ni la intento, para qué, si cada día se cierran más y en teoría es sólo para SMTP, si es que la tienen.

En fin.

¿De qué va el tema? De que en el RFC sobre POP3 dice que, aun siendo el comando TOP opcional, debe de funcionar de la manera en que se especifique un número de mensaje y las líneas a devolver por el servidor. O sea, si queremos el mensaje 1563 y no queremos recibirlo entero, en vez de usar el comando RETR, pues usamos el TOP y eso que ahorramos (esto lo digo yo, pero OJO a la palabra, ahorrar). Si especificamos, entonces, un comando "TOP 1563 150" recibiremos las cabeceras y las primeras 150 líneas del mensaje. Si se usa "TOP 1563 0", pues sólo las cabeceras. Fácil, ¿no? Se entiende.

Práctico es, ¿o no? Y la mayoría de los servidores lo implementan. Y aunque puede que ya menos, los clientes de correo que se hagan llamar como tal, también.

El caso es que de siempre el servidor de correo Yahoo ha ido de aquella manera, pero desde que se unieron con AOL y pusieron el mismo servidor (jpop 0.1 según reportan) para ambos servicios, aparte de lento, se atasca cuando quiere y va como va.

Pero anoche fue el colmo del atasco. No es que el servidor no respondiera, no, si responder respondía al comando TOP, pero el problema es que cuando responde… ¡¡¡LO HACE ENVIANDO EL CORREO COMPLETO!!! No hace ni puñetero caso a los parámetros del comando en cuanto a las líneas a devolver. Pongas el número que pongas, ¡¡¡todo el correo!!! ¡¡VIVA EL AHORRO!! (¿entiendes ahora por qué he dicho lo del ahorro antes?)

Así que claro, llega mi super cliente de correo (algún lector ya le estará echando las culpas), que no espera recibir decenas de megas a la pregunta de “TOP 1563 0” (0 líneas, sólo cabeceras) y se queda pa’llá, se me cuelga y adiós muy buenas.

La única solución, pues configurar el cliente para decirle al servidor que no envíe X líneas, que se descargue todo. Entonces sí espera las decenas de megas y sabe manejarlo, aunque sea un puñetero desperdicio de memoria (lo descarto después) y de ancho de banda.

Y te paras a pensar…, esto en una conexión doméstica, pase, pero, ¿en una conexión móvil? ¡¡Adiós datos!! Y no hablo del tráfico en los servidores de Yahoo/AOL pero, ¡¡coño, por eso van tan lentos!! Pero bueno, allá ellos con sus facturas.

Total, que al final llego a lo que decía al principio, les intentas contactar, y pasan de la mierda así que aquí vengo a contarlo. A desahogarme, vaya, que ya anda uno hasta … de cómo funciona hoy Internet: para dummies, y no te quejes, que ya es mucho.

Y por último el procedimiento para que lo probéis vosotros.

A la mayoría no creo que haga falta deciros como usar un cliente Telnet, ni, si no soporta TLS, cómo usar Stunnel o similares, así que, que cada uno se las arregle con lo suyo.

Por lo demás, en conexión con el servidor de Yahoo/AOL, los comandos serían, sustituyendo el texto entre corchetes por vuestros datos (entre comandos debe mediar un “OK”):

user [nombre de usuario de Yahoo]
pass [tu contraseña]
top [numero de mensaje a probar] [número de líneas a recibir]
quit

Como veréis, el servidor envía absolutamente todo el correo al completo.

Y si es un mensaje muy grande (muchos megas) pues, tal vez, acabaréis con una pérdida de conexión con el servidor por timeout mientras vuestro cliente Telnet procesa lo que recibe, aunque sólo sea para sacarlo por pantalla.

Y hasta aquí la parrafada. Si alguno sabe cómo hacerles llegar esto a los de Yahoo/AOL, Verizon, Oath, o como demonios quieran acabar llamándose, pues que lo diga o se lo haga llegar. Como prefiera.

Qué aburrido acaba uno de tanta mierda.

BocaDePez
BocaDePez

Entiendo el protocolo y tú enfado, pero básicamente lo que están diciendo es que su negocio no depende de soportar implementaciones de terceros (la tuya) por lo que no lo van ni a mirar.

A saber por qué tomaron la decisión de implementarlo así, la cosa es que dudo que cambie si no rompe el funcionamiento de su cliente web o clients como Thunderbird.

Por si te sirve puedes intentar exponerlo en mailing lists de email o en Twitter en inglés.

saludos.

🗨️ 11
NetSpot

(Ya me había olvidado que la flechita era responder … A ver si ahora el servidor me deja enviar esto donde debe)

> su negocio no depende de soportar implementaciones de terceros (la tuya) por lo que no lo van ni a mirar.

Mi implementación dice 🤣 Otro que no sabe lo que es un RFC.

Y no es mía, es un cliente de correo que sigue los RFC como lo hacen todos. Y qué tendrá que ver Thunderbird. Si Thunderbird eligió no implementar, que no lo sé porque hace años que no lo uso, el comando TOP para protocolo POP3, es su problema, pero si el servidor lo implementa debe seguir el RFC, si no, que no lo haga, que para algo es opcional. Que tire un error de servidor y todos contentos.

Por si te sirve puedes intentar exponerlo en mailing lists de email o en Twitter en inglés.

¿Pero no has leído ya que eso es lo que he hecho? 🤦

En fin, no esperaba encontrar almas gemelas por aquí (de hecho esperaba comentarios de este tipo), sólo es un desahogo, pero primer mensaje, primer "que hagan lo que quieran aunque se salten los estándares". Como para molestarse con contactar con nadie que se supone que sabe lo que hace llevando un servidor XD

🗨️ 10
rbetancor

Con independencia de lo que diga el RFC, tu implementación del lado cliente, tampoco estará muy bien … cuando se queda bloqueado recibiendo los datos. Tu no puedes saber de antemano si las cabeceras (cuando pides un TOP [ID] 0) van a pesar 10kb o 10M, así que la implementación debería simplemente contemplar la recogida de esos datos, hasta que el servidor te indique que ha terminado de ejecutar el comando TOP.

A parte de ese pequeño tema … hablar con gigantes, sobre temas de que respetan o no RFC, suele acabar con dolor de cabeza, sobre todo sino tienes forma de hablar "directamente" con los que pueden arreglarlo.

🗨️ 6
NetSpot

Otra. Que no es mi implementación XD.

Hombre, en un TOP x 0 no se puede saber, aunque las cabeceras acaban con una línea en blanco y por tanto es lo que se espera, pero tampoco es que vayan a ser 10GB en cabeceras X_D Aunque al ritmo que vamos con tanta basura.

El servidor no termina de ejecutar TOP, simplemente vuelca datos con lo que le mandas. Y si un cliente espera 10 líneas y le vienen de vuelta 10MB, pues… se satura.

EDIT, para quien se lo pregunte, 1 línea = 80 bytes, máximo, normalmente, leer RFC, pero vamos, el límite alto es raro.

🗨️ 5
rbetancor
🗨️ 4
NetSpot
🗨️ 3
rbetancor
🗨️ 2
NetSpot
🗨️ 1
rbetancor
BocaDePez
BocaDePez

Con esas formas anda a pasar tu y tu implementación basurienta.

Se lo que es un RFC perfectamente, y una empresa puede o no implementarlo totalmente o saltarselo si le interesa por el motivo que sea.

A ver si pretendes que gratuitamente una empresa haga lo que tú esperas de ella en base a un RFC sin contrato de por medio.

Yahoo implementará como le de la gana y si lo que comentas no es un fallo si no que han decidido hacerlo así por un motivo que desconocemos pues te apañas y vas a llorar a Jerusalem.

🗨️ 2
NetSpot

Que no es mi implementación.

¿Pero cuántas veces tengo que decirlo? Si no lo he dicho en ningún momento.

🗨️ 1
BocaDePez
BocaDePez
Bramante

Espero equivocarme, pero me da que todo intento de hacerles ver que no están respetando el protocolo (imagino que son perfectamente conscientes) va a acabar dando con la cabeza en una pared.

En mi opinión, Yahoo lleva ya años siendo un cadaver andante por el que el propietario de turno no tiene el más mínimo interés y se traduce en movidas como esta.

🗨️ 4
NetSpot

No, si perfectamente conscientes no lo dudo, de hecho la respuesta que da TOP es la de RETR…, pero para implementarlo así , que no lo hagan. Me gustaría pensar que fue un error.

Las alternativas, creo que no se salva ni uno entre una cosa y la otra, y mejor no las menciono para no aburrir.

🗨️ 3
Bramante

No he desarrollado nunca nada relacionado con POP3 (tengo pendiente JavaMail para una historieta personal) pero entiendo que, por lo que comentas, top es útil para vistas previas, e.g., y entiendo que se utiliza a menudo en clientes de correo.

Lo digo porque me sorprende no haber encontrado a nadie quejándose del tema en el par de búsquedas que he hecho.

🗨️ 2
NetSpot

Como le he dicho al BocaDePez, el cliente no es mío. Pero sí, es útil para eso que dices.

Normalmente un correo, lo que es el cuerpo, si pasa de 2-4KB es un milagro. Sin ir más lejos, la parrafada de este tema son 4.5KB escasos. ¿Qué se consigue con TOP?, pues no bajar más que lo justo y necesario. Si es un correo con adjuntos, pues si eso te lo descargas y ya, pero si no, ¿para qué descargarte un correo de 20MB?

La primera vez, te puede interesar, pero la siguiente, no, si dejas los mensajes en el servidor. Y las siguientes pueden ser una sincronización rápida del listado de correos. No te vas a bajar la bandeja entera (RETR) para descargarte sólo uno.

Es la manera de un cliente POP3 de mantener, y comprobar contra el servidor, la lista de correos (TOP x 0, sólo las cabeceras).

NetSpot

Lo digo porque me sorprende no haber encontrado a nadie quejándose del tema en el par de búsquedas que he hecho.

Se me olvidó esto.

No te negaré que el uso del comando sea residual y sea para frikis como yo, así que es normal que no veas quejas por la red y no haya una masa enfurecida a las puertas de Oath demandando un cambio ;-)

HUMOR, para que quede claro.

BocaDePez
BocaDePez

Pregunta tonta ¿Has probado a recibir una línea en lugar de 0 líneas?

🗨️ 4
NetSpot

Lo de 0 era una ejemplo para que se entienda su funcionalidad.

Y sí, por telnet (y dentro de la configuración del programa), he probado diferentes cantidades. Yahoo siempre responde con todo el mensaje como con un RETR.

🗨️ 3
BocaDePez
BocaDePez
1

Me temo que has hecho lo único que podías: Quejarte y que sea de público conocimiento.

Es terrible para gente que tenga los datos muy limitados, como conexiones satélite, por avión o barcos. Pero ahí se soluciona evitando Yahoo.

No debería extrañarte que las compañías no sigan el estándar ni les importe.

🗨️ 2
NetSpot

Pero ahí se soluciona evitando Yahoo.

Lo que acabará tocando, por desgracia. Son ya demasiadas. Pero uno es cabezón y dentro de 20 años, si sigo por estas tierras, tal vez siga con ello a pesar de lo dicho, así que, como dices, toca intentarlo :)

🗨️ 1
BocaDePez
BocaDePez
Spyd

Supongo que el tema es que el protocolo POP está obsoleto. ¿Ocurre lo mismo en IMAP?

🗨️ 1
NetSpot

¿Ocurre lo mismo en IMAP?

No.

Supongo que el tema es que el protocolo POP está obsoleto.

Hombre, tanto como afirmar que está obsoleto. Sirven a propósitos diferentes.

Con IMAP puedes gestionar las carpetas y POP3 es un sistema para comprobar y gestionar la bandeja de entrada.

Hace décadas soñábamos con que lo implementaran y no lo hacían (por recursos, se decía) y hoy vemos anticuado un sistema que sólo permite manejar la bandeja de entrada, pero sigue sirviendo a su propósito perfectamente.

Cada uno tiene sus ventajas.

Debo ser un bicho raro por seguir usando un sistema rápido de consulta de la bandeja de entrada ;O)