You are on page 1of 7

Simple Mail Transfer Protocol

El Simple Mail Transfer Protocol (SMTP) (protocolo para transferencia simple de correo), es un protocolo
de red utilizado para el intercambio de mensajes de
correo electrnico entre computadoras u otros dispositivos (PDA, telfonos mviles, etctera). Fue denido en
el RFC 2821 y es un estndar ocial de Internet.[1]

Mail
exchanger (MX)

MDA

MUA

El funcionamiento de este protocolo se da en lnea, de


manera que opera en los servicios de correo electrnico.
Sin embargo, este protocolo posee algunas limitaciones
en cuanto a la recepcin de mensajes en el servidor de
MTA
MSA
destino (cola de mensajes recibidos). Como alternativa a
esta limitacin se asocia normalmente a este protocolo Modelo de procesamiento del correo
con otros, como el POP o IMAP, otorgando a SMTP la
tarea especca de enviar correo, y recibirlos empleando
los otros protocolos antes mencionados (POP O IMAP). de Correo). En algunas ocasiones, estos dos agentes son
casos diferentes aunque hay que destacar que provienen
del mismo software de donde fueron lanzados slo que
presentan opciones diferentes dentro de la misma mqui1 Historia
na.
En 1982 se dise el primer sistema para intercambiar
correos electrnicos en ARPANET, denido en los Request for comments RFC 821 y RFC 822. La primera de
ellas dene este protocolo y la + SMTP se basa en el modelo cliente-servidor, donde un cliente enva un mensaje a
uno o varios receptores. La comunicacin entre el cliente
y el servidor consiste enteramente en lneas de texto compuestas por caracteres ASCII. El tamao mximo permitido para estas lneas es de 1000 caracteres.[2]

El procesamiento local que se presenta puede ser realizado en una sola mquina 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 congurados para usar la siguiente aplicacin
como un antrin elegante. Para lograr la localizacin del
servidor objetivo, el MTA divisorio tiene que usar el sistema de nombre de dominio (DNS) para lograr la bsqueda del registro interno de cambiado de correo conocido
como registro MX para la esfera del recipiente (la parte
de la direccin a la derecha). Es en ese instante cuando el
registro de MX devuelto contiene el nombre del antrin
objetivo.[cita requerida]

