Simple Mail Transfer Protocol

El Simple Mail Transfer Protocol (SMTP) (protoco-lo para transferencia simple de correo), es un protocolode red utilizado para el intercambio de mensajes decorreo electrnico entre computadoras u otros disposi-tivos (PDA, telfonos mviles, etctera). Fue denido enel RFC 2821 y es un estndar ocial de Internet.[1]

El funcionamiento de este protocolo se da en lnea, demanera que opera en los servicios de correo electrnico.Sin embargo, este protocolo posee algunas limitacionesen cuanto a la recepcin de mensajes en el servidor dedestino (cola de mensajes recibidos). Como alternativa aesta limitacin se asocia normalmente a este protocolocon otros, como el POP o IMAP, otorgando a SMTP latarea especca de enviar correo, y recibirlos empleandolos otros protocolos antes mencionados (POP O IMAP).

1 HistoriaEn 1982 se dise el primer sistema para intercambiarcorreos electrnicos en ARPANET, denido en los Re-quest for comments RFC 821 y RFC 822. La primera deellas dene este protocolo y la + SMTP se basa en el mo-delo cliente-servidor, donde un cliente enva un mensaje auno o varios receptores. La comunicacin entre el clientey el servidor consiste enteramente en lneas de texto com-puestas por caracteres ASCII. El tamao mximo permi-tido para estas lneas es de 1000 caracteres.[2]

Las respuestas del servidor constan de un cdigo num-rico de tres dgitos, seguido de un texto explicativo. Elnmero va dirigido a un procesado automtico de la res-puesta por autmata, mientras que el texto permite queun humano interprete la respuesta. En el protocolo SMTPtodas las rdenes, rplicas o datos son lneas de texto, de-limitadas por el carcter . Todas las rplicas tie-nen un cdigo numrico al comienzo de la lnea.[2]

2 Modelo de procesamiento de co-rreo

El correo electrnico es presentado por un cliente de co-rreo (MUA, agente de usuario de correo) a un servidorde correo (MSA, agente de sumisin de correo) usandoSMTP. Una gran parte de los abastecedores de caja per-miten la sumisin. Desde all, el MSA entrega el correoa su agente de transferencia postal mejor conocido comoel MTA (Mail Transfer Agent, Agente de Transferencia

Mailexchanger (MX)

MSA MTA

MDA

MUA

Modelo de procesamiento del correo

de Correo). En algunas ocasiones, estos dos agentes soncasos diferentes aunque hay que destacar que provienendel mismo software de donde fueron lanzados slo quepresentan opciones diferentes dentro de la misma mqui-na.El procesamiento local que se presenta puede ser rea-lizado en una sola mquina o partido entre varias apli-caciones; en este segundo caso, los procesos implicadospueden compartir archivos; aqu SMTP es usado para latransferencia de mensajes internamente, con cada uno delos hosts congurados para usar la siguiente aplicacincomo un antrin elegante. Para lograr la localizacin delservidor objetivo, el MTA divisorio tiene que usar el sis-tema de nombre de dominio (DNS) para lograr la bsque-da del registro interno de cambiado de correo conocidocomo registro MX para la esfera del recipiente (la partede la direccin a la derecha). Es en ese instante cuando elregistro de MX devuelto contiene el nombre del antrinobjetivo.[cita requerida]

Luego el MTA se une al servidor de cambio como uncliente SMTP. Una vez que MX acepta el mensaje en-trante, este a su vez se lo da a un agente de entrega de co-rreo (MDA) para luego ser llevado a la entrega de correolocal. El MDA, adems de entregar mensajes es tambincapaz de salvar mensajes en un buzn de formato, y larecepcin de correo puede ser realizada usando muchascomputadoras. Hay dos formas en que un MDA puedeentregar mensajes: ya sea envindolos directamente al al-macenamiento, o expedirlos sobre una red usando SMTP.Una vez entregado al servidor de correo local, dicho co-rreo es almacenado para la recuperacin de la hornada.Su recuperacin se logra por medio de las aplicacionesde usuario nal, conocidas como clientes de correo elec-trnico, usando el Protocolo de Acceso de Mensaje deInternet (IMAP), este protocolo que facilita tanto el ac-

