[escepticos] Re: Sobre las respuestas de correo

[Moreno]

Veo que lo del SNMP ya había sido respondido.

En cuanto a si la gente ve html o texto, puedes prescindir de la bola de
cristal y hacer alguna prueba sencilla. No sé, poner algo en negrita o
cursiva, por ejemplo.

On Sat, 10 Nov 2007 16:13:14 +0100, "Jose Luis" <joseluis.vm en terra.es>
said:
> 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.
> 
> 
> 
> _______________________________________________
> Escepticos mailing list
> Escepticos en dis.ulpgc.es
> http://correo.dis.ulpgc.es/mailman/listinfo/escepticos

-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free