¿Qué demonios son todos esos signos igual (=)?

• Últimamente se han viralizado en Twitter citas de correos electrónicos antiguos, lo que despertó la duda de por qué aparecen signos igual (=) al final de las frases
• Ese símbolo aparece por el proceso de codificación “quoted-printable”, donde se usa para indicar que una línea larga fue dividida a la fuerza y que continúa en la siguiente
• Al transmitir correos electrónicos se usa CRLF (carriage return + line feed) como salto de línea, pero al convertirlo al NL de Unix, si el algoritmo de decodificación funciona mal, el signo igual puede quedar visible o perderse caracteres
• El signo igual también se usa para representar caracteres no ASCII (por ejemplo, =C2=A0), y un decodificador defectuoso puede provocar errores al sustituirlo de forma simplista
• La causa del problema es una combinación de lógica de decodificación con bugs y manejo inadecuado de conversiones, lo que muestra que quien procesó esos correos tenía poca pericia técnica

---

La identidad del signo igual (=) en las citas de correos electrónicos

• En los últimos días se compartieron en Twitter muchas citas de correos electrónicos antiguos, y llamó la atención la aparición de signos igual al final de las oraciones

  • El autor rebate las afirmaciones de quienes lo confundieron con un error de código o de OCR (reconocimiento óptico de caracteres)
  • En realidad, se trata de un error de procesamiento de codificación ocurrido al convertir el correo a un formato más legible

• Antes el correo electrónico era texto simple, pero para manejar líneas largas o caracteres especiales se introdujo la codificación “quoted-printable”

  • Al dividir una línea larga, se agrega un signo igual (=) al final para indicar: “esta línea continúa”
  • En ese caso, después del signo igual viene un CRLF (carriage return + line feed)

Errores de codificación y decodificación de saltos de línea

• Los servidores de correo usan CRLF como estándar de salto de línea, mientras que los sistemas Unix usan solo NL

  • Durante la conversión se pierde un byte, y si el decodificador lo maneja mal, el signo igual puede quedar visible o pueden desaparecer caracteres
  • Por ejemplo, si “non- =CRLF cloven” se procesa mal, puede terminar como “non- loven”, haciendo que desaparezca la “c”

• Algunas implementaciones procesan un signo igual al final de línea eliminando dos caracteres

  • Ese algoritmo falla en archivos con formato Unix y hace que el signo igual quede tal cual

Otro uso del signo igual: codificación de caracteres no ASCII

• El signo igual también se usa para la codificación de caracteres no ASCII, además de los saltos de línea

  • Por ejemplo, “=C2=A0” significa un non-breaking space (espacio de no separación)
  • Suele aparecer al representar sangrías o caracteres especiales dentro del cuerpo del correo

• El autor supone que algunos conversores simplemente hicieron un search-replace de =C2, =A0, etc., sin usar un decodificador adecuado

Contexto técnico y estándar

• El estándar RFC 2045 define la codificación quoted-printable como algo para transporte (transport)

  • Después de recibir el mensaje, lo correcto es decodificarlo y guardarlo como texto limpio
  • Sin embargo, en implementaciones reales este proceso a veces se omite, y por eso son frecuentes los errores al procesar saltos de línea

• En el código de ejemplo, (quoted-printable-decode-string "he=\nllo") se restaura correctamente como "hello"

  • Esto ocurre porque se reutilizó un algoritmo que asume CRLF dentro del contexto de un servidor SMTP
  • Funciona bien en archivos basados en Windows, pero falla en Unix

Conclusión

• Los signos igual en las citas de correos electrónicos son residuos de la codificación quoted-printable y el resultado de combinar
  fallas en el manejo de saltos de línea y en la decodificación de caracteres no ASCII
• La raíz del problema es una implementación imprecisa del decodificador y errores en la conversión de codificación
• El autor lo resume como “un problema técnico y el resultado de un procesamiento incorrecto”,
  y subraya la necesidad de respetar con cuidado los estándares durante la conversión de correos electrónicos

[GN⁺]

Opiniones de Hacker News

• El protagonista de este artículo es Lars Ingebrigtsen, quien escribió el manual de Gnus, el paquete lector de correo/Usenet de Emacs
  Su manual es ingenioso y útil, y demuestra una comprensión del parseo de correo electrónico mucho más profunda que la de la mayoría de la gente
  El manual puede verse aquí, y otra versión está en este enlace

  • No solo escribió el manual, también es desarrollador de Gnus
    Recuerdo la época en la que empezó a crear Gnus en la Universidad de Oslo (UiO)
    Era una pequeña estrella desarrolladora entre los estudiantes de informática, y todos usábamos Emacs y Gnus