Las respuestas del servidor constan de un cdigo numrico de tres dgitos, seguido de un texto explicativo. El
nmero va dirigido a un procesado automtico de la respuesta por autmata, mientras que el texto permite que
un humano interprete la respuesta. En el protocolo SMTP
todas las rdenes, rplicas o datos son lneas de texto, de- Luego el MTA se une al servidor de cambio como un
limitadas por el carcter <CRLF>. Todas las rplicas tie- cliente SMTP. Una vez que MX acepta el mensaje ennen un cdigo numrico al comienzo de la lnea.[2]
trante, 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, adems de entregar mensajes es tambin
2 Modelo de procesamiento de co- capaz de salvar mensajes en un buzn de formato, y la
recepcin de correo puede ser realizada usando muchas
rreo
computadoras. Hay dos formas en que un MDA puede
entregar mensajes: ya sea envindolos directamente al alEl correo electrnico es presentado por un cliente de co- macenamiento, o expedirlos sobre una red usando SMTP.
rreo (MUA, agente de usuario de correo) a un servidor Una vez entregado al servidor de correo local, dicho code correo (MSA, agente de sumisin de correo) usando rreo es almacenado para la recuperacin de la hornada.
SMTP. Una gran parte de los abastecedores de caja per- Su recuperacin se logra por medio de las aplicaciones
miten la sumisin. Desde all, el MSA entrega el correo de usuario nal, conocidas como clientes de correo eleca su agente de transferencia postal mejor conocido como trnico, usando el Protocolo de Acceso de Mensaje de
el MTA (Mail Transfer Agent, Agente de Transferencia Internet (IMAP), este protocolo que facilita tanto el ac1

DESCRIPCIN DEL PROTOCOLO

ceso para enviar, como el manejo de correo almacenado. sin de secuencias de comandos y el suministro de los
datos necesarios en un canal de ujo de datos ordenado
able, normalmente un protocolo de control de transmi2.1 Puertos
sin de conexin (TCP). Una sesin SMTP consiste en
comandos originados por un cliente SMTP (el agente de
Los administradores de servidor pueden elegir si los inicio, emisor o transmisor) y las respuestas corresponclientes utilizan TCP puerto 25 (SMTP) o el puerto 587 dientes del SMTP del servidor (el agente de escucha, o
(Presentacin) para retransmitir el correo saliente a una receptor) para que la sesin se abra y se intercambian los
inicial del servidor de correo.[3] Las especicaciones y parmetros de la sesin. Una sesin puede incluir cero o
muchos servidores soportan ambos. Aunque algunos ser- ms transacciones SMTP. Una transaccin de SMTP se
vidores soportan el puerto 465 para el legado SMTP segu- compone de tres secuencias de comando / respuesta (varo en violacin de las especicaciones, es preferible uti- se el ejemplo a continuacin).
lizar los puertos estndar y comandos ESMTP estndar
Ellos son:
de acuerdo con RFC 3207, si se debe utilizar una sesin
segura entre el cliente y el servidor.
MAIL: comando para establecer la direccin de reAlgunos servidores estn congurados para rechazar toda
torno, tambin conocido como Return-Path, remila retransmisin en el puerto 25, pero los usuarios vlidos
tente o sobre. Esta es la direccin para mensajes de
de autenticacin en el puerto 587 pueden retransmitir codespedida.
rreo a cualquier direccin vlida.[cita requerida] Algunos pro RCPT: comando, para establecer un destinatario de
veedores de servicios de Internet interceptan el puerto 25,
este mensaje. Este mandato puede emitirse varias
volviendo a dirigir el trco a su propio servidor SMTP,
veces, una para cada destinatario. Estas direcciones
independientemente de la direccin de destino. Esto sigson tambin parte de la envolvente.
nica que no es posible para sus usuarios acceder a un
servidor SMTP fuera de la red del ISP a travs del puerto
DATA: para enviar el mensaje de texto. Este es el
25.
contenido del mensaje, en lugar de su envoltura. Se
Algunos servidores SMTP soportan el acceso autenticacompone de una cabecera de mensaje y el cuerpo
do en otro puerto que no sea 587 o 25 para permitir a los
del mensaje separado por una lnea en blanco. DAusuarios conectarse a ellos, incluso si el puerto 25 est
TA es en realidad un grupo de comandos, y el servibloqueado, pero 587 es el puerto estndar y ampliamendor responde dos veces: una vez para el comando de
te apoyada por los usuarios enviar correo nuevo. Microdatos adecuada, para reconocer que est listo para
soft Exchange Server 2013 SMTP puede escuchar en los
recibir el texto, y la segunda vez despus de la sepuertos 25, 587, 465, 475, y 2525, en funcin de servidor
cuencia nal de los datos, para aceptar o rechazar
y si los roles se combinan en un solo servidor.[cita requerida]
todo el mensaje.
Los puertos 25 y 587 se utilizan para proporcionar la conectividad del cliente con el servicio de transporte en la
parte delantera de la funcin de servidor de acceso de 3.1 Resumen simple del funcionamiento
del protocolo SMTP
cliente (CAS). Los puertos 25, 465 y 475 son utilizados
por el servicio de transporte de buzn de correo. Sin em Cuando un cliente establece una conexin con el serbargo, cuando la funcin de buzn se combina con la funvidor SMTP, espera a que ste enve un mensaje
cin de CAS en un nico servidor, el puerto 2525 se uti220 Service ready o 421 Service non availaliza por la funcin de buzn de SMTP desde el servicio
ble
de transporte de extremo delantero del CAS, CAS, mientras que contina para utilizar el puerto 25. Puerto 465 es
Se enva un HELO desde el cliente. Con ello el serutilizado por el servicio de transporte de buzn de correo
vidor se identica. Esto puede usarse para compropara recibir las conexiones de cliente proxy de la funcin
bar si se conect con el servidor SMTP correcto.
CAS. Puerto 475 es utilizado por la funcin de buzn para comunicarse directamente con otras funciones de bu El cliente comienza la transaccin del correo con
zn, la transferencia de correo entre el servicio de envo
la orden MAIL FROM. Como argumento de
de transporte de buzn de correo y el servicio de entrega
esta orden se puede pasar la direccin de code transporte buzn.[4]
rreo al que el servidor noticar cualquier fallo en el envo del correo (Por ejemplo, MAIL
FROM:<fuente@host0>). Luego si el servidor
comprueba que el origen es vlido, el servidor res3 Descripcin del Protocolo
ponde 250 OK.
SMTP es un protocolo orientado a la conexin basado
en texto, en el que un remitente de correo se comunica
con un receptor de correo electrnico mediante la emi-

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

3.2

Ejemplo de una comunicacin SMTP


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.

3
HELP Permite solicitar informacin sobre un comando.
NOOP Se emplea para reiniciar los temporizadores.

Una vez enviados todos los RCPT, el cliente en TURN Solicita al servidor que intercambien los pava una orden DATA para indicar que a continuapeles.
cin se envan los contenidos del mensaje. El servidor responde 354 Start mail input, end with
De los tres dgitos del cdigo numrico, el primero indica
<CRLF>.<CRLF> Esto indica al cliente como
la categora de la respuesta, estando denidas las siguienha de noticar el n del mensaje.
tes categoras:
Ahora el cliente enva el cuerpo del mensaje, lnea a lnea. Una vez nalizado, se termina con un
2XX, la operacin solicitada mediante el comando
<CRLF>.<CRLF> (la ltima lnea ser un punto),
anterior ha sido concluida con xito
a lo que el servidor contestar 250 OK, o un mensaje de error apropiado.
3XX, la orden ha sido aceptada, pero el servidor esta pendiente de que el cliente le enve nuevos datos
Tras el envo, el cliente, si no tiene que enviar ms
para terminar la operacin
correos, con la orden QUIT corta la conexin. Tambin puede usar la orden TURN, con lo que el clien 4XX, para una respuesta de error, pero se espera a
te pasa a ser el servidor, y el servidor se convierte
que se repita la instruccin
en cliente. Finalmente, si tiene ms mensajes que
enviar, repite el proceso hasta completarlos.
5XX, para indicar una condicin de error permanente, por lo que no debe repetirse la orden
Puede que el servidor SMTP soporte las extensiones denidas en el RFC 1651, en este caso, la orden HELO puede Una vez que el servidor recibe el mensaje nalizado con
ser sustituida por la orden EHLO, con lo que el servidor un punto puede almacenarlo si es para un destinatario que
contestar con una lista de las extensiones admitidas. Si pertenece a su dominio, o bien retransmitirlo a otro serviel servidor no soporta las extensiones, contestar con un dor para que nalmente llegue a un servidor del dominio
mensaje 500 Syntax error, command unrecognized.
del receptor.
En el ejemplo pueden verse las rdenes bsicas de SMTP:
HELO, para abrir una sesin con el servidor

3.2 Ejemplo de una comunicacin SMTP

MAIL FROM, para indicar quien enva el mensaje

En primer lugar se ha de establecer una conexin entre el


emisor (cliente) y el receptor (servidor). Esto puede ha RCPT TO, para indicar el destinatario del mensaje
cerse automticamente con un programa cliente de correo
DATA, para indicar el comienzo del mensaje, ste o mediante un cliente telnet.
nalizar cuando haya una lnea nicamente con un En el siguiente ejemplo se muestra una conexin tpica.
punto.
Se nombra con la letra C al cliente y con S al servidor.
QUIT, para cerrar la sesin

S: 220 Servidor SMTP C: HELO miequipo.midominio.com S: 250 Hello, please to meet you C:
RSET Aborta la transaccin en curso y borra todos MAIL FROM: <yo@midominio.com> S: 250 Ok C:
los registros.
RCPT TO: <destinatario@sudominio.com> S: 250 Ok C:
SEND Inicia una transaccin en la cual el mensaje DATA S: 354 End data with <CR><LF>.<CR><LF> C:
Subject: Campo de asunto C: From: yo@midominio.com
se entrega a una terminal.
C: To: destinatario@sudominio.com C: C: Hola, C: Esto
SOML El mensaje se entrega a un terminal o a un es una prueba. C: Hasta luego. C: C: . S: 250 Ok: queued
as 12345 C: quit S: 221 Bye
buzn.
SAML El mensaje se entrega a un terminal y a un
buzn.
VRFY Solicita al servidor la vericacin de todo un
argumento.

3.3 Formato del mensaje

Como se muestra en el ejemplo anterior, el mensaje es


enviado por el cliente despus de que ste manda la orden
EXPN Solicita al servidor la conrmacin del argu- DATA al servidor. El mensaje est compuesto por dos
mento.
partes:

4
Cabecera: en el ejemplo las tres primeras lneas del
mensaje son la cabecera. En ellas se usan unas palabras clave para denir los campos del mensaje. Estos campos ayudan a los clientes de correo a organizarlos y mostrarlos. Los ms tpicos son subject
(asunto), from (emisor) y to (receptor). stos 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.

CORREO SALIENTE CON SMTP

el protocolo SMTP, al iniciar sesin el cortafuegos o el


servidor pueden bloquear la sesin entrante debido a IP
dinmicas. Slo el servidor ODMR, el proveedor del servicio, debe escuchar las sesiones SMTP en una direccin
de IP ja.

3.7 Internacionalizacin

Muchos usuarios cuyo lenguaje base no es el latn han


tenido dicultades con el requisito de correo electrnico
en Amrica. RFC 6531 fue creado para resolver ese problema, proporcionando caractersticas de internacionalizacin de SMTP, la extensin SMTPUTF8. RFC 6531
proporciona soporte para caracteres de varios bytes y no
para ASCII en las direcciones de correo electrnico. El
3.4 SMTP vs Recuperacin de correo
soporte del internacionalizacin actualmente es limitada
pero hay un gran inters en la ampliacin de el RFC 6531.
El protocolo de transferencia de correo simple (SMTP) RFC en pases como en china, que tiene una gran base de
solo se encarga de entregar el mensaje. En un ambiente usuarios en Amrica.
comn el mensaje es enviado a un servidor de correo de
salto siguiente a medida que llega a su destino. El correo
se enlaza basado en el servidor de destino. Otros protocolos como el protocolo de ocina de correos (POP) y 4 Correo saliente con SMTP
el protocolo de acceso a mensaje de internet (IMAP) su
estructura es para usuarios individuales, recuperacin de Un cliente de correo electrnico tiene que saber la
mensajes, gestin de buzones de correo. SMTP usa una direccin IP de su servidor SMTP inicial y esto tiene que
funcin, el procesamiento de colas de correo en un servi- ser dado como parte de su conguracin (usualmente dador remoto, permite que un servidor de correo de forma da como un nombre DNS). Este servidor enviar mensaintermitente conectado a mandar mensajes desde un ser- jes salientes en nombre del usuario.
vidor remoto. El IMAP y el POP son protocolos inadecuados para la retransmisin de correo de mquinas de
forma intermitente-conectados, sino que estn diseados 4.1 Restriccin de acceso y salida al servipara funcionar despus de la entrega nal.
dor de correo
Cuerpo del mensaje: es el mensaje propiamente
dicho. En el SMTP bsico est compuesto nicamente por texto, y nalizado con una lnea en la que
el nico carcter es un punto.

3.5

Inicio remoto de mensaje en cola

Es una caracterstica 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 envo del comando TURN. Esta caracterstica se considera insegura pero usando el comando
ETRN en la extensin RFC 1985 funciona de forma ms
segura.

3.6

Peticin de Reenvo de Correo Bajo


Demanda (ODMR)

On-Demand Mail Relay (ODMR por sus siglas en Ingls)


es una extensin de SMTP estandarizada en la RFC 2645
que permite que el correo electrnico sea transmitido al
receptor despus de que l ha sido aprobado. Usa la orden de SMTP ampliada ATRN, disponible para la direcciones de IP dinmicas. 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

En un ambiente de servidores, los administradores deben


tomar medidas de control en donde los servidores estn
disponibles para los clientes. Esto permite implementar
seguridad frente a posibles amenazas. Anteriormente, la
mayora de los sistemas imponan restricciones de uso de
acuerdo a la ubicacin del cliente, slo estaba permitido
su uso por aquellos clientes cuya direccin 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 autenticacin mediante credenciales por parte de los clientes antes
de permitir el acceso.

4.2 Restringir el acceso por ubicacin


Mediante este sistema, el servidor SMTP relativo al ISP
no permitir el acceso de los usuarios que estn fuera de la
red del ISP. Especcamente, el servidor solo puede permitir el acceso de aquellos usuarios cuya direccin IP fue
proporcionada por el ISP, lo cual es equivalente a exigir
que estn conectados a internet mediante el mismo ISP.
Un usuario mvil suele estar a menudo en una red distinta a la normal de su ISP, y luego descubrir que el envo

5
de correo electrnico falla porque la eleccin del servidor
SMTP congurado ya no es accesible. Este sistema tiene distintas variaciones, por ejemplo, el servidor SMTP
de la organizacin slo 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 travs de Internet. O puede que el servicio realice
comprobaciones de alcance en la direccin IP del cliente.
Estos mtodos 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 organizacin. Sin embargo, la
mayora de estos organismos utilizan ahora mtodos de
autenticacin de cliente, tal como se describe a continuacin. Al restringir el acceso a determinadas direcciones
IP, los administradores de servidores pueden reconocer
fcilmente la direccin IP de cualquier agresor. Como esta representa una direccin signicativa para ellos, los administradores pueden hacer frente a la mquina o usuario
sospechoso. Cuando un usuario es mvil, y puede utilizar
diferentes proveedores para conectarse a internet, este tipo de restriccin de uso es costoso, y la alteracin de la
conguracin perteneciente a la direccin de correo electrnico del servidor SMTP saliente resulta ser poco prctica. Es altamente deseable poder utilizar la informacin
de conguracin del cliente de correo electrnico que no
necesita cambiar.

7 RFCs asociados
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 Notications (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 Notications (deja bsoleto a RFC
1894)
RFC 3798 Message Disposition Notication

Seguridad y spam

Una de las limitaciones del SMTP original es que no facilita mtodos de autenticacin a los emisores, as que se
deni la extensin SMTP-AUTH en RFC 2554.
A pesar de esto, el spam es an el mayor problema. No
se cree que las extensiones sean una forma prctica para
prevenirlo. Internet Mail 2000 es una de las propuestas
para reemplazarlo.[cita requerida]

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)

Diferentes metodologas han aparecido para combatir el


spam. Entre ellas destacan DKIM, Sender Policy Framework (SPF) y desde el 2012 Domain-based Message Authentication, Reporting and Conformance (DMARC).[5]

RFC 5321 The Simple Mail Transfer Protocol (deja bsoleto a RFC 821 aka STD 10, RFC 974, RFC
1869, RFC 2821)

RFC 5336 SMTP Extension for Internationalized


Email Addresses (actualiza RFC 2821, RFC 2822 y
RFC 4952)

Vase tambin
POP3

RFC 5322 Internet Message Format (deja bsoleto


a RFC 822 aka STD 11, and RFC 2822)

IMAP

RFC 5504 Downgrading Mechanism for Email


Address Internationalization

Mail transfer agent

RFC 6409 Message Submission for Mail (deja bsoleto a RFC 4409, RFC 2476)

Sendmail
DNS
ESMTP

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)

