swaks - Online na nuvem

PROGRAMA:

NOME

swaks - Swiss Army Knife SMTP, o testador de transações smtp para todos os fins

DESCRIÇÃO

O objetivo principal do design do swaks é ser um teste SMTP flexível, com script e orientado para transações
ferramenta. Ele lida com recursos e extensões SMTP, como TLS, autenticação e
pipelining; várias versões do protocolo SMTP, incluindo SMTP, ESMTP e LMTP; e
vários métodos de transporte, incluindo soquetes de domínio unix, soquetes de domínio da Internet e
tubos para processos gerados. As opções podem ser especificadas em variáveis ​​de ambiente,
arquivos de configuração e a linha de comando permitindo a configuração máxima e facilidade de uso
para operadores e criadores de scripts.

QUICK Abra

Entregue um e-mail de teste padrão para [email protected] na porta 25 de test-server.example.net:

swaks - para [email protected] --server test-server.example.net

Entregue um e-mail de teste padrão, exigindo autenticação CRAM-MD5 como usuário [email protected].
Um cabeçalho "X-Test" será adicionado ao corpo do e-mail. A senha de autenticação será
solicitado.

swaks - para [email protected] --a partir de [email protected] --auth CRAM-MD5 --auth-usuário [email protected] --header-X-Test "email de teste"

Teste um antivírus usando EICAR em um anexo. Não mostrar a parte DATA da mensagem:

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

Teste um scanner de spam usando GTUBE no corpo de um e-mail, roteado por meio dos registros MX para
exemplo.com:

swaks - para [email protected] --body / caminho / para / gtube / arquivo

Entregue um e-mail de teste padrão para [email protected] usando o protocolo LMTP por meio de um UNIX
arquivo de soquete de domínio

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

Relate todos os destinatários em um arquivo de texto que não podem ser verificados em um servidor de teste:

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

TERMOS E CONVENÇÕES

Este documento tenta ser consistente e específico no uso dos seguintes termos para
reduzir a confusão.

transação
Uma transação é a abertura de uma conexão através de um transporte para um destino e usando um
protocolo de mensagens para tentar entregar uma mensagem.

Alvo
O alvo de uma transação é aquilo ao qual os swaks se conectam. Este termo genérico é
usado em toda a documentação porque a maioria dos outros termos implicam indevidamente em algo
sobre o transporte que está sendo usado.

Transporte
O transporte é o método subjacente usado para se conectar ao destino.

Protocolo
O protocolo é a linguagem do aplicativo usada para se comunicar com o destino. Esse
documento usa SMTP para falar genericamente de todos os três protocolos suportados, a menos que
afirma que se refere ao protocolo 'SMTP' específico e exclui os outros.

Mensagem
Os protocolos SMTP existem para transferir mensagens, um conjunto de bytes em um formato acordado
que tem um remetente e um destinatário.

Envelope
O envelope de uma mensagem contém o remetente e o destinatário "verdadeiros" de uma mensagem. Pode
também ser referidos como seus componentes, remetente e destinatários do envelope. Isto é
É importante observar que um envelope de mensagem não precisa corresponder a seu Para: e De:
cabeçalhos.

DADOS
A parte DATA de uma transação SMTP é a mensagem real que está sendo
transportado. Consiste nos cabeçalhos e no corpo da mensagem. DATA e corpo
às vezes são usados ​​como sinônimos, mas são sempre duas coisas distintas neste
documento.

Cabeçalhos
Os cabeçalhos de uma mensagem são definidos como todas as linhas na seção DATA da mensagem antes
a primeira linha em branco. Eles contêm informações sobre o e-mail que será exibido
para o destinatário, como Para :, De :, Assunto :, etc. Neste documento, os cabeçalhos serão
sempre deve ser escrito com a primeira letra maiúscula e dois pontos à direita.

Corpo
O corpo de uma mensagem é a parte de sua seção de DADOS após a primeira linha em branco.

OPÇÃO EM PROCESSAMENTO

Para evitar confusão potencial neste documento, um sinalizador para swaks é sempre referido como
uma opção". Se a opção leva dados adicionais, esses dados adicionais são referidos como
um argumento para a opção. Por exemplo, "--de [email protected]"pode ​​ser fornecido para
swaks na linha de comando, com "--from" sendo a opção e "[email protected]" ser
--do argumento.

As opções podem ser fornecidas aos swaks de três maneiras. Eles podem ser especificados em uma configuração
arquivo, em variáveis ​​de ambiente e na linha de comando. Dependendo da opção específica
e independentemente de ser ou não fornecido um argumento, os swaks podem solicitar ao usuário o argumento.

Quando swaks avalia suas opções, ele primeiro procura por um arquivo de configuração (em um
local padrão ou especificado com --config). Em seguida, avalia todas as opções em
variáveis ​​ambientais. Finalmente, ele avalia as opções de linha de comando. Em cada rodada de
processamento, quaisquer opções definidas anteriormente serão substituídas. Além disso, qualquer opção pode ser
prefixado com "no-" para fazer com que os swaks se esqueçam de que a variável foi definida anteriormente.
Esse recurso é necessário porque muitas opções tratam argumentos definidos, mas não
diferente de não definido.

O mecanismo e formato exatos para usar cada um dos tipos estão listados abaixo.

ARQUIVO DE CONFIGURAÇÃO
Um arquivo de configuração pode ser usado para definir opções comumente usadas ou anormalmente detalhadas.
Por padrão, os swaks parecem estar em ordem para $ SWAKS_HOME / .swaksrc, $ HOME / .swaksrc e
$ LOGDIR / .swaksrc. Se um desses existir (e --config não tiver sido usado)
esse arquivo é usado como o arquivo de configuração.

Além disso, um arquivo de configuração em um local não padrão pode ser especificado usando
--config. Se estiver definido e não for fornecido um argumento, os swaks não usarão nenhum
arquivo de configuração, incluindo qualquer arquivo padrão. Se --config aponta para um legível
arquivo, ele é usado como o arquivo de configuração, substituindo qualquer padrão que possa existir. Se
ele aponta para um arquivo ilegível e um erro será mostrado e os swaks serão encerrados.

Um conjunto de padrões "portáteis" também pode ser criado adicionando opções ao final do
arquivo de programa de swaks. Conforme distribuído, a última linha de swaks deve ser "__END__". Algum
linhas adicionadas após __END__ serão tratadas como o conteúdo de um arquivo de configuração.
Isso permite que um conjunto de preferências do usuário seja copiado automaticamente de servidor para servidor
em um único arquivo.

Se os arquivos presentes e de configuração não tiverem sido explicitamente desativados, o __END__
a configuração é sempre lida. Apenas um outro arquivo de configuração será usado por único
invocação de swaks, mesmo se vários arquivos de configuração forem especificados. Especificando
a opção --config sem nenhum argumento desativa o processamento de __END__
config e quaisquer arquivos de configuração reais.

