swaks - Online en la nube

PROGRAMA:

NOMBRE

swaks - Swiss Army Knife SMTP, el probador de transacciones smtp de uso múltiple

DESCRIPCIÓN

El objetivo principal del diseño de Swaks es ser una prueba SMTP flexible, programable y orientada a transacciones.
herramienta. Maneja funciones y extensiones SMTP como TLS, autenticación y
canalización; múltiples versiones del protocolo SMTP, incluidos SMTP, ESMTP y LMTP; y
múltiples métodos de transporte, incluidos sockets de dominio Unix, sockets de dominio de Internet y
tuberías a procesos generados. Las opciones se pueden especificar en variables de entorno,
archivos de configuración y la línea de comando que permite la máxima configuración y facilidad de uso
para operadores y scripters.

RÁPIDO EMPIEZA

Envíe un correo electrónico de prueba estándar a [email protected] en el puerto 25 de test-server.example.net:

swaks --a [email protected] --servidor prueba-servidor.ejemplo.net

Entregue un correo electrónico de prueba estándar, que requiera autenticación CRAM-MD5 como usuario [email protected].
Se agregará un encabezado "X-Test" al cuerpo del correo electrónico. La contraseña de autenticación será
solicitado.

swaks --a [email protected] --desde [email protected] --auth CRAM-MD5 --auth-usuario [email protected] --header-X-Test "correo electrónico de prueba"

Pruebe un escáner de virus usando EICAR en un archivo adjunto. No mostrar el mensaje DATOS parte:

swaks-t [email protected] --attach - --server test-server.example.com --suppress-data

Pruebe un escáner de spam usando GTUBE en el cuerpo de un correo electrónico, enrutado a través de los registros MX para
ejemplo.com:

swaks --a [email protected] --cuerpo / ruta / a / gtube / archivo

Envíe un correo electrónico de prueba estándar a [email protected] utilizando el protocolo LMTP a través de UNIX
archivo de socket de dominio

swaks --a [email protected] --socket /var/lda.sock --protocolo LMTP

Informe todos los destinatarios en un archivo de texto que no se pueden verificar en un servidor de prueba:

para E en `cat / path / to / email / file`
do
swaks --to $ E --server test-server.example.com --quit-after RCPT --hide-all
PS -ne 0] && echo $ E
done

CONDICIONES Y Convenciones

Este documento intenta ser coherente y específico en el uso de los siguientes términos para
reducir la confusión.

transacción
Una transacción es la apertura de una conexión a través de un transporte a un objetivo y el uso de un
protocolo de mensajería para intentar entregar un mensaje.

Destino
El objetivo de una transacción es aquello a lo que se conecta Swaks. Este término genérico es
utilizado en toda la documentación porque la mayoría de los otros términos implican incorrectamente algo
sobre el transporte utilizado.

Transporte
El transporte es el método subyacente que se utiliza para conectarse al destino.

Protocolo
El protocolo es el lenguaje de la aplicación que se utiliza para comunicarse con el objetivo. Esta
El documento utiliza SMTP para hablar genéricamente de los tres protocolos admitidos a menos que
afirma que se trata del protocolo específico 'SMTP' y excluye a los demás.

Mensaje
Existen protocolos SMTP para transferir mensajes, un conjunto de bytes en un formato acordado
que tiene un remitente y un destinatario.

Sobre
El sobre de un mensaje contiene el remitente y el receptor "verdadero" de un mensaje. Puede
también se denominarán sus componentes, remitente del sobre y destinatarios del sobre. Está
importante tener en cuenta que un sobre de mensajes no tiene que coincidir con su Para: y De:
encabezados.

DATOS
La parte de DATOS de una transacción SMTP es el mensaje real que se está enviando.
transportado. Consiste tanto en los encabezados como en el cuerpo del mensaje. DATOS y cuerpo
a veces se usan como sinónimos, pero siempre son dos cosas distintas en este
documento.

Cabezales
Los encabezados de un mensaje se definen como todas las líneas en la sección de DATOS del mensaje antes
la primera línea en blanco. Contienen información sobre el correo electrónico que se mostrará.
al destinatario, como Para :, De :, Asunto :, etc. En este documento, los encabezados
siempre debe escribirse con una primera letra en mayúscula y dos puntos al final.

Cuerpo
El cuerpo de un mensaje es la parte de su sección de DATOS que sigue a la primera línea en blanco.

OPCIÓN Tratamiento

Para evitar posibles confusiones en este documento, siempre se hace referencia a un indicador de swaks como
una opción". Si la opción toma datos adicionales, esos datos adicionales se denominan
un argumento a la opción. Por ejemplo, "--desde [email protected]"podría proporcionarse a
cambia en la línea de comando, con "- de" como opción y "[email protected]" ser
- del argumento de From.

Se pueden dar opciones a los swaks de tres formas. Se pueden especificar en una configuración.
archivo, en variables de entorno y en la línea de comando. Dependiendo de la opción específica
y ya sea que se le dé un argumento o no, los swaks pueden solicitar al usuario el argumento.

Cuando swaks evalúa sus opciones, primero busca un archivo de configuración (ya sea en un
ubicación predeterminada o especificada con --config). Luego evalúa las opciones en
Variables de entorno. Finalmente, evalúa las opciones de la línea de comandos. En cada ronda de
procesamiento, se anularán las opciones establecidas anteriormente. Además, cualquier opción puede ser
con el prefijo "no-" para hacer que los swaks olviden que la variable se había establecido previamente.
Esta capacidad es necesaria porque muchas opciones tratan los elementos definidos pero sin argumentos
diferente a no definido.

El mecanismo y formato exactos para usar cada uno de los tipos se enumeran a continuación.

ARCHIVO DE CONFIGURACIÓN
Se puede utilizar un archivo de configuración para establecer opciones de uso común o anormalmente detalladas.
Por defecto, swaks busca $ SWAKS_HOME / .swaksrc, $ HOME / .swaksrc y
$ LOGDIR / .swaksrc. Si se encuentra que existe uno de esos (y no se ha utilizado --config)
ese archivo se utiliza como archivo de configuración.

Además, se puede especificar un archivo de configuración en una ubicación no predeterminada utilizando
--config. Si esto está configurado y no se le da un argumento, los swaks no usarán ningún
archivo de configuración, incluido cualquier archivo predeterminado. Si --config apunta a un legible
archivo, se utiliza como archivo de configuración, anulando cualquier predeterminado que pueda existir. Si
apunta a un archivo no legible y se mostrará el error y se cerrarán los swaks.

También se puede crear un conjunto de valores predeterminados "portátiles" agregando opciones al final de la
archivo de programa swaks. Tal como se distribuye, la última línea de swaks debería ser "__END__". Alguna
las líneas agregadas después de __END__ se tratarán como el contenido de un archivo de configuración.
Esto permite copiar automáticamente un conjunto de preferencias de usuario de un servidor a otro.
en un solo archivo.

Si los archivos presentes y de configuración no se han desactivado explícitamente, el __END__
config siempre se lee. Solo se utilizará otro archivo de configuración por
invocación de swaks, incluso si se especifican varios archivos de configuración. Especificando
la opción --config sin argumento desactiva el procesamiento tanto de __END__
config y cualquier archivo de configuración real.

