Resumen de semana 15

do depI. A. Vargas Villanueva <

092-19-14335Universidad Mariano Gálvez
9989-19-14335 aarteagar@miumg.edu.gt
092504 Topologia de redes ing.ivargas21314@gmail.com

Protocolo para transferencia simple de correo

El protocolo para transferencia simple de correo (en inglés: Simple Mail Transfer Protocol o
SMTP) es un protocolo de red utilizado para el intercambio de mensajes de correo electrónico
entre computadoras u otros dispositivos (PDA, teléfonos móviles, impresoras, etc.). Es, en otras
palabras, un protocolo de conexión de Internet. Se encuentra en la capa de aplicación del modelo
OSI1, la última capa de este modelo que dispone la interfaz entre las aplicaciones de
comunicación y la red que transmite los mensajes2. Fue definido inicialmente en agosto de 1982
por el RFC 821 (para la transferencia) y el RFC 822 (para el mensaje). Estos eran dos estándares
oficiales de Internet que fueron reemplazados respectivamente por el RFC 2821 y el RFC 2822,
que a su vez fueron destituidos por los estándares RFC 5321 y el RFC 5322.3

El funcionamiento de este protocolo se da en línea, de manera que opera en los servicios de

correo electrónico. Sin embargo, este protocolo posee algunas limitaciones en cuanto a la
recepción de mensajes en el servidor de destino (cola de mensajes recibidos). Como alternativa
a esta limitación, este protocolo se ejecuta normalmente en relación con otros, como por
ejemplo el POP o IMAP, otorgando a SMTP la tarea específica de enviar correos y recibirlos
empleando los otros protocolos antes mencionados (POP o IMAP).
Historia
En 1982 se diseñó el primer sistema basado en SMTP para intercambiar correos electrónicos
en ARPANET, definido en los request for comments RFC 821 y RFC 822. La primera de ellas
define este protocolo y la segunda la forma del mensaje que este protocolo debía transportar.
La estructura del SMTP se basa en el modelo cliente-servidor, donde un cliente envía un mensaje
a uno o varios servidores para recibir una respuesta. La comunicación entre el cliente y el
servidor consiste enteramente en líneas de texto compuestas por caracteres Unicode, aunque
originalmente estaba compuesto por caracteres ASCII. El tamaño máximo permitido para estas
líneas es de 1000 caracteres.
Las respuestas del servidor constan de un código numérico de tres dígitos, seguido de un texto
explicativo. El número va dirigido a un procesado automático de la respuesta por autómata,
mientras que el texto permite que un humano interprete la respuesta.
En el protocolo SMTP todas las órdenes, réplicas o datos son líneas de texto, son delimitadas
por el carácter <CRLF>. Todas las réplicas tienen un código numérico al comienzo de la línea
central.
Modelo de procesamiento de correo[editar]

Modelo de procesamiento del correo.

El correo electrónico es presentado por un cliente de correo (MUA, agente de usuario de correo)
a un servidor de correo (MSA, agente de sumisión de correo) usando SMTP a través del puerto
587. Una gran parte de los proveedores de correo todavía permiten el envío a través del puerto
25. Desde allí, el MSA entrega el correo a su agente de transferencia postal mejor conocido
como el MTA (Mail Transfer Agent, Agente de Transferencia de Correo). En algunas ocasiones,
estos dos agentes son casos diferentes aunque hay que destacar que provienen del mismo
software de donde fueron lanzados sólo que presentan opciones diferentes dentro de la misma
máquina.
El procesamiento local que se presenta puede ser realizado en una sola máquina o partido entre
varias aplicaciones; en este segundo caso, los procesos implicados pueden compartir archivos;
aquí SMTP es usado para la transferencia de mensajes internamente, con cada uno de los hosts
configurados para usar la siguiente aplicación como un anfitrión elegante. Para lograr la
localización del servidor objetivo, el MTA divisorio tiene que usar el sistema de nombre de
dominio (DNS) para lograr la búsqueda del registro interno de cambiado de correo conocido
como registro MX para la esfera del recipiente (la parte de la dirección a la derecha). Es en ese
instante cuando el registro de MX devuelto contiene el nombre del anfitrión objetivo.
Luego el MTA se une al servidor de cambio como un cliente SMTP. Una vez que MX acepta el
mensaje entrante, este a su vez se lo da a un agente de entrega de correo (MDA) para luego ser
llevado a la entrega de correo local. El MDA, además de entregar mensajes es también capaz de
salvar mensajes en un buzón de formato, y la recepción de correo puede ser realizada usando
muchas computadoras. Hay dos formas en que un MDA puede entregar mensajes: ya sea
enviándolos directamente al almacenamiento, o expedirlos sobre una red usando SMTP. Una
vez entregado al servidor de correo local, dicho correo es almacenado para la recuperación de
la hornada. Su recuperación se logra por medio de las aplicaciones de usuario final, conocidas
como clientes de correo electrónico, usando el Protocolo de Acceso de Mensaje de Internet
(IMAP), este protocolo que facilita tanto el acceso para enviar, como el manejo de correo
almacenado.
Puertos[editar]
Los administradores de servidor pueden elegir si los clientes utilizan TCP puerto 25 (SMTP) o el
puerto 587 (Presentación) para retransmitir el correo saliente a una inicial del servidor de
correo.4 Las especificaciones y muchos servidores soportan ambos. Aunque algunos servidores
soportan el puerto 465 para el legado SMTP seguro en violación de las especificaciones, es
preferible utilizar los puertos estándar y comandos SMTP estándar de acuerdo con RFC 3207,
si se debe utilizar una sesión segura entre el cliente y el servidor.
Algunos servidores están configurados para rechazar toda la retransmisión en el puerto 25, pero
los usuarios válidos de autenticación en el puerto 587 pueden retransmitir correo a cualquier
dirección válida.[cita requerida] Algunos proveedores de servicios de Internet interceptan el puerto
25, volviendo a dirigir el tráfico a su propio servidor SMTP, independientemente de la dirección
de destino. Esto significa que no es posible para sus usuarios acceder a un servidor SMTP fuera
de la red del ISP a través del puerto 25.
Algunos servidores SMTP soportan el acceso autenticado en otro puerto que no sea 587 o 25
para permitir a los usuarios conectarse a ellos, incluso si el puerto 25 está bloqueado, pero 587
es el puerto estándar y ampliamente apoyada por los usuarios enviar correo nuevo. Microsoft
Exchange Server 2013 SMTP puede escuchar en los puertos 25, 587, 465, 475, y 2525, en
función de servidor y si los roles se combinan en un solo servidor.[cita requerida] Los puertos 25 y
587 se utilizan para proporcionar la conectividad del cliente con el servicio de transporte en la
parte delantera de la función de servidor de acceso de cliente (CAS). Los puertos 25, 465 y 475
son utilizados por el servicio de transporte de buzón de correo. Sin embargo, cuando la función
de buzón se combina con la función de CAS en un único servidor, el puerto 2525 se utiliza por
la función de buzón de SMTP desde el servicio de transporte de extremo delantero del CAS,
CAS, mientras que continúa para utilizar el puerto 25. Puerto 465 es utilizado por el servicio de
transporte de buzón de correo para recibir las conexiones de cliente proxy de la función CAS.
Puerto 475 es utilizado por la función de buzón para comunicarse directamente con otras
funciones de buzón, la transferencia de correo entre el servicio de envío de transporte de buzón
de correo y el servicio de entrega de transporte buzón.5
Descripción del Protocolo[editar]
SMTP. Una transacción de SMTP se compone de tres secuencias de comando / respuesta (véase
el ejemplo a continuación).
Ellos son:
• MAIL FROM: comando para establecer la dirección de retorno, también conocido como
Return-Path, remitente o sobre. Esta es la dirección para mensajes de despedida.
• RCPT TO: comando, para establecer un destinatario de este mensaje. Este mandato
puede emitirse varias veces, una para cada destinatario. Estas direcciones son también
parte de la envolvente.
 • DATA: para enviar el mensaje de texto. Este es el contenido del mensaje, en lugar de su