Referencias

[1] Internet Ocial Protocol Standards


[2] Que es SMTP y como funciona
[3] Ver RFC 6409
[4] http://es.kioskea.net/contents/
279-protocolos-de-mensajeria-smtp-pop3-e-imap4.
Falta el |ttulo= (ayuda)
[5] dmarc.org (6 de febrero de 2013). In First Year,
DMARC Protects 60 Percent of Global Consumer Mailboxes (en ingls). Consultado el 26 de febrero de 2014.

Enlaces externos
Email Address Internationalization IETF Working
Group

ENLACES EXTERNOS

10
10.1

Texto e imgenes de origen, colaboradores y licencias


Texto

Simple Mail Transfer Protocol Fuente: http://es.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol?oldid=82853994 Colaboradores:


Trango~eswiki, Moriel, Sauron, JorgeGG, Vanbasten 23, Badjov, Canariocio, Dodo, Sms, Jjmerelo, Tano4595, Murphy era un optimista,
Barcex, Enric Naval, Alejandro Matos, Niqueco, Renabot, FAR, Caos, Boticario, Taichi, RobotQuistnix, Superzerocool, Chobot, Caiserbot,
Yrbot, FlaBot, Vitamine, YurikBot, GermanX, KnightRider, JRGL, Eskimbot, Juan Antonio Cordero, Chlewbot, Lancaster, BOTpolicia,
l, CEM-bot, AlejandroLapeyre, Damifb, Laura Fiorucci, Ignacio Icke, MachuneitorULE, Jjafjjaf, Dorieo, Montgomery, Thijs!bot, Albertomolina, Draugmor, Escarbot, Bryant1410, Mpeinadopa, JAnDbot, Lmartinez, Muro de Aguas, TXiKiBoT, Gacq, Plux, Galaxy4, Yitan007, AlnoktaBOT, Cinevoro, VolkovBot, Technopat, George.bo, Matdrodes, Shooke, Barri, Muro Bot, Edmenb, SieBot, DaBot~eswiki,
Santiago.gomez, Marcecoro, HUB, Arinaga, Botelln, Pan con queso, Jperelli, Alexbot, Apj, AVBOT, Louperibot, MarcoAurelio, DumZiBoT, MelancholieBot, Luckas-bot, Ptbotgourou, Jotterbot, Danielitagal, SuperBraulio13, Xqbot, Jkbw, Rubinbot, FrescoBot, Halfdrag,
PatruBOT, Dinamik-bot, Tarawa1943, GrouchoBot, EmausBot, HRoestBot, KLBot, ChuispastonBot, Diego Moya, Xerox 5B, SaeedVilla,
Bodhost, Jeusamio, Aofvilla, Deepname, Addbot, Jose Guerra G., Frang18, Luis octavio1602, Juandavid2013 y Annimos: 154

10.2

Imgenes

Archivo:SMTP-transfer-model.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/6/69/SMTP-transfer-model.svg Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original: Ale2006-from-en

10.3

Licencia de contenido

Creative Commons Attribution-Share Alike 3.0

You might also like