Planeta BSD

Porque ya van dos… dos fallos remotamente explotables en OpenBSD en la instalación por defecto en 10 años. Hacían 4 del anterior percance, y no es porque no le busquen las cosquillas .

De la errata de la vigente 4.0:

010: SECURITY FIX: March 7, 2007 All architectures
Incorrect mbuf handling for ICMP6 packets.

Using pf(4) to avoid the problem packets is an effective workaround until the patch can be installed.
Use “block in inet6″ in /etc/pf.conf

A source code patch exists which remedies this problem.

Theo De Raadt envió un correo que lo explica todo muy bien, tanto que igual me parcheo mi versión de OpenBSD, que ya no tengo soporte en la versión que vengo usando .

Por ahora he puesto en práctica el workaround (solución provisional al problema), aunque tampoco es que tenga conectividad IPv6 en este momento, así que…

Eso sí, me he dado cuenta que actualizar depende que cosas desde aquí no es tan fácil como hacerlo desde casa. Claro, si te equivocas no es lo mismo tener el servidor en la habitación de al lado que a 800 Km. Al menos psicológicamente .

No sé si es momento de buscar algún sistema más cómodo de administrar, porque tampoco tengo tiempo últimamente de aprender cacharreando. En cualquier caso, por ahora no tengo elección .

Leer el post completo »

Porque ya van dos… dos fallos remotamente explotables en OpenBSD en la instalación por defecto en 10 años. Hacían 4 del anterior percance, y no es porque no le busquen las cosquillas .

De la errata de la vigente 4.0:

010: SECURITY FIX: March 7, 2007 All architectures
Incorrect mbuf handling for ICMP6 packets.

Using pf(4) to avoid the problem packets is an effective workaround until the patch can be installed.
Use “block in inet6″ in /etc/pf.conf

A source code patch exists which remedies this problem.

Theo De Raadt envió un correo que lo explica todo muy bien, tanto que igual me parcheo mi versión de OpenBSD, que ya no tengo soporte en la versión que vengo usando .

Por ahora he puesto en práctica el workaround (solución provisional al problema), aunque tampoco es que tenga conectividad IPv6 en este momento, así que…

Eso sí, me he dado cuenta que actualizar depende que cosas desde aquí no es tan fácil como hacerlo desde casa. Claro, si te equivocas no es lo mismo tener el servidor en la habitación de al lado que a 800 Km. Al menos psicológicamente .

No sé si es momento de buscar algún sistema más cómodo de administrar, porque tampoco tengo tiempo últimamente de aprender cacharreando. En cualquier caso, por ahora no tengo elección .

Leer el post completo »

En el trabajo se empeñan en seguir ignorando la realidad: vi es el editor, cualquier reemplazo (que no sea EMACS) es simplemente insuficiente .

Ya comenté el otro día que uso mail(1) para leer el correo en el servidor, aunque los correos los escribo realmente con vi (en la entrada de un mensaje, el comando ~v).

Vamos a repasar un poco por encima algunas características básicas que, por desconocimiento, suelen limitar a la gente cuando emplea este editor de textos tan útil administrando sistemas.

Leer más

Leer el post completo »

En el trabajo se empeñan en seguir ignorando la realidad: vi es el editor, cualquier reemplazo (que no sea EMACS) es simplemente insuficiente .

Ya comenté el otro día que uso mail(1) para leer el correo en el servidor, aunque los correos los escribo realmente con vi (en la entrada de un mensaje, el comando ~v).

Vamos a repasar un poco por encima algunas características básicas que, por desconocimiento, suelen limitar a la gente cuando emplea este editor de textos tan útil administrando sistemas.

Leer más

Leer el post completo »

Hace tiempo que vengo usando el venerable mail(1) de OpenBSD para leer el correo fuera de casa. Es muy rudimentario, pero básicamente no necesito más y puedo usarlo sin problemas vía SSH con cualquier conexión por cutre que sea.

Aunque esto no es del todo cierto . Habían un par de cosas que hacían que su uso fuera incómodo. Tanto que ya estaba pensando en instalar un programa más potente para leer el correo vía terminal de texto, pero unos son bastante inseguros, y otros muy complicados de usar (aunque todo es ponerse, sino no usaría mail).

Ojeando un poco el código, al final no ha hecho falta instalar nada .

En realidad eran dos minucias, que paso a enumerar:

