entendiendo SMTP
734 views
Skip to first unread message
fenix
May 8, 2009, 8:10:36 PM5/8/09
to zimbra grupo
Buenas.
He visto que muchas de las consultas, tanto en la lista como fuera de
ella (por ejemplo, en los propios foros de Zimbra), versan sobre los
errores al enviar correo.
En mi opinión, los técnicos a menudo pecamos de algo: mientras nos
empeñamos en aprender a manejar cosas cada vez más complicadas,
pasamos por alto conocimientos muy simples que nos pueden resultar más
útiles. Como por ejemplo, los protocolos de comunicación. En este caso
SMTP.
Entender un poco SMTP ha sido una de las mejores inversiones que he
podido hacer como técnico, y por eso he decidido tratarlo en este
tema.
Hoy empezamos por los errores.
SMTP funciona mediante peticiones del cliente al servidor. Para cada
petición del cliente (como EHLO, MAIL FROM, RCPT TO...), el servidor
genera una respuesta en forma de código. Si aprendemos a leer esos
códigos, sabremos qué nos dice el servidor con cada operación que
intentamos hacer.
Estos códigos están compuestos de tres dígitos, como 550, 250, 421...
Los que trabajéis con servidores web os daréis cuenta de que esto se
parece mucho a las respuestas de HTTP (no es por casualidad; la idea
es la misma).
Cada dígito significa una cosa, dependiendo de su posición. Así, el
primer dígito representa la reacción del servidor frente a una
petición concreta:
2** El servidor ha procesado la operación que le solicitó el cliente.
3** El servidor está aceptando la petición del cliente, pero le faltan
más datos para procesarla.
4** Respuesta negativa temporal. La petición no se ha procesado, pero
puede volver a realizarse ya que el servidor, técnicamente, puede
atenderla..
5** Respuesta negativa permanente: el servidor nos dice que no puede
procesar esa petición. Intentarlo de nuevo sin solucionar el problema
no servirá de nada.
Sólo con esto ya tenemos una buena base para diagnosticar muchas
incidencias de correo: normalmente, si empieza por 4 ó 5, malo...
Por cierto, la historia del dígito 1 es curiosa: está previsto para
cierto tipo de mensajes, pero la propia naturaleza de SMTP impide que
ese tipo de mensajes pueda existir. Estos romanos están locos ;-)
El segundo dígito nos especifica el porqué del primer dígito:
*0* Nos está diciendo algo sobre la sintaxis de la petición.
Normalmente aparece en errores, aunque el código 200 es el estándar de
OK (no nos dice nada, salvo que ha hecho lo que hemos pedido).
*1* Respuesta a una petición de información (por ejemplo a HELP).
*2* Nos dice algo sobre la conexión.
*3* No se usa.
*4* No se usa.
*5* Se refiere al servidor o al sistema de correo.
Existen también errores 6 y 7 en este dígito, pero están definidos
como mejoras del protocolo en las RFCs 1893 y 2034, y no todos los
servidores de correo los soportan.
El tercer dígito no tiene un significado propio, y simplemente nos
concreta el tipo de respuesta. Muchos códigos están estandarizados, y
este tercer dígito sirve para indicarnos esos errores comunes.
Por ejemplo, tanto el error 451 como el 452 son errores temporales de
servidor: pero el tercer dígito nos indica en el primer caso que ha
habido un error al procesar el correo, y en el segundo, que no se
puede procesar el correo porque no hay espacio en disco.
Todo esto viene definido en las siguientes RFC:
RFC821 (la primera) http://www.faqs.org/rfcs/rfc821.html
RFC2821 http://www.faqs.org/rfcs/rfc2821.html
Y mejorado en:
RFC2034 http://www.rfc-editor.org/rfc/rfc2034.txt
RFC1893 http://www.rfc-editor.org/rfc/rfc1893.txt
También podemos ver una explicación muy sencilla en la Wikipedia:
http://es.wikipedia.org/wiki/SMTP
Y un par de listados de errores y explicaciones sobre el protocolo:
http://www.mailserverblog.com/2008/12/smtp-responses-and-error-codes.html
(incluye explicaciones bonitas del workflow del protocolo).
http://www.greenend.org.uk/rjk/2000/05/21/smtp-replies.html (muy
buena, vienen los errores organizados por los comandos a los que
responden).
http://lo-wiki.acor.org/index.php/SMTP_Error_Codes (explica los
errores más comunes detalladamente).
También he subido a la sección de Archivos del grupo un PDF muy majo
con el listado de errores.
Y eso es todo por hoy. Recomiendo echarle un ojo a la RFC821.
En otro momento deberíamos hablar de los comandos SMTP (a los que
responden los códigos de los que hemos hablado ahora), y sobre todo,
de las cabeceras de los mensajes (interpretarlas puede ser todo un
arte).
Venga, a ver quién se anima.
Saludotes.
He visto que muchas de las consultas, tanto en la lista como fuera de
ella (por ejemplo, en los propios foros de Zimbra), versan sobre los
errores al enviar correo.
En mi opinión, los técnicos a menudo pecamos de algo: mientras nos
empeñamos en aprender a manejar cosas cada vez más complicadas,
pasamos por alto conocimientos muy simples que nos pueden resultar más
útiles. Como por ejemplo, los protocolos de comunicación. En este caso
SMTP.
Entender un poco SMTP ha sido una de las mejores inversiones que he
podido hacer como técnico, y por eso he decidido tratarlo en este
tema.
Hoy empezamos por los errores.
SMTP funciona mediante peticiones del cliente al servidor. Para cada
petición del cliente (como EHLO, MAIL FROM, RCPT TO...), el servidor
genera una respuesta en forma de código. Si aprendemos a leer esos
códigos, sabremos qué nos dice el servidor con cada operación que
intentamos hacer.
Estos códigos están compuestos de tres dígitos, como 550, 250, 421...
Los que trabajéis con servidores web os daréis cuenta de que esto se
parece mucho a las respuestas de HTTP (no es por casualidad; la idea
es la misma).
Cada dígito significa una cosa, dependiendo de su posición. Así, el
primer dígito representa la reacción del servidor frente a una
petición concreta:
2** El servidor ha procesado la operación que le solicitó el cliente.
3** El servidor está aceptando la petición del cliente, pero le faltan
más datos para procesarla.
4** Respuesta negativa temporal. La petición no se ha procesado, pero
puede volver a realizarse ya que el servidor, técnicamente, puede
atenderla..
5** Respuesta negativa permanente: el servidor nos dice que no puede
procesar esa petición. Intentarlo de nuevo sin solucionar el problema
no servirá de nada.
Sólo con esto ya tenemos una buena base para diagnosticar muchas
incidencias de correo: normalmente, si empieza por 4 ó 5, malo...
Por cierto, la historia del dígito 1 es curiosa: está previsto para
cierto tipo de mensajes, pero la propia naturaleza de SMTP impide que
ese tipo de mensajes pueda existir. Estos romanos están locos ;-)
El segundo dígito nos especifica el porqué del primer dígito:
*0* Nos está diciendo algo sobre la sintaxis de la petición.
Normalmente aparece en errores, aunque el código 200 es el estándar de
OK (no nos dice nada, salvo que ha hecho lo que hemos pedido).
*1* Respuesta a una petición de información (por ejemplo a HELP).
*2* Nos dice algo sobre la conexión.
*3* No se usa.
*4* No se usa.
*5* Se refiere al servidor o al sistema de correo.
Existen también errores 6 y 7 en este dígito, pero están definidos
como mejoras del protocolo en las RFCs 1893 y 2034, y no todos los
servidores de correo los soportan.
El tercer dígito no tiene un significado propio, y simplemente nos
concreta el tipo de respuesta. Muchos códigos están estandarizados, y
este tercer dígito sirve para indicarnos esos errores comunes.
Por ejemplo, tanto el error 451 como el 452 son errores temporales de
servidor: pero el tercer dígito nos indica en el primer caso que ha
habido un error al procesar el correo, y en el segundo, que no se
puede procesar el correo porque no hay espacio en disco.
Todo esto viene definido en las siguientes RFC:
RFC821 (la primera) http://www.faqs.org/rfcs/rfc821.html
RFC2821 http://www.faqs.org/rfcs/rfc2821.html
Y mejorado en:
RFC2034 http://www.rfc-editor.org/rfc/rfc2034.txt
RFC1893 http://www.rfc-editor.org/rfc/rfc1893.txt
También podemos ver una explicación muy sencilla en la Wikipedia:
http://es.wikipedia.org/wiki/SMTP
Y un par de listados de errores y explicaciones sobre el protocolo:
http://www.mailserverblog.com/2008/12/smtp-responses-and-error-codes.html
(incluye explicaciones bonitas del workflow del protocolo).
http://www.greenend.org.uk/rjk/2000/05/21/smtp-replies.html (muy
buena, vienen los errores organizados por los comandos a los que
responden).
http://lo-wiki.acor.org/index.php/SMTP_Error_Codes (explica los
errores más comunes detalladamente).
También he subido a la sección de Archivos del grupo un PDF muy majo
con el listado de errores.
Y eso es todo por hoy. Recomiendo echarle un ojo a la RFC821.
En otro momento deberíamos hablar de los comandos SMTP (a los que
responden los códigos de los que hemos hablado ahora), y sobre todo,
de las cabeceras de los mensajes (interpretarlas puede ser todo un
arte).
Venga, a ver quién se anima.
Saludotes.
amperisblog
May 9, 2009, 3:08:48 AM5/9/09
to zimbra grupo
Muy pero que muy bueno.
Se merece una chincheta para que esté arriba el la lista de mensajes.
> RFC1893http://www.rfc-editor.org/rfc/rfc1893.txt
Se merece una chincheta para que esté arriba el la lista de mensajes.
>
> También podemos ver una explicación muy sencilla en la Wikipedia:http://es.wikipedia.org/wiki/SMTP
>
> Y un par de listados de errores y explicaciones sobre el protocolo:
>
> http://www.mailserverblog.com/2008/12/smtp-responses-and-error-codes....
> También podemos ver una explicación muy sencilla en la Wikipedia:http://es.wikipedia.org/wiki/SMTP
>
> Y un par de listados de errores y explicaciones sobre el protocolo:
>
> (incluye explicaciones bonitas del workflow del protocolo).http://www.greenend.org.uk/rjk/2000/05/21/smtp-replies.html(muy
> buena, vienen los errores organizados por los comandos a los que
> responden).http://lo-wiki.acor.org/index.php/SMTP_Error_Codes(explica los
> buena, vienen los errores organizados por los comandos a los que
cejodrake
May 9, 2009, 10:10:39 AM5/9/09
to zimbr...@googlegroups.com
esta muy bueno tu comentario , es bueno tener siempre ese tipo de mensajes q ayudan a la hora de la practica
--
nadie nace aprendido todo en esta vida se aprende
nadie nace aprendido todo en esta vida se aprende
kotaro
Jun 16, 2009, 2:34:06 PM6/16/09
to zimbra grupo
Muy buen aporte,
francamente no había indagado sobre SMTP,
me he quedado anonadado con este comentario,
creo que dejaré un ratito el diseño y el anime y leeré sobre esto,
sobre todo porque ahora me han asignado la sección de servicios a
mi :-)
excelente,
gracias!
francamente no había indagado sobre SMTP,
me he quedado anonadado con este comentario,
creo que dejaré un ratito el diseño y el anime y leeré sobre esto,
sobre todo porque ahora me han asignado la sección de servicios a
mi :-)
excelente,
gracias!
> RFC821 (la primera)http://www.faqs.org/rfcs/rfc821.html
> RFC2821http://www.faqs.org/rfcs/rfc2821.html
>
> Y mejorado en:
> RFC2034http://www.rfc-editor.org/rfc/rfc2034.txt
> RFC1893http://www.rfc-editor.org/rfc/rfc1893.txt
> RFC2821http://www.faqs.org/rfcs/rfc2821.html
>
> Y mejorado en:
> RFC2034http://www.rfc-editor.org/rfc/rfc2034.txt
>
> También podemos ver una explicación muy sencilla en la Wikipedia:http://es.wikipedia.org/wiki/SMTP
>
> Y un par de listados de errores y explicaciones sobre el protocolo:
>
> http://www.mailserverblog.com/2008/12/smtp-responses-and-error-codes....
> También podemos ver una explicación muy sencilla en la Wikipedia:http://es.wikipedia.org/wiki/SMTP
>
> Y un par de listados de errores y explicaciones sobre el protocolo:
>
> (incluye explicaciones bonitas del workflow del protocolo).http://www.greenend.org.uk/rjk/2000/05/21/smtp-replies.html(muy
> buena, vienen los errores organizados por los comandos a los que
> responden).http://lo-wiki.acor.org/index.php/SMTP_Error_Codes(explica los
> buena, vienen los errores organizados por los comandos a los que
Edwind Richzendy Contreras Soto
Jun 16, 2009, 6:14:18 PM6/16/09
to zimbr...@googlegroups.com
El 17 de junio de 2009 14:04, kotaro<wizard...@gmail.com> escribió:
>
> Muy buen aporte,
> francamente no había indagado sobre SMTP,
> me he quedado anonadado con este comentario,
> creo que dejaré un ratito el diseño y el anime y leeré sobre esto,
> sobre todo porque ahora me han asignado la sección de servicios a
> mi :-)
> excelente,
> gracias!
>
Excelente, muchas gracias, siempre es bien recibido un aporte tan bien
>
> Muy buen aporte,
> francamente no había indagado sobre SMTP,
> me he quedado anonadado con este comentario,
> creo que dejaré un ratito el diseño y el anime y leeré sobre esto,
> sobre todo porque ahora me han asignado la sección de servicios a
> mi :-)
> excelente,
> gracias!
>
explicado y tienes razón a veces estas cosas las pasamos por alto y
son básicas para comprender a veces los problemas complejos que nos
pasan.
cardan
Aug 7, 2019, 10:22:36 PM8/7/19
to zimbra grupo
Muchisimas gracias, un gran aporte..
Reply all
Reply to author
Forward
0 new messages