¿Por qué un cliente SMTP enviará un command RSET (Reset)?

Estoy tratando de entender cómo exactamente un correo electrónico es procesado por Postfix – y algunos de los detalles más finos de las transactions de correo SMTP. Mi objective a corto ploop es depurar un cliente SMTP propietario (binary, cerrado), pero primero pensé que examinaría lo que sucede en una transacción SMTP exitosa.

Planeo bloquear SMTP saliente (puerto 25) en nuestro cortafuegos de LAN, así que configuré Postfix como un server de correo interno para aceptar correos de software de cliente local (primitivo) que sólo puede enviar correo electrónico a través de SMTP no autenticado.

smtpd debugging del process smtpd Postfix agregando el indicador -v verbose en master.cf como se describe en Solución de problemas con loggings de Postfix . Luego envié un correo electrónico desde mi propia estación de trabajo usando Cygwin Mutt con sSMTP (una implementación mínima de sendmail ).

Los loggings de Postfix muestran que después de que la línea RCPT TO: se procesó correctamente y la dirección del destinatario fuera aceptable, smtpd de Postfix asignó a la transacción un ID de queue y respondió al cliente SMTP (sSMTP) con 250 OK .

Sin embargo, en lugar de emitir un command DATA , el cliente SMTP emitió un RSET para restablecer / anular la transacción de correo actual y Postfix respondió con un 250 OK .

Hice algunas investigaciones sobre lo que hace este command de command y, como era de esperar, el protocolo de transferencia de correo simple, RFC 2821 proporcionó la información más completa:

Este command especifica que la transacción de correo actual será abortada. Cualquier remitente, destinatarios y datos de correo almacenados DEBEN desecharse, y todos los buffers y tablas de estado se borran. El receptor DEBE enviar una respuesta "250 OK" a un command RSET sin arguments. El cliente puede emitir un command de restablecimiento en cualquier momento. Es efectivamente equivalente a un NOOP (es decir, si no tiene efecto) si se emite inmediatamente después de EHLO, antes de que EHLO se emita en la session, después de que un indicador de fin de datos haya sido enviado y reconocido, o inmediatamente antes de un QUIT. Un server SMTP NO DEBE cerrar la connection como el resultado de recibir un RSET; esa acción está reservada para QUIT (ver sección 4.1.1.10).

Dado que EHLO implica algún procesamiento y respuesta adicionales por el server, RSET normalmente será más eficiente que reeditar ese command, aunque la semántica formal sea la misma.

Existen circunstancias, contrarias a la intención de esta especificación, en las que un server SMTP puede recibir una indicación de que la connection TCP subyacente ha sido cerrada o restablecida. Para preservar la robustez del sistema de correo, serveres SMTP DEBE estar preparados para esta condición y DEBE tratarlo como si un QUIT se había recibido antes de la connection desapareció.

Todo lo anterior ocurrió en el espacio de un segundo por lo que no debería haber problemas con los times muertos.

En el siguiente segundo, el cliente envió otro RSET pero el cliente esperó un total de 10s antes de reiniciar con MAIL FROM: RCPT TO: pero esta vez sigue a través y emite el command DATA y la transacción se completa (todos dentro del mismo segundo segundo a los loggings).

Esencialmente, me pregunto por qué un cliente SMTP interrumpir su propia transacción mediante la emisión de commands RSET lugar de un command DATA .

Notas:

  1. Puedo editar la pregunta para include extracto del file de logging de correo, pero con la debugging -v , son muy detalladas y no quiero abrumar a la gente con una firehose de datos irrelevantes.

  2. Busqué el código fuente sSMTP pero no encontré ninguna mención de RSET .

One Solution collect form web for “¿Por qué un cliente SMTP enviará un command RSET (Reset)?”

TLDR: Respuesta corta

Me había estado preguntando porqué un cliente del smtp interrumpiría su propia transacción emitiendo órdenes de RSET en vez del command de los DATOS. La respuesta corta es que no lo haría; este es un síntoma de las conexiones SMTP que son interceptadas por el software antivirus.

Registro de cliente

Hice clic en la opción de debugging en la configuration de sSMTP, pero tomó algún time para que averiguara cómo instalar y configurar syslog en Cygwin para que los posts de los processs de Cygwin se /var/log/messages lugar del visor de events de Windows.

Sin embargo, sólo registró los primeros commands MAIL FROM: y RCPT TO: no había ninguna indicación de que estos commands se enviaron más de una vez – o que sSMTP alguna vez envió un command RSET .

Como se mencionó en mi pregunta, había comprobado el código fuente sSMTP, pero no hay código para enviar un command RSET .