envoltura. Se compone de una cabecera de mensaje y el cuerpo del mensaje separado
por una línea en blanco. DATA es en realidad un grupo de comandos, y el servidor
responde dos veces: una vez para el comando de datos adecuada, para reconocer que
está listo para recibir el texto, y la segunda vez después de la secuencia final de los datos,
para aceptar o rechazar todo el mensaje.
Resumen simple del funcionamiento del protocolo SMTP[editar]
• Cuando un cliente establece una conexión con el servidor SMTP, espera a que este envíe
un mensaje “220 Service ready” o “421 Service non available”.
• Se envía un HELO desde el cliente. Con ello el servidor se identifica. Esto puede usarse
para comprobar si se conectó con el servidor SMTP correcto.
• El cliente comienza la transacción del correo con la orden MAIL FROM. Como argumento
de esta orden se puede pasar la dirección de correo al que el servidor notificará cualquier
fallo en el envío del correo (Por ejemplo, MAIL FROM:<fuente@host0>). Luego si el
servidor comprueba que el origen es válido, el servidor responde “250 OK”.
• Ya le hemos dicho al servidor que queremos mandar un correo, ahora hay que
comunicarle a quien. La orden para esto es RCPT TO:<destino@host>. Se pueden mandar
tantas órdenes RCPT como destinatarios del correo queramos. Por cada destinatario, el
servidor contestará “250 OK” o bien “550 No such user here”, si no encuentra al
destinatario.
• Una vez enviados todos los RCPT, el cliente envía una orden DATA para indicar que a
continuación se envían los contenidos del mensaje. El servidor responde “354 Start mail
input, end with <CRLF>.<CRLF>” Esto indica al cliente como ha de notificar el fin del
mensaje.
• Ahora el cliente envía el cuerpo del mensaje, línea a línea. Una vez finalizado, se termina
con un <CRLF>.<CRLF> (la última línea será un punto), a lo que el servidor
contestará “250 OK”, o un mensaje de error apropiado.
• Tras el envío, el cliente, si no tiene que enviar más correos, con la orden QUIT corta la
conexión. También puede usar la orden TURN, con lo que el cliente pasa a ser el servidor,
y el servidor se convierte en cliente. Finalmente, si tiene más mensajes que enviar, repite
el proceso hasta completarlos.
Puede que el servidor SMTP soporte las extensiones definidas en el RFC 1651, en este caso, la
orden HELO puede ser sustituida por la orden EHLO, con lo que el servidor contestará con una
lista de las extensiones admitidas. Si el servidor no soporta las extensiones, contestará con un
mensaje "500 Syntax error, command unrecognized".
Comandos[editar]
• HELO, para abrir una sesión con el servidor
• EHLO, para abrir una sesión, en el caso de que el servidor soporte extensiones definidas
en el RFC 1651
• MAIL FROM, para indicar quien envía el mensaje
• RCPT TO, para indicar el destinatario del mensaje
• DATA, para indicar el comienzo del mensaje, este finalizará cuando haya una línea
únicamente con un punto.
• QUIT, para cerrar la sesión
• RSET Aborta la transacción en curso y borra todos los registros.
• SEND Inicia una transacción en la cual el mensaje se entrega a una terminal.
• SOML El mensaje se entrega a un terminal o a un buzón.
• SAML El mensaje se entrega a un terminal y a un buzón.
• VRFY Solicita al servidor la verificación de todo un argumento.
• EXPN Solicita al servidor la confirmación del argumento.
• HELP Permite solicitar información sobre un comando.
• NOOP No decir nada, se emplea para mantener la sesión abierta
• TURN Solicita al servidor que intercambien los papeles.
De los tres dígitos del código numérico, el primero indica la categoría de la respuesta, estando
definidas las siguientes categorías:
• 2XX, la operación solicitada mediante el comando anterior ha sido concluida con éxito
• 3XX, la orden ha sido aceptada, pero el servidor está pendiente de que el cliente le envíe
nuevos datos para terminar la operación
• 4XX, para una respuesta de error, pero se espera a que se repita la instrucción
 • 5XX, para indicar una condición de error permanente, por lo que no debe repetirse la