1

2 3 DESCRIPCIN DEL PROTOCOLO

ceso para enviar, como el manejo de correo almacenado.

2.1 Puertos

Los administradores de servidor pueden elegir si losclientes utilizan TCP puerto 25 (SMTP) o el puerto 587(Presentacin) para retransmitir el correo saliente a unainicial del servidor de correo.[3] Las especicaciones ymuchos servidores soportan ambos. Aunque algunos ser-vidores soportan el puerto 465 para el legado SMTP segu-ro en violacin de las especicaciones, es preferible uti-lizar los puertos estndar y comandos ESMTP estndarde acuerdo con RFC 3207, si se debe utilizar una sesinsegura entre el cliente y el servidor.Algunos servidores estn congurados para rechazar todala retransmisin en el puerto 25, pero los usuarios vlidosde autenticacin en el puerto 587 pueden retransmitir co-rreo a cualquier direccin vlida.[cita requerida] Algunos pro-veedores de servicios de Internet interceptan el puerto 25,volviendo a dirigir el trco a su propio servidor SMTP,independientemente de la direccin de destino. Esto sig-nica que no es posible para sus usuarios acceder a unservidor SMTP fuera de la red del ISP a travs del puerto25.Algunos servidores SMTP soportan el acceso autentica-do en otro puerto que no sea 587 o 25 para permitir a losusuarios conectarse a ellos, incluso si el puerto 25 estbloqueado, pero 587 es el puerto estndar y ampliamen-te apoyada por los usuarios enviar correo nuevo. Micro-soft Exchange Server 2013 SMTP puede escuchar en lospuertos 25, 587, 465, 475, y 2525, en funcin de servidory si los roles se combinan en un solo servidor.[cita requerida]Los puertos 25 y 587 se utilizan para proporcionar la co-nectividad del cliente con el servicio de transporte en laparte delantera de la funcin de servidor de acceso decliente (CAS). Los puertos 25, 465 y 475 son utilizadospor el servicio de transporte de buzn de correo. Sin em-bargo, cuando la funcin de buzn se combina con la fun-cin de CAS en un nico servidor, el puerto 2525 se uti-liza por la funcin de buzn de SMTP desde el serviciode transporte de extremo delantero del CAS, CAS, mien-tras que contina para utilizar el puerto 25. Puerto 465 esutilizado por el servicio de transporte de buzn de correopara recibir las conexiones de cliente proxy de la funcinCAS. Puerto 475 es utilizado por la funcin de buzn pa-ra comunicarse directamente con otras funciones de bu-zn, la transferencia de correo entre el servicio de envode transporte de buzn de correo y el servicio de entregade transporte buzn.[4]

3 Descripcin del ProtocoloSMTP es un protocolo orientado a la conexin basadoen texto, en el que un remitente de correo se comunicacon un receptor de correo electrnico mediante la emi-

sin de secuencias de comandos y el suministro de losdatos necesarios en un canal de ujo de datos ordenadoable, normalmente un protocolo de control de transmi-sin de conexin (TCP). Una sesin SMTP consiste encomandos originados por un cliente SMTP (el agente deinicio, emisor o transmisor) y las respuestas correspon-dientes del SMTP del servidor (el agente de escucha, oreceptor) para que la sesin se abra y se intercambian losparmetros de la sesin. Una sesin puede incluir cero oms transacciones SMTP. Una transaccin de SMTP secompone de tres secuencias de comando / respuesta (va-se el ejemplo a continuacin).Ellos son:

MAIL: comando para establecer la direccin de re-torno, tambin conocido como Return-Path, remi-tente o sobre. Esta es la direccin para mensajes dedespedida.

RCPT: comando, para establecer un destinatario deeste mensaje. Este mandato puede emitirse variasveces, una para cada destinatario. Estas direccionesson tambin parte de la envolvente.