• Yo no uso us-ascii: el cliente no implementa los añadidos MIME, muy recientes si los comparamos con la edad de mail . Tiene sentido, porque en aquella época todo Internet estaba en USA .

  Pero las cosas cambian, y yo escribo mis correos con acentos empleando iso-8859-1. Cuando un cliente de correo recibe uno de mis mensajes no lo sabe, y por lo tanto no se visualizan bien los correos si no coincide que usamos el mismo juego de caracteres.

  Esto se soluciona implementando las cabeceras MIME mínimas para indicar el juego de caracteres: MIME-Version y Content-Type.

  Sería añadir algo así:

  MIME-Version: 1.0
  Content-Type: text/plain; charset=CHARSET; format=fixed

  Solo tenemos que indicar en CHARSET un código válido para el juego de caracteres que usamos (como iso-8859-1, o utf-8 si lo usara) y listo. Además el atributo opcional format nos permite indicar que usamos una fuente de ancho fijo y que no esperamos que el cliente que muestra el correo agrupe por párrafos, por ejemplo.

• Las refencias a los mensajes en la respuesta son útiles: esto es gracias a la cabecera In-Reply-To, donde los clientes de correo pueden indicar el Message-Id (otra cabecera, esta no es opcional) del correo al que se responde, de forma que los programas puedan agrupar mensajes por conversaciones. Mail no se preocupa de esto, y al mandar mensajes a listas de correo, era un inconveniente porque rompía los hilos de discusión .

He tardado poco, unos 15 minutos en ver cómo iba el fuente (muy clarito, por cierto), y otros 15 en meter las lineas de código necesarias.

Para que se añada el tipo MIME hay que indicar en $HOME/.mailrc el valor de charset a usar, por ejemplo:

set charset=iso-8859-1

La inclusión de la cabecera In-Reply-To es automática al responder, así que en esa parte no hay que hacer nada.

Si a alguien le interesa, aquí hay un parche. Es muy simple, y creo que no tiene ningún fallo fundamental (pese a que ahora veo que hay una variable declarada que finalmente no he usado ).

Actualización: he limpiado el parche quitando la variable que no se usaba .

Leer el post completo »

Hace tiempo que vengo usando el venerable mail(1) de OpenBSD para leer el correo fuera de casa. Es muy rudimentario, pero básicamente no necesito más y puedo usarlo sin problemas vía SSH con cualquier conexión por cutre que sea.

Aunque esto no es del todo cierto . Habían un par de cosas que hacían que su uso fuera incómodo. Tanto que ya estaba pensando en instalar un programa más potente para leer el correo vía terminal de texto, pero unos son bastante inseguros, y otros muy complicados de usar (aunque todo es ponerse, sino no usaría mail).

Ojeando un poco el código, al final no ha hecho falta instalar nada .

En realidad eran dos minucias, que paso a enumerar:

• Yo no uso us-ascii: el cliente no implementa los añadidos MIME, muy recientes si los comparamos con la edad de mail . Tiene sentido, porque en aquella época todo Internet estaba en USA .

  Pero las cosas cambian, y yo escribo mis correos con acentos empleando iso-8859-1. Cuando un cliente de correo recibe uno de mis mensajes no lo sabe, y por lo tanto no se visualizan bien los correos si no coincide que usamos el mismo juego de caracteres.

  Esto se soluciona implementando las cabeceras MIME mínimas para indicar el juego de caracteres: MIME-Version y Content-Type.

  Sería añadir algo así:

  MIME-Version: 1.0
  Content-Type: text/plain; charset=CHARSET; format=fixed

  Solo tenemos que indicar en CHARSET un código válido para el juego de caracteres que usamos (como iso-8859-1, o utf-8 si lo usara) y listo. Además el atributo opcional format nos permite indicar que usamos una fuente de ancho fijo y que no esperamos que el cliente que muestra el correo agrupe por párrafos, por ejemplo.

• Las refencias a los mensajes en la respuesta son útiles: esto es gracias a la cabecera In-Reply-To, donde los clientes de correo pueden indicar el Message-Id (otra cabecera, esta no es opcional) del correo al que se responde, de forma que los programas puedan agrupar mensajes por conversaciones. Mail no se preocupa de esto, y al mandar mensajes a listas de correo, era un inconveniente porque rompía los hilos de discusión .