orden
Una vez que el servidor recibe el mensaje finalizado con un punto puede almacenarlo si es para
un destinatario que pertenece a su dominio, o bien retransmitirlo a otro servidor para que
finalmente llegue a un servidor del dominio del receptor.
Ejemplo de una comunicación SMTP[editar]
En primer lugar se ha de establecer una conexión entre el emisor (cliente) y el receptor (servidor).
Esto puede hacerse automáticamente con un programa cliente de correo o mediante un
cliente telnet.
En el siguiente ejemplo se muestra una conexión típica. Se nombra con la letra C al cliente y con
S al servidor.
S: 220 Servidor SMTP
C: HELO miequipo.midominio.com
S: 250 Hello, please to meet you
C: MAIL FROM: <yo@midominio.com>
S: 250 Ok
C: RCPT TO: <destinatario@sudominio.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: Campo de asunto
C: From: yo@midominio.com
C: To: destinatario@sudominio.com
C:
C: Hola.
C: Esto es una prueba.
C: Hasta luego.
C:
C: .
C: <CR><LF>.<CR><LF>
S: 250 Ok: queued as 12345
C: quit
S: 221 Bye
Formato del mensaje[editar]
Como se muestra en el ejemplo anterior, el mensaje es enviado por el cliente después de que
este manda la orden DATA al servidor. El mensaje está compuesto por dos partes:
• Cabecera: en el ejemplo las tres primeras líneas del mensaje son la cabecera. En ellas se
usan unas palabras clave para definir los campos del mensaje. Estos campos ayudan a los
clientes de correo a organizarlos y mostrarlos. Los más típicos
son subject (asunto), from (emisor) y to (receptor). Estos dos últimos campos no hay que
confundirlos con las órdenes MAIL FROM y RCPT TO, que pertenecen al protocolo, pero
no al formato del mensaje.
• Cuerpo del mensaje: es el mensaje propiamente dicho. En el SMTP básico está
compuesto únicamente por texto, y finalizado con una línea en la que el único carácter
es un punto.
SMTP vs Recuperación de correo[editar]
El protocolo de transferencia de correo simple (SMTP) solo se encarga de entregar el mensaje.
En cuanto se reciben, los mensajes son enviados al servidor de correo de destino o al servidor
de correo de siguiente salto. El correo se enruta en base al servidor de destino, no a las
direcciones de los usuarios individuales. Otros protocolos como el protocolo de oficina de
correos (POP) y el protocolo de acceso a mensaje de internet (IMAP) su estructura es para
usuarios individuales, recuperación de mensajes, gestión de buzones de correo. SMTP usa una
función, el procesamiento de colas de correo en un servidor remoto, permite que un servidor de
correo de forma intermitente conectado a mandar mensajes desde un servidor remoto. El IMAP
y el POP son protocolos inadecuados para la retransmisión de correo de máquinas de forma
intermitente-conectados, sino que están diseñados para funcionar después de la entrega final.
Inicio remoto de mensaje en cola[editar]
Es una característica de SMTP que permite a un host remoto para iniciar el procesamiento de la
cola de correo en el servidor por lo que puede recibir mensajes destinados a ella mediante el
envío del comando TURN. Esta característica se considera insegura pero usando el comando
ETRN en la extensión RFC 1985 funciona de forma más segura.
Petición de Reenvío de Correo Bajo Demanda (ODMR)[editar]
On-Demand Mail Relay (ODMR por sus siglas en Inglés) es una extensión de SMTP
estandarizada en la RFC 2645 que permite que el correo electrónico sea transmitido al receptor
después de que él ha sido aprobado. Usa la orden de SMTP ampliada ATRN, disponible para la
direcciones de IP dinámicas. El cliente publica EHLO y órdenes de AUTH de servicios ODMR de
correo, ODMR comienza a actuar como un cliente SMTP y comienza a enviar todos los mensajes
dirigidos a un cliente usando el protocolo SMTP, al iniciar sesión el cortafuegos o el servidor
pueden bloquear la sesión entrante debido a IP dinámicas. Sólo el servidor ODMR, el proveedor
del servicio, debe escuchar las sesiones SMTP en una dirección de IP fija.
Internacionalización[editar]
Muchos usuarios cuyo lenguaje base no es el latín han tenido dificultades con el requisito de
correo electrónico en América. RFC 6531 fue creado para resolver ese problema,
proporcionando características de internacionalización de SMTP, la extensión SMTPUTF8. RFC
6531 proporciona soporte para caracteres de varios bytes y no para ASCII en las direcciones de
correo electrónico. El soporte del internacionalización actualmente es limitada pero hay un gran
interés en la ampliación del RFC 6531. RFC en países como en China, que tiene una gran base
de usuarios en América.
Correo saliente con SMTP[editar]
Un cliente de correo electrónico tiene que saber la dirección IP de su servidor SMTP inicial y
esto tiene que ser dado como parte de su configuración (usualmente dada como un
nombre DNS). Este servidor enviará mensajes salientes en nombre del usuario.
Restricción de acceso y salida al servidor de correo[editar]
En un ambiente de servidores, los administradores deben tomar medidas de control en donde
los servidores estén disponibles para los clientes. Esto permite implementar seguridad frente a
posibles amenazas. Anteriormente, la mayoría de los sistemas imponían restricciones de uso de
acuerdo a la ubicación del cliente, sólo estaba permitido su uso por aquellos clientes cuya
dirección IP es una de las controladas por los administradores del servidor. Los servidores SMTP
modernos se caracterizan por ofrecer un sistema alternativo, el cual requiere de una
autenticación mediante credenciales por parte de los clientes antes de permitir el acceso.
Restringir el acceso por ubicación[editar]
Mediante este sistema, el servidor SMTP relativo al ISP no permitirá el acceso de los usuarios
que están fuera de la red del ISP. Específicamente, el servidor solo puede permitir el acceso de
aquellos usuarios cuya dirección IP fue proporcionada por el ISP, lo cual es equivalente a exigir
que estén conectados a internet mediante el mismo ISP. Un usuario móvil suele estar a menudo
en una red distinta a la normal de su ISP, y luego descubrir que el envío de correo electrónico
falla porque la elección del servidor SMTP configurado ya no es accesible. Este sistema tiene
distintas variaciones, por ejemplo, el servidor SMTP de la organización sólo puede proporcionar
servicio a los usuarios en la misma red, esto se hace cumplir mediante cortafuegos para bloquear
el acceso de los usuarios en general a través de Internet. O puede que el servicio realice
comprobaciones de alcance en la dirección IP del cliente. Estos métodos son utilizados
normalmente por empresas e instituciones, como las universidades que proporcionan un
servidor SMTP para el correo saliente solo para su uso interno dentro de la organización. Sin
embargo, la mayoría de estos organismos utilizan ahora métodos de autenticación de cliente, tal
como se describe a continuación. Al restringir el acceso a determinadas direcciones IP, los
administradores de servidores pueden reconocer fácilmente la dirección IP de cualquier agresor.
Como esta representa una dirección significativa para ellos, los administradores pueden hacer
frente a la máquina o usuario sospechoso. Cuando un usuario es móvil, y puede utilizar
diferentes proveedores para conectarse a internet, este tipo de restricción de uso es costoso, y
la alteración de la configuración perteneciente a la dirección de correo electrónico del servidor
SMTP saliente resulta ser poco práctica. Es altamente deseable poder utilizar la información de
configuración del cliente de correo electrónico que no necesita cambiar.
Seguridad y spam[editar]
Artículo principal: Antispam
Una de las limitaciones del SMTP original es que no facilita métodos de autenticación a los
emisores, así que se definió la extensión SMTP-AUTH en RFC 2554.
A pesar de esto, el spam es aún el mayor problema. No se cree que las extensiones sean una
forma práctica para prevenirlo. Internet Mail 2000 es una de las propuestas para
reemplazarlo.[cita requerida]
Diferentes metodologías han aparecido para combatir el spam. Entre ellas
destacan DKIM, Sender Policy Framework (SPF) y desde 2012 Domain-based Message
Authentication, Reporting and Conformance (DMARC).6
Los RFC asociados[editar]
• RFC 1123 – Requirements for Internet Hosts—Application and Support (STD 3)
• RFC 1870 – SMTP Service Extension for Message Size Declaration (deja оbsoleto a: RFC
1653)
• RFC 2505 – Anti-Spam Recommendations for SMTP MTAs (BCP 30)
• RFC 2920 – SMTP Service Extension for Command Pipelining (STD 60)
• RFC 3030 – SMTP Service Extensions for Transmission of Large and Binary MIME
Messages
• RFC 3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security
(deja оbsoleto a RFC 2487)
• RFC 3461 – SMTP Service Extension for Delivery Status Notifications (deja оbsoleto
a RFC 1891)
• RFC 3463 – Enhanced Status Codes for SMTP (deja оbsoleto a RFC 1893)
• RFC 3464 – An Extensible Message Format for Delivery Status Notifications (deja
оbsoleto a RFC 1894)
• RFC 3798 – Message Disposition Notification
• RFC 3834 – Recommendations for Automatic Responses to Electronic Mail
• RFC 4952 – Overview and Framework for Internationalized E-mail
• RFC 4954 – SMTP Service Extension for Authentication (deja оbsoleto a RFC 2554)
• RFC 5068 – E-mail Submission Operations: Access and Accountability Requirements
(BCP 134)
• RFC 5321 – The Simple Mail Transfer Protocol (deja оbsoleto a RFC 821 aka STD
10, RFC 974, RFC 1869, RFC 2821)
• RFC 5322 – Internet Message Format (deja оbsoleto a RFC 822 aka STD 11, and RFC
2822)
• RFC 5336 – SMTP Extension for Internationalized Email Addresses (actualiza RFC
2821, RFC 2822 y RFC 4952)
• RFC 5504 – Downgrading Mechanism for Email Address Internationalization
• RFC 6409 – Message Submission for Mail (deja оbsoleto a RFC 4409, RFC 2476)
• RFC 6522 – The Multipart/Report Content Type for the Reporting of Mail System
Administrative Messages (deja оbsoleto a RFC 3462, y a su vez a RFC 1892)

Post Office Protocol (POP)