En un archivo de configuración, las líneas que comienzan con un hash (#) se ignoran. Todas las demás líneas
se supone que son una opción para los cambios, con el guión o guiones iniciales opcionales.
Se supone que todo lo que sigue al primer espacio de una línea de opción es el argumento de la opción
y no se procesa en shell. Por lo tanto, la cotización suele ser innecesaria y será
incluido literalmente en el argumento. A continuación se muestra un ejemplo del contenido de un
archivo de configuración:

# use siempre este remitente, sin importar el servidor o el usuario que haya iniciado sesión
--desde [email protected]
# Prefiero que mis correos electrónicos de prueba tengan un bonito encabezado. Nota
# la falta de guiones en la opción y la falta de comillas alrededor
# argumento completo.
h-De: "Ejemplo de Fred"[email protected]>

VARIABLES DE ENTORNO
Las opciones se pueden suministrar mediante variables de entorno. Las variables están en la forma
$ SWAKS_OPT_name, donde nombre es el nombre de la opción que se especificaría en el
línea de comando. Debido a que los guiones no están permitidos en los nombres de las variables de entorno en la mayoría de
shells unix-ish, no se deben usar guiones iniciales y cualquier guión dentro de la opción
El nombre debe reemplazarse por guiones bajos. Lo siguiente crearía las mismas opciones
mostrado en el ejemplo del archivo de configuración:

$ SWAKS_OPT_from = '[email protected]'
$ SWAKS_OPT_h_From = '"Ejemplo de Fred"[email protected]>'

Establecer una variable en un valor vacío es lo mismo que especificarla en la línea de comando
sin argumento. Por ejemplo, configurar SWAKS_OPT_server = "" provocaría cambios en
solicitar el uso del servidor al que conectarse en cada invocación.

Además de configurar el equivalente a las opciones de la línea de comandos, se puede configurar SWAKS_HOME
a un directorio que contiene el .swaksrc predeterminado que se utilizará.

OPCIONES DE LÍNEA DE COMANDO
El método final de proporcionar opciones a los swaks es a través de la línea de comandos. Las opciones
comportarse de manera coherente con la mayoría de los programas de línea de comandos de Unix. Muchas opciones
tienen una forma corta y larga (por ejemplo, -s y --server). Por convención corta
Las opciones se especifican con un solo guión y las opciones largas se especifican con un doble
pizca. Esto es solo una convención y cualquier prefijo funcionará con cualquier tipo.

A continuación, se muestra el ejemplo que se muestra en el archivo de configuración y el entorno.
secciones variables:

$ swaks --de [email protected] --h-From: '"Ejemplo de Fred"[email protected]>'

TRANSPORTE

los swaks pueden conectarse a un objetivo a través de tuberías Unix ("tuberías"), sockets de dominio Unix ("Unix
sockets "), o sockets de dominio de Internet (" sockets de red "). Conexión a través de sockets de red
es el comportamiento predeterminado. Debido a la naturaleza singular del transporte utilizado, cada conjunto
de opciones en la siguiente sección es mutuamente excluyente. Especificando más de uno de
--server, --pipe o --socket generará un error. Mezclando otras opciones entre
Los tipos de transporte solo darán lugar a que se ignoren las opciones irrelevantes. A continuación se muestra un
Breve descripción de cada tipo de transporte y las opciones que son específicas para ese
tipo de transporte.

TOMAS DE RED
Este transporte intenta entregar un mensaje a través de TCP / IP, el método estándar para
entregando SMTP. Este es el transporte predeterminado para swaks. Si ninguno de --server,
--pipe, o --socket, entonces se usa este transporte y el servidor de destino es
determinado a partir del dominio del destinatario (consulte --server a continuación para obtener más detalles).

Este transporte requiere el módulo IO :: Socket que es parte del estándar perl
distribución. Si este módulo no se puede cargar, intentar utilizar este transporte
dar como resultado un error y la terminación del programa.

Se admite IPv6 cuando está presente el módulo IO :: Socket :: INET6.

-s, --server [servidor de correo de destino [: puerto]]
Dile explícitamente a los swaks que utilicen sockets de red y especifiquen el nombre de host o la IP
dirección a la que conectarse, o preguntar si no se proporciona ningún argumento. Si esta opcion es
no se proporciona y no se proporciona ninguna otra opción de transporte, el servidor de correo de destino es
determinado a partir de los registros DNS apropiados para el dominio del correo electrónico del destinatario
dirección utilizando el módulo Net :: DNS. Si Net :: DNS no está disponible, los swaks
intente conectarse a localhost para entregar. El puerto de destino se puede configurar opcionalmente
aquí. Los formatos admitidos para esto incluyen SERVER: PORT (nombres de soporte e IPv4
direcciones); [SERVIDOR]: PUERTO y SERVIDOR / PUERTO (nombres de apoyo, IPv4 e IPv6
direcciones). Consulte también --copy-routing.

-p, --port [puerto]
Especifique qué puerto TCP en el destino se utilizará, o pregunte si no hay ningún argumento
enumerados. El argumento puede ser un nombre de servicio (recuperado por getservbyname(3)) o
un número de puerto. El puerto predeterminado está determinado por la opción --protocol. Ver
--protocol para más detalles.

-li, --local-interface [IP o nombre de host [: puerto]]
Utilice el argumento como interfaz local para la conexión SMTP saliente o solicite
usuario si no se proporciona ningún argumento. El argumento puede ser una dirección IP o un nombre de host. Defecto
La acción es dejar que el sistema operativo elija la interfaz local. Ver --server para
comentarios adicionales sobre: ​​formato de puerto.

-lp, --local-port [puerto]
Especifique el puerto de salida desde el que originar la transacción. Si esta opcion es
no especificado, el sistema seleccionará un puerto efímero. Tenga en cuenta que los usuarios habituales
no se pueden especificar algunos puertos.

--copy-routing [dominio]
El argumento se interpreta como la parte del dominio de una dirección de correo electrónico y se utiliza
para encontrar el servidor de destino utilizando la misma lógica que se utilizaría para buscar el
servidor de destino para la dirección de correo electrónico de un destinatario. Consulte la opción --to para obtener más detalles
sobre cómo se determina el destino a partir del dominio de correo electrónico.

-4, -6
Forzar IPv4 o IPv6.

TOMAS UNIX
Este método de transporte intenta entregar mensajes a través de un archivo de socket de dominio Unix.
Esto es útil para probar MTA / MDA que escuchan en archivos de socket (por ejemplo, probar
Entrega de LMTP a Cyrus). Este transporte requiere el módulo IO :: Socket que forma parte
de la distribución estándar de Perl. Si este módulo no se puede cargar, intente utilizar
este transporte resultará en un error y la terminación del programa.

--socket [/ ruta / a / socket / archivo]
Esta opción toma como argumento un archivo de socket de dominio Unix. Si swaks no puede
para abrir este socket, mostrará un error y saldrá.

TUBERÍA
Este transporte intenta generar un proceso y comunicarse con él a través de tuberías. los
El programa generado debe estar preparado para comportarse como un servidor de correo sobre STDIN / STDOUT. Alguna
El MTA diseñado para operar desde inet / xinet debería admitir esto. Además, algunos MTA
proporcionan modos de prueba con los que se puede comunicar a través de STDIN / STDOUT. Este transporte
se puede utilizar para automatizar esas pruebas. Por ejemplo, si implementó la verificación DNSBL
con Exim y quería asegurarse de que funcionaba, podía ejecutar 'swaks --pipe
"exim -bh 127.0.0.2" '. En un mundo ideal, el proceso con el que estás hablando debería comportarse
exactamente como un servidor SMTP en stdin y stdout. Cualquier depuración debe enviarse a
stderr, que se dirigirá a su terminal. En el mundo real, los swaks pueden
generalmente maneja algunas depuraciones en la salida estándar del niño, pero no hay garantías sobre cómo
mucho que puede manejar.

Este transporte requiere el módulo IPC :: Open2 que es parte del estándar perl
distribución. Si este módulo no se puede cargar, intentar utilizar este transporte
dar como resultado un error y la terminación del programa.

--pipe [/ ruta / a / comando y argumentos]
Proporcione un nombre de proceso y argumentos para el proceso. los swaks intentarán engendrar
el proceso y comunicarse con él a través de tuberías. Si el argumento no es un
Los swaks ejecutables mostrarán un error y saldrán.

PROTOCOLO OPCIONES

Estas opciones están relacionadas con la capa de protocolo.

-t, --to [dirección de correo electrónico [, dirección de correo electrónico, ...]]
Le dice a los swaks que usen argumento (s) como el destinatario del sobre para el correo electrónico, o solicita
destinatario si no se proporciona ningún argumento. Si se proporcionan varios destinatarios y el
El dominio del destinatario es necesario para determinar el enrutamiento del dominio del último destinatario.
proporcionado se utiliza.

No hay un valor predeterminado para esta opción. Si no se proporcionan destinatarios a través de
significa que se le pedirá al usuario que proporcione uno de forma interactiva. La única excepción a esto
es si se proporciona un valor --quit-after que hará que la transacción smtp sea
terminado antes de que el destinatario sea necesario.

-f, - de [dirección de correo electrónico]
Utilice el argumento como remitente del sobre para el correo electrónico o pregunte al usuario si no se especifica ningún argumento.
La cadena <> se puede proporcionar para indicar el remitente nulo. Si el usuario no especifica un
dirección del remitente se utiliza un valor predeterminado. La parte de dominio del remitente predeterminado es un
la mejor conjetura es el nombre de dominio completo del host local. El método de
la determinación de la parte local varía. En Windows, Win32 :: Nombre de inicio de sesión () se utiliza. En unix
ish plataformas, la variable de entorno $ LOGNAME se utiliza si está configurada. De lo contrario
obtenerpwuid(3) se utiliza. Consulte también --force-getpwuid.

--ehlo, --lhlo, -h, --helo [helo-cadena]
Cadena para usar como argumento para el comando HELO / EHLO / LHLO, o usar el indicador si no hay ningún argumento
especificado. Si esta opción no se usa, una mejor estimación del nombre de dominio completo
del host local. Si el módulo Sys :: Hostname, que es parte de la base
distribución, no está disponible, se le pedirá al usuario un valor HELO. Tenga en cuenta que
Sys :: Se ha observado que el nombre de host no puede encontrar el nombre de host local en ciertos
circunstancias. Esto tiene el mismo efecto que si Sys :: Hostname no estuviera disponible.

-q, --quit-after [punto de parada]
Punto en el que se debe detener la transacción. Cuando el punto de parada solicitado
se alcanza en la transacción, y siempre que los swaks no hayan cometido errores antes de
Al alcanzarlo, los swaks enviarán "SALIR" e intentarán cerrar la conexión limpiamente.
Estos son los argumentos y notas válidos sobre su significado.

CONECTAR, BANNER
Termine la sesión después de recibir el banner de saludo del objetivo.

PRIMERO-HELO, PRIMERO-EHLO, PRIMERO-LHLO
En una sesión STARTTLS (pero no tls-on-connect), finalice la transacción después
el primero de dos HELO. En una transacción que no es STARTTLS, se comporta igual que HELO
(vea abajo).

XCLIENTE
Salir después de que se envíe XCLIENT

TLS Salga de la transacción inmediatamente después de la negociación TLS. Tenga en cuenta que esto
ocurre en diferentes lugares dependiendo de si STARTTLS o tls-on-connect son
usó. Esto siempre se cierra después del punto en el que se habría negociado TLS,
independientemente de si se intentó.

HOLA, EHLO, LHLO
En una sesión de STARTTLS o XCLIENT, salga después del segundo HELO. De lo contrario, sal
después del primer y único HELO.

AUTH
Salir después de la autenticación. Esto siempre se cierra después del punto en el que la autenticación
habría sido negociado, independientemente de si se intentó.

CORREO DE
Salir después de que se envíe MAIL FROM :.

RCPT, A
Salir después de que se envíe RCPT TO :.

--timeout [tiempo]
Utilice el argumento como tiempo de espera de la transacción SMTP o pregunte al usuario si no se proporciona ningún argumento.
El argumento puede ser un dígito puro, que se interpretará como segundos, o puede
tener un especificador so m (5s = 5 segundos, 3m = 180 segundos). Como caso especial, 0
significa que no se agote el tiempo de espera de las transacciones. El valor predeterminado es 30 segundos.

--protocolo [protocolo]
Especifique qué protocolo usar en la transacción. Las opciones válidas se muestran en el
La mesa debajo. Actualmente, los protocolos 'centrales' son SMTP, ESMTP y LMTP. Mediante el uso
variaciones de estos tipos de protocolo, uno puede especificar concisamente los puertos predeterminados, ya sea
Se debe intentar la autenticación y el tipo de conexión TLS que se debe
intentó. El protocolo predeterminado es ESMTP. Esta tabla muestra la disponibilidad
argumentos para --protocol y las opciones que cada uno establece como efecto secundario:

SMTP
HOLA, "-p 25"

SSMTP
EHLO-> HELO, "-tlsc -p 465"

SSMTPA
EHLO-> HELO, "-a -tlsc -p 465"

SMTPS
HOLA, "-tlsc -p 465"

ESMTP
EHLO-> HELO, "-p 25"

ESMTPA
EHLO-> HELO, "-a -p 25"

ESMTPS
EHLO-> HELO, "-tls -p 25"

ESMTPSA
EHLO-> HELO, "-a -tls -p 25"

LMTP
LHLO, "-p 24"

LMTPA
LHLO, "-a -p 24"

LMTPS
LHLO, "-tls -p 24"

LMTPSA
LHLO, "-a -tls -p 24"

--tubería
Si el servidor remoto lo admite, intente SMTP PIPELINING (RFC 2920). Esto es un
opción más joven, si tiene problemas con él, notifique al autor.
Las áreas de problemas potenciales incluyen servidores que aceptan DATOS aunque no haya
destinatarios (los swaks deben enviar un cuerpo vacío en ese caso, no SALIR) y los interbloqueos causados
enviando paquetes fuera del tamaño de la ventana tcp.

--force-getpwuid
Dígale a Swaks que use el método getpwuid para encontrar la parte local del remitente predeterminado en su lugar
de probar $ LOGNAME primero.

TLS / ENCRYPTION

Estas son opciones relacionadas con el cifrado de la transacción. Estos han sido probados y
confirmado para trabajar con los tres métodos de transporte. El módulo Net :: SSLeay se utiliza para
realizar el cifrado cuando se le solicite. Si este módulo no se puede cargar, los swaks tampoco
ignore la solicitud TLS o el error, dependiendo de si la solicitud fue opcional.
STARTTLS se define como una extensión en el protocolo ESMTP y no estará disponible si
--protocol se establece en una variación de smtp. Porque no está definido en el protocolo.
en sí, --tls-on-connect está disponible para cualquier tipo de protocolo si el destino lo admite.

No se requiere un certificado local para negociar una conexión TLS. Sin embargo, algunos
Los servidores utilizan la verificación de certificados de cliente para verificar que el cliente puede conectarse.
Se puede decir a los swaks que utilicen un certificado local específico mediante el uso de --tls-cert
y opciones --tls-key.

-tls
Requiere conexión para usar STARTTLS. Salga si TLS no está disponible por algún motivo (no
anunciados, negociaciones fallidas, etc.).

-tlso, --tls-opcional
Intente usar STARTTLS si está disponible, continúe con la transacción normal si TLS fue
no se puede negociar por ningún motivo. Tenga en cuenta que esta es una opción semi-inútil ya que
implementado actualmente porque después de una falla en la negociación, el estado de la conexión
es desconocido. En algunos casos, como una discrepancia de versión, la conexión debe dejarse como
Texto sin formato. En otros, como una falla de verificación, el lado del servidor puede pensar que
debe continuar hablando TLS mientras el cliente piensa que es texto sin formato. Puede haber un
Intente agregar una detección de estado más granular en el futuro, pero por ahora solo tenga en cuenta
que pueden suceder cosas extrañas con esta opción si se intenta la negociación TLS y
falla.

-tlsos, --tls-opcional-estricto
Intente utilizar STARTTLS si está disponible. Continuar con la transacción si se negocia TLS
exitosamente o STARTTLS no anunciado. Si se anuncia STARTTLS pero TLS
las negociaciones fallan, se tratan como un error y se cancela la transacción. Debido a la advertencia señalada
arriba, esta es una opción mucho más sensata que --tls-optional.

--tlsc, --tls-on-conectar
Inicie una conexión TLS inmediatamente después de la conexión. Siguiendo la convención común, si
Esta opción se especifica, el puerto predeterminado cambia de 25 a 465, aunque esto puede
aún se anulará con la opción --port.

-tlsp, --tls-protocol ESPECIFICACIÓN
Especifique qué protocolos usar (o no usar) al negociar TLS. En el momento de esto
escritura, los protocolos disponibles son sslv2, sslv3, tlsv1, tlsv1_1 y tlsv1_2. los
la disponibilidad de estos protocolos depende de su biblioteca OpenSSL subyacente, por lo que
no todos estos pueden estar disponibles. La lista de protocolos disponibles se muestra en la
salida de --dump (suponiendo que TLS esté disponible).

La cadena de especificación es una lista delimitada por comas de protocolos que se pueden utilizar o
no utilizado. Por ejemplo, 'tlsv1, tlsv1_1' solo tendrá éxito si uno de esos dos
protocolos está disponible tanto en el cliente como en el servidor. En cambio,
'no_sslv2, no_sslv3' intentará negociar cualquier protocolo excepto sslv2 y sslv3.
Las dos formas de especificación no se pueden mezclar.

-tls-cipher CIPHER_STRING
El argumento de esta opción se pasa a la biblioteca OpenSSL subyacente para establecer la lista.
de cifrados aceptables que se utilizarán para la conexión. El formato de esta cadena es
opaco a los hisopos y se define en
http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT. Un breve ejemplo
sería --tls-cipher '3DES: + RSA'.

--tls-verificar
De forma predeterminada, Swaks no realiza ninguna verificación de certificado. Configuración de --tls-verify will
provocar que los swaks intenten verificar el certificado del servidor. Si esta opción está configurada y
el certificado del servidor no es verificable (ya sea usando la CA predeterminada del sistema
información o información de CA personalizada (consulte --tls-ca-path)) La negociación de TLS no
tener éxito.

--tls-ca-path [/ ruta / al / CAfile | / ruta / a / CAdir /]
De forma predeterminada, los swaks utilizarán la información de CA predeterminada de la biblioteca OpenSSL subyacente para
verificación de certificados de servidor. --tls-ca-path le permite especificar una alternativa
localización. Ver http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html para
detalles del contenido del archivo / directorio.

--tls-cert / ruta / a / archivo
Proporcione una ruta a un archivo que contenga los intercambios de certificados locales que deben usar si TLS es
negociado. El argumento de la ruta del archivo es obligatorio. Tal como está implementado actualmente,
El certificado en el archivo debe estar en formato PEM. Póngase en contacto con el autor si hay un
necesidad imperiosa de ASN1. Si se establece esta opción, también se requiere --tls-key.

--tls-key / ruta / a / archivo
Proporcione una ruta a un archivo que contenga la clave privada local que los swaks deben usar si TLS es
negociado. El argumento de la ruta del archivo es obligatorio. Tal como está implementado actualmente,
El certificado en el archivo debe estar en formato PEM. Póngase en contacto con el autor si hay un
necesidad imperiosa de ASN1. Si se establece esta opción, también se requiere --tls-cert.

--tls-get-peer-cert [/ ruta / a / archivo]
Obtenga una copia del certificado del par TLS. Si no se da ningún argumento, será
mostrado en STDOUT. Si se da un argumento, se asume que es una ruta del sistema de archivos
especificando dónde debe escribirse el certificado. El certificado guardado se puede
examinado utilizando herramientas estándar como el comando openssl. Si se especifica un archivo, su
se sobrescribirá el contenido.

AUTENTICACIÓN

Swaks intentará autenticarse en el servidor de correo de destino si se le indica que lo haga. Esta
sección detalla los tipos de autenticación disponibles, los requisitos, las opciones y sus
interacciones y otros puntos finos en el uso de la autenticación. Porque la autenticación es
definido como una extensión en el protocolo ESMTP, no estará disponible si --protocol está configurado
a una variación de smtp.

Todos los métodos de autenticación requieren codificación base64. Si el módulo perl MIME :: Base64 es
swaks cargables intenta utilizarlo para realizar estas codificaciones. Si MIME :: Base64 no es
Los swaks disponibles utilizarán sus propias rutinas base64 integradas. Estos son más lentos que los
Rutinas MIME :: Base64 y menos revisadas, aunque han sido probadas a fondo. Utilizando
Se recomienda el módulo MIME :: Base64.

Si se requiere autenticación (consulte las opciones a continuación para saber cuándo se requiere y cuándo no) y
no se cumplen los requisitos para el tipo de autenticación disponible, swaks muestra un error
y salidas. Dos formas en que esto puede suceder incluyen forzar a los swaks a usar un
tipo de autenticación que los swaks no pueden usar debido a que faltan requisitos o que permiten que los
use cualquier tipo de autenticación, pero el servidor solo anuncia tipos que los swaks no pueden admitir. En
el primer caso intercambia errores en el tiempo de procesamiento de la opción, ya que lo sabe de antemano
no podrá autenticarse. En el último caso, los swaks generarán un error en el
etapa de autenticación de la transacción smtp, ya que los swaks no se darán cuenta de que
no podrá autenticarse hasta ese momento.

A continuación se muestran los tipos de autenticación admitidos, incluidas las notas individuales y
• Requisitos.

Las siguientes opciones afectan el uso de autenticación de los swaks. Todas estas opciones son
relacionado. Por ejemplo, especificar --auth-user implica --auth y --auth-password.
Especificar --auth-optional implica --auth-user y --auth-password, etc.

-a, --auth [auth-type [, auth-type, ...]]
Requerir que los swaks se autentiquen. Si no se proporciona ningún argumento, los tipos de autenticación admitidos
anunciados por el servidor se prueban hasta que uno tiene éxito o todos fallan. Si uno o más
Los tipos de autenticación se especifican como un argumento, cada uno que el servidor también admite se prueba
en orden hasta que uno tenga éxito o todos fracasen. Esta opción requiere swaks para autenticarse,
por lo tanto, si no se encuentran tipos de autenticación comunes o no se realizan correctamente las credenciales, swaks muestra un
error y salidas.

Las siguientes tablas enumeran los tipos de autenticación válidos

INICIAR SESIÓN, SIMPLE
Estos tipos de autenticación básica son totalmente compatibles y probados y no tienen
requerimientos adicionales

CRAM-MD5
El autenticador CRAM-MD5 requiere el módulo Digest :: MD5. Está completamente probado
y se cree que funciona contra cualquier servidor que lo implemente.

DIGESTIÓN-MD5
El autenticador DIGEST-MD5 (RFC2831) requiere el módulo Authen :: SASL. Versión
20100211.0 y anteriores usaban Authen :: DigestMD5 que tenía algunos errores de nivel de protocolo
lo que le impedía trabajar con algunos servidores. Authen :: DIGEST-MD5 de SASL
el manejo es mucho más robusto.

La implementación de DIGEST-MD5 en swaks es bastante inmadura. Actualmente es compatible
sólo el tipo qop "auth", por ejemplo. Si tiene experiencia con DIGEST-MD5 y
quisiera ayudar a los swaks a soportar mejor DIGEST-MD5, por favor contácteme.

El valor de "reino" del protocolo DIGEST-MD5 se puede configurar usando --auth-extra "realm"
palabra clave. Si no se da ningún reino, se utilizará un valor predeterminado razonable.

Los valores "digest-uri" del protocolo DIGEST-MD5 se pueden configurar usando --auth-extra
opción. Por ejemplo, puede crear el valor digest-uri de
"lmtp / mail.example.com / example.com" con la opción "--auth-extra
dmd5-serv-type = lmtp, dmd5-host = mail.example.com, dmd5-serv-name = example.com ".
La cadena "digest-uri-value" y sus componentes se definen en RFC2831. Si ninguno de
se dan estos valores, se utilizarán valores predeterminados razonables.

CRAM-SHA1
El autenticador CRAM-SHA1 requiere el módulo Digest :: SHA. Este tipo solo tiene
ha sido probado contra una implementación no estándar en un servidor Exim y puede
por lo tanto, tienen algunas deficiencias en la implementación.

NTLM / SPA / MSN
Estos autenticadores requieren el módulo Authen :: NTLM. Tenga en cuenta que hay dos
módulos que utilizan el espacio de nombres Authen :: NTLM en CPAN. La implementación de Mark Bush
(Authen / NTLM-1.03.tar.gz) es la versión requerida por los swaks. Este tipo ha sido
probado contra Exim, Communigate y Exchange 2007.

Además del nombre de usuario y la contraseña estándar, este tipo de autenticación puede
también reconoce un "dominio". El dominio se puede configurar usando el "dominio" --auth-extra
palabra clave. Tenga en cuenta que esto nunca se ha probado con un servidor de correo que no
ignore DOMAIN por lo que esto puede implementarse incorrectamente.

-ao, --auth-opcional [auth-type [, auth-type, ...]]
Esta opción se comporta de manera idéntica a --auth excepto que solicita autenticación
en lugar de requerirlo. Si no se encuentran tipos de autenticación comunes o no hay credenciales
correctamente, los swaks proceden como si no se hubiera solicitado la autenticación.

-aos, --auth-opcional-estricto [auth-type [, auth-type, ...]]
Esta opción es un compromiso entre --auth y --auth-optional. Si no hay autorizacin comn
se encuentran los tipos, los swaks se comportan como si se especificara --auth-optional y continúa con
la transacción. Si los swaks no pueden admitir el tipo de autenticación solicitado, el servidor no
anunciar cualquier tipo de autenticación común, o si ninguna credencial tiene éxito, los swaks se comportan como si
--auth se usaron y sale con un error.

-au, --auth-user [nombre de usuario]
Proporcione el nombre de usuario que se utilizará para la autenticación o solicítelo al usuario si no
se proporciona el argumento. La cadena <> se puede proporcionar para indicar un nombre de usuario vacío.

-ap, --auth-password [contraseña]
Proporcione la contraseña que se utilizará para la autenticación o solicítela al usuario si no
se proporciona el argumento. La cadena <> se puede proporcionar para indicar una contraseña vacía.

-ae, --auth-extra [PALABRA CLAVE = valor [, ...]]
Algunos de los tipos de autenticación permiten incluir información adicional en la
proceso de autenticación. En lugar de agregar una nueva opción para cada rincón y grieta de
cada autenticador, la opción --auth-extra permite suministrar esta información.

La siguiente tabla enumera las palabras clave reconocidas actualmente y los autenticadores
que los usan

reino, dominio
Las palabras clave de reino y de dominio son sinónimos. El uso de cualquiera establecerá el "dominio"
opción en NTLM / MSN / SPA y la opción "reino" en DIGEST-MD5

tipo-serv-dmd5
El autenticador DIGEST-MD5 utiliza la palabra clave dmd5-serv-type y se utiliza en
part, para construir la cadena digest-uri-value (ver RFC2831)

host dmd5
El autenticador DIGEST-MD5 utiliza la palabra clave dmd5-host y se utiliza en
part, para construir la cadena digest-uri-value (ver RFC2831)

nombre-serv-dmd5
El autenticador DIGEST-MD5 utiliza la palabra clave dmd5-serv-name y se utiliza en
part, para construir la cadena digest-uri-value (ver RFC2831)

-am, --auth-map [auth-alias = auth-type [, ...]]
Proporciona una forma de asignar nombres alternativos a tipos de autenticación base. Útil para cualquier
sitios que utilizan nombres alternativos para tipos comunes. Esta funcionalidad se utiliza realmente
internamente para mapear los tipos SPA y MSN en el tipo base NTLM. La linea de comando
El argumento para simular esto sería "--auth-map SPA = NTLM, MSN = NTLM". Todas las autorizaciones
los tipos enumerados anteriormente son destinos válidos para el mapeo, excepto SPA y MSN.

-apt, --auth-texto sin formato
En lugar de mostrar cadenas AUTH codificadas en base64 a medida que se transmiten, conviértalas
a texto sin formato antes de imprimir en la pantalla.

-ahp, --auth-hide-password [cadena de reemplazo]
Si se especifica esta opción, cada vez que se imprima una contraseña legible en el
terminal (específicamente AUTH PLAIN y AUTH LOGIN) la contraseña se reemplaza con un
cadena ficticia (o el contenido de "cadena de reemplazo" si se proporciona). La cuerda ficticia
estará codificado en base64 o no dependerá de la opción --auth-plaintext.

Tenga en cuenta que --auth-hide-password es similar, pero no idéntico, al --protect-prompt
opción. El primero protege las contraseñas para que no se muestren en la transacción SMTP.
independientemente de cómo se ingresen. Este último protege las cuerdas sensibles cuando el
el usuario los escribe en la terminal, independientemente de cómo se use la cadena.

XCLIENTE OPCIONES

XCLIENT es una extensión SMTP introducida por el proyecto Postfix. XCLIENT permite un
cliente (debidamente autorizado) para decirle a un servidor que utilice información alternativa, como IP
dirección o nombre de host, para el cliente. Esto permite rutas mucho más fáciles para probar el correo.
configuraciones de servidor. Los detalles completos sobre el protocolo están disponibles en
http://www.postfix.org/XCLIENT_README.html.

--xclient-addr [VALOR]
--xnombre-cliente [VALOR]
--xclient-port [VALOR]
--xclient-proto [VALOR]
--xclient-helo [VALOR]
--xclient-login [VALOR]
--xclient-reverse-name [VALOR]
Estas opciones especifican atributos XCLIENT que deben enviarse al servidor de destino. Si
No se proporciona [VALUE], los swaks solicitarán y leerán el valor en STDIN. Ver
http://www.postfix.org/XCLIENT_README.html para obtener documentación oficial de lo que
los atributos significan y sus posibles valores, incluido el especial "[NO DISPONIBLE]" y
Valores "[TEMPUNAVAIL]".

A modo de ejemplo simple, establezca "--xclient-name foo.example.com --xclient-addr
192.168.1.1 "hará que los swaks envíen el comando SMTP" XCLIENT NAME = foo.example.com
DIRECCIÓN = 192.168.1.1 ".

Tenga en cuenta que el atributo "REVERSE_NAME" no parece aparecer en el
documentación. Hay un hilo de lista de correo que lo documenta, visible en
http://comments.gmane.org/gmane.mail.postfix.user/192623.

Todas estas opciones se pueden mezclar entre sí y se pueden mezclar con el --xclient
opción (ver más abajo).

--xcliente [XCLIENT_STRING]
Esta es la opción XCLIENT de "forma libre". Cualquiera que sea el valor proporcionado para XCLIENT_STRING
se enviará literalmente como argumento del comando smtp de XCLIENT. Por ejemplo, si
Se utiliza "--xclient 'NAME = ADDR = 192.168.1.1 FOO = bar'", los swaks enviarán el comando SMTP
"XCLIENT NAME = ADDR = 192.168.1.1 FOO = bar". La principal ventaja de esto sobre los más
Las opciones específicas anteriores es que no hay validación de sintaxis XCLIENT aquí. Esta
le permite enviar XCLIENT no válido al servidor de destino para su prueba. Si no
XCLIENT_STRING se pasa en la línea de comando, swaks solicitará y leerá el valor en
ESTÁNDAR

La opción --xclient se puede mezclar libremente con las opciones --xclient- * anteriores. Si
"--xclient-addr 192.168.0.1 --xclient 'FOO = bar NAME = wind'" se le da a los swaks, "XCLIENT
ADDR = 192.168.0.1 FOO = bar NAME = wind "se enviará al servidor de destino.

--xclient-opcional
--xclient-opcional-estricto
En funcionamiento normal, configurar una de las opciones --xclient * provocará una
La transacción XCLIENT se llevará a cabo para poder continuar (es decir, XCLIENT debe ser
anunciados, todos los atributos solicitados por el usuario deben haber sido anunciados, y el
el servidor debe haber aceptado la solicitud XCLIENT de los swaks). Estas opciones cambian eso
comportamiento. --xclient-optional le dice a los swaks que procedan incondicionalmente más allá del XCLIENT
etapa de la transacción SMTP, independientemente de si se realizó correctamente.
--xclient-opcional-estricto es similar pero más granular. La versión estricta
Continuar a XCLIENT no se anunció, pero fallará si se intentó XCLIENT pero lo hizo
fracaso.

DATOS OPCIONES

Estas opciones pertenecen al contenido de la parte de DATOS de la transacción SMTP.

-d, --data [porción de datos]
Utilice argumento como el contenido completo de DATOS, o pregunte al usuario si no se especifica ningún argumento.
Si se proporciona el argumento '-', los datos se leerán desde STDIN. Si alguna otra
se proporciona el argumento y representa el nombre de un archivo que se puede abrir, el contenido de
se utilizará el archivo. Cualquier otro argumento será él mismo para el contenido de los DATOS.

El valor puede estar en una sola línea, donde \ n (ascii 0x5c, 0x6e) representa donde
Deben colocarse saltos de línea. Se citarán los puntos iniciales. El punto de cierre no es
requerido pero permitido. El valor predeterminado para esta opción es "Fecha:% FECHA% \ nPara:
% TO_ADDRESS% \ nDe:% FROM_ADDRESS% \ nAsunto: prueba% DATE% \ nX-Mailer: swaks v $ p_version
jetmore.org/john/code/swaks/\n%NEW_HEADERS%\n%BODY%\n ".

Se realiza un análisis de tokens muy básico en la parte de DATOS. Ver --use-old-data-tokens
para obtener detalles sobre los tokens de un solo carácter marcados como obsoletos. El seguimiento
La tabla muestra los tokens reconocidos y sus valores de reemplazo:

%DE LA DIRECCIÓN%
Reemplazado con el remitente del sobre. Reemplaza el token% F obsoleto.

%DIRIGIRSE%
Reemplazado con el (los) destinatario (s) del sobre. Reemplaza el token% T obsoleto.

%FECHA%
Reemplazado con la hora actual en un formato adecuado para su inclusión en la Fecha:
encabezamiento. Tenga en cuenta que esto intenta utilizar el módulo estándar Time :: Local para la zona horaria
cálculos. Si este módulo no está disponible, la cadena de fecha estará en GMT.
Reemplaza el token% D obsoleto.

% NEW_HEADERS%
Reemplazado con el contenido de la opción --add-header. Si --add-header no es
especificado, este token simplemente se elimina. Reemplaza el token% H obsoleto.

%CUERPO%
Reemplazado con el valor especificado por la opción --body. Ver --body por defecto.
Reemplaza el token% H obsoleto.

--use-tokens-de-datos-antiguos
En versiones anteriores de swaks, los tokens DATA como se describe en la opción --data anterior
usó tokens de un solo carácter (por ejemplo,% F). Estas no fueron una gran opción por defecto.
tokens, y resultó especialmente problemático con idiomas codificados, distintos del inglés, donde
estas combinaciones de caracteres pueden ser comunes. Los tokens de un solo carácter fueron
reemplazado con las versiones ligeramente menos propensas a errores enumeradas anteriormente. La retención de
los tokens antiguos y la inclusión de esta opción para activarlos están pensados ​​como un
ayuda temporal a los usuarios que tienen un corpus de mensajes existente utilizando los tokens antiguos. los
Se deben considerar los tokens de un solo carácter y la opción --use-old-data-tokens
obsoleto y es probable que se elimine en la próxima versión.

-dab, - dump-as-body
Si se usa --dump-as-body y no se usa ninguna otra opción para cambiar el cuerpo predeterminado de
mensaje, el cuerpo se reemplaza con una salida similar a la salida de lo que es
proporcionado por --dump. - no se muestra la estrofa de capacidad del programa inicial de dump, y
la sección de "datos" no está incluida. Además, --dump siempre incluye contraseñas.
De forma predeterminada, --dump-as-body no incluye contraseñas, aunque esto se puede cambiar con
--volcar-como-cuerpo-muestra-contraseña.

-dabsp, --dump-as-body-shows-contraseña
Hacer que --dump-as-body incluya contraseñas de texto sin formato. No se recomienda esta opción.
Esta opción implica --dump-as-body.

--body [especificación del cuerpo]
Especifique el cuerpo del correo electrónico. El valor predeterminado es "Este es un envío de prueba". Si no
se da argumento a --body, se le pide que proporcione uno de forma interactiva. Si se proporciona '-',
el cuerpo se leerá desde la entrada estándar. Si se proporciona cualquier otro texto y el texto
representa un archivo que se puede abrir, el contenido de ese archivo se utiliza como cuerpo. Si se
no representa un archivo que se pueda abrir, el texto en sí se utiliza como cuerpo.

Si el mensaje se fuerza al formato MIME (ver - adjuntar) el argumento a esta opción
se incluirá sin codificar como la primera parte MIME. Su tipo de contenido siempre será
Texto sin formato.

--attach [adjunto-especificación]
Cuando se proporciona una o más opciones --attach, el mensaje se cambia a una
Mensaje MIME multiparte / mixto. Los argumentos para - adjuntar se procesan de la misma manera que
--cuerpo con respecto a stdin, contenido de archivo, etc. --el adjunto se puede suministrar múltiples
veces para crear varios archivos adjuntos. De forma predeterminada, cada archivo adjunto se adjunta como
aplicación / archivo de flujo de octetos. Consulte --attach-type para cambiar este comportamiento.

Si se especifica un nombre de archivo, la codificación MIME incluirá ese nombre de archivo. Ver
--attach-name para obtener más detalles sobre la denominación de archivos.

Es legal que '-' (STDIN) se especifique como argumento varias veces (una vez para
--cuerpo y varias veces para --enganchar). En este caso, el mismo contenido será
adjunta cada vez que se especifica. Esto es útil para adjuntar el mismo contenido.
con varios tipos MIME.

--attach-type [mimo-tipo]
De forma predeterminada, el contenido que se adjunta MIME a un mensaje con la opción --attach es
codificado como aplicación / flujo de octetos. --attach-type cambia el tipo de mímica para cada
- adjuntar la opción que le sigue. Se puede especificar varias veces.

--attach-name [nombre]
Esta opción establece el nombre de archivo que se incluirá en la parte MIME creada para el
siguiente - opción adjuntar. Si no se establece ningún argumento para esta opción, no genera ningún nombre de archivo
información que se incluirá para la siguiente parte MIME, incluso si los swaks pudieran generarla
del nombre del archivo local.

-ah, --add-header [encabezado]
Esta opción permite agregar encabezados a los DATOS. Si% H está presente en los DATOS,
se reemplaza con el argumento de esta opción. Si% H no está presente, el argumento es
insertado entre las dos primeras líneas nuevas consecutivas en los DATOS (es decir, es
insertado al final de los encabezados existentes).

La opción se puede especificar varias veces o una sola vez con múltiples
encabezados separados por una cadena literal '\ n'. Entonces, "--add-header 'Foo: bar' --add-header
'Baz: foo' "y" --add-header 'Foo: bar \ nBaz: foo' "terminan agregando los mismos dos
encabezados.

--header [encabezado-y-datos], --h-Encabezado [datos]
Estas opciones permiten una forma de cambiar los encabezados que ya existen en los DATOS. '--encabezamiento
"Asunto: foo" 'y' --h-Asunto foo 'son equivalentes. Si el encabezado aún no
existen en los datos, entonces este argumento se comporta de manera idéntica a --add-header. Sin embargo, si
el encabezado ya existe se reemplaza por el especificado.

-g Si se especifica, los swaks leerán el valor de DATOS para el correo de STDIN. Este es
equivalente a "--data -". Si hay una línea From_ en el correo electrónico, se eliminará
(pero vea la opción -nsf). Útil para entregar mensajes reales (almacenados en archivos) en su lugar
de usar mensajes de ejemplo.

--sin-reparación-de-datos, -ndf
Esta opción obliga a los swaks a no masajear la parte de DATOS del correo electrónico. Esta
incluye reemplazo de token, From_ stripping, adición de punto final, --cuerpo / adjunto
inclusión y cualquier adición de encabezado. Esta opción solo es útil cuando se usa con
--data, ya que la porción de DATOS interna predeterminada usa tokens.

--no-strip-from, -nsf
No elimine la línea From_ de la parte DATA, si está presente.

SALIDA OPCIONES

De forma predeterminada, swaks proporciona una transcripción de sus transacciones a la persona que llama (STDOUT / STDERR).
Esta transcripción tiene como objetivo ser una representación lo más fiel posible de la transacción.
aunque modifica esta salida agregando prefijos informativos a las líneas y por
proporcionar versiones de texto sin formato de transacciones TLS

Los "prefijos informativos" se conocen como sugerencias de transacciones. Estas pistas son
inicialmente compuesto por las líneas de marcado que son la salida de los propios swaks, ya sea
mensajes informativos o de error, y aquellos que indican una línea de datos realmente enviados o
recibido en una transacción. Esta tabla indica las sugerencias y sus significados:

=== Indica una línea informativa generada por swaks

*** Indica un error generado dentro de swaks

-> Indica una línea esperada enviada por swaks al servidor de destino

~> Indica una línea esperada cifrada con TLS enviada por swaks al servidor de destino

**> Indica una línea inesperada enviada por swaks al servidor de destino

* ~> Indica una línea inesperada encriptada con TLS enviada por swaks al servidor de destino

> Indica un fragmento de prueba sin procesar enviado por swaks a un servidor de destino (consulte --show-raw-text).
No existe el concepto de "esperado" o "inesperado" en este nivel.

<- Indica una línea esperada enviada por el servidor de destino a los swaks

<~ Indica una línea esperada cifrada con TLS enviada por el servidor de destino a los swaks

<** Indica una línea inesperada enviada por el servidor de destino a los swaks

<~ * Indica una línea inesperada encriptada con TLS enviada por el servidor de destino a los swaks

<Indica un fragmento de texto sin procesar recibido por swaks de un servidor de destino (ver
--show-raw-text). No existe el concepto de "esperado" o "inesperado" en este nivel.

Las siguientes opciones controlan qué y cómo se muestra la salida a la persona que llama.

-n, --suprimir-datos
Resume la parte de DATOS de la transacción SMTP en lugar de imprimir cada línea.
Esta opción es muy útil, al borde de la requerida, cuando se utilizan swaks para enviar ciertos
correos electrónicos de prueba. Los correos electrónicos con archivos adjuntos, por ejemplo, abrumarán rápidamente una terminal
si no se suprimen los DATOS.

-stl, --show-lapso de tiempo [i]
Muestra el lapso de tiempo entre los pares de envío / recepción. Esta opción es más útil cuando
Time :: HiRes está disponible, en cuyo caso el lapso de tiempo se mostrará en
milésimas de segundo. Si Time :: HiRes no está disponible o se da "i" como argumento
el lapso se mostrará solo en segundos enteros.

-nih, --no-información-pistas
No muestre la sugerencia de transacción para transacciones informativas. Esto es lo mas
útil cuando se necesita copiar alguna porción de las líneas informativas, por ejemplo,
certificado de salida de --tls-get-peer-cert.

-nsh, --no-enviar-sugerencias
-nrh, --no-recibir-pistas
-nth, --sin pistas
--no-send-hints y --no-receive-hints suprimen el prefijo de transacción de send y
recibir líneas, respectivamente. Esto suele ser útil cuando se copia alguna parte del
transacción para usar en otro lugar (por ejemplo, "--no-send-hints --hide-receive
--hide-informational "es una forma útil de obtener solo los comandos del lado del cliente para un determinado
transacción). --no-hints es idéntico a especificar tanto --no-send-hints como
--no-recibir-sugerencias.

No muestre sugerencias de transacciones (útil junto con -hr para crear copias / pegar
actas).

-sin procesar, --mostrar-texto sin procesar
Esta opción imprimirá un volcado hexadecimal de datos brutos enviados y recibidos por swaks. Cada hex
dump es el contenido de una sola lectura o escritura en la red. Esto debería ser
idéntico a lo que ya se está mostrando (con la excepción de los caracteres \ r
siendo eliminado). Esta opción es útil para ver detalles cuando los servidores envían lotes
de datos en paquetes individuales, o dividir líneas individuales en varios paquetes. Si
realmente necesita profundizar en esa área, probablemente sea mejor con un paquete
sniffer, pero esta opción es un buen primer paso para detectar problemas de conexión extraños.

--archivo de salida
--salida-archivo-stdout
--archivo-de-salida-stderr
Estas opciones permiten al usuario enviar resultados a archivos en lugar de stdout / stderr. los
la primera opción envía ambos al mismo archivo. Los argumentos de & STDOUT y & STDERR son
tratado especialmente, refiriéndose a los identificadores de archivos "normales", por lo que "--output-file-stderr
'& STDOUT' "redirigiría STDERR a STDOUT.

-pp, --proteger-prompt
No repita la entrada del usuario en las solicitudes que son potencialmente sensibles (ahora solo
contraseña de autenticación). Véase también --auth-hide-password

-hr, - ocultar-recibir
No muestre las líneas enviadas desde el servidor remoto que reciben los swaks

-hs, --hide-enviar
No muestre las líneas enviadas por swaks al servidor remoto

-hola, --ocultar-informativo
No muestre líneas informativas sin errores de los propios swaks.

-ha, - esconder-todo
No muestre ningún contenido al terminal.

-S, --silent [nivel]
Haz que los swaks guarden silencio. Si no se da ningún argumento o si se da un argumento de "1",
no imprima ninguna salida a menos que / hasta que se produzca un error, después de lo cual se muestran todas las salidas. Si una
Se da el argumento de "2", solo errores de impresión. Si se da "3", no muestra ningún resultado.

--apoyo
Capacidades de impresión y salida. Algunas funciones requieren módulos de Perl no estándar.
Esta opción evalúa si estos módulos están presentes y muestra qué
la funcionalidad está disponible y cuál no, y qué módulos deberían agregarse
para obtener la funcionalidad que falta.

--vertedero
Esta opción hace que los swaks impriman los resultados del procesamiento de opciones, inmediatamente antes
se habría enviado el correo. No se enviará ningún correo cuando se utilice --dump. Tenga en cuenta que
--dump se considera una herramienta pura de autodiagnóstico y no se hace ningún esfuerzo
alguna vez para enmascarar contraseñas en la salida --dump.

--ayuda
Muestra esta información de ayuda.

--versión
Muestra información sobre la versión.

PORTABILIDAD

SISTEMAS OPERATIVOS
Este programa fue diseñado principalmente para su uso en sistemas operativos similares a Unix, y
debería funcionar en cualquier versión razonable del mismo. Ha sido desarrollado y probado en
Solaris, Linux y Mac OS X y tiene todas las funciones de todos ellos.

Se sabe que este programa demuestra la funcionalidad básica en Windows usando
Perl de ActiveState. No se ha probado completamente. Se sabe que funcionan son SMTP básico
funcionalidad y los tipos de autenticación LOGIN, PLAIN y CRAM-MD5. Desconocido es cualquier TLS
funcionalidad y los tipos de autenticación NTLM / SPA y DIGEST-MD5.

Debido a que este programa debería funcionar en cualquier lugar donde funcione Perl, agradecería conocer
cualquier nuevo sistema operativo en el que haya utilizado a fondo los swaks, así como cualquier problema
encontrado en un nuevo sistema operativo.

SERVIDORES DE CORREO
Este programa fue desarrollado casi exclusivamente contra servidores de correo Exim. Ha sido
usado casualmente por el autor, aunque no probado a fondo, con Sendmail, Smail,
Exchange, Oracle Collaboration Suite, qpsmtpd y Communigate. Porque todo
La funcionalidad en swaks se basa en estándares conocidos y debería funcionar con cualquier
servidor de correo moderno. Si se encuentra un problema, avise al autor en la dirección
abajo.

SALIR Codigos

0 no ocurrieron errores

1 error al analizar las opciones de la línea de comandos

2 error al conectarse al servidor remoto

3 tipo de conexión desconocido

4 mientras se ejecuta con el tipo de conexión de "tubería", problema fatal al escribir o leer desde
el proceso del niño

5 mientras se ejecutaba con el tipo de conexión de "tubería", el proceso hijo murió inesperadamente. Esta
puede significar que el programa especificado con --pipe no existe.

6 Conexión cerrada inesperadamente. Si el cierre se detecta en respuesta al 'SALIR'
swaks envía después de una respuesta inesperada, el código de error para ese inesperado
En su lugar, se utiliza la respuesta. Por ejemplo, si un servidor de correo devuelve una respuesta 550 a un
MAIL FROM: e inmediatamente cierra la conexión, swaks detecta que el
La conexión está cerrada, pero usa el código de salida 23 más específico para detallar la naturaleza de
la falla. Si, en cambio, el servidor devuelve un código 250 y luego cierra inmediatamente el
conexión, los swaks usarán el código de salida 6 porque no hay una salida más específica
código.

10 error en los requisitos previos (módulo necesario no disponible)

21 error al leer el banner inicial del servidor

22 error en la transacción HELO

23 error en la transacción de CORREO

24 no se aceptan RCPT

25 servidor devolvió un error a la solicitud de DATOS

26 servidor no aceptó correo siguiente datos

27 el servidor devolvió un error después de una solicitud de salida de sesión normal

28 error en la transacción AUTH

29 error en la transacción TLS

32 error en EHLO después de la negociación TLS

33 error en la transacción XCLIENT

Error 34 en EHLO siguiendo XCLIENT

SOBRE NOSOTROS Las NOMBRE

El nombre "swaks" es una especie de acrónimo de "Swiss Army Knife Smtp". Fue elegido para ser
bastante distinto y pronunciable. Si bien "swaks" es único como nombre de un software
package, tiene otros significados no relacionados con el software. Envíe otros usos de "swak" o
"swaks" para su inclusión.

"Sellado con un beso"
SWAK / SWAK aparece ocasionalmente en Internet con el significado de "con amor".

malo / pobre / enfermo (afrikáans)
Visto en el titular "SA se bes en swaks gekledes en 2011", que se tradujo como
"mejor y peor vestidos" por hablantes nativos. Al Traductor de Google no le gustan los "swaks
gekledes ", pero traducirá" swak "como" pobre "y" swak geklede "como" mal vestido ".

CONTACTO

[email protected]
Utilice esta dirección para contacto general, preguntas, parches, solicitudes, etc.

[email protected]
Si desea ser incluido en una lista para recibir notificaciones cuando una nueva versión de
Swaks se libera, envíe un correo electrónico a esta dirección.

http://www.jetmore.org/john/code/swaks/
Los registros de cambios, esta ayuda y la última versión se encuentran en este enlace.

Use swaks en línea usando los servicios de onworks.net