DATA: para enviar el mensaje de texto. Este es elcontenido del mensaje, en lugar de su envoltura. Secompone de una cabecera de mensaje y el cuerpodel mensaje separado por una lnea en blanco. DA-TA es en realidad un grupo de comandos, y el servi-dor responde dos veces: una vez para el comando dedatos adecuada, para reconocer que est listo pararecibir el texto, y la segunda vez despus de la se-cuencia nal de los datos, para aceptar o rechazartodo el mensaje.

3.1 Resumen simple del funcionamientodel protocolo SMTP

Cuando un cliente establece una conexin con el ser-vidor SMTP, espera a que ste enve un mensaje220 Service ready o 421 Service non availa-ble

Se enva unHELO desde el cliente. Con ello el ser-vidor se identica. Esto puede usarse para compro-bar si se conect con el servidor SMTP correcto.

El cliente comienza la transaccin del correo conla orden MAIL FROM. Como argumento deesta orden se puede pasar la direccin de co-rreo al que el servidor noticar cualquier fa-llo en el envo del correo (Por ejemplo, MAILFROM:). Luego si el servidorcomprueba que el origen es vlido, el servidor res-ponde 250 OK.

Ya le hemos dicho al servidor que queremos mandarun correo, ahora hay que comunicarle a quien. La or-den para esto es RCPT TO:. Se

3.2 Ejemplo de una comunicacin SMTP 3

pueden mandar tantas rdenes RCPT como destina-tarios del correo queramos. Por cada destinatario, elservidor contestar 250 OK o bien 550 No suchuser here, si no encuentra al destinatario.

Una vez enviados todos los RCPT, el cliente en-va una orden DATA para indicar que a continua-cin se envan los contenidos del mensaje. El ser-vidor responde 354 Start mail input, end with. Esto indica al cliente comoha de noticar el n del mensaje.

Ahora el cliente enva el cuerpo del mensaje, l-nea a lnea. Una vez nalizado, se termina con un. (la ltima lnea ser un punto),a lo que el servidor contestar 250 OK, o un men-saje de error apropiado.

Tras el envo, el cliente, si no tiene que enviar mscorreos, con la ordenQUIT corta la conexin. Tam-bin puede usar la orden TURN, con lo que el clien-te pasa a ser el servidor, y el servidor se convierteen cliente. Finalmente, si tiene ms mensajes queenviar, repite el proceso hasta completarlos.

Puede que el servidor SMTP soporte las extensiones de-nidas en el RFC 1651, en este caso, la orden HELO puedeser sustituida por la orden EHLO, con lo que el servidorcontestar con una lista de las extensiones admitidas. Siel servidor no soporta las extensiones, contestar con unmensaje 500 Syntax error, command unrecognized.En el ejemplo pueden verse las rdenes bsicas de SMTP:

HELO, para abrir una sesin con el servidor MAIL FROM, para indicar quien enva el mensaje RCPT TO, para indicar el destinatario del mensaje DATA, para indicar el comienzo del mensaje, stenalizar cuando haya una lnea nicamente con unpunto.

QUIT, para cerrar la sesin RSET Aborta la transaccin en curso y borra todoslos registros.

SEND Inicia una transaccin en la cual el mensajese entrega a una terminal.

SOML El mensaje se entrega a un terminal o a unbuzn.

SAML El mensaje se entrega a un terminal y a unbuzn.

VRFY Solicita al servidor la vericacin de todo unargumento.

EXPN Solicita al servidor la conrmacin del argu-mento.

HELP Permite solicitar informacin sobre un co-mando.

NOOP Se emplea para reiniciar los temporizadores.

TURN Solicita al servidor que intercambien los pa-peles.

De los tres dgitos del cdigo numrico, el primero indicala categora de la respuesta, estando denidas las siguien-tes categoras:

2XX, la operacin solicitada mediante el comandoanterior ha sido concluida con xito