En informática, el Post Office Protocol (POP), castellanizado Protocolo de la Oficina Postal es un
protocolo estándar de Internet de capa de aplicación que utilizan los clientes de correo electrónico
para recuperar el correo electrónico de un servidor de correo. POP versión 3 (POP3) es la versión de
uso común y, junto con IMAP, los protocolos más comunes para la recuperación de correo electrónico.
Objetivo
El Protocolo de oficina postal proporciona acceso a través de una red de Protocolo de Internet (IP)
para una aplicación de cliente de usuario a un buzón (maildrop) mantenido en un servidor de correo. El
protocolo admite operaciones de descarga y eliminación de mensajes. Los clientes POP3 se conectan,
recuperan todos los mensajes, los almacenan en la computadora del cliente y finalmente los eliminan
del servidor. Este diseño de POP y sus procedimientos fue impulsado por la necesidad de los usuarios
de tener solo conexiones temporales a Internet, como acceso telefónico, lo que les permite recuperar
el correo electrónico cuando están conectados y, posteriormente, ver y manipular los mensajes
recuperados cuando están desconectados.
Los clientes POP3 también tienen la opción de dejar el correo en el servidor después de la descarga.
Por el contrario, el Protocolo de acceso a mensajes de Internet (IMAP) se diseñó para dejar
normalmente todos los mensajes en el servidor para permitir la administración con múltiples
aplicaciones cliente y para admitir modos de operación conectados (en línea) y desconectados (fuera
de línea).
Un servidor POP3 escucha en el conocido puerto número 110 las solicitudes de servicio. La
comunicación cifrada para POP3 se solicita después del inicio del protocolo, mediante el comando
STLS, si es compatible, o mediante POP3S, que se conecta al servidor mediante Transport Layer
Security (TLS) o Secure Sockets Layer (SSL) en el conocido puerto TCP número 995.
Los mensajes disponibles para el cliente se determinan cuando una sesión POP3 abre el buzón y se
identifican por el número de mensaje local para esa sesión o, opcionalmente, por un identificador
único asignado al mensaje por el servidor POP. Este identificador único es permanente y único para el
buzón y permite que un cliente acceda al mismo mensaje en diferentes sesiones POP. El correo se
recupera y se marca para su eliminación por el número de mensaje. Cuando el cliente sale de la sesión,
el correo marcado para su eliminación se elimina del buzón.
Historia
La primera versión del Protocolo de oficina postal, POP1, se especificó en RFC 918 (1984). POP2 se
especificó en RFC 937 (1985).
POP3 es la versión de uso más común. Se originó con RFC 1081 (1988), pero la especificación más
reciente es RFC 1939, actualizada con un mecanismo de extensión (RFC 2449) y un mecanismo de
autenticación en RFC 1734. Esto llevó a una serie de implementaciones POP como Pine, POPmail y
otras primeros clientes de correo.
Si bien la especificación POP3 original solo admitía un mecanismo de inicio de sesión de
USUARIO/PASS sin cifrar o control de acceso Berkeley.rhosts, hoy POP3 admite varios métodos de
autenticación para proporcionar diversos niveles de protección contra el acceso ilegítimo al correo
electrónico de un usuario. La mayoría son proporcionados por los mecanismos de extensión POP3.
Los clientes POP3 admiten métodos de autenticación SASL a través de la extensión AUTH. MIT
Project Athena también produjo una versión Kerberizada. RFC 1460 introdujo APOP en el protocolo
central. APOP es un protocolo de desafío-respuesta que utiliza la función hash MD5 en un intento de
evitar ataques de reproducción y divulgación del secreto compartido. Los clientes que implementan
APOP incluyen Mozilla Thunderbird, Opera Mail, Eudora, KMail, Novell Evolution, RimArts'
Becky!,Windows Live Mail, PowerMail, Apple Mail y Mutt. RFC 1460 quedó obsoleto por RFC 1725,
que a su vez quedó obsoleto por RFC 1939.
POP4
POP4 existe solo como una propuesta informal que agrega administración básica de carpetas, soporte
de mensajes de varias partes, así como administración de banderas de mensajes para competir con
IMAP; sin embargo, su desarrollo no ha progresado desde 2003.
Extensiones y especificaciones
Se propuso un mecanismo de extensión en RFC 2449 para acomodar extensiones generales y
anunciar de manera organizada la compatibilidad con comandos opcionales, como TOP y UIDL. El RFC
no tenía la intención de fomentar las extensiones y reafirmó que la función de POP3 es proporcionar
un soporte simple principalmente para los requisitos de descarga y eliminación del manejo de
buzones.
Las extensiones se denominan capacidades y se enumeran mediante el comando CAPA. Con la
excepción de APOP, los comandos opcionales se incluyeron en el conjunto inicial de capacidades.
Siguiendo el ejemplo de ESMTP (RFC 5321), las capacidades que comienzan con una X significan
capacidades locales.
INICIOTLS
La extensión STARTTLS permite negociar el uso de Transport Layer Security (TLS) o Secure Sockets
Layer (SSL) mediante el comando STLS, en el puerto POP3 estándar, en lugar de un puerto alternativo.
En su lugar, algunos clientes y servidores utilizan el método de puerto alternativo, que utiliza el puerto
TCP 995 (POP3S).
SDPS
Demon Internet introdujo extensiones para POP3 que permiten múltiples cuentas por dominio y se
conoce como Servicio POP3 de acceso telefónico estándar (SDPS). Para acceder a cada cuenta, el
nombre de usuario incluye el nombre de host, como john@hostname o john+hostname.
Google Apps utiliza el mismo método.
Protocolo de oficina de correos Kerberizado
En informática, los clientes de correo electrónico locales pueden utilizar el Protocolo de oficina de
correos Kerberizado (KPOP), un protocolo estándar de Internet de nivel de aplicación, para recuperar
el correo electrónico de un servidor remoto a través de una conexión TCP/IP. El protocolo KPOP se
basa en el protocolo POP3, y se diferencia en que agrega seguridad Kerberos y que se ejecuta de
forma predeterminada en el puerto TCP número 1109 en lugar del 110. Una implementación de
software de servidor de correo se encuentra en el servidor Cyrus IMAP.
Ejemplo de sesión
El siguiente diálogo de sesión POP3 es un ejemplo en RFC 1939:
S: <esperar la conexión en el puerto TCP 110>
C: <abrir conexión>
S: +OK Servidor POP3 listo <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK el maildrop de mrose tiene 2 mensajes (320 octetos)
C: ESTADO
S: +OK 2 320
C: LISTA
S: +OK 2 mensajes (320 octetos)
S: 1 120
S: 2 200
S:.
C: RETR 1
S: +OK 120 octetos
S: <el servidor POP3 envía el mensaje 1>
S:.
C: DELE 1
S: +OK mensaje 1 borrado
C: RETR 2
S: +OK 200 octetos
S: <el servidor POP3 envía el mensaje 2>
S:.
C: DELE 2
S: +OK mensaje 2 borrado
C: SALIR
S: +OK cierre de sesión del servidor POP3 dewey (buzón de correo vacío)
C: <cerrar conexión>
S: <esperar la próxima conexión>
Los servidores POP3 sin el comando APOP opcional esperan que el cliente inicie sesión con los
comandos USER y PASS:
C: USUARIO mrose
S: +OK Usuario aceptado
C: APROBADO tanstaaf
S: +OK Pase aceptado
Comparación con IMAP
El Protocolo de acceso a mensajes de Internet (IMAP) es un protocolo de acceso a buzón alternativo y
más reciente. Los aspectos más destacados de las diferencias son:
• POP es un protocolo más simple, lo que facilita la implementación.
• POP mueve el mensaje del servidor de correo electrónico a la computadora local, aunque
generalmente hay una opción en los clientes de correo electrónico para dejar los mensajes
también en el servidor de correo electrónico. IMAP por defecto deja el mensaje en el servidor
de correo electrónico, simplemente descargando una copia local.
• POP trata el buzón como una sola tienda y no tiene concepto de carpetas
• Un cliente IMAP realiza consultas complejas, solicitando al servidor encabezados o el cuerpo
de mensajes específicos, o para buscar mensajes que cumplan con ciertos criterios. Los
mensajes en el repositorio de correo se pueden marcar con varios indicadores de estado (por
ejemplo, "eliminado" o "respondido") y permanecen en el repositorio hasta que el usuario los
elimine explícitamente, lo que puede no ser hasta una sesión posterior. En resumen: IMAP está
diseñado para permitir la manipulación de buzones remotos como si fueran locales. Según la
implementación del cliente IMAP y la arquitectura de correo deseada por el administrador del
sistema, el usuario puede guardar los mensajes directamente en la máquina del cliente, o
guardarlos en el servidor, o se le puede dar la opción de hacerlo.
• El protocolo POP requiere que el cliente actualmente conectado sea el único cliente conectado
al buzón. Por el contrario, el protocolo IMAP permite específicamente el acceso simultáneo de
varios clientes y proporciona mecanismos para que los clientes detecten los cambios
realizados en el buzón por otros clientes conectados simultáneamente. Consulte, por ejemplo,
la sección 5.2 de RFC3501, que cita específicamente "acceso simultáneo al mismo buzón por
parte de varios agentes" como ejemplo.
• Cuando POP recupera un mensaje, recibe todas sus partes, mientras que el protocolo IMAP4
permite a los clientes recuperar cualquiera de las partes MIME individuales por separado; por
ejemplo, recuperar el texto sin formato sin recuperar los archivos adjuntos.
• IMAP admite banderas en el servidor para realizar un seguimiento del estado del mensaje: por
ejemplo, si el mensaje ha sido leído, respondido, reenviado o eliminado.
Solicitudes de comentarios relacionadas (RFC)
• RFC 918 – PROTOCOLO DE LA OFICINA DE CORREOS
• RFC 937 – PROTOCOLO DE OFICINA DE CORREOS – VERSIÓN 2
• RFC 1081 – Protocolo de oficina de correos – Versión 3
• RFC 1939 - Protocolo de oficina de correos - Versión 3 (STD 53)
• RFC 1957: algunas observaciones sobre las implementaciones del protocolo de oficina postal
(POP3)
• RFC 2195 – IMAP/POP AUTHorize Extension for Simple Challenge/Response
• RFC 2384 – Esquema de URL POP
• RFC 2449 – Mecanismo de extensión POP3
• RFC 2595: uso de TLS con IMAP, POP3 y ACAP
• RFC 3206: los códigos de respuesta SYS y AUTH POP
• RFC 5034: el mecanismo de autenticación simple de autenticación y capa de seguridad (SASL)
del Protocolo de oficina de correos (POP3)
 • RFC 8314: texto sin cifrar considerado obsoleto: uso de la seguridad de la capa de transporte