Em um arquivo de configuração, as linhas que começam com um hash (#) são ignoradas. Todas as outras linhas
são considerados uma opção para swaks, com o traço inicial ou traços opcionais.
Tudo o que está depois do primeiro espaço de uma linha de opção é considerado o argumento da opção
e não é processado em shell. Portanto, citar geralmente é desnecessário e será
incluído literalmente no argumento. Aqui está um exemplo do conteúdo de um
arquivo de configuração:

# sempre use este remetente, não importa o servidor ou usuário conectado
--a partir de [email protected]
# Prefiro que meus e-mails de teste tenham um cabeçalho bonito. Observação
# a falta de travessões na opção e a falta de aspas ao redor
# argumento inteiro.
h-From: "Fred Exemplo"[email protected]>

VARIÁVEIS AMBIENTAIS
As opções podem ser fornecidas por meio de variáveis ​​de ambiente. As variáveis ​​estão na forma
$ SWAKS_OPT_name, onde name é o nome da opção que seria especificada no
linha de comando. Porque travessões não são permitidos em nomes de variáveis ​​de ambiente na maioria
shells unix-ish, nenhum traço inicial deve ser usado e quaisquer traços dentro da opção
o nome deve ser substituído por sublinhados. O seguinte criaria as mesmas opções
mostrado no exemplo de arquivo de configuração:

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

Definir uma variável com um valor vazio é o mesmo que especificá-la na linha de comando
sem argumento. Por exemplo, definir SWAKS_OPT_server = "" faria com que swaks para
solicitará o uso do servidor ao qual se conectar a cada chamada.

Além de definir o equivalente às opções de linha de comando, SWAKS_HOME pode ser definido
para um diretório que contém o .swaksrc padrão a ser usado.

OPÇÕES DE LINHA DE COMANDO
O método final de fornecer opções para swaks é por meio da linha de comando. As opções
se comporte de maneira consistente com a maioria dos programas de linha de comando unix-ish. Muitas opções
tem formato curto e longo (por exemplo -s e --server). Por convenção curta
as opções são especificadas com um único traço e as opções longas são especificadas com um duplo
traço. Esta é apenas uma convenção e qualquer prefixo funcionará com qualquer tipo.

O seguinte demonstra o exemplo mostrado no arquivo de configuração e ambiente
seções variáveis:

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

TRANSPORTE

Os swaks podem se conectar a um alvo via tubos unix ("tubos"), soquetes de domínio unix ("unix
sockets ") ou sockets de domínio da Internet (" sockets de rede "). Ligar através de sockets de rede
é o comportamento padrão. Devido à natureza singular do transporte utilizado, cada conjunto
de opções na seção a seguir são mutuamente exclusivas. Especificando mais de um de
--server, --pipe ou --socket resultará em um erro. Misturando outras opções entre
os tipos de transporte resultarão apenas em opções irrelevantes ignoradas. Abaixo está um
breve descrição de cada tipo de transporte e as opções que são específicas para aquele
tipo de transporte.

SOQUETES DE REDE
Este transporte tenta entregar uma mensagem via TCP / IP, o método padrão para
entregando SMTP. Este é o transporte padrão para swaks. Se nenhum de --server,
--pipe ou --socket são fornecidos, então este transporte é usado e o servidor de destino é
determinado a partir do domínio do destinatário (veja --server abaixo para mais detalhes).

Este transporte requer o módulo IO :: Socket que faz parte do perl padrão
distribuição. Se este módulo não for carregável, a tentativa de usar este transporte irá
resultar em um erro e no encerramento do programa.

IPv6 é suportado quando o módulo IO :: Socket :: INET6 está presente.

-s, --server [servidor de e-mail de destino [: porta]]
Diga explicitamente aos swaks para usar sockets de rede e especificar o nome do host ou IP
endereço para o qual conectar, ou prompt se nenhum argumento for fornecido. Se esta opção for
não fornecido e nenhuma outra opção de transporte é fornecida, o servidor de e-mail de destino é
determinado a partir dos registros DNS apropriados para o domínio do e-mail do destinatário
endereço usando o módulo Net :: DNS. Se Net :: DNS não estiver disponível, os swaks irão
tentativa de se conectar ao localhost para entregar. A porta de destino pode ser opcionalmente definida
aqui. Os formatos suportados para isso incluem SERVER: PORT (nomes de suporte e IPv4
endereços); [SERVIDOR]: PORTA e SERVIDOR / PORTA (nomes de suporte, IPv4 e IPv6
endereços). Veja também --copy-routing.

-p, --port [porta]
Especifique qual porta TCP no destino deve ser usada ou avise se nenhum argumento for
listados. O argumento pode ser um nome de serviço (conforme recuperado por getservbyname(3)) ou
um número de porta. A porta padrão é determinada pela opção --protocol. Ver
--protocol para mais detalhes.

-li, --local-interface [IP ou nome do host [: porta]]
Use o argumento como a interface local para a conexão SMTP de saída ou prompt
usuário se nenhum argumento for fornecido. O argumento pode ser um endereço IP ou um nome de host. Predefinição
a ação é deixar o sistema operacional escolher a interface local. Veja --server para
comentários adicionais sobre: ​​formato de porta.

-lp, --local-port [porta]
Especifique a porta de saída para originar a transação. Se esta opção for
não especificado, o sistema escolherá uma porta efêmera. Observe que usuários regulares
não pode especificar algumas portas.

--copy-routing [domínio]
O argumento é interpretado como a parte do domínio de um endereço de e-mail e é usado
para encontrar o servidor de destino usando a mesma lógica que seria usada para procurar o
servidor de destino para um endereço de e-mail de destinatário. Veja a opção --to para mais detalhes
sobre como o destino é determinado a partir do domínio de e-mail.

-4, -6
Forçar IPv4 ou IPv6.

SOQUETES UNIX
Este método de transporte tenta entregar mensagens por meio de um arquivo de soquete de domínio unix.
Isso é útil para testar MTA / MDAs que ouvem em arquivos de soquete (por exemplo, teste
Entrega LMTP para Cyrus). Este transporte requer o módulo IO :: Socket que faz parte
da distribuição perl padrão. Se este módulo não for carregável, tente usar
este transporte resultará em um erro e no encerramento do programa.

--socket [/ caminho / para / socket / arquivo]
Esta opção leva como argumento um arquivo de socket de domínio unix. Se swaks for incapaz
para abrir esse soquete, ele exibirá um erro e sairá.

TUBOS
Esse transporte tenta gerar um processo e se comunicar com ele por meio de tubos. o
o programa gerado deve ser preparado para se comportar como um servidor de e-mail em STDIN / STDOUT. Algum
O MTA projetado para operar a partir de inet / xinet deve oferecer suporte a isso. Além disso, alguns MTAs
fornecem modos de teste que podem ser comunicados via STDIN / STDOUT. Este transporte
pode ser usado para automatizar esse teste. Por exemplo, se você implementou a verificação de DNSBL
com o Exim e você queria ter certeza de que estava funcionando, você poderia executar 'swaks --pipe
"exim -bh 127.0.0.2" '. Em um mundo ideal, o processo com o qual você está falando deve se comportar
exatamente como um servidor SMTP em stdin e stdout. Qualquer depuração deve ser enviada para
stderr, que será direcionado ao seu terminal. No mundo real, swaks podem
geralmente lidam com alguma depuração no stdout da criança, mas não há garantias de como
muito que pode suportar.

Este transporte requer o módulo IPC :: Open2 que faz parte do perl padrão
distribuição. Se este módulo não for carregável, tentar usar este transporte irá
resultar em um erro e no encerramento do programa.

--pipe [/ caminho / para / comando e argumentos]
Forneça um nome de processo e argumentos para o processo. swaks tentarão gerar
o processo e se comunicar com ele por meio de tubos. Se o argumento não for um
swaks executáveis ​​exibirão um erro e sairão.

PROTOCOLO OPÇÕES

Essas opções estão relacionadas à camada de protocolo.

-t, --to [endereço de e-mail [, endereço de e-mail, ...]]
Diz swaks para usar argumento (s) como o destinatário do envelope para o e-mail, ou pergunta para
destinatário se nenhum argumento fornecido. Se vários destinatários forem fornecidos e o
o domínio do destinatário é necessário para determinar o roteamento do domínio do último destinatário
fornecido é usado.

Não há valor padrão para esta opção. Se nenhum destinatário for fornecido por meio de qualquer
significa que o usuário será solicitado a fornecer um interativamente. A única exceção a isso
é se um valor --quit-after for fornecido, o que fará com que a transação smtp seja
encerrado antes que o destinatário seja necessário.

-f, --from [endereço de e-mail]
Use o argumento como remetente do envelope para e-mail ou avise o usuário se nenhum argumento for especificado.
A string <> pode ser fornecida para significar o remetente nulo. Se o usuário não especificar um
endereço do remetente, um valor padrão é usado. A parte do domínio do remetente padrão é um
melhor supor o nome de domínio totalmente qualificado do host local. O método de
determinar a parte local varia. No Windows, Win32 :: LoginName () é usado. No unix-
plataformas ish, a variável de ambiente $ LOGNAME é usada se estiver definida. De outra forma
getpwuid(3) é usado. Veja também --force-getpwuid.

--ehlo, --lhlo, -h, --helo [helo-string]
String a ser usada como argumento para o comando HELO / EHLO / LHLO ou prompt de uso se nenhum argumento for
Especificadas. Se esta opção não for usada, uma melhor estimativa do nome de domínio totalmente qualificado
do host local é usado. Se o módulo Sys :: Hostname, que faz parte da base
distribuição, não está disponível, o usuário será solicitado a fornecer um valor HELO. Observe que
Sys :: Hostname foi observado para não ser capaz de encontrar o hostname local em certos
circunstâncias. Isso tem o mesmo efeito como se Sys :: Hostname não estivesse disponível.

-q, --quit-after [ponto de parada]
Ponto em que a transação deve ser interrompida. Quando o ponto de parada solicitado
é alcançado na transação, e desde que os swaks não tenham dado um erro antes de
alcançá-lo, swaks enviará "QUIT" e tentará fechar a conexão de forma limpa.
Estes são os argumentos e notas válidos sobre seu significado.

CONECTAR, BANNER
Encerre a sessão após receber o banner de saudação do alvo.

PRIMEIRO-HELO, PRIMEIRO-EHLO, PRIMEIRO-LHLO
Em uma sessão STARTTLS (mas não tls-on-connect), encerre a transação após
o primeiro de dois HELOs. Em uma transação não STARTTLS, se comporta da mesma forma que HELO
(ver abaixo).

XCLIENTE
Saia após o envio de XCLIENT

TLS Encerra a transação imediatamente após a negociação TLS. Observe que este
acontece em lugares diferentes, dependendo se STARTTLS ou tls-on-connect são
usado. Isso sempre termina após o ponto em que o TLS teria sido negociado,
independentemente de ter sido tentado.

OLÁ, EHLO, LHLO
Em uma sessão STARTTLS ou XCLIENT, saia após o segundo HELO. Caso contrário, saia
após o primeiro e único HELO.

AUTH
Saia após a autenticação. Isso sempre termina após o ponto em que a autenticação
teria sido negociado, independentemente de ter sido tentado.

MAIL DE
Saia após MAIL FROM: ser enviado.

RCPT, PARA
Saia após o envio de RCPT TO :.

- tempo limite [tempo]
Use o argumento como o tempo limite da transação SMTP ou avise o usuário se nenhum argumento for fornecido.
O argumento pode ser um dígito puro, que será interpretado como segundos, ou pode
tem um especificador s ou m (5s = 5 segundos, 3m = 180 segundos). Como um caso especial, 0
significa não esgotar o tempo das transações. O valor padrão é 30s.

--protocol [protocolo]
Especifique qual protocolo usar na transação. As opções válidas são mostradas no
tabela abaixo. Atualmente, os protocolos 'principais' são SMTP, ESMTP e LMTP. Usando
variações desses tipos de protocolo, pode-se especificar as portas padrão, se
autenticação deve ser tentada, e o tipo de conexão TLS que deve ser
tentada. O protocolo padrão é ESMTP. Esta tabela demonstra os
argumentos para --protocol e as opções que cada um define como efeito colateral:

SMTP
HELO, "-p 25"

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

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

SMTPS
HELO, "-tlsc -p 465"

ESMTP
EHLO-> HELO, "-p 25"

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

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

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

LMTP
LHLO, "-p 24"

LMTPA
LHLO, "-a -p 24"

LMTPS
LHLO, "-tls -p 24"

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

--pipeline
Se o servidor remoto suportar, tente SMTP PIPELINING (RFC 2920). Isto é um
opção mais jovem, se você tiver problemas com isso, notifique o autor.
As áreas com problemas potenciais incluem servidores que aceitam DADOS, embora não houvesse nenhum
destinatários (swaks devem enviar corpo vazio nesse caso, não QUIT) e bloqueios causados
enviando pacotes fora do tamanho da janela tcp.

--force-getpwuid
Diga ao swaks para usar o método getpwuid para encontrar a parte local do remetente padrão
de tentar $ LOGNAME primeiro.

TLS / CRIPTOGRAFIA

Estas são opções relacionadas à criptografia da transação. Estes foram testados e
confirmado para trabalhar com todos os três métodos de transporte. O módulo Net :: SSLeay é usado para
execute a criptografia quando for solicitada. Se este módulo não for carregável, os swaks também
ignore a solicitação TLS ou erro, dependendo se a solicitação era opcional.
STARTTLS é definido como uma extensão no protocolo ESMTP e não estará disponível se
--protocol é definido como uma variação de smtp. Porque não está definido no protocolo
em si, --tls-on-connect está disponível para qualquer tipo de protocolo se o destino o suportar.

Não é necessário um certificado local para que uma conexão TLS seja negociada. No entanto, alguns
os servidores usam a verificação do certificado do cliente para verificar se o cliente tem permissão para se conectar.
swaks pode ser instruído a usar um certificado local específico através do uso do --tls-cert
e opções --tls-key.

-tls
Requer conexão para usar STARTTLS. Saia se o TLS não estiver disponível por algum motivo (não
anunciado, as negociações falharam, etc).

-tlso, --tls-opcional
Tente usar STARTTLS se disponível, continue com a transação normal se TLS foi
incapaz de ser negociado por qualquer motivo. Observe que esta é uma opção semi-inútil, pois
atualmente implementado porque após uma falha de negociação, o estado da conexão
É desconhecido. Em alguns casos, como uma incompatibilidade de versão, a conexão deve ser deixada como
texto simples. Em outros, como uma falha de verificação, o lado do servidor pode pensar que
deve continuar falando TLS enquanto o cliente pensa que é texto simples. Pode haver um
tente adicionar mais detecção de estado granular no futuro, mas por enquanto, apenas esteja ciente
que coisas estranhas podem acontecer com esta opção se a negociação TLS for tentada e
falha.

-tlsos, --tls-opcional-estrito
Tente usar STARTTLS, se disponível. Prossiga com a transação se TLS for negociado
com sucesso ou STARTTLS não anunciado. Se STARTTLS for anunciado, mas TLS
as negociações falham, trate como um erro e cancele a transação. Devido à advertência observada
acima, esta é uma opção muito mais sensata do que --tls-optional.

--tlsc, --tls-on-connect
Inicie uma conexão TLS imediatamente na conexão. Seguindo a convenção comum, se
esta opção é especificada, a porta padrão muda de 25 para 465, embora isso possa
ainda será sobrescrito com a opção --port.

-tlsp, --tls-protocol ESPECIFICAÇÃO
Especifique quais protocolos usar (ou não) ao negociar TLS. Na hora disso
gravação, os protocolos disponíveis são sslv2, sslv3, tlsv1, tlsv1_1 e tlsv1_2. o
a disponibilidade desses protocolos depende de sua biblioteca OpenSSL subjacente, então
nem todos eles podem estar disponíveis. A lista de protocolos disponíveis é mostrada no
saída de --dump (assumindo que o TLS esteja disponível).

A string de especificação é uma lista delimitada por vírgulas de protocolos que podem ser usados ​​ou
não usado. Por exemplo, 'tlsv1, tlsv1_1' só terá sucesso se um dos dois
os protocolos estão disponíveis no cliente e no servidor. Por outro lado,
'no_sslv2, no_sslv3' tentará negociar qualquer protocolo, exceto sslv2 e sslv3.
As duas formas de especificação não podem ser misturadas.

-tls-cifra CIPHER_STRING
O argumento para esta opção é passado para a biblioteca OpenSSL subjacente para definir a lista
de cifras aceitáveis ​​a serem usadas para a conexão. O formato desta string é
opaco a swaks e é definido em
http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT. Um breve exemplo
seria --tls-cipher '3DES: + RSA'.

--tls-verificar
Por padrão, os swaks não fazem nenhuma verificação de certificado. Configurar --tls-verify irá
fazer com que swaks tentem verificar o certificado do servidor. Se esta opção estiver definida e
o certificado do servidor não é verificável (usando a CA padrão do sistema
informações ou informações personalizadas de CA (consulte --tls-ca-path)) A negociação TLS não
suceder.

--tls-ca-path [/ path / to / CAfile | / caminho / para / CAdir /]
Por padrão, os swaks usarão as informações de CA padrão da biblioteca OpenSSL subjacente para
verificar os certificados do servidor. --tls-ca-path permite que você especifique um caminho alternativo
localização. Ver http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html for
detalhes do conteúdo do arquivo / diretório.

--tls-cert / caminho / para / arquivo
Forneça um caminho para um arquivo contendo os swaks de certificados locais que devem ser usados ​​se TLS for
negociado. O argumento do caminho do arquivo é obrigatório. Conforme implementado atualmente, o
O certificado no arquivo deve estar no formato PEM. Contate o autor se houver um
necessidade imperiosa de ASN1. Se esta opção for definida, --tls-key também é necessária.

--tls-key / path / to / file
Forneça um caminho para um arquivo contendo as chaves privadas locais swaks que devem ser usados ​​se TLS for
negociado. O argumento do caminho do arquivo é obrigatório. Conforme implementado atualmente, o
O certificado no arquivo deve estar no formato PEM. Contate o autor se houver um
necessidade imperiosa de ASN1. Se esta opção for definida, --tls-cert também é necessário.

--tls-get-peer-cert [/ caminho / para / arquivo]
Obtenha uma cópia do certificado do par TLS. Se nenhum argumento for dado, será
exibido em STDOUT. Se for fornecido um argumento, é considerado um caminho do sistema de arquivos
especificando onde o certificado deve ser escrito. O certificado salvo pode então ser
examinado usando ferramentas padrão como o comando openssl. Se um arquivo for especificado, seu
o conteúdo será sobrescrito.

AUTENTICAÇÃO

Os swaks tentarão se autenticar no servidor de e-mail de destino se forem instruídos a fazê-lo. Esse
a seção detalha os tipos de autenticação disponíveis, requisitos, opções e seus
interações e outros pontos finos no uso de autenticação. Porque a autenticação é
definido como uma extensão no protocolo ESMTP, não estará disponível se --protocol estiver definido
a uma variação de smtp.

Todos os métodos de autenticação requerem codificação base64. Se o módulo MIME :: Base64 perl for
swaks carregáveis ​​tenta usá-lo para realizar essas codificações. Se MIME :: Base64 não for
swaks disponíveis usarão suas próprias rotinas base64 integradas. Estes são mais lentos que o
Rotinas MIME :: Base64 e menos revisadas, embora tenham sido testadas exaustivamente. Usando
o módulo MIME :: Base64 é encorajado.

Se a autenticação for necessária (veja as opções abaixo para saber quando é e quando não é necessária) e
os requisitos não são atendidos para o tipo de autenticação disponível, swaks exibe um erro
e sai. Duas maneiras pelas quais isso pode acontecer incluem forçar swaks a usar um específico
tipo de autenticação que swaks não pode usar devido a requisitos ausentes ou permitindo swaks para
use qualquer tipo de autenticação, mas o servidor apenas anuncia os tipos que os swaks não podem suportar. No
o primeiro caso extrai erros no tempo de processamento da opção, uma vez que sabe de antemão
não será capaz de autenticar. No último caso, os swaks irão errar no
estágio de autenticação da transação smtp, uma vez que os swaks não estarão cientes de que
não será capaz de autenticar até esse ponto.

A seguir estão os tipos de autenticação com suporte, incluindo quaisquer notas individuais e
.

As opções a seguir afetam o uso de autenticação por swaks. Essas opções são todas inter-
relacionado. Por exemplo, especificar --auth-user implica em --auth e --auth-password.
Especificar --auth-optional implica em --auth-user e --auth-password, etc.

-a, --auth [auth-type [, auth-type, ...]]
Exigir swaks para autenticar. Se nenhum argumento for fornecido, qualquer tipo de autenticação compatível
anunciados pelo servidor são tentados até que um seja bem-sucedido ou todos falhem. Se um ou mais
tipos de autenticação são especificados como um argumento, cada um que o servidor também suporta é tentado
em ordem até que um tenha sucesso ou todos falhem. Esta opção requer swaks para autenticar,
portanto, se nenhum tipo de autenticação comum for encontrado ou nenhuma credencial for bem-sucedida, swaks exibe um
erro e sai.

As tabelas a seguir listam os tipos de autenticação válidos

LOGIN, PLANO
Esses tipos de autenticação básica são totalmente suportados e testados e não têm
requisitos adicionais

CRAM-MD5
O autenticador CRAM-MD5 requer o módulo Digest :: MD5. É totalmente testado
e acredita-se que funcione contra qualquer servidor que o implemente.

DIGEST-MD5
O autenticador DIGEST-MD5 (RFC2831) requer o módulo Authen :: SASL. Versão
20100211.0 e anteriores usavam Authen :: DigestMD5 que apresentava alguns erros de nível de protocolo
o que o impediu de funcionar com alguns servidores. Authen :: SASL's DIGEST-MD5
o manuseio é muito mais robusto.

A implementação do DIGEST-MD5 em swaks é bastante imatura. Atualmente suporta
apenas o tipo qop "auth", por exemplo. Se você tem experiência com DIGEST-MD5 e
gostaria de ajudar swaks a suportar melhor o DIGEST-MD5, por favor, entre em contato comigo.

O valor "realm" do protocolo DIGEST-MD5 pode ser definido usando --auth-extra "realm"
palavra-chave. Se nenhum reino for fornecido, um padrão razoável será usado.

Os valores "digest-uri" do protocolo DIGEST-MD5 podem ser definidos usando --auth-extra
opção. Por exemplo, você pode criar o valor digest-uri de
"lmtp / mail.example.com / example.com" com a opção "--auth-extra
dmd5-serv-type = lmtp, dmd5-host = mail.example.com, dmd5-serv-name = example.com ".
A string "digest-uri-value" e seus componentes são definidos no RFC2831. Se nenhum de
esses valores são fornecidos, padrões razoáveis ​​serão usados.

CRAM-SHA1
O autenticador CRAM-SHA1 requer o módulo Digest :: SHA. Este tipo tem apenas
foi testado contra uma implementação não padrão em um servidor Exim e pode
portanto, tem algumas deficiências de implementação.

NTLM / SPA / MSN
Esses autenticadores requerem o módulo Authen :: NTLM. Observe que existem dois
módulos usando o namespace Authen :: NTLM no CPAN. A implementação de Mark Bush
(Authen / NTLM-1.03.tar.gz) é a versão exigida por swaks. Este tipo foi
testado em relação ao Exim, Communigate e Exchange 2007.

Além do nome de usuário e senha padrão, este tipo de autenticação pode
também reconhece um "domínio". O domínio pode ser definido usando --auth-extra "domínio"
palavra-chave. Observe que isso nunca foi testado com um servidor de e-mail que não
ignore DOMAIN para que isso seja implementado incorretamente.

-ao, --auth-opcional [auth-type [, auth-type, ...]]
Esta opção se comporta de forma idêntica a --auth, exceto que solicita autenticação
em vez de exigir isso. Se nenhum tipo de autenticação comum for encontrado ou nenhuma credencial
sucesso, swaks continua como se a autenticação não tivesse sido solicitada.

-aos, --auth-optional-strict [auth-type [, auth-type, ...]]
Esta opção é um meio-termo entre --auth e --auth-opcional. Se não houver autenticação comum
tipos forem encontrados, swaks se comporta como se --auth-optional fosse especificado e prossegue com
a transação. Se os swaks não suportam o tipo de autenticação solicitado, o servidor não
anunciar qualquer tipo de autenticação comum ou, se nenhuma credencial for bem-sucedida, os swaks se comportam como se
--auth foi usado e sai com um erro.

-au, --auth-user [nome de usuário]
Forneça o nome de usuário a ser usado para autenticação ou solicite ao usuário se não
argumento é fornecido. A string <> pode ser fornecida para significar um nome de usuário vazio.

-ap, --auth-password [senha]
Forneça a senha a ser usada para autenticação ou solicite ao usuário se não
argumento é fornecido. A string <> pode ser fornecida para significar uma senha vazia.

-ae, --auth-extra [KEYWORD = value [, ...]]
Alguns dos tipos de autenticação permitem que informações extras sejam incluídas no
processo de autenticação. Em vez de adicionar uma nova opção para cada canto e recanto de
para cada autenticador, a opção --auth-extra permite que essas informações sejam fornecidas.

A tabela a seguir lista as palavras-chave atualmente reconhecidas e os autenticadores
que os usam

reino, domínio
As palavras-chave realm e domain são sinônimos. Usar qualquer um dos dois definirá o "domínio"
opção em NTLM / MSN / SPA e a opção "realm" em DIGEST-MD5

tipo dmd5-serv
A palavra-chave dmd5-serv-type é usada pelo autenticador DIGEST-MD5 e é usada, em
parte, para construir a string digest-uri-value (consulte RFC2831)

host dmd5
A palavra-chave dmd5-host é usada pelo autenticador DIGEST-MD5 e é usada, em
parte, para construir a string digest-uri-value (consulte RFC2831)

dmd5-serv-nome
A palavra-chave dmd5-serv-name é usada pelo autenticador DIGEST-MD5 e é usada, em
parte, para construir a string digest-uri-value (consulte RFC2831)

-am, --auth-map [auth-alias = auth-type [, ...]]
Fornece uma maneira de mapear nomes alternativos em tipos de autenticação de base. Útil para qualquer
sites que usam nomes alternativos para tipos comuns. Esta funcionalidade é realmente usada
internamente para mapear os tipos SPA e MSN no tipo base NTLM. A linha de comando
o argumento para simular isso seria "--auth-map SPA = NTLM, MSN = NTLM". Todos os autores
os tipos listados acima são alvos válidos para mapeamento, exceto SPA e MSN.

-apt, --auth-texto simples
Em vez de mostrar strings AUTH codificadas em base64 à medida que são transmitidas, traduza-as
para texto simples antes de imprimir na tela.

-ahp, --auth-hide-password [string de substituição]
Se esta opção for especificada, a qualquer momento uma senha legível será impressa para o
terminal (especificamente AUTH PLAIN e AUTH LOGIN) a senha é substituída por um
string fictícia (ou o conteúdo da "string de substituição", se fornecida). A corda falsa
será codificado em base64 ou não depende da opção --auth-plaintext.

Observe que --auth-hide-password é semelhante, mas não idêntico, ao --protect-prompt
opção. O primeiro protege as senhas de serem exibidas na transação SMTP
independentemente de como eles são inseridos. Este último protege strings sensíveis quando o
o usuário os digita no terminal, independentemente de como a string seria usada.

XCLIENTE OPÇÕES

XCLIENT é uma extensão SMTP introduzida pelo projeto Postfix. XCLIENT permite um
cliente (devidamente autorizado) para dizer a um servidor para usar informações alternativas, como IP
endereço ou nome do host, para o cliente. Isso permite caminhos muito mais fáceis para testar e-mail
configurações do servidor. Detalhes completos sobre o protocolo estão disponíveis em
http://www.postfix.org/XCLIENT_README.html.

--xclient-addr [VALOR]
--xclient-name [VALOR]
--xclient-port [VALOR]
--xclient-proto [VALOR]
--xclient-helo [VALOR]
--xclient-login [VALOR]
--xclient-reverse-name [VALOR]
Essas opções especificam atributos XCLIENT que devem ser enviados ao servidor de destino. Se
[VALUE] não é fornecido, swaks solicitará e lerá o valor em STDIN. Ver
http://www.postfix.org/XCLIENT_README.html para documentação oficial para o que o
média dos atributos e seus valores possíveis, incluindo o especial "[UNAVAILABLE]" e
Valores "[TEMPUNAVAIL]".

A título de exemplo simples, definindo "--xclient-name foo.example.com --xclient-addr
192.168.1.1 "fará com que swaks enviem o comando SMTP" NOME XCLIENTE = foo.example.com
ADDR = 192.168.1.1 ".

Observe que o atributo "REVERSE_NAME" não parece aparecer na versão oficial
documentação. Há um tópico da lista de discussão que o documenta, podendo ser visto em
http://comments.gmane.org/gmane.mail.postfix.user/192623.

Essas opções podem ser combinadas umas com as outras e podem ser combinadas com o --xclient
opção (veja abaixo).

--xclient [XCLIENT_STRING]
Esta é a opção XCLIENT de "formato livre". Qualquer valor fornecido para XCLIENT_STRING
será enviado literalmente como o argumento para o comando smtp do XCLIENT. Por exemplo, se
"--xclient 'NAME = ADDR = 192.168.1.1 FOO = bar'" for usado, swaks enviará o comando SMTP
"NOME XCLIENT = ADDR = 192.168.1.1 FOO = bar". A principal vantagem disso em relação a mais
opções específicas acima é que não há validação de sintaxe XCLIENT aqui. Esse
permite enviar XCLIENT inválido ao servidor de destino para teste. Se não
XCLIENT_STRING é passado na linha de comando, swaks irá solicitar e ler o valor
STDIN.

A opção --xclient pode ser misturada livremente com as opções --xclient- * acima. Se
"--xclient-addr 192.168.0.1 --xclient 'FOO = bar NAME = wind'" é dado a swaks, "XCLIENT
ADDR = 192.168.0.1 FOO = bar NAME = wind "será enviado ao servidor de destino.

--xclient-opcional
--xclient-opcional-estrito
Em operação normal, definir uma das opções --xclient * fará com que um
A transação XCLIENT deve ocorrer para prosseguir (ou seja, XCLIENT precisa ser
anunciados, todos os atributos solicitados pelo usuário precisam ter sido anunciados, e o
o servidor precisa ter aceito a solicitação XCLIENT dos swaks). Essas opções mudam isso
comportamento. --xclient-optional diz aos swaks para prosseguir incondicionalmente após o XCLIENT
estágio da transação SMTP, independentemente de ela ter sido bem-sucedida.
--xclient-optional-strict é semelhante, mas mais granular. A versão estrita irá
continuar para XCLIENT não foi anunciado, mas falhará se XCLIENT foi tentado, mas ocorreu
não teve sucesso.

DADOS OPÇÕES

Essas opções referem-se ao conteúdo da parte DATA da transação SMTP.

-d, --data [porção de dados]
Use o argumento como todo o conteúdo de DATA ou avise o usuário se nenhum argumento for especificado.
Se o argumento '-' for fornecido, os dados serão lidos do STDIN. Se qualquer outro
argumento é fornecido e representa o nome de um arquivo que pode ser aberto, o conteúdo de
o arquivo será usado. Qualquer outro argumento será ele mesmo para o conteúdo de DATA.

O valor pode estar em uma única linha, com \ n (ascii 0x5c, 0x6e) representando onde
quebras de linha devem ser colocadas. Os pontos iniciais serão citados. Fechar o ponto não é
obrigatório, mas é permitido. O valor padrão para esta opção é "Data:% DATE% \ nPara:
% TO_ADDRESS% \ nDe:% FROM_ADDRESS% \ nSubject: teste% DATE% \ nX-Mailer: swaks v $ p_version
jetmore.org/john/code/swaks/\n%NEW_HEADERS%\n%BODY%\n ".

A análise de token muito básica é executada na parte DATA. Veja --use-old-data-tokens
para obter detalhes sobre os tokens de um caractere marcados como obsoletos. A seguir
A tabela mostra os tokens reconhecidos e seus valores de substituição:

%A PARTIR DO ENDEREÇO%
Substituído pelo remetente do envelope. Substitui o token% F obsoleto.

%ENDEREÇAR%
Substituído pelo (s) destinatário (s) do envelope. Substitui o token% T obsoleto.

%ENCONTRO%
Substituída pela hora atual em um formato adequado para inclusão na Data:
cabeçalho. Observe que esta tentativa de usar o módulo padrão Hora :: Local para fuso horário
cálculos. Se este módulo não estiver disponível, a string de data estará em GMT.
Substitui o token% D obsoleto.

% NEW_HEADERS%
Substituído pelo conteúdo da opção --add-header. Se --add-header não for
especificado, este token é simplesmente removido. Substitui o token% H obsoleto.

%CORPO%
Substituído pelo valor especificado pela opção --body. Veja --body para padrão.
Substitui o token% H obsoleto.

--use tokens de dados antigos
Em versões anteriores de swaks os tokens DATA conforme descrito na opção --data acima
utilizou tokens de um único caractere (por exemplo,% F). Essas não eram uma ótima escolha para o padrão
tokens, e provou ser especialmente problemático com idiomas codificados, diferentes do inglês, onde
essas combinações de caracteres podem ser comuns. Os tokens de um único caractere eram
substituída pelas versões ligeiramente menos sujeitas a erros listadas acima. A retenção de
os tokens antigos e a inclusão desta opção para ativá-los têm como objetivo
ajuda temporária para usuários que possuem um corpus de mensagem existente usando os tokens antigos. o
tokens de um caractere e a opção --use-old-data-tokens devem ser considerados
obsoleto e provavelmente removido na próxima versão.

-dab, --dump-como-corpo
Se --dump-as-body for usado e nenhuma outra opção for usada para alterar o corpo padrão de
a mensagem, o corpo é substituído por uma saída semelhante à saída do que é
fornecido por --dump. A estrofe de capacidade inicial do programa --dump não é exibida e
a seção "dados" não está incluída. Além disso, --dump sempre inclui senhas.
Por padrão --dump-as-body não inclui senhas, embora isso possa ser alterado com
--dump-as-body-mostra-senha.

-dabsp, --dump-as-body-mostra-senha
Faz com que --dump-as-body inclua senhas em texto simples. Esta opção não é recomendada.
Esta opção implica --dump-as-body.

--body [especificação do corpo]
Especifique o corpo do e-mail. O padrão é "Esta é uma correspondência de teste". Se não
argumento para --body é fornecido, pronto para fornecer um interativamente. Se '-' for fornecido,
o corpo será lido a partir da entrada padrão. Se qualquer outro texto for fornecido e o texto
representa um arquivo que pode ser aberto, o conteúdo desse arquivo é usado como o corpo. Se isso
não representa um arquivo que pode ser aberto, o próprio texto é usado como corpo.

Se a mensagem for forçada para o formato MIME (consulte --attach), o argumento para esta opção
será incluído não codificado como a primeira parte MIME. Seu tipo de conteúdo sempre será
texto / simples.

--attach [especificação do anexo]
Quando uma ou mais opções --attach são fornecidas, a mensagem é alterada para uma
mensagem MIME multiparte / mista. Os argumentos para --attach são processados ​​da mesma forma que
--body com relação a stdin, conteúdo de arquivo, etc. --attach pode ser fornecido com vários
vezes para criar vários anexos. Por padrão, cada anexo é anexado como um
arquivo de aplicativo / fluxo de octeto. Veja --attach-type para alterar este comportamento.

Se um nome de arquivo for especificado, a codificação MIME incluirá esse nome de arquivo. Ver
--attach-name para obter mais detalhes sobre a nomenclatura de arquivos.

É legal que '-' (STDIN) seja especificado como um argumento várias vezes (uma vez para
--body e várias vezes para --attach). Nesse caso, o mesmo conteúdo será
anexado sempre que for especificado. Isso é útil para anexar o mesmo conteúdo
com vários tipos de MIME.

--attach-type [tipo mime]
Por padrão, o conteúdo que obtém MIME anexado a uma mensagem com a opção --attach é
codificado como aplicativo / fluxo de octeto. --attach-type muda o tipo MIME para cada
--attach opção que o segue. Pode ser especificado várias vezes.

--attach-name [nome]
Esta opção define o nome do arquivo que será incluído na parte MIME criada para o
próxima opção --attach. Se nenhum argumento for definido para esta opção, não causa nenhum nome de arquivo
informações a serem incluídas para a próxima parte MIME, mesmo se swaks pudessem gerá-la
a partir do nome do arquivo local.

-ah, --add-header [cabeçalho]
Esta opção permite que cabeçalhos sejam adicionados aos DADOS. Se% H estiver presente no DATA ele
é substituído pelo argumento desta opção. Se% H não estiver presente, o argumento é
inserido entre as duas primeiras novas linhas consecutivas em DATA (ou seja, é
inserido no final dos cabeçalhos existentes).

A opção pode ser especificada várias vezes ou uma única vez com vários
cabeçalhos separados por uma string literal '\ n'. Portanto, "--add-header 'Foo: bar' --add-header
'Baz: foo' "e" --add-header 'Foo: bar \ nBaz: foo' "acabam adicionando os mesmos dois
cabeçalhos.

--header [cabeçalho e dados], --h-cabeçalho [dados]
Essas opções permitem uma forma de alterar os cabeçalhos que já existem nos DATA. '--cabeçalho
"Assunto: foo" 'e' --h-Assunto foo 'são equivalentes. Se o cabeçalho ainda não
existir nos dados, então este argumento se comporta de forma idêntica a --add-header. No entanto, se
o cabeçalho já existe, ele é substituído pelo especificado.

-g Se especificado, swaks lerá o valor DATA para o e-mail de STDIN. Isto é
equivalente a "--data -". Se houver uma linha From_ no e-mail, ela será removida
(mas veja a opção -nsf). Útil para entregar mensagem real (armazenada em arquivos) em vez
de usar mensagens de exemplo.

--no-data-fixup, -ndf
Esta opção força os swaks a não massagear a parte DATA do e-mail. Esse
inclui substituição de token, From_ stripping, adição de ponto final, --body / attachment
inclusão e quaisquer adições de cabeçalho. Esta opção só é realmente útil quando usada com
--data, uma vez que a parte interna de DADOS padrão usa tokens.

--no-strip-from, -nsf
Não retire a linha From_ da parte DATA, se houver.

SAÍDA OPÇÕES

Por padrão, swaks fornece uma transcrição de suas transações para seu chamador (STDOUT / STDERR).
Esta transcrição visa ser uma representação o mais fiel possível da transação
embora modifique esta saída adicionando prefixos informativos às linhas e por
fornecendo versões em texto simples de transações TLS

Os "prefixos informativos" são chamados de dicas de transação. Essas dicas são
inicialmente composto por essas linhas de marcação que são a saída dos próprios swaks,
mensagens informativas ou de erro e aquelas que indicam uma linha de dados realmente enviada ou
recebido em uma transação. Esta tabela indica as dicas e seus significados:

=== Indica uma linha informativa gerada por swaks

*** Indica um erro gerado em swaks

-> Indica uma linha esperada enviada por swaks para o servidor de destino

~> Indica uma linha esperada criptografada por TLS enviada por swaks para o servidor de destino

**> Indica uma linha inesperada enviada por swaks para o servidor de destino

* ~> Indica uma linha inesperada criptografada por TLS enviada por swaks para o servidor de destino

> Indica um pedaço bruto de teste enviado por swaks para um servidor de destino (veja --show-raw-text).
Não existe o conceito de "esperado" ou "inesperado" neste nível.

<- Indica uma linha esperada enviada pelo servidor de destino para swaks

<~ Indica uma linha esperada criptografada por TLS enviada pelo servidor de destino para swaks

<** Indica uma linha inesperada enviada pelo servidor de destino para swaks

<~ * Indica uma linha inesperada criptografada por TLS enviada pelo servidor de destino para swaks

<Indica um pedaço de texto bruto recebido por swaks de um servidor de destino (ver
--show-raw-text). Não existe o conceito de "esperado" ou "inesperado" neste nível.

As opções a seguir controlam o que e como a saída é exibida para o chamador.

-n, --suprimir dados
Resume a parte DATA da transação SMTP em vez de imprimir todas as linhas.
Esta opção é muito útil, quase obrigatória, ao usar swaks para enviar certos
teste de e-mails. E-mails com anexos, por exemplo, sobrecarregam rapidamente um terminal
se DATA não for suprimido.

-stl, --show-time-lapse [i]
Mostra o lapso de tempo entre os pares de envio / recebimento. Esta opção é mais útil quando
Time :: HiRes está disponível, caso em que o lapso de tempo será exibido em
milésimos de segundo. Se Time :: HiRes não estiver disponível ou "i" for fornecido como um argumento
o lapso será exibido apenas em segundos inteiros.

-nih, --no-info-dicas
Não exiba a dica de transação para transações informativas. Isso é mais
útil quando precisar copiar alguma parte das linhas informativas, por exemplo, o
saída do certificado de --tls-get-peer-cert.

-nsh, --no-enviar-dicas
-nrh, --no-receive-hints
-nth, --no-hints
--no-send-hints e --no-receive-hints suprimem o prefixo da transação de send e
receber linhas, respectivamente. Isso geralmente é útil ao copiar alguma parte do
transação para uso em outro lugar (por exemplo, "--no-send-hints --hide-receive
--hide-informational "é uma maneira útil de obter apenas os comandos do lado do cliente para um determinado
transação). --no-hints é idêntico a especificar --no-send-hints e
--sem receber dicas.

Não mostra dicas de transação (útil em conjunto com -hr para criar capacidade de copiar / colar
transações).

-raw, --show-texto bruto
Esta opção imprimirá um dump hexadecimal de dados brutos enviados e recebidos por swaks. Cada hex
despejo é o conteúdo de uma única leitura ou gravação na rede. Isso deve ser
idêntico ao que já está sendo mostrado (com exceção dos caracteres \ r
sendo removido). Esta opção é útil para ver detalhes quando os servidores estão enviando lotes
de dados em pacotes únicos ou dividindo linhas individuais em pacotes múltiplos. Se
você realmente precisa ir a fundo nessa área, provavelmente é melhor com um pacote
sniffer, mas essa opção é um bom primeiro passo para detectar problemas de conexão estranhos.

--arquivo de saída
--output-file-stdout
--output-file-stderr
Essas opções permitem que o usuário envie saída para arquivos em vez de stdout / stderr. o
a primeira opção envia ambos para o mesmo arquivo. Os argumentos de & STDOUT e & STDERR são
tratado especialmente, referindo-se aos identificadores de arquivo "normais", então "--output-file-stderr
'& STDOUT' "redirecionaria STDERR para STDOUT.

-pp, --proteger-prompt
Não ecoe a entrada do usuário em prompts que são potencialmente sensíveis (agora apenas
senha de autenticação). Veja também --auth-hide-password

-hr, --ocultar-receber
Não exibe linhas enviadas do servidor remoto sendo recebidas por swaks

-hs, --hide-enviar
Não exibe linhas sendo enviadas por swaks para o servidor remoto

-oi, --hide-informativo
Não exiba linhas informativas sem erros do próprio swaks.

-ha, --ocobrir tudo
Não exiba nenhum conteúdo no terminal.

-S, --silent [nível]
Faça swaks ficar em silêncio. Se nenhum argumento for fornecido ou se um argumento de "1" for fornecido,
não imprime nenhuma saída, a menos / até que ocorra um erro, após o qual todas as saídas são mostradas. Se um
argumento de "2" é fornecido, apenas erros de impressão. Se "3" for fornecido, não mostra nenhuma saída.

--Apoio, suporte
Recursos de impressão e saída. Certos recursos requerem módulos perl não padrão.
Esta opção avalia se esses módulos estão presentes e exibe quais
funcionalidade está disponível e qual não está, e quais módulos precisam ser adicionados
para obter a funcionalidade ausente.

--jogar fora
Esta opção faz com que os swaks imprimam os resultados do processamento da opção, imediatamente antes
o correio teria sido enviado. Nenhum email será enviado quando --dump for usado. Observe que
--dump é considerado uma ferramenta de autodiagnóstico puro e nenhum esforço é feito ou será
nunca deve ser feito para mascarar senhas na saída --dump.

--Socorro
Exiba essas informações de ajuda.

--versão
Exibir informações da versão.

PORTABILIDADE

SISTEMAS OPERACIONAIS
Este programa foi projetado principalmente para uso em sistemas operacionais tipo Unix, e
deve funcionar em qualquer versão razoável do mesmo. Foi desenvolvido e testado em
Solaris, Linux e Mac OS X e todos eles possuem recursos completos.

Este programa é conhecido por demonstrar a funcionalidade básica do Windows usando
Perl de ActiveState. Não foi totalmente testado. Funciona com SMTP básico
funcionalidade e os tipos de autenticação LOGIN, PLAIN e CRAM-MD5. Desconhecido é qualquer TLS
funcionalidade e os tipos de autenticação NTLM / SPA e DIGEST-MD5.

Como este programa deve funcionar em qualquer lugar em que o Perl funcione, gostaria de saber sobre
quaisquer novos sistemas operacionais que você usou completamente, bem como quaisquer problemas
encontrado em um novo sistema operacional.

SERVIDORES DE CORREIO
Este programa foi desenvolvido quase exclusivamente contra servidores de email Exim. Foi
usado casualmente pelo autor, embora não completamente testado, com Sendmail, Smail,
Exchange, Oracle Collaboration Suite, qpsmtpd e Communigate. Porque tudo
funcionalidade em swaks é baseada em padrões conhecidos e deve funcionar com qualquer
servidor de correio moderno. Se algum problema for encontrado, por favor alerte o autor no endereço
abaixo.

SAIR CÓDIGOS

0 nenhum erro ocorreu

1 erro ao analisar opções de linha de comando

2 erros ao conectar ao servidor remoto

3 tipo de conexão desconhecido

4 durante a execução com tipo de conexão de "tubo", problema fatal ao escrever ou ler de
o processo filho

5 durante a execução com o tipo de conexão de "tubo", o processo filho morreu inesperadamente. Esse
pode significar que o programa especificado com --pipe não existe.

6 Conexão fechada inesperadamente. Se o fechamento for detectado em resposta ao 'QUIT'
swaks envia após uma resposta inesperada, o código de erro para aquele
resposta é usada em seu lugar. Por exemplo, se um servidor de e-mail retorna uma resposta 550 para um
CORREIO DE: e imediatamente fecha a conexão, o swaks detecta que o
a conexão é fechada, mas usa o código de saída 23 mais específico para detalhar a natureza do
a falha. Se, em vez disso, o servidor retornar um código 250 e, em seguida, fechar imediatamente o
conexão, swaks usará o código de saída 6 porque não há uma saída mais específica
código.

10 erro nos pré-requisitos (módulo necessário não disponível)

21 erro ao ler banner inicial do servidor

22 erro na transação HELO

23 erro na transação MAIL

24 RCPTs não são aceitos

25 servidor devolveu erro ao pedido de DATA

26 o servidor não aceitou o correio a seguir os dados

27 servidor retornou erro após solicitação de encerramento de sessão normal

28 erro na transação AUTH

29 erro na transação TLS

32 erro em EHLO após negociação TLS

33 erro na transação XCLIENT

34 erro em EHLO seguindo XCLIENT

SOBRE NÓS A NOME

O nome "swaks" é uma (espécie de) acrônimo para "SWiss Army Knife Smtp". Foi escolhido para ser
bastante distinto e pronunciável. Embora "swaks" seja único como o nome de um software
pacote, tem alguns outros significados que não são de software. Envie outros usos de "swak" ou
"swaks" para inclusão.

"Selado com um beijo"
SWAK / SWAKs aparecem ocasionalmente na internet com o significado "com amor".

ruim / ruim / doente (afrikaans)
Visto no título "SA se bes en swaks gekledes em 2011", que foi traduzido como
"melhor e pior vestida" por falantes nativos. O Google Tradutor não gosta de "swaks
gekledes ", mas irá traduzir" swak "como" pobre "e" swak geklede "como" mal vestido ".

FALA COM

[email protected]
Use este endereço para contato geral, perguntas, patches, solicitações, etc.

[email protected]
Se você gostaria de ser colocado em uma lista para receber notificações quando uma nova versão do
swaks foi liberado, envie um e-mail para este endereço.

http://www.jetmore.org/john/code/swaks/
Os logs de alterações, esta ajuda e a versão mais recente podem ser encontrados neste link.

Use swaks online usando serviços onworks.net