He tardado poco, unos 15 minutos en ver cómo iba el fuente (muy clarito, por cierto), y otros 15 en meter las lineas de código necesarias.

Para que se añada el tipo MIME hay que indicar en $HOME/.mailrc el valor de charset a usar, por ejemplo:

set charset=iso-8859-1

La inclusión de la cabecera In-Reply-To es automática al responder, así que en esa parte no hay que hacer nada.

Si a alguien le interesa, aquí hay un parche. Es muy simple, y creo que no tiene ningún fallo fundamental (pese a que ahora veo que hay una variable declarada que finalmente no he usado ).

Actualización: he limpiado el parche quitando la variable que no se usaba .

Leer el post completo »

Los filtros bayesianos son una herramienta muy útil a la hora de tratar el spam, como ya hemos hablado por aquí. Este tipo de programas tienen la particularidad de requerir entrenamiento inicial, y posteriores correciones porque el spam que recibimos puede ir cambiando y el filtro deber ir adaptándose a la nueva situación. Hablamos de falsos positivos y negativos hace un tiempo.

Podemos enfrentarnos al problema desde diferentes enfoques, aunque personalmente prefiero que la solución parta desde la misma aplicación de correo electrónico.

Leer más

Leer el post completo »

Los filtros bayesianos son una herramienta muy útil a la hora de tratar el spam, como ya hemos hablado por aquí. Este tipo de programas tienen la particularidad de requerir entrenamiento inicial, y posteriores correciones porque el spam que recibimos puede ir cambiando y el filtro deber ir adaptándose a la nueva situación. Hablamos de falsos positivos y negativos hace un tiempo.

Podemos enfrentarnos al problema desde diferentes enfoques, aunque personalmente prefiero que la solución parta desde la misma aplicación de correo electrónico.

Leer más

Leer el post completo »

Por fin me ha desquiciado :S.

Entrega de correo en peligro

Ya comenté que están jugando con medidas antispam y que eso me está perjudicando (porque lo hacen mal, claro), y es desesperante mandar correos y que te reboten.

Desde hace tiempo empleo ssh para conectar a mi servidor y desde ahí utilizar mail(1) para leer y enviar mensajes de correo electrónico cuando estoy fuera mi máquina habitual.

Vale, estoy de acuerdo con que mail no es el MUA definitivo ni para consola
(Mail User Agent, lo que vamos entendiendo por cliente de correo: se usa para componer mensajes, leerlos, etc; más sobre esto en una explicación del correo electrónico), pero a mi me va muy bien y teniendo un MTA en casa bien configurado (Mail Transport Agent, que es el que finalmente lleva el correo de un sitio a otro; la cosa no queda aquí, sigua leyendo ), ¿para qué más?

Pues bien, como a los señores administradores de Gmail les ha dado otra vez porque estoy enviando spam desde mi dirección IP, como ya comenté hace unas semanas, y da la casualidad que envío correos a varias personas con sus cuentas en ese servicio gratuito, pues se me han hinchado las narices: la solución es emplear un smarthost que entregue el correo en nuestro lugar.

Leer más

Leer el post completo »

Por fin me ha desquiciado :S.

Entrega de correo en peligro

Ya comenté que están jugando con medidas antispam y que eso me está perjudicando (porque lo hacen mal, claro), y es desesperante mandar correos y que te reboten.

Desde hace tiempo empleo ssh para conectar a mi servidor y desde ahí utilizar mail(1) para leer y enviar mensajes de correo electrónico cuando estoy fuera mi máquina habitual.

Vale, estoy de acuerdo con que mail no es el MUA definitivo ni para consola
(Mail User Agent, lo que vamos entendiendo por cliente de correo: se usa para componer mensajes, leerlos, etc; más sobre esto en una explicación del correo electrónico), pero a mi me va muy bien y teniendo un MTA en casa bien configurado (Mail Transport Agent, que es el que finalmente lleva el correo de un sitio a otro; la cosa no queda aquí, sigua leyendo ), ¿para qué más?

Pues bien, como a los señores administradores de Gmail les ha dado otra vez porque estoy enviando spam desde mi dirección IP, como ya comenté hace unas semanas, y da la casualidad que envío correos a varias personas con sus cuentas en ese servicio gratuito, pues se me han hinchado las narices: la solución es emplear un smarthost que entregue el correo en nuestro lugar.

Leer más

Leer el post completo »