(TLS) para el envío y el acceso a correos electrónicos
• Te puede interesar

Post Office Protocol (POP)

En informática, el Post Office Protocol (POP), castellanizado Protocolo de la Oficina Postal es un
protocolo estándar de Internet de capa de aplicación que utilizan los clientes de correo electrónico
para recuperar el correo electrónico de un servidor de correo. POP versión 3 (POP3) es la versión de
uso común y, junto con IMAP, los protocolos más comunes para la recuperación de correo electrónico.
Objetivo
El Protocolo de oficina postal proporciona acceso a través de una red de Protocolo de Internet (IP)
para una aplicación de cliente de usuario a un buzón (maildrop) mantenido en un servidor de correo. El
protocolo admite operaciones de descarga y eliminación de mensajes. Los clientes POP3 se conectan,
recuperan todos los mensajes, los almacenan en la computadora del cliente y finalmente los eliminan
del servidor. Este diseño de POP y sus procedimientos fue impulsado por la necesidad de los usuarios
de tener solo conexiones temporales a Internet, como acceso telefónico, lo que les permite recuperar
el correo electrónico cuando están conectados y, posteriormente, ver y manipular los mensajes
recuperados cuando están desconectados.
Los clientes POP3 también tienen la opción de dejar el correo en el servidor después de la descarga.
Por el contrario, el Protocolo de acceso a mensajes de Internet (IMAP) se diseñó para dejar
normalmente todos los mensajes en el servidor para permitir la administración con múltiples
aplicaciones cliente y para admitir modos de operación conectados (en línea) y desconectados (fuera
de línea).
Un servidor POP3 escucha en el conocido puerto número 110 las solicitudes de servicio. La
comunicación cifrada para POP3 se solicita después del inicio del protocolo, mediante el comando
STLS, si es compatible, o mediante POP3S, que se conecta al servidor mediante Transport Layer
Security (TLS) o Secure Sockets Layer (SSL) en el conocido puerto TCP número 995.
Los mensajes disponibles para el cliente se determinan cuando una sesión POP3 abre el buzón y se
identifican por el número de mensaje local para esa sesión o, opcionalmente, por un identificador
único asignado al mensaje por el servidor POP. Este identificador único es permanente y único para el
buzón y permite que un cliente acceda al mismo mensaje en diferentes sesiones POP. El correo se
recupera y se marca para su eliminación por el número de mensaje. Cuando el cliente sale de la sesión,
el correo marcado para su eliminación se elimina del buzón.
Historia
La primera versión del Protocolo de oficina postal, POP1, se especificó en RFC 918 (1984). POP2 se
especificó en RFC 937 (1985).
POP3 es la versión de uso más común. Se originó con RFC 1081 (1988), pero la especificación más
reciente es RFC 1939, actualizada con un mecanismo de extensión (RFC 2449) y un mecanismo de
autenticación en RFC 1734. Esto llevó a una serie de implementaciones POP como Pine, POPmail y
otras primeros clientes de correo.
Si bien la especificación POP3 original solo admitía un mecanismo de inicio de sesión de
USUARIO/PASS sin cifrar o control de acceso Berkeley.rhosts, hoy POP3 admite varios métodos de
autenticación para proporcionar diversos niveles de protección contra el acceso ilegítimo al correo
electrónico de un usuario. La mayoría son proporcionados por los mecanismos de extensión POP3.
Los clientes POP3 admiten métodos de autenticación SASL a través de la extensión AUTH. MIT
Project Athena también produjo una versión Kerberizada. RFC 1460 introdujo APOP en el protocolo
central. APOP es un protocolo de desafío-respuesta que utiliza la función hash MD5 en un intento de
evitar ataques de reproducción y divulgación del secreto compartido. Los clientes que implementan
APOP incluyen Mozilla Thunderbird, Opera Mail, Eudora, KMail, Novell Evolution, RimArts'
Becky!,Windows Live Mail, PowerMail, Apple Mail y Mutt. RFC 1460 quedó obsoleto por RFC 1725,
que a su vez quedó obsoleto por RFC 1939.
POP4
POP4 existe solo como una propuesta informal que agrega administración básica de carpetas, soporte
de mensajes de varias partes, así como administración de banderas de mensajes para competir con
IMAP; sin embargo, su desarrollo no ha progresado desde 2003.
Extensiones y especificaciones
Se propuso un mecanismo de extensión en RFC 2449 para acomodar extensiones generales y
anunciar de manera organizada la compatibilidad con comandos opcionales, como TOP y UIDL. El RFC
no tenía la intención de fomentar las extensiones y reafirmó que la función de POP3 es proporcionar
un soporte simple principalmente para los requisitos de descarga y eliminación del manejo de
buzones.
Las extensiones se denominan capacidades y se enumeran mediante el comando CAPA. Con la
excepción de APOP, los comandos opcionales se incluyeron en el conjunto inicial de capacidades.
Siguiendo el ejemplo de ESMTP (RFC 5321), las capacidades que comienzan con una X significan
capacidades locales.
INICIOTLS
La extensión STARTTLS permite negociar el uso de Transport Layer Security (TLS) o Secure Sockets
Layer (SSL) mediante el comando STLS, en el puerto POP3 estándar, en lugar de un puerto alternativo.
En su lugar, algunos clientes y servidores utilizan el método de puerto alternativo, que utiliza el puerto
TCP 995 (POP3S).
SDPS
Demon Internet introdujo extensiones para POP3 que permiten múltiples cuentas por dominio y se
conoce como Servicio POP3 de acceso telefónico estándar (SDPS). Para acceder a cada cuenta, el
nombre de usuario incluye el nombre de host, como john@hostname o john+hostname.
Google Apps utiliza el mismo método.

Protocolo de oficina de correos Kerberizado

