[escepticos] Re: Sobre las respuestas de correo
Jose Luis
joseluis.vm en terra.es
Sab Nov 10 15:13:14 WET 2007
Por lo que respecta al evolution y el thunderbird, hablando en serio,
tengo argumentos en favor y en contra de los dos; sencillamente prefiero
el thunderbird.
Por lo que respecta a los virus, las diferencia en el riesgo está entre
Windows y Linux. Quiero decir que entre evolution y thunderbird
funcionando en Linux no hay diferencia y entre los outlook y thunderbird
funcionando en Windows hay poca. No creo que sea conveniente extenderme
más en este punto.
Por lo que respecta a los protocolos, Eloy, también son ganas de
discutir. Según he leído en esta lista "in dubio pro reo" así que
imagino que es una errata y has escrito SNMP cuando querias escribir SMTP.
* SNMP (Simple Network Management Protocol) es un protocolo de gestion
de red. Su especificación actual se encuentra en el RFC 1157 y se usa
para gestionar los objetos definidos en el MBI: SMI (RFC 1155) describe
cómo se definen los objetos gestionados contenidos en el MIB y MIB-II
(RFC 1213) - describe los objetos gestionados contenidos en el MIB.
La funcion del MIB (Management Information Base) es proporcionar los
medios para la coordinación entre múltiples estaciones de gestión. Es
decir, los medios por los que las funciones de control y monitorización
de la gestión de red se pueden distribuir entre múltiples NMS en una
gran red.
* SMTP se basa en tres RFCs
RFC 821 - SMTP("Simple Mail Transfer Protocol")
RFC 822 - estándar para el formato de los mensajes de texto para la red ARPA
RFC 974 - Encaminamiento de correo y el DNS
* SMTPSE("SMTP Service Extensions"), que define un mecanismo para
extender las posibilidades de SMTP más allá de las limitaciones
impuestas por RFC 821. Actualmente hay tres RFCs que lo describen:
* El RFC 1651 modifica el 821 para permitir que un cliente agente SMTP
solicite al servidor una lista de las extensiones de servicio que
soporta el inicio de una sesión SMTP. Si el servidor no soporta este
RFC, responderá con un error y el cliente podrá terminar la sesión o
intentar iniciar una sesión según las reglas RFC 821. Si sí lo soporta,
puede responder con una lista de las extensiones que soporta. IANA
mantiene un registro de servicios: la lista inicial del RFC 1651
contiene los comandos listados en el RFC 1123 - Requerimientos para
hosts de Internet - Aplicación y soporte como opcionales en servidores SMTP.
* Un protocolo para transmisión de texto de 8 bits(RFC 1652) ...
* Un protocolo para la declaración del tamaño del mensaje(RFC 1653) ...
En fin no voy a seguir porque ni siquiera estamos hablando de esto, no
hablamos del envio, sino de la recepción (vease que en la intervención
del TELNET hablabamos del puerto 110 y no del 25) más bien entraria en
el ambito del POP3 que es el protocolo que usamos para recuperar el correo:
* RFC 937 - POP("Post Office Protocol") - Versión 2
* RFC 1725 - POP("Post Office Protocol") - Versión 3
y el RFC 934 que discute la encapsulación de mensajes en el contexto de
la retransmisión de mensajes y define las separadores de encapsulación:
líneas indicando el comienzo y el fin de un mensaje encapsulado. MIME
conserva bastante compatibilidad con RFC 934, pero no incluye el
mecanismo de "entrecomillado" de RFC 934 para líneas de mensajes
encapsulados que de otro modo se podrían confundir con separadores.
MIME-Version
Debe tener el valor "1.0"
Content-Type
Describe como se ha de interpretar el objeto dentro del cuerpo. El
valor por defecto es "text/plain; charset=us-ascii" que indica texto de
7 bits sin formato(cuerpo de mensaje según la definición de RFC 822).
Content-Transfer-Encoding
Describe cómo está codificado el objeto de modo que se puede
incluir en el correo de forma fiable.
Content-Description
Una descripción en texto plano del objeto del cuerpo que es útil
cuando el objeto no es legible (por ejemplo, datos de audio).
Content-ID
Un valor unívoco especificando el contenido de esta parte del mensaje.
En el caso de nuestra lista:
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
(text plain: Texto sin formatear. El juego de caracteres se puede
especificar con el parámetro charset. Se admiten los siguientes valores.
ISO-8859 están basados en ASCII con caracteres nacionales en el rango de
128 a 255. Si el juego no contiene caracteres con valores mayores de
127, se debería usar "us-ascii", ya que así se pueden representar
adecuadamente. Que no es el caso)
Pero tampoco estamos hablando de esto. Ya sea tipo Texto plano o tipo
html en la configuración del lector de correo podemos seleccionar si lo
vemos como código html o texto plano. Y sin "bola de cristal" puedo
adivinar que la gran mayoría están viendo html. En cuanto al rtf, los
outlook y el exchange server no voy a entrar a discutir si entiendo o no
como funciona un sistema que he estado administrando durante cinco años.
Más información sobre la lista de distribución Escepticos