5
En teoría, el conjunto de Solicitud de comentarios (RFC) contiene todo lo que un desarrollador necesita saber para construir un cliente SMTP. Sin embargo, no siempre es fácil saber qué RFC deben considerarse y cuáles se pueden ignorar.¿Qué RFCs deben tenerse en cuenta al desarrollar un cliente SMTP?
¿Alguien tiene una hoja de ruta de RFC para dirigir a los desarrolladores a través de esto? Por RFC hoja de ruta, quiero decir:
- Una lista completa de los RFC que necesitan leer y entender, con el fin de desarrollar un cliente SMTP.
- Se debe tener en cuenta qué RFC ya no son , ya que se han reemplazado .
- Un resumen de los RFC relevantes.
- Detalle sobre cómo se relacionan entre sí las RFC pertinentes .
- Una indicación del orden lógico para leer y comprender los pertinentes RFC .
Esa es la razón por la que hice la pregunta. Es muy fácil enfocarse en un RFC, solo para descubrir más tarde que la mayor parte o la totalidad han sido reemplazadas por otro RFC. Luego, por supuesto, está la cuestión del retraso, cuando los servidores SMTP implementan las RFC. Debido a ese retraso en la implementación, a veces es necesario no olvidar lo que está contenido en los RFC antiguos, aunque, en términos de configuración de estándares, han sido reemplazados. –
El beneficio es que estos nuevos RFC aclaran el lenguaje antiguo y son más completos. Ya que solo está creando un cliente SMTP, no un motor de correo no deseado o MTA, esto debería ser todo lo que necesita. Esto se vuelve mucho más complicado si sus escritos dicen un MTA o un motor de spam. Si bien muchas técnicas de anit-spam son públicas, muchas no son – LamonteCristo
Las nuevas versiones también describen en líneas generales lo que ha cambiado y cómo (si es que lo hace) debe adaptarse. Una vez que una antigua RFC ha quedado obsoleta, debería ser bastante seguro adherirse a la nueva. – tripleee