3XX, la orden ha sido aceptada, pero el servidor es-ta pendiente de que el cliente le enve nuevos datospara terminar la operacin

4XX, para una respuesta de error, pero se espera aque se repita la instruccin

5XX, para indicar una condicin de error perma-nente, por lo que no debe repetirse la orden

Una vez que el servidor recibe el mensaje nalizado conun punto puede almacenarlo si es para un destinatario quepertenece a su dominio, o bien retransmitirlo a otro servi-dor para que nalmente llegue a un servidor del dominiodel receptor.

3.2 Ejemplo de una comunicacin SMTP

En primer lugar se ha de establecer una conexin entre elemisor (cliente) y el receptor (servidor). Esto puede ha-cerse automticamente con un programa cliente de correoo mediante un cliente telnet.En el siguiente ejemplo se muestra una conexin tpica.Se nombra con la letra C al cliente y con S al servidor.S: 220 Servidor SMTP C: HELO miequi-po.midominio.com S: 250 Hello, please to meet you C:MAIL FROM: S: 250 Ok C:RCPTTO: S: 250OkC:DATA S: 354 End data with . C:Subject: Campo de asunto C: From: yo@midominio.comC: To: destinatario@sudominio.com C: C: Hola, C: Estoes una prueba. C: Hasta luego. C: C: . S: 250 Ok: queuedas 12345 C: quit S: 221 Bye

3.3 Formato del mensaje

Como se muestra en el ejemplo anterior, el mensaje esenviado por el cliente despus de que ste manda la ordenDATA al servidor. El mensaje est compuesto por dospartes:

4 4 CORREO SALIENTE CON SMTP

Cabecera: en el ejemplo las tres primeras lneas delmensaje son la cabecera. En ellas se usan unas pala-bras clave para denir los campos del mensaje. Es-tos campos ayudan a los clientes de correo a orga-nizarlos y mostrarlos. Los ms tpicos son subject(asunto), from (emisor) y to (receptor). stos dosltimos campos no hay que confundirlos con las r-denes MAIL FROM y RCPT TO, que pertenecen alprotocolo, pero no al formato del mensaje.

Cuerpo del mensaje: es el mensaje propiamentedicho. En el SMTP bsico est compuesto nica-mente por texto, y nalizado con una lnea en la queel nico carcter es un punto.

3.4 SMTP vs Recuperacin de correoEl protocolo de transferencia de correo simple (SMTP)solo se encarga de entregar el mensaje. En un ambientecomn el mensaje es enviado a un servidor de correo desalto siguiente a medida que llega a su destino. El correose enlaza basado en el servidor de destino. Otros proto-colos como el protocolo de ocina de correos (POP) yel protocolo de acceso a mensaje de internet (IMAP) suestructura es para usuarios individuales, recuperacin demensajes, gestin de buzones de correo. SMTP usa unafuncin, el procesamiento de colas de correo en un servi-dor remoto, permite que un servidor de correo de formaintermitente conectado a mandar mensajes desde un ser-vidor remoto. El IMAP y el POP son protocolos inade-cuados para la retransmisin de correo de mquinas deforma intermitente-conectados, sino que estn diseadospara funcionar despus de la entrega nal.

3.5 Inicio remoto de mensaje en colaEs una caracterstica de SMTP que permite a un host re-moto para iniciar el procesamiento de la cola de correo enel servidor por lo que puede recibir mensajes destinadosa ella mediante el envo del comando TURN. Esta carac-terstica se considera insegura pero usando el comandoETRN en la extensin RFC 1985 funciona de forma mssegura.

3.6 Peticin de Reenvo de Correo BajoDemanda (ODMR)

On-DemandMail Relay (ODMR por sus siglas en Ingls)es una extensin de SMTP estandarizada en la RFC 2645que permite que el correo electrnico sea transmitido alreceptor despus de que l ha sido aprobado. Usa la or-den de SMTP ampliada ATRN, disponible para la direc-ciones de IP dinmicas. El cliente publica EHLO y r-denes de AUTH de servicios ODMR de correo, ODMRcomienza a actuar como un cliente SMTP y comienza aenviar todos los mensajes dirigidos a un cliente usando