• Este caso es un ejemplo clásico de alguien que “sabe lo suficiente como para ser peligroso”
  Sabía que el correo no es texto plano simple, pero no que el decodificado quoted-printable no puede hacerse con una sustitución sencilla
  Es de la misma clase de error que intentar parsear HTML directamente con expresiones regulares: al principio parece funcionar, pero luego termina con un montón de signos ‘=’ en evidencia presentada ante el Congreso

  • En relación con eso, compartieron una famosa respuesta de Stack Overflow que explica con humor por qué no se debe parsear HTML con expresiones regulares
  • Como la salida suele seguir siendo legible, nadie notó el problema hasta que años después fue presentada como evidencia ante el Congreso
  • Cierra con la broma de que “la mejor gente ya está trabajando en ello”

• Hubo una pregunta sobre “por qué a los servidores de correo no les gustan las líneas largas”

  • SMTP es un protocolo basado en líneas, así que el cuerpo del mensaje también se transmite línea por línea
    El servidor debe parsear los encabezados, por lo que no puede tratarse simplemente como un blob binario
    IMAP requiere que el servidor haga un parseo completo, y POP3 estaba pensado para un solo dispositivo, así que ya no encaja bien hoy en día
  • Antes, el correo se procesaba línea por línea con buffers de longitud fija
    El RFC 821 limitaba la longitud de línea a 1000 bytes, y por compatibilidad era común cortar a menos de 80 caracteres
    Por eso la codificación Base64 también inserta saltos de línea cada 76 caracteres
  • Cuando se diseñó SMTP, la memoria era extremadamente limitada
    Por ejemplo, un PDP-11 tenía unos 512 KB y un VAX-11 alrededor de 2 MB, y los programadores calculaban la memoria byte por byte
  • Muestran directamente el flujo de comandos de SMTP y explican la estructura de comunicación con HELO, MAIL FROM, RCPT TO, DATA, etc.
  • También se menciona BITNET, la red universitaria de los años 80, recordando que incluso entonces había límites de longitud de línea
    Los documentos relacionados pueden verse en la documentación oficial de IBM y en Wikipedia

• Al principio pensé que el artículo trataría sobre el significado de operadores como = == === .=. <== ==> <<== ==>> (==) => =~=

  • Alguien hizo la broma: “¿Esto es Haskell para hormigas?”
  • Pero dijo que el contenido real era mucho más interesante

• Yo personalmente hice software de archivado de correo electrónico
  Lo más difícil fue manejar los casos límite de archivos .eml acumulados durante más de 20 años
  El concepto es simple, pero el correo electrónico es sorprendentemente complejo

  • El estándar de correo no se diseñó desde cero, sino que es un estándar maldito armado a la fuerza uniendo sistemas previos
    Validar direcciones de correo también es, en la práctica, casi imposible
  • Hice un cliente de correo para consola, con 25% en C++ y 75% en Lua para definir la UI y el procesamiento
    Tuvo unos pocos usuarios durante varios años, pero el manejo de MIME fue el mayor sufrimiento

• Lo que me pareció interesante no fue tanto el signo ‘=’ en sí, sino el fenómeno de que desaparecen los caracteres de alrededor
  Parece un error off-by-one: en vez de borrar el ‘=’, desaparece parte del texto real
  Tal vez tenga que ver con la conversión CRLF/LF

  • El artículo original explica exactamente por qué ocurre
  • Así es como aparecen estos misterios de caracteres desaparecidos en evidencia

• Me preguntaba por qué este problema aparece justo ahora
  En los últimos días la gente ha estado subiendo correos viejos a Twitter, y me preguntaba por qué

  • Al parecer, podría deberse a la publicación de correos relacionados con Epstein
  • De hecho, se dice que el DOJ publicó correos adicionales de Epstein

• Algunas personas plantearon que la causa de este problema quizá no sea Gmail, sino una transformación en un servidor intermedio
  Además de la conversión CRLF→LF, si quoted-printable se aplica dos veces también quedan signos ‘=’, así que podrían haber intervenido dos servidores de correo

  • En algunos PDF aparece metadato plist de Apple Mail.app, así que podría haber sido extraído desde un formato interno
  • Esto ocurre con frecuencia durante la recopilación de evidencia legal
    En la práctica, un pasante sin experiencia reúne los datos con herramientas simples, se convierten varias veces y el formato termina destruido
    El original ya fue descartado, y lo único que queda son fragmentos de datos con la forma intacta pero el contenido dañado
  • A veces esto pasa al importar correos a archivos PST de MS Outlook
  • No parece un único volcado de Gmail, sino el resultado de varios sistemas que “intentaron ayudar” modificando los datos
  • Hubo quien opinó que esta hipótesis es la más convincente

• El artículo de archive.today también muestra el mismo problema de quoted-printable roto
  Los enlaces relacionados son pastes.io/correspond y el hilo de HN

• Dijeron que estaría bien tener un visor de .eml que, al ver correos descargados desde Outlook, decodifique quoted-printable automáticamente