En informática, los clientes de correo electrónico locales pueden utilizar el Protocolo de oficina de
correos Kerberizado (KPOP), un protocolo estándar de Internet de nivel de aplicación, para recuperar
el correo electrónico de un servidor remoto a través de una conexión TCP/IP. El protocolo KPOP se
basa en el protocolo POP3, y se diferencia en que agrega seguridad Kerberos y que se ejecuta de
forma predeterminada en el puerto TCP número 1109 en lugar del 110. Una implementación de
software de servidor de correo se encuentra en el servidor Cyrus IMAP.
Ejemplo de sesión
El siguiente diálogo de sesión POP3 es un ejemplo en RFC 1939:
S: <esperar la conexión en el puerto TCP 110>
C: <abrir conexión>
S: +OK Servidor POP3 listo <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK el maildrop de mrose tiene 2 mensajes (320 octetos)
C: ESTADO
S: +OK 2 320
C: LISTA
S: +OK 2 mensajes (320 octetos)
S: 1 120
S: 2 200
S:.
C: RETR 1
S: +OK 120 octetos
S: <el servidor POP3 envía el mensaje 1>
S:.
C: DELE 1
S: +OK mensaje 1 borrado
C: RETR 2
S: +OK 200 octetos
S: <el servidor POP3 envía el mensaje 2>
S:.
C: DELE 2
S: +OK mensaje 2 borrado
C: SALIR
S: +OK cierre de sesión del servidor POP3 dewey (buzón de correo vacío)
C: <cerrar conexión>
S: <esperar la próxima conexión>
Los servidores POP3 sin el comando APOP opcional esperan que el cliente inicie sesión con los
comandos USER y PASS:
C: USUARIO mrose
S: +OK Usuario aceptado
C: APROBADO tanstaaf
S: +OK Pase aceptado
Comparación con IMAP
El Protocolo de acceso a mensajes de Internet (IMAP) es un protocolo de acceso a buzón alternativo y
más reciente. Los aspectos más destacados de las diferencias son:
• POP es un protocolo más simple, lo que facilita la implementación.
• POP mueve el mensaje del servidor de correo electrónico a la computadora local, aunque
generalmente hay una opción en los clientes de correo electrónico para dejar los mensajes
también en el servidor de correo electrónico. IMAP por defecto deja el mensaje en el servidor
de correo electrónico, simplemente descargando una copia local.
• POP trata el buzón como una sola tienda y no tiene concepto de carpetas
• Un cliente IMAP realiza consultas complejas, solicitando al servidor encabezados o el cuerpo
de mensajes específicos, o para buscar mensajes que cumplan con ciertos criterios. Los
 mensajes en el repositorio de correo se pueden marcar con varios indicadores de estado (por
ejemplo, "eliminado" o "respondido") y permanecen en el repositorio hasta que el usuario los
elimine explícitamente, lo que puede no ser hasta una sesión posterior. En resumen: IMAP está
diseñado para permitir la manipulación de buzones remotos como si fueran locales. Según la
implementación del cliente IMAP y la arquitectura de correo deseada por el administrador del
sistema, el usuario puede guardar los mensajes directamente en la máquina del cliente, o
guardarlos en el servidor, o se le puede dar la opción de hacerlo.
• El protocolo POP requiere que el cliente actualmente conectado sea el único cliente conectado
al buzón. Por el contrario, el protocolo IMAP permite específicamente el acceso simultáneo de
varios clientes y proporciona mecanismos para que los clientes detecten los cambios
realizados en el buzón por otros clientes conectados simultáneamente. Consulte, por ejemplo,
la sección 5.2 de RFC3501, que cita específicamente "acceso simultáneo al mismo buzón por
parte de varios agentes" como ejemplo.
• Cuando POP recupera un mensaje, recibe todas sus partes, mientras que el protocolo IMAP4
permite a los clientes recuperar cualquiera de las partes MIME individuales por separado; por
ejemplo, recuperar el texto sin formato sin recuperar los archivos adjuntos.
• IMAP admite banderas en el servidor para realizar un seguimiento del estado del mensaje: por
ejemplo, si el mensaje ha sido leído, respondido, reenviado o eliminado.
Solicitudes de comentarios relacionadas (RFC)
• RFC 918 – PROTOCOLO DE LA OFICINA DE CORREOS
• RFC 937 – PROTOCOLO DE OFICINA DE CORREOS – VERSIÓN 2
• RFC 1081 – Protocolo de oficina de correos – Versión 3
• RFC 1939 - Protocolo de oficina de correos - Versión 3 (STD 53)
• RFC 1957: algunas observaciones sobre las implementaciones del protocolo de oficina postal
(POP3)
• RFC 2195 – IMAP/POP AUTHorize Extension for Simple Challenge/Response
• RFC 2384 – Esquema de URL POP
• RFC 2449 – Mecanismo de extensión POP3
• RFC 2595: uso de TLS con IMAP, POP3 y ACAP
• RFC 3206: los códigos de respuesta SYS y AUTH POP
• RFC 5034: el mecanismo de autenticación simple de autenticación y capa de seguridad (SASL)
del Protocolo de oficina de correos (POP3)
• RFC 8314: texto sin cifrar considerado obsoleto: uso de la seguridad de la capa de transporte
(TLS) para el envío y el acceso a correos electrónicos
• Te puede interesar

Protocolo de acceso a mensajes de Internet

Ir a la navegaciónIr a la búsqueda
El protocolo de acceso a mensajes de Internet (en inglés Internet Message Access Protocol o IMAP),
es un protocolo de aplicación que permite el acceso a mensajes almacenados en un servidor de
Internet. Mediante IMAP se puede tener acceso al correo electrónico desde cualquier equipo que
tenga una conexión a Internet. IMAP tiene varias ventajas sobre POP (otro protocolo empleado para
obtener correos desde un servidor). Por ejemplo, es posible especificar en IMAP carpetas del lado del
servidor. Por otro lado, es más complejo que POP ya que permite visualizar los mensajes de manera
remota y no descargando los mensajes como lo hace POP.
IMAP y POP3 (Post Office Protocol versión 3) son los dos protocolos que prevalecen en la obtención
de correo electrónico. Todos los servidores y clientes de correo electrónico están virtualmente
soportados por ambos, aunque en algunos casos hay algunas interfaces específicas del fabricante
típicamente propietarias. Por ejemplo, los protocolos propietarios utilizados entre el cliente Microsoft
Outlook y su servidor Microsoft Exchange Server o el cliente Lotus Notes de IBM y el servidor
Domino. Sin embargo, estos productos también soportan interoperabilidad con IMAP y POP3 con
otros clientes y servidores. La versión actual de IMAP, IMAP versión 4 revisión 1 (IMAP4rev1), está
definida por el RFC 3501.
IMAP fue diseñado como una moderna alternativa a POP por Mark Crispin en el año 1986.
Fundamentalmente, los dos protocolos les permiten a los clientes de correo acceder a los mensajes
almacenados en un servidor de correo.
Ya sea empleando POP3 o IMAP4 para obtener los mensajes, los clientes utilizan SMTP para enviar
mensajes. Los clientes de correo electrónico son comúnmente denominados clientes POP o IMAP,
pero en ambos casos se utiliza SMTP
Ventajas sobre POP3[editar]
En la siguiente tabla se recogen las principales ventajas de IMAP con respecto a POP3:}
 Protocolo Ventajas Desventajas