el protocolo SMTP, al iniciar sesin el cortafuegos o elservidor pueden bloquear la sesin entrante debido a IPdinmicas. Slo el servidor ODMR, el proveedor del ser-vicio, debe escuchar las sesiones SMTP en una direccinde IP ja.

3.7 Internacionalizacin

Muchos usuarios cuyo lenguaje base no es el latn hantenido dicultades con el requisito de correo electrnicoen Amrica. RFC 6531 fue creado para resolver ese pro-blema, proporcionando caractersticas de internacionali-zacin de SMTP, la extensin SMTPUTF8. RFC 6531proporciona soporte para caracteres de varios bytes y nopara ASCII en las direcciones de correo electrnico. Elsoporte del internacionalizacin actualmente es limitadapero hay un gran inters en la ampliacin de el RFC 6531.RFC en pases como en china, que tiene una gran base deusuarios en Amrica.

4 Correo saliente con SMTPUn cliente de correo electrnico tiene que saber ladireccin IP de su servidor SMTP inicial y esto tiene queser dado como parte de su conguracin (usualmente da-da como un nombre DNS). Este servidor enviar mensa-jes salientes en nombre del usuario.

4.1 Restriccin de acceso y salida al servi-dor de correo

En un ambiente de servidores, los administradores debentomar medidas de control en donde los servidores estndisponibles para los clientes. Esto permite implementarseguridad frente a posibles amenazas. Anteriormente, lamayora de los sistemas imponan restricciones de uso deacuerdo a la ubicacin del cliente, slo estaba permitidosu uso por aquellos clientes cuya direccin IP es una delas controladas por los administradores del servidor. Losservidores SMTP modernos se caracterizan por ofrecerun sistema alternativo, el cual requiere de una autentica-cin mediante credenciales por parte de los clientes antesde permitir el acceso.

4.2 Restringir el acceso por ubicacin

Mediante este sistema, el servidor SMTP relativo al ISPno permitir el acceso de los usuarios que estn fuera de lared del ISP. Especcamente, el servidor solo puede per-mitir el acceso de aquellos usuarios cuya direccin IP fueproporcionada por el ISP, lo cual es equivalente a exigirque estn conectados a internet mediante el mismo ISP.Un usuario mvil suele estar a menudo en una red distin-ta a la normal de su ISP, y luego descubrir que el envo

5de correo electrnico falla porque la eleccin del servidorSMTP congurado ya no es accesible. Este sistema tie-ne distintas variaciones, por ejemplo, el servidor SMTPde la organizacin slo puede proporcionar servicio a losusuarios en la misma red, esto se hace cumplir mediantecortafuegos para bloquear el acceso de los usuarios en ge-neral a travs de Internet. O puede que el servicio realicecomprobaciones de alcance en la direccin IP del cliente.Estos mtodos son utilizados normalmente por empresase instituciones, como las universidades que proporcionanun servidor SMTP para el correo saliente solo para suuso interno dentro de la organizacin. Sin embargo, lamayora de estos organismos utilizan ahora mtodos deautenticacin de cliente, tal como se describe a continua-cin. Al restringir el acceso a determinadas direccionesIP, los administradores de servidores pueden reconocerfcilmente la direccin IP de cualquier agresor. Como es-ta representa una direccin signicativa para ellos, los ad-ministradores pueden hacer frente a la mquina o usuariosospechoso. Cuando un usuario es mvil, y puede utilizardiferentes proveedores para conectarse a internet, este ti-po de restriccin de uso es costoso, y la alteracin de laconguracin perteneciente a la direccin de correo elec-trnico del servidor SMTP saliente resulta ser poco prc-tica. Es altamente deseable poder utilizar la informacinde conguracin del cliente de correo electrnico que nonecesita cambiar.

5 Seguridad y spamUna de las limitaciones del SMTP original es que no fa-cilita mtodos de autenticacin a los emisores, as que sedeni la extensin SMTP-AUTH en RFC 2554.A pesar de esto, el spam es an el mayor problema. Nose cree que las extensiones sean una forma prctica paraprevenirlo. Internet Mail 2000 es una de las propuestaspara reemplazarlo.[cita requerida]

Diferentes metodologas han aparecido para combatir elspam. Entre ellas destacan DKIM, Sender Policy Frame-work (SPF) y desde el 2012 Domain-basedMessage Aut-hentication, Reporting and Conformance (DMARC).[5]

6 Vase tambin POP3

IMAP

Mail transfer agent

Sendmail

DNS

ESMTP

7 RFCs asociados RFC 1123 Requirements for Internet HostsApplication and Support (STD 3)

RFC 1870 SMTP Service Extension for MessageSize Declaration (deja bsoleto a: RFC 1653)

RFC 2505 Anti-Spam Recommendations forSMTP MTAs (BCP 30)

RFC 2920 SMTP Service Extension for Com-mand Pipelining (STD 60)

RFC 3030 SMTP Service Extensions for Trans-mission of Large and Binary MIME Messages

RFC 3207 SMTP Service Extension for SecureSMTP over Transport Layer Security (deja bsoletoa RFC 2487)

RFC 3461 SMTP Service Extension for DeliveryStatus Notications (deja bsoleto a RFC 1891)

RFC 3463 Enhanced Status Codes for SMTP (dejabsoleto a RFC 1893)

RFC 3464 An Extensible Message Format forDelivery Status Notications (deja bsoleto a RFC1894)

RFC 3798 Message Disposition Notication RFC 3834 Recommendations for Automatic Res-ponses to Electronic Mail

RFC 4952 Overview and Framework for Interna-tionalized E-mail

RFC 4954 SMTP Service Extension for Authen-tication (deja bsoleto a RFC 2554)

RFC 5068 E-mail Submission Operations: Accessand Accountability Requirements (BCP 134)

RFC5321 The SimpleMail Transfer Protocol (de-ja bsoleto a RFC 821 aka STD 10, RFC 974, RFC1869, RFC 2821)

RFC 5322 InternetMessage Format (deja bsoletoa RFC 822 aka STD 11, and RFC 2822)

RFC 5336 SMTP Extension for InternationalizedEmail Addresses (actualiza RFC 2821, RFC 2822 yRFC 4952)

RFC 5504 Downgrading Mechanism for EmailAddress Internationalization

RFC 6409 Message Submission for Mail (deja b-soleto a RFC 4409, RFC 2476)

RFC6522 TheMultipart/Report Content Type forthe Reporting of Mail System Administrative Mes-sages (deja bsoleto a RFC 3462, y a su vez a RFC1892)

6 9 ENLACES EXTERNOS

8 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 Mail-boxes (en ingls). Consultado el 26 de febrero de 2014.

9 Enlaces externos Email Address Internationalization IETF WorkingGroup

710 Texto e imgenes de origen, colaboradores y licencias10.1 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, AlejandroMatos, 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, Al-bertomolina, Draugmor, Escarbot, Bryant1410, Mpeinadopa, JAnDbot, Lmartinez, Muro de Aguas, TXiKiBoT, Gacq, Plux, Galaxy4, Yi-tan007, 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, Dum-ZiBoT, 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 Licen-

cia: 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

Historia Modelo de procesamiento de correo Puertos

Descripcin del Protocolo Resumen simple del funcionamiento del protocolo SMTP Ejemplo de una comunicacin SMTP Formato del mensaje SMTP vs Recuperacin de correo Inicio remoto de mensaje en cola Peticin de Reenvo de Correo Bajo Demanda (ODMR) Internacionalizacin

Correo saliente con SMTP Restriccin de acceso y salida al servidor de correo Restringir el acceso por ubicacin

Seguridad y spam Vase tambin RFCs asociados Referencias Enlaces externos Texto e imgenes de origen, colaboradores y licenciasTextoImgenesLicencia de contenido