Symantec Interceptación de tráfico SMTP

El usuario masegaloeh sugirió que el software antivirus puede estar modificando los packages SMTP y tenía razón: desactivé temporalmente Symantec Endpoint Protection en mi computadora y las transactions SMTP procedieron como de costumbre.

Después de volver a habilitar Symantec Endpoint Protection, monitoreé las conexiones TCP usando la utilidad TCPView de Windows Sysinternals y pude ver que el process ccSvcHst.exe Symantec ccSvcHst.exe todo el tráfico TCP cuyo puerto de destino era 25.

Telnetted al puerto 25 en el server del correo (el netcat no trabajaría correctamente, posiblemente debido a la interceptación de Symantec) para enviar un correo de la testing usar manualmente entrando commands del smtp. Al mismo time, tenía otra window de terminal abierta con una connection SSH al host de correo mientras ejecuta sudo tail -F /var/log/maillog para supervisar simultáneamente lo que el server SMTP estaba viendo.

La interceptación realizada por el proxy de Symantec es sutil. Desde la perspectiva del cliente de correo, hay muy poca indicación de que no se está hablando directamente con el server SMTP. La mayoría de los commands se pasan al server de correo a medida que fueron enviados y las respuestas son las que se esperan. No fue hasta que entré en el command DATA , que el proxy de Symantec comenzó a cambiar las cosas: respondió con:

 354 Please start mail input. 

Esto parece normal, pero en realidad, la respuesta de mi server Postfix debería haber sido

 354 End data with <CR><LF>.<CR><LF> 

Además: en realidad no pasó el command DATA a Postfix hasta después de haber completado el cuerpo del post y lo siguió con un QUIT .

Nota: mientras escribía el contenido del post de testing, el proxy de Symantec mantuvo viva su connection con el server Postfix emitiendo commands NOOP .

Tratar con clientes SMTP con errores

Mencioné en mi pregunta que mi objective final era solucionar un cliente propietario (binary, código cerrado) usado por mi organización. He descubierto que este cliente es realmente buggy: envía un inválido HELO command (sin nombre de host) y luego simplemente renuncia y QUITs después de que es cortésmente informado por el server SMTP que su syntax está mal – a pesar de que había configurado Postfix para no requieren un HELO (válido o no).

He resuelto este problema mediante la installation de un nuevo server con CentOS 7 que viene con una versión de Postfix lo suficientemente reciente para que pueda deshabilitar cheques HELO postfix completamente (similar a cómo MS Exchange simplemente ignora HELO inválido commands).

Reset / RSET

También me había estado preguntando sobre el uso general de RSET en transactions de SMTP y encontré lo siguiente en el RFC 821 original para SMTP:

Este command especifica que la transacción de correo actual debe ser abortada. Todos los remitentes, destinatarios y datos de correo almacenados deben ser desechados y todos los buffers y tablas de estado borrados. El receptor debe enviar una respuesta OK.

RSET se utilizaría si resultara que la dirección de correo electrónico del destinatario era para un usuario inexistente. La transacción SMTP siguiente es un ejemplo de un escenario de transacción SMTP anulada .

 R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready S: HELO ISI-VAXA.ARPA R: 250 MIT-Multics.ARPA S: MAIL FROM:<Smith@ISI-VAXA.ARPA> R: 250 OK S: RCPT TO:<Jones@MIT-Multics.ARPA> R: 250 OK S: RCPT TO:<Green@MIT-Multics.ARPA> R: 550 No such user here S: RSET R: 250 OK S: QUIT R: 221 MIT-Multics.ARPA Service closing transmission channel 
  • sSMTP No se puede enviar el post utilizando el server de correo externo SMTP
  • PHP + sSMTP sin locking
  • Impedir que postmaster@domain.com rebote con sSMTP
  • banner de entrega smtp - no puede enviar correos a través de Outlook
  • Xenserver 6.2 no puede enviar alertas usando gmail smtp
  • Centos 5.xx Nagios sSMTP correo no se puede enviar desde el server nagios, pero funciona muy bien desde la console
  • Error de logwatch al enviar correo con ssmtp a SES
  • Registrar todos los posts y contenido (sSMTP)
  • ssmtp - El command de correo no se ha encontrado
  • Logwatch no está respetando MailFrom
  • SSMTP No se puede enviar el mensaje utilizando el servidor de correo externo SMTP
  • sSMTP: No se puede abrir el server smtp
  • ¿Cómo configurar SSMTP para utilizar el nombre de host del host en lugar de hardcoding en ssmtp.conf?
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.