• Trabaja en modo de conexión
permanente, por lo que avisa
inmediatamente de la llegada de
nuevo correo
• Transmite solo las cabeceras por
lo que el usuario puede decidir su • No todos los clientes de correo
borrado inmediato soporta la extensión IMAP IDLE
• La bajada del mensaje se produce (aviso de nuevos correos)
solo cuando el usuario quiere • Necesita una transacción por
leerlo cada correo que se quiera leer
• El almacenamiento local del • Hay un retraso en la aparición
mensaje es opcional (una opción del mensaje en la pantalla del
del cliente de correo) usuario, mientras se descarga
• Gestiona carpetas, plantillas y • Si se pierde la conexión, no se
IMAP4
borradores en el servidor podrá ver el mensaje salvo si el
• El almacenamiento de mensajes cliente de correo lo haya
y carpetas en el servidor permite almacenado en local
su uso desde múltiples • Las carpetas, plantillas y
dispositivos y de forma borradores no podrán ser leídos
simultánea usando POP (excepto la Bandeja
• Permite la búsqueda de mensajes de entrada)
por medio de palabras claves • Todos los mensajes ocupan
• Los mensajes se pueden espacio en disco del servidor.
etiquetar. El marcado queda en el
servidor
• Se pueden crear carpetas
compartidas con otros usuarios
(depende del servidor)
• Sólo se conecta periódicamente
cada X minutos para buscar por
nuevo correo
• La conexión periódica provoca
un aumento del tráfico y un
• Los correos aparecen
retraso en la respuesta del
inmediatamente porque quedan
cliente (esperar la descarga
residentes en el dispositivo (una
completa)
vez descargados)
POP3 • En cada conexión, se baja todos
• Permite ahorrar espacio en el
los correos nuevos, vayan a ser
disco del servidor Si se configura
después leídos o no
para eliminar los mensajes
• Los correos ocupan espacio local
descargados al cliente.
del dispositivo
• Por defecto, elimina los
mensajes del servidor, haciendo
imposible el acceso a ellos desde
otro dispositivo.
Modos de operación conectado y desconectado[editar]
Al utilizar POP, los clientes se conectan brevemente al servidor de correo, solamente el tiempo que les
tome descargar los nuevos mensajes. Al utilizar IMAP4, los clientes permanecen conectados el tiempo
que su interfaz permanezca activa y descargan los mensajes bajo demanda. Esta manera de trabajar de
IMAP puede dar tiempos de respuesta más rápidos para usuarios que tienen una gran cantidad de
mensajes o mensajes grandes.
Conexión de múltiples clientes de forma simultánea a un mismo buzón[editar]
El protocolo POP requiere que el cliente conectado sea el único conectado al buzón. En contraste, el
protocolo IMAP4 permite accesos simultáneos a múltiples clientes y proporciona ciertos mecanismos
a los clientes para que se detecten los cambios hechos a un buzón por parte de otro cliente conectado.
Vea, por ejemplo, el RFC3501, sección 5.2 que, específicamente, dice "accesos simultáneos al mismo
buzón por múltiples agentes".
Acceso a partes MIME de los mensajes y obtención parcial[editar]
Casi todo el correo electrónico de Internet se transmite en formato MIME, permitiendo a los mensajes
tener una estructura en árbol, donde las hojas son de una variedad de tipos de contenidos en una
única parte, y los nodos que no son hojas son de una variedad de tipos multiparte. El protocolo IMAP4
permite a los clientes obtener separadamente cualquier parte MIME individual y también obtener
porciones de las partes individuales o los mensajes completos. Estos mecanismos permiten a los
clientes obtener la porción de texto de un mensaje sin tener que descargar los archivos adjuntos o en
flujos.
Información del estado del mensaje[editar]
A través de la utilización de señales definidas en el protocolo IMAP4, los clientes pueden seguir el
estado del mensaje: por ejemplo, si el mensaje ha sido leído o no, respondido o eliminado. Estas
señales se almacenan en el servidor, de manera que varios clientes conectados al mismo buzón, en
diferentes momentos, pueden detectar los cambios hechos por otros clientes. POP no ofrece ningún
mecanismo para los clientes para que almacenen esta información de estado en el servidor, así que si
un usuario accede a un buzón con dos clientes POP diferentes (en tiempos diferentes), la información
de estado -como si el mensaje ha sido accedido- no puede sincronizarse entre los clientes. El
protocolo IMAP4 soporta tanto el sistema predefinido de señales del sistema, como el de palabras
claves definidas. Las señales del sistema indican la información de estado, tales como si el mensaje ha
sido leído. Las palabras clave, que no se soporta en todos los servidores IMAP, permite que a los
mensajes se les den una o más etiquetas cuyo significado depende del cliente. Las palabras clave
IMAP no deben confundirse con etiquetas propietarias de los servicios de correo basados en web, que
alguna web se traducen en carpetas IMAP por los correspondientes servidores propietarios.
Múltiples buzones en el servidor[editar]
Los clientes de IMAP4 pueden crear, renombrar y/o eliminar buzones (por lo general presentado
como carpetas al usuario) en el servidor, y copiar mensajes entre buzones. El soporte para múltiples
buzones también le permite a los servidores proporcionar acceso a carpetas públicas y compartidas.
La IMAP4 Access Control List (ACL) Extension (RFC 4314) se puede usar para regular los derechos de
acceso.
Búsquedas de parte del servidor[editar]
IMAP4 proporciona un mecanismo para que los clientes pidan al servidor que busque mensajes de
acuerdo a una cierta variedad de criterios. Este mecanismo evita que los clientes descarguen todos los
mensajes de su buzón de correo, agilizando de esta manera las búsquedas.
Mecanismo de extensión[editar]
Como reflejo de la experiencia en los protocolos anteriores de Internet, IMAP define un mecanismo
explícito mediante el cual se puede extender. Se han propuesto muchas extensiones de IMAP4 y son
de uso común. IMAP2bis no tiene ese mecanismo, y POP tiene definido uno en RFC 2449.
Un ejemplo de extensión es el IMAP IDLE, que sirve para que el servidor avise al cliente cuando ha
llegado un nuevo mensaje de correo y éstos se sincronicen. Sin esta extensión, para realizar la misma
tarea, el cliente debería contactar periódicamente al servidor para ver si hay mensajes nuevos.
Versiones de IMAP[editar]
IMAP da acceso al correo electrónico de manera que los clientes pueden guardarse copias locales de
los mensajes (consideradas como una caché temporal). Además, presenta múltiples versiones, entre
las cuales se encuentran: IMAP2, IMAP3, IMAP2bis e IMAP4.
IMAP2[editar]
La versión IMAP2 fue la primera versión de IMAP distribuida públicamente y fue definida en el RFC
1064 en 1988. Más tarde, fue actualizado por el RFC 1176, la misma buscó hacerle frente a la
administración de correo electrónico centralizado que carecía de POP2. En ella se introdujeron
comandos y respuestas de etiquetado.
IMAP3[editar]
IMAP3 es una versión rara del IMAP, fue específicamente una contrapuesta del RFC 1176, la cual fue
definida por el RFC 1203 en los años 1991 pero no fue aceptada por el mercado.
IMAP2 bis[editar]
El protocolo de oficina de correo deja gran parte de la gestión a un usuario que permanece sujeto a
una sola máquina o computadora, si el equipo llega a fallar, se pierden todos sus datos y no se pueden
recuperar los correo electrónicos, debido a esto y con la llegada del MIME se toma la decisión de
ampliar IMAP2 para apoyar el MIME y agregar funciones para las administración de buzones.
Entonces IMAP2 bis considerado una revisión experimental añade estas funcionalidades de crear,
eliminar y guardar como borradores los mensajes en los respectivos buzones.
IMAP4[editar]
El IMAP realizar un cambio en el nombre de IMAP2 bis para evitar confusiones con la propuesta dada
en los años 1991 (IMAP3), la cual fue hecha por un grupo de la competencia que no obtuvo logros con
dicha propuesta, el nuevo nombre dado de IMAP2 bis sería entonces IMAP4. IMAP4 permite a los
clientes de correo electrónico manipular los mensajes de correo electrónico almacenados en el
servidor, como también la manipulación de las carpetas locales. Sin embargo fue revisada puesto que
encontraron o descubrieron fallas en la seguridad. Para el año del 2003 surge IMAP4rev1 que incluyó
las funciones de escuchar los mensajes antes de descargar el cuerpo entero del correo electrónico.

TFTP
Ir a la navegaciónIr a la búsqueda

Trivial File Transfer Protocol

(TFTP)
 Familia Protocolo de red LAN
Función transferencia de archivos
Puertos 69/UDP
Ubicación en la pila de protocolos

Aplicación TFTP
Transporte UDP
Red IP

Estándares
RFC 1350 (1992)
[editar datos en Wikidata]
TFTP son las siglas de Trivial file transfer Protocol (Protocolo de transferencia de archivos trivial).
Es un protocolo de transferencia muy simple semejante a una versión básica de FTP. TFTP a menudo
se utiliza para transferir pequeños archivos entre computadoras en una red, como cuando
un terminal X Window o cualquier otro cliente ligero arranca desde un servidor de red. Surgió a
principios de la década de los 80, por lo que no es precisamente un protocolo reciente, sirve para
regular la transferencia de archivos entre un cliente y un servidor; destaca especialmente por ser
sencillo y simple, por lo que a diferencia de otros protocolos no cuenta con funciones complejas de
transferencia.
Algunos detalles del TFTP:
• Utiliza UDP (en el puerto 69) como protocolo de transporte (a diferencia de FTP que utiliza los
puertos 20 y 21 TCP).
• No puede listar el contenido de los directorios.
• No existen mecanismos de autenticación o cifrado.
• Se utiliza para leer o escribir archivos de un servidor remoto.
• Soporta tres modos diferentes de transferencia, "netascii", "octet" y "mail", de los que los dos
primeros corresponden a los modos "ascii" e "imagen" (binario) del protocolo FTP.

Índice
• 1Funcionamiento
• 2Posibles causas de error
• 3Detalles de una sesión TFTP
• 4Estándares IETF
• 5Véase también
• 6Usos
• 7Enlaces externos
Funcionamiento[editar]
Utiliza generalmente el puerto UDP 69 para realizar la transferencia de archivos, aunque esto lo
pueden cambiar el emisor y receptor. Esta es una diferencia importante respecto a FTP, que utiliza
TCP para la transferencia de archivos y en este caso sí es seguro. La transferencia se realiza bloque a
bloque, el servidor no envía un nuevo bloque hasta que reciba el paquete de confirmación del bloque
anterior. El paquete de datos final se identifica por ser más pequeño del tamaño establecido. Si un
paquete se pierde se generará un timeout, tras el que se efectuará la retransmisión del último
paquete. De esta manera, el emisor del paquete perdido sabrá que tiene que retransmitir dicho
paquete. Cualquier error que ocurra al transferir archivos mediante TFTP da lugar a paquetes de error
que en la mayoría de los casos causan la finalización de la transferencia.
Posibles causas de error[editar]
• No es posible aceptar una solicitud de transferencia: por ejemplo, porque el archivo no se ha
podido encontrar, el usuario no existe o se ha producido una violación de permisos (archivo
protegido, etc.).
• Los clientes o servidores reciben un paquete que no se puede explicar por un retraso o
duplicación en la red: por ejemplo, de paquetes con formato incorrecto.
• Se pierde el acceso a un recurso necesario: por ejemplo, si no hay espacio en el disco duro.
Detalles de una sesión TFTP[editar]
Ya que TFTP utiliza UDP, no hay una definición formal de sesión, cliente y servidor, aunque se
considera servidor a aquel que abre el puerto 69 en modo UDP, y cliente a quien se conecta.
Sin embargo, cada archivo transferido vía TFTP constituye un intercambio independiente de paquetes,
y existe una relación cliente-servidor informal entre la máquina que inicia la comunicación y la que
responde.
• La máquina A, que inicia la comunicación, envía un paquete RRQ (read request/petición de
lectura) o WRQ (write request/petición de escritura) a la máquina B, conteniendo el nombre
del archivo y el modo de transferencia.
 • B responde con un paquete ACK (acknowledgement/confirmación), que también sirve para
informar a A del puerto de la máquina B al que tendrá que enviar los paquetes restantes.
• La máquina origen envía paquetes de datos numerados a la máquina destino, todos excepto el
último conteniendo 512 bytes de datos. La máquina destino responde con paquetes ACK
numerados para todos los paquetes de datos.
• El paquete de datos final debe contener menos de 512 bytes de datos para indicar que es el
último. Si el tamaño del archivo transferido es un múltiplo exacto de 512 bytes, el origen envía
un paquete final que contiene 0 bytes de datos.
Estándares IETF[editar]
RFC
Title Published Author Obsolete and Update Information
Number
The TFTP Protocol
RFC 783 June 1981 K. Sollins Obsoleted by - RFC 1350
(Revision 1)
Bootstrap Loading using Ross
RFC 906 June 1984 -
TFTP Finlayson
Updated by RFC 1395, RFC
RFC 951 Bootstrap Protocol Sep.1985 Bill Croft 1497, RFC 1532, RFC 1542, RFC
5494
Updated by RFC 1782, RFC
RFC The TFTP Protocol
July 1992 K. Sollins 1783, RFC 1784, RFC 1785, RFC
1350 (Revision 2)
2347, RFC 2348, RFC 2349
RFC March
TFTP Option Extension G. Malkin Obsoleted by - RFC 2347
1782 1995
RFC Dynamic Host March Updated by RFC 3396, RFC
R. Droms
2131 Configuration Protocol 1997 4361, RFC 5494, RFC 6842
RFC
TFTP Option Extension May 1998 G. Malkin -
2347
RFC
TFTP Blocksize Option May 1998 G. Malkin -
2348
TFTP Timeout Interval
RFC
and Transfer Size May 1998 G. Malkin -
2349
Options
RFC Principles of Internet
May 2009 B. Aboba -
5505 Host Configuration
RFC TFTP Windowsize
Jan 2015 P. Masotta
7440 Option
USOS:

Dispositivos que no tienen disco duro: Se utiliza también en dispositivos que no tienen un disco
duro para almacenar archivos. Esto permite que TFTP use una pequeña parte de la memoria y
por ejemplo poder arrancar una red o un sistema.
Crear copias de seguridad: Un punto importante a destacar y que permite realizar el protocolo
TFTP es el de crear copias de seguridad. Podemos hacerlo con la configuración de red de un
equipo. Estamos hablando de pequeños archivos que podemos transferir fácilmente y que no va
a ser necesario autenticarnos.
Analizar en busca de virus: Aunque hoy en día es un protocolo mucho menos utilizado y popular
de lo que lo fue hace unas décadas, lo cierto es que TFTP sigue siendo útil cuando se trata de
analizar un equipo para detectar posibles amenazas en forma de malware.
Equipos con poca capacidad: Una de las razones es para aprovechar su sencillez en equipos que
no tengan una gran capacidad y no tener que utilizar muchos recursos para transferir archivos o
poder configurar algo.

FTPS
Ir a la navegaciónIr a la búsqueda
FTPS (comúnmente referido como FTP/SSL) es un nombre usado para abarcar un número de formas
en las cuales el protocolo FTP puede realizar transferencias de ficheros seguras. Cada forma conlleva
el uso de una capa SSL/TLS debajo del protocolo estándar FTP para cifrar los canales de control y/o
datos. No debe confundirse con el protocolo seguro de transferencia de ficheros SFTP, el cual suele
ser usado con SSH.
Para solucionar el problema de la confidencialidad (cifrado de los datos) en la autenticación y en la
transferencia de datos, se decidió añadir una capa de seguridad SSL/TLS al propio protocolo FTP.
FTPS y FTPES también se conocen como FTP over TLS/SSL, y están basados en el propio protocolo
FTP.
El uso más común de FTP y SSL es:
• AUTH TLS o FTPS Explícito, nombrado por el comando emitido para indicar que la seguridad
TLS es obligatoria. Este es el método preferido de acuerdo al RFC que define FTP sobre TLS. El
cliente se conecta al puerto 21 del servidor y comienza una sesión FTP sin cifrar de manera
tradicional, pero pide que la seguridad TLS sea usada y realiza la negociación apropiada antes
de enviar cualquier dato sensible.
• AUTH como está definido en el RFC 2228.
• FTPS Implícito es un estilo antiguo, pero todavía ampliamente implementado en el cual el
cliente se conecta a un puerto distinto (como por ejemplo el 990), y se realiza una negociación
SSL antes de que se envíe cualquier comando FTP.
Funcionamiento[editar]
Cuando se establece una conexión segura a SSL ocurre lo siguiente:
• Se autentica el servidor ante el cliente.
• Se permite al cliente y al servidor seleccionar los algoritmos criptográficos o códigos de cifrado
que son compatibles con ambos.
• Opcionalmente, se autentica al cliente ante el servidor.
• Se utilizan técnicas de cifrado de clave pública para generar secretos compartidos.
Canales de Datos[editar]
La comunicación pueden ser o no ser cifrada en el canal de comandos, en el canal de datos, o más a
menudo en ambos. Si el canal de comandos no se cifra, se dice que el protocolo está usando un canal
de comandos en claro (CCC). Si el canal de datos no está cifrado, se dice que el protocolo usa un canal
de datos en claro (CDC).
Véase también[editar]