swaks - En ligne dans le Cloud

PROGRAMME:

Nom

swaks - Swiss Army Knife SMTP, le testeur de transactions smtp tout usage

DESCRIPTION

Le principal objectif de conception de swaks est d'être un test SMTP flexible, scriptable et orienté transaction
outil. Il gère les fonctionnalités et extensions SMTP telles que TLS, l'authentification et
canalisation; plusieurs versions du protocole SMTP, notamment SMTP, ESMTP et LMTP ; et
plusieurs méthodes de transport, y compris les sockets de domaine unix, les sockets de domaine Internet et
tuyaux vers les processus engendrés. Les options peuvent être spécifiées dans les variables d'environnement,
fichiers de configuration, et la ligne de commande permettant une configurabilité et une facilité d'utilisation maximales
pour les opérateurs et les scripteurs.

RAPIDE La START

Envoyez un e-mail de test standard à [email protected] sur le port 25 de test-server.example.net :

swaks --à [email protected] --server serveur-test.exemple.net

Envoyer un e-mail de test standard, nécessitant une authentification CRAM-MD5 en tant qu'utilisateur [email protected].
Un en-tête "X-Test" sera ajouté au corps de l'e-mail. Le mot de passe d'authentification sera
demandé.

swaks --à [email protected] --de [email protected] --auth CRAM-MD5 --auth-utilisateur [email protected] --header-X-Test "tester l'e-mail"

Testez un antivirus à l'aide d'EICAR dans une pièce jointe. Ne pas afficher le message DATA part. :

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

Testez un scanner de spam à l'aide de GTUBE dans le corps d'un e-mail, acheminé via les enregistrements MX pour
exemple.com :

swaks --à [email protected] --body /chemin/vers/gtube/fichier

Envoyez un e-mail de test standard à [email protected] utilisant le protocole LMTP via un UNIX
fichier de socket de domaine

swaks --à [email protected] --socket /var/lda.sock --protocole LMTP

Signalez tous les destinataires dans un fichier texte qui ne sont pas vérifiables sur un serveur de test :

pour E dans `cat /chemin/vers/email/fichier`
do
swaks --to $E --server test-server.example.com --quit-after RCPT --hide-all
[ $ ? -ne 0 ] && echo $E
fait

CONDITIONS ET CONVENTIONS

Ce document essaie d'être cohérent et spécifique dans son utilisation des termes suivants pour
réduire la confusion.

Transaction
Une transaction est l'ouverture d'une connexion via un transport vers une cible et l'utilisation d'un
protocole de messagerie pour tenter de remettre un message.

Cible
La cible d'une transaction est la chose à laquelle swaks se connecte. Ce terme générique est
utilisé tout au long de la documentation parce que la plupart des autres termes impliquent incorrectement quelque chose
sur le moyen de transport utilisé.

Transport
Le transport est la méthode sous-jacente utilisée pour se connecter à la cible.

Passerelle
Le protocole est le langage d'application utilisé pour communiquer avec la cible. Cette
document utilise SMTP pour parler génériquement des trois protocoles pris en charge à moins qu'il
précise qu'il s'agit du protocole spécifique « SMTP » et exclut les autres.

Message
Les protocoles SMTP existent pour transférer des messages, un ensemble d'octets dans un format convenu
qui a un expéditeur et un destinataire.

Enveloppe
L'enveloppe d'un message contient le « vrai » expéditeur et destinataire d'un message. Ça peut
également appelés ses composants, enveloppe-expéditeur et enveloppe-destinataires. Il est
Il est important de noter qu'une enveloppe de messages ne doit pas nécessairement correspondre à ses destinataires et à ses destinataires :
En-têtes.

DONNEES
La partie DATA d'une transaction SMTP est le message réel qui est
transporté. Il se compose à la fois des en-têtes du message et de son corps. DONNÉES et corps
sont parfois utilisés comme synonymes, mais ce sont toujours deux choses distinctes dans ce
document.

En-têtes
Les en-têtes d'un message sont définis comme toutes les lignes de la section DATA du message avant
la première ligne vierge. Ils contiennent des informations sur l'email qui sera affiché
au destinataire tels que À :, De :, Objet :, etc. Dans ce document, les en-têtes seront
toujours être écrit avec une première lettre en majuscule et un deux-points à la fin.

Les chuchotements
Le corps d'un message est la partie de sa section DATA qui suit la première ligne vide.

OPTION TRAITEMENT DES SEMENCES

Pour éviter toute confusion potentielle dans ce document, un drapeau à swaks est toujours appelé
une option". Si l'option prend des données supplémentaires, ces données supplémentaires sont appelées
un argument à l'option. Par exemple, "--de [email protected]" pourrait être fourni à
swaks sur la ligne de commande, avec "--from" étant l'option et "[email protected]" étant
--de l'argument de.

Des options peuvent être données aux swaks de trois manières. Ils peuvent être spécifiés dans une configuration
fichier, dans les variables d'environnement et sur la ligne de commande. Selon l'option spécifique
et qu'un argument lui soit donné ou non, swaks peut demander à l'utilisateur l'argument.

Lorsque swaks évalue ses options, il recherche d'abord un fichier de configuration (soit dans un
emplacement par défaut ou spécifié avec --config). Ensuite, il évalue toutes les options dans
Variables d'environnement. Enfin, il évalue les options de la ligne de commande. A chaque tour de
traitement, toutes les options définies précédemment seront remplacées. De plus, toute option peut être
préfixé par "no-" pour faire oublier aux swaks que la variable avait été précédemment définie.
Cette capacité est nécessaire car de nombreuses options traitent défini mais sans argument
différemment que non défini.

Le mécanisme et le format exacts d'utilisation de chacun des types sont répertoriés ci-dessous.

FICHIER DE CONFIGURATION
Un fichier de configuration peut être utilisé pour définir des options couramment utilisées ou anormalement détaillées.
Par défaut, swaks recherche dans l'ordre $SWAKS_HOME/.swaksrc, $HOME/.swaksrc et
$REPLOG/.swaksrc. Si l'un de ceux-ci existe (et --config n'a pas été utilisé)
ce fichier est utilisé comme fichier de configuration.

De plus, un fichier de configuration dans un emplacement différent de celui par défaut peut être spécifié en utilisant
--config. S'il est défini et qu'aucun argument n'est donné, swaks n'en utilisera aucun
fichier de configuration, y compris tout fichier par défaut. Si --config pointe vers un
fichier, il est utilisé comme fichier de configuration, remplaçant toute valeur par défaut pouvant exister. Si
il pointe vers un fichier non lisible et une erreur s'affichera et les swaks se termineront.

Un ensemble de valeurs par défaut « portables » peut également être créé en ajoutant des options à la fin de la
fichier programme swaks. Tel qu'il est distribué, la dernière ligne de swaks doit être "__END__". Tout
les lignes ajoutées après __END__ seront traitées comme le contenu d'un fichier de configuration.
Cela permet à un ensemble de préférences utilisateur d'être automatiquement copié d'un serveur à l'autre
dans un seul fichier.

Si les fichiers présents et de configuration n'ont pas été explicitement désactivés, le __END__
config est toujours lu. Un seul autre fichier de configuration sera utilisé par simple
invocation de swaks, même si plusieurs fichiers de configuration sont spécifiés. En précisant
l'option --config sans argument désactive le traitement des deux __END__
config et tous les fichiers de configuration réels.

Dans un fichier de configuration, les lignes commençant par un dièse (#) sont ignorées. Toutes les autres lignes
sont supposés être une option aux swaks, avec le ou les tirets de début facultatifs.
Tout ce qui se trouve après le premier espace d'une ligne d'option est supposé être l'argument de l'option
et n'est pas traité par shell. Par conséquent, les citations sont généralement inutiles et seront
inclus littéralement dans l'argument. Voici un exemple du contenu d'un
fichier de configuration:

# utilisez toujours cet expéditeur, quel que soit le serveur ou l'utilisateur connecté
--de [email protected]
# Je préfère que mes e-mails de test aient un joli en-tête de. Noter
# le manque de tirets sur option et le manque de guillemets autour
# argument complet.
h-De : « exemple de Fred »[email protected]>

VARIABLES D'ENVIRONNEMENT
Les options peuvent être fournies via des variables d'environnement. Les variables sont sous la forme
$SWAKS_OPT_name, où name est le nom de l'option qui serait spécifié sur le
ligne de commande. Parce que les tirets ne sont pas autorisés dans les noms de variables d'environnement dans la plupart des
shells unix, aucun tiret de début ne doit être utilisé et tout tiret à l'intérieur de l'option
le nom doit être remplacé par des traits de soulignement. Ce qui suit créerait les mêmes options
montré dans l'exemple de fichier de configuration :

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

Définir une variable sur une valeur vide revient à la spécifier sur la ligne de commande
sans argument. Par exemple, définir SWAKS_OPT_server="" entraînerait des swaks à
demander l'utilisation du serveur auquel se connecter à chaque invocation.

En plus de définir l'équivalent des options de ligne de commande, SWAKS_HOME peut être défini
dans un répertoire contenant le .swaksrc par défaut à utiliser.

OPTIONS DE LIGNE DE COMMANDE
La dernière méthode pour fournir des options aux swaks est via la ligne de commande. Les options
se comporter d'une manière cohérente avec la plupart des programmes de ligne de commande unix-ish. De nombreuses options
ont à la fois une forme courte et une forme longue (par exemple -s et --server). Par convention courte
les options sont spécifiées avec un seul tiret et les options longues sont spécifiées avec un double
tiret. Ceci n'est qu'une convention et l'un ou l'autre préfixe fonctionnera avec l'un ou l'autre type.

Ce qui suit montre l'exemple montré dans le fichier de configuration et l'environnement
sections variables :

$ swaks --de [email protected] --h-De : '"Exemple de Fred"[email protected]>'

TRANSPORTS

les swaks peuvent se connecter à une cible via des pipes unix ("pipes"), des sockets de domaine unix ("unix
sockets"), ou des sockets de domaine Internet ("network sockets"). Connexion via des sockets réseau
est le comportement par défaut. En raison du caractère singulier du transport utilisé, chaque ensemble
d'options dans la section suivante s'excluent mutuellement. Spécifier plus d'un des
--server, --pipe ou --socket entraînera une erreur. Mélanger d'autres options entre
Les types de transport n'entraîneront que l'ignorance des options non pertinentes. Ci-dessous un
brève description de chaque type de transport et des options qui lui sont spécifiques
type de transports.

PRISES DE RÉSEAU
Ce transport tente de livrer un message via TCP/IP, la méthode standard pour
livraison SMTP. Il s'agit du transport par défaut pour les swaks. Si aucun de --server,
--pipe ou --socket sont donnés, ce transport est utilisé et le serveur cible est
déterminé à partir du domaine du destinataire (voir --server ci-dessous pour plus de détails).

Ce transport nécessite le module IO::Socket qui fait partie du perl standard
Distribution. Si ce module n'est pas chargeable, essayer d'utiliser un ce transport
entraîner une erreur et l'arrêt du programme.

IPv6 est pris en charge lorsque le module IO::Socket::INET6 est présent.

-s, --server [serveur de messagerie cible[:port]]
Dites explicitement à swaks d'utiliser les sockets réseau et spécifiez le nom d'hôte ou l'IP
adresse à laquelle se connecter, ou invite si aucun argument n'est donné. Si cette option est
pas donné et aucune autre option de transport n'est donnée, le serveur de messagerie cible est
déterminé à partir des enregistrements DNS appropriés pour le domaine de l'e-mail du destinataire
adresse à l'aide du module Net::DNS. Si Net::DNS n'est pas disponible, les swaks
essayez de vous connecter à localhost pour livrer. Le port cible peut éventuellement être défini
ici. Les formats pris en charge pour cela incluent SERVER:PORT (noms pris en charge et IPv4
adresses) ; [SERVEUR] : PORT et SERVEUR/PORT (noms pris en charge, IPv4 et IPv6
adresses). Voir aussi --copy-routing.

-p, --port [port]
Spécifiez quel port TCP sur la cible doit être utilisé, ou demandez si aucun argument n'est
répertorié. L'argument peut être un nom de service (tel que récupéré par getservbyname(3)) ou
un numéro de port. Le port par défaut est déterminé par l'option --protocol. Voir
--protocole pour plus de détails.

-li, --local-interface [IP ou nom d'hôte[:port]]
Utilisez l'argument comme interface locale pour la connexion SMTP sortante, ou invite
user si aucun argument n'est donné. L'argument peut être une adresse IP ou un nom d'hôte. Défaut
l'action est de laisser le système d'exploitation choisir l'interface locale. Voir --server pour
commentaires supplémentaires sur :port format.

-lp, --local-port [port]
Spécifiez le port de sortie d'où émaner la transaction. Si cette option est
pas spécifié, le système choisira un port éphémère. Notez que les utilisateurs réguliers
ne peut pas spécifier certains ports.

--copy-routing [domaine]
L'argument est interprété comme la partie domaine d'une adresse e-mail et il est utilisé
pour trouver le serveur cible en utilisant la même logique qui serait utilisée pour rechercher le
serveur cible pour une adresse e-mail de destinataire. Voir l'option --to pour plus de détails
sur la façon dont la cible est déterminée à partir du domaine de messagerie.

-4, -6
Forcer IPv4 ou IPv6.

PRISES UNIX
Cette méthode de transport tente de livrer des messages via un fichier socket de domaine unix.
Ceci est utile pour tester les MTA/MDA qui écoutent les fichiers socket (par exemple, tester
livraison LMTP à Cyrus). Ce transport nécessite le module IO::Socket qui fait partie
de la distribution perl standard. Si ce module n'est pas chargeable, essayez d'utiliser
ce transport entraînera une erreur et l'arrêt du programme.

--socket [/chemin/vers/socket/fichier]
Cette option prend comme argument un fichier socket de domaine unix. Si swaks est incapable
pour ouvrir ce socket, il affichera une erreur et quittera.

TUYAUX
Ce transport tente de générer un processus et de communiquer avec lui via des canaux. le
Le programme généré doit être prêt à se comporter comme un serveur de messagerie sur STDIN/STDOUT. Tout
Le MTA conçu pour fonctionner à partir d'inet/xinet devrait le prendre en charge. De plus, certains MTA
fournir des modes de test qui peuvent être communiqués via STDIN/STDOUT. Ce transport
peut être utilisé pour automatiser ces tests. Par exemple, si vous avez implémenté la vérification DNSBL
avec Exim et que vous vouliez vous assurer que cela fonctionnait, vous pouviez exécuter 'swaks --pipe
"exim -bh 127.0.0.2"'. Dans un monde idéal, le processus auquel vous parlez devrait se comporter
exactement comme un serveur SMTP sur stdin et stdout. Tout débogage doit être envoyé à
stderr, qui sera dirigé vers votre terminal. Dans le monde réel, les swaks peuvent
gèrent généralement certains débogages sur la sortie standard de l'enfant, mais il n'y a aucune garantie sur la façon dont
beaucoup qu'il peut gérer.

Ce transport nécessite le module IPC::Open2 qui fait partie du standard perl
Distribution. Si ce module n'est pas chargeable, essayer d'utiliser ce transport
entraîner une erreur et l'arrêt du programme.

--pipe [/chemin/vers/commande et arguments]
Fournissez un nom de processus et des arguments au processus. les swaks tenteront d'apparaître
le processus et communiquer avec lui via des tuyaux. Si l'argument n'est pas un
les swaks exécutables afficheront une erreur et quitteront.

PROTOCOLE OPTIONS

Ces options sont liées à la couche de protocole.

-t, --to [adresse-e-mail[,adresse-e-mail,...]]
Indique à swaks d'utiliser le ou les arguments comme destinataire de l'enveloppe pour l'e-mail, ou invite à
destinataire si aucun argument n'est fourni. Si plusieurs destinataires sont fournis et que le
le domaine du destinataire est nécessaire pour déterminer le routage du domaine du dernier destinataire
fourni est utilisé.

Il n'y a pas de valeur par défaut pour cette option. Si aucun destinataire n'est fourni via un
signifie que l'utilisateur sera invité à en fournir un de manière interactive. La seule exception à cela
est si une valeur --quit-after est fournie, ce qui entraînera la transaction smtp
terminé avant que le destinataire ne soit nécessaire.

-f, --from [adresse-e-mail]
Utilisez l'argument comme expéditeur d'enveloppe pour l'e-mail ou invitez l'utilisateur si aucun argument n'est spécifié.
La chaîne <> peut être fournie pour signifier l'expéditeur nul. Si l'utilisateur ne spécifie pas de
adresse de l'expéditeur, une valeur par défaut est utilisée. La partie domaine de l'expéditeur par défaut est un
meilleure estimation du nom de domaine complet de l'hôte local. La méthode de
la détermination de la partie locale varie. Sous Windows, Win32::Nom de connexion() est utilisé. sur unix-
plates-formes ish, la variable d'environnement $LOGNAME est utilisée si elle est définie. Autrement
obtenirpwuid(3) est utilisé. Voir aussi --force-getpwuid.

--ehlo, --lhlo, -h, --helo [chaîne-helo]
Chaîne à utiliser comme argument de la commande HELO/EHLO/LHLO, ou invite à utiliser si aucun argument n'est
spécifié. Si cette option n'est pas utilisée, une meilleure estimation du nom de domaine complet
de l'hôte local est utilisé. Si le module Sys::Hostname, qui fait partie de la base
distribution, n'est pas disponible, l'utilisateur sera invité à saisir une valeur HELO. Noter que
Sys::Hostname a été observé pour ne pas être en mesure de trouver le nom d'hôte local dans certains
conditions. Cela a le même effet que si Sys::Hostname n'était pas disponible.

-q, --quit-after [point d'arrêt]
Point auquel la transaction doit être arrêtée. Lorsque le point d'arrêt demandé
est atteint dans la transaction, et à condition que swaks ne se soit pas trompé avant
l'atteignant, swaks enverra "QUIT" et tentera de fermer la connexion proprement.
Ce sont les arguments valables et les notes sur leur signification.

CONNECTER, BANNIÈRE
Terminez la session après avoir reçu la bannière d'accueil de la cible.

PREMIER-HELO, PREMIER-EHLO, PREMIER-LHLO
Dans une session STARTTLS (mais pas tls-on-connect), terminez la transaction après
le premier des deux HELO. Dans une transaction non STARTTLS, se comporte de la même manière que HELO
(voir ci-dessous).

XCLIENT
Quitter après l'envoi de XCLIENT

TLS Quitte la transaction immédiatement après la négociation TLS. Notez que ce
se produit à des endroits différents selon que STARTTLS ou tls-on-connect sont
utilisé. Cela s'arrête toujours après le point où TLS aurait été négocié,
indépendamment du fait qu'il a été tenté.

HELO, EHLO, LHLO
Dans une session STARTTLS ou XCLIENT, quittez après le deuxième HELO. Sinon arrête
après le premier et unique HELO.

AUTH
Quitter après authentification. Cela se termine toujours après le point où l'authentification
aurait été négociée, qu'elle ait été tentée ou non.

COURRIER DE
Quitter après l'envoi de MAIL FROM:.

RCPT, À
Quitter après RCPT TO : est envoyé.

--timeout [heure]
Utilisez l'argument comme délai d'expiration de la transaction SMTP ou invitez l'utilisateur si aucun argument n'est fourni.
L'argument peut être soit un chiffre pur, qui sera interprété comme des secondes, soit
avoir un spécificateur s ou m (5s = 5 secondes, 3m = 180 secondes). Comme cas particulier, 0
signifie ne pas expirer les transactions. La valeur par défaut est 30s.

--protocole [protocole]
Spécifiez le protocole à utiliser dans la transaction. Les options valides sont affichées dans le
tableau ci-dessous. Actuellement, les protocoles « principaux » sont SMTP, ESMTP et LMTP. En utilisant
variantes de ces types de protocoles, on peut spécifier succinctement les ports par défaut, que ce soit
l'authentification doit être tentée, et le type de connexion TLS qui doit être
tenté. Le protocole par défaut est ESMTP. Ce tableau montre la disponibilité
arguments à --protocol et les options que chacun définit comme effet secondaire :

SMTP
SALUT, "-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"

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"

--pipeline
Si le serveur distant le prend en charge, essayez le PIPELINING SMTP (RFC 2920). C'est un
option plus jeune, si vous rencontrez des problèmes avec elle, veuillez en informer l'auteur.
Les problèmes potentiels incluent les serveurs acceptant les DONNÉES même s'il n'y avait pas de données valides
destinataires (les swaks doivent envoyer un corps vide dans ce cas, pas QUITTER) et des blocages causés
en envoyant des paquets en dehors de la taille de la fenêtre TCP.

--force-getpwuid
Dites à swaks d'utiliser la méthode getpwuid pour trouver la partie locale de l'expéditeur par défaut à la place
d'essayer d'abord $LOGNAME.

TLS / ENCRYPTION

Ce sont des options liées au cryptage de la transaction. Ceux-ci ont été testés et
confirmé pour fonctionner avec les trois modes de transport. Le module Net::SSLeay est utilisé pour
effectuer le cryptage lorsqu'il est demandé. Si ce module n'est pas chargeable, les swaks seront soit
ignorer la demande TLS ou la sortie d'erreur, selon que la demande était facultative.
STARTTLS est défini comme une extension dans le protocole ESMTP et sera indisponible si
--protocol est défini sur une variation de smtp. Parce que ce n'est pas défini dans le protocole
lui-même, --tls-on-connect est disponible pour tout type de protocole si la cible le prend en charge.

Un certificat local n'est pas requis pour qu'une connexion TLS soit négociée. Cependant, certains
les serveurs utilisent la vérification du certificat client pour vérifier que le client est autorisé à se connecter.
swaks peut être invité à utiliser un certificat local spécifique via l'utilisation de --tls-cert
et --tls-key options.

-tls
Nécessite une connexion pour utiliser STARTTLS. Quitter si TLS n'est pas disponible pour une raison quelconque (pas
annoncé, les négociations ont échoué, etc.).

-tlso, --tls-facultatif
Essayez d'utiliser STARTTLS si disponible, continuez avec la transaction normale si TLS était
impossible à négocier pour quelque raison que ce soit. Notez qu'il s'agit d'une option semi-inutile car
actuellement mis en œuvre car après un échec de négociation, l'état de la connexion
est inconnu. Dans certains cas, comme une incompatibilité de version, la connexion doit être laissée comme
texte en clair. Dans d'autres, comme un échec de vérification, le côté serveur peut penser qu'il
devrait continuer à parler TLS pendant que le client pense qu'il s'agit de texte en clair. Il peut y avoir un
essayez d'ajouter une détection d'état plus granulaire à l'avenir, mais pour l'instant, sachez simplement
que des choses étranges peuvent arriver avec cette option si la négociation TLS est tentée et
échoue.

-tlsos, --tls-facultatif-strict
Essayez d'utiliser STARTTLS si disponible. Procéder à la transaction si TLS est négocié
avec succès ou STARTTLS non annoncé. Si STARTTLS est annoncé mais TLS
les négociations échouent, traitez comme une erreur et annulez la transaction. En raison de la mise en garde notée
ci-dessus, c'est une option beaucoup plus sensée que --tls-facultatif.

--tlsc, --tls-on-connect
Initiez une connexion TLS immédiatement lors de la connexion. Selon la convention commune, si
cette option est spécifiée, le port par défaut passe de 25 à 465, bien que cela puisse
toujours être remplacé par l'option --port.

-tlsp, --tls-protocol SPÉCIFICATIONS
Spécifiez les protocoles à utiliser (ou à ne pas utiliser) lors de la négociation de TLS. A l'heure de ce
en écriture, les protocoles disponibles sont sslv2, sslv3, tlsv1, tlsv1_1 et tlsv1_2. le
la disponibilité de ces protocoles dépend de votre bibliothèque OpenSSL sous-jacente, donc
tous ces éléments peuvent ne pas être disponibles. La liste des protocoles disponibles est affichée dans le
sortie de --dump (en supposant que TLS soit disponible).

La chaîne de spécification est une liste délimitée par des virgules de protocoles qui peuvent être utilisés ou
non utilisé. Par exemple, 'tlsv1,tlsv1_1' ne réussira que si l'un de ces deux
protocoles est disponible à la fois sur le client et sur le serveur. Inversement,
'no_sslv2,no_sslv3' tentera de négocier n'importe quel protocole sauf sslv2 et sslv3.
Les deux formes de spécification ne peuvent pas être mélangées.

-chiffrement-tls CIPHER_STRING
L'argument de cette option est passé à la bibliothèque OpenSSL sous-jacente pour définir la liste
de chiffrements acceptables à utiliser pour la connexion. Le format de cette chaîne est
opaque aux swaks et est défini dans
http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT. Un bref exemple
serait --tls-cipher '3DES:+RSA'.

--tls-vérifier
Par défaut, swaks ne fait aucune vérification de certificat. Le paramètre --tls-verify
faire en sorte que swaks essaie de vérifier le certificat du serveur. Si cette option est définie et
le certificat du serveur n'est pas vérifiable (soit en utilisant l'autorité de certification par défaut du système
ou des informations d'autorité de certification personnalisées (voir --tls-ca-path)) La négociation TLS ne
réussir.

--tls-ca-path [ /chemin/vers/fichier CA | /chemin/vers/CAdir/ ]
Par défaut, les swaks utiliseront les informations d'autorité de certification par défaut de la bibliothèque OpenSSL sous-jacente pour
vérification des certificats de serveur. --tls-ca-path vous permet de spécifier un autre
emplacement. Voir http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html pour
détails du contenu du fichier/répertoire.

--tls-cert /chemin/vers/fichier
Fournissez un chemin vers un fichier contenant le certificat local que les swaks doivent utiliser si TLS est
négocié. L'argument chemin du fichier est obligatoire. Tel qu'il est actuellement mis en œuvre, le
certificat dans le fichier doit être au format PEM. Contactez l'auteur s'il y a un
besoin impérieux d'ASN1. Si cette option est définie, --tls-key est également requis.

--tls-key /chemin/vers/fichier
Fournissez un chemin vers un fichier contenant la clé privée locale que les swaks doivent utiliser si TLS est
négocié. L'argument chemin du fichier est obligatoire. Tel qu'il est actuellement mis en œuvre, le
certificat dans le fichier doit être au format PEM. Contactez l'auteur s'il y a un
besoin impérieux d'ASN1. Si cette option est définie, --tls-cert est également requis.

--tls-get-peer-cert [/chemin/vers/fichier]
Obtenez une copie du certificat de l'homologue TLS. Si aucun argument n'est donné, il sera
affiché sur STDOUT. Si un argument est donné, il est supposé être un chemin d'accès au système de fichiers
précisant où le certificat doit être écrit. Le certificat enregistré peut alors être
examiné à l'aide d'outils standard tels que la commande openssl. Si un fichier est spécifié son
le contenu sera écrasé.

AUTHENTIFICATION

swaks tentera de s'authentifier auprès du serveur de messagerie cible si cela lui est demandé. Cette
la section détaille les types d'authentification disponibles, les exigences, les options et leurs
interactions, et d'autres points délicats dans l'utilisation de l'authentification. Parce que l'authentification est
défini comme une extension dans le protocole ESMTP, il sera indisponible si --protocol est défini
à une variation de smtp.

Toutes les méthodes d'authentification nécessitent un codage base64. Si le module perl MIME::Base64 est
swaks chargeables tente de l'utiliser pour effectuer ces encodages. Si MIME::Base64 n'est pas
les swaks disponibles utiliseront leurs propres routines base64 embarquées. Ceux-ci sont plus lents que les
Routines MIME::Base64 et moins revues, bien qu'elles aient été testées de manière approfondie. À l'aide de
le module MIME::Base64 est encouragé.

Si l'authentification est requise (voir les options ci-dessous pour savoir quand elle est requise ou non) et
les exigences ne sont pas remplies pour le type d'authentification disponible, swaks affiche une erreur
et sorties. Cela peut se produire de deux manières : forcer les swaks à utiliser un
type d'authentification que les swaks ne peuvent pas utiliser en raison d'exigences manquantes ou autorisant les swaks à
utilisez n'importe quel type d'authentification, mais le serveur n'annonce que les types que les swaks ne peuvent pas prendre en charge. Dans
le premier cas élimine les erreurs au moment du traitement de l'option car il le sait à l'avance
ne pourra pas s'authentifier. Dans ce dernier cas, les swaks seront erronés au
étape d'authentification de la transaction smtp car swaks ne saura pas qu'il
pas en mesure de s'authentifier jusqu'à ce point.

Voici les types d'authentification pris en charge, y compris les notes individuelles et
exigences.

Les options suivantes affectent l'utilisation de l'authentification par swaks. Ces options sont toutes inter-
en relation. Par exemple, spécifier --auth-user implique --auth et --auth-password.
Spécifier --auth-facultatif implique --auth-user et --auth-password, etc.

-a, --auth [type-auth[,type-auth,...]]
Exiger des swaks pour s'authentifier. Si aucun argument n'est fourni, tous les types d'autorisation pris en charge
annoncés par le serveur sont essayés jusqu'à ce que l'un d'eux réussisse ou que tous échouent. Si un ou plusieurs
les types auth sont spécifiés en tant qu'argument, chacun que le serveur prend également en charge est essayé
dans l'ordre jusqu'à ce que l'un réussisse ou que tous échouent. Cette option nécessite des swaks pour s'authentifier,
donc si aucun type d'authentification commun n'est trouvé ou si aucune information d'identification ne réussit, swaks affiche un
erreur et sorties.

Les tableaux suivants répertorient les types d'autorisation valides

CONNEXION, PLAINE
Ces types d'authentification de base sont entièrement pris en charge et testés et n'ont aucun
exigences supplémentaires

CRAM-MD5
L'authentificateur CRAM-MD5 nécessite le module Digest::MD5. Il est entièrement testé
et censé fonctionner contre tout serveur qui l'implémente.

DIGEST-MD5
L'authentificateur DIGEST-MD5 (RFC2831) nécessite le module Authen::SASL. Version
20100211.0 et versions antérieures utilisaient Authen::DigestMD5 qui présentait des erreurs au niveau du protocole
ce qui l'empêchait de fonctionner avec certains serveurs. Authen::SASL's DIGEST-MD5
la manipulation est beaucoup plus robuste.

L'implémentation DIGEST-MD5 dans swaks est assez immature. Il prend actuellement en charge
uniquement le type de qop "auth", par exemple. Si vous avez l'expérience DIGEST-MD5 et
J'aimerais aider swaks à mieux prendre en charge DIGEST-MD5, veuillez me contacter.

La valeur "realm" du protocole DIGEST-MD5 peut être définie à l'aide du "realm" --auth-extra
mot-clé. Si aucun domaine n'est donné, une valeur par défaut raisonnable sera utilisée.

Les valeurs "digest-uri" du protocole DIGEST-MD5 peuvent être définies à l'aide de l'option --auth-extra
option. Par exemple, vous pouvez créer la valeur digest-uri de
"lmtp/mail.example.com/example.com" avec l'option "--auth-extra
dmd5-serv-type=lmtp,dmd5-host=mail.example.com,dmd5-serv-name=example.com". Le
La chaîne "digest-uri-value" et ses composants sont définis dans la RFC2831. Si aucun de
ces valeurs sont données, des valeurs par défaut raisonnables seront utilisées.

CRAM-SHA1
L'authentificateur CRAM-SHA1 nécessite le module Digest::SHA. Ce type n'a que
été testé par rapport à une implémentation non standard sur un serveur Exim et peut
présentent donc des lacunes dans la mise en œuvre.

NTLM/SPA/MSN
Ces authentificateurs nécessitent le module Authen::NTLM. Notez qu'il y a deux
modules utilisant l'espace de noms Authen::NTLM sur CPAN. La mise en œuvre de Mark Bush
(Authen/NTLM-1.03.tar.gz) est la version requise par swaks. Ce type a été
testé par rapport à Exim, Communigate et Exchange 2007.

En plus du nom d'utilisateur et du mot de passe standard, ce type d'authentification peut
reconnaissent également un "domaine". Le domaine peut être défini à l'aide du "domaine" --auth-extra
mot-clé. Notez que cela n'a jamais été testé avec un serveur de messagerie qui ne
ignorer DOMAIN afin que cela puisse être implémenté de manière incorrecte.

-ao, --auth-facultatif [auth-type[,auth-type,...]]
Cette option se comporte de la même manière que --auth sauf qu'elle demande l'authentification
plutôt que de l'exiger. Si aucun type d'authentification commun n'est trouvé ou aucune information d'identification
réussit, swaks procède comme si l'authentification n'avait pas été demandée.

-aos, --auth-facultatif-strict [auth-type[,auth-type,...]]
Cette option est un compromis entre --auth et --auth-facultatif. S'il n'y a pas d'auth-
types sont trouvés, swaks se comporte comme si --auth-facultatif était spécifié et continue avec
la transaction. Si swaks ne peut pas prendre en charge le type d'authentification demandé, le serveur ne le fait pas
annoncer tous les types d'authentification courants, ou si aucune information d'identification ne réussit, swaks se comporte comme si
--auth ont été utilisés et se termine avec une erreur.

-au, --auth-user [nom d'utilisateur]
Fournissez le nom d'utilisateur à utiliser pour l'authentification, ou invitez l'utilisateur à le saisir si ce n'est pas le cas.
argument est fourni. La chaîne <> peut être fournie pour signifier un nom d'utilisateur vide.

-ap, --auth-password [mot de passe]
Fournissez le mot de passe à utiliser pour l'authentification, ou invitez l'utilisateur à le saisir si aucun
argument est fourni. La chaîne <> peut être fournie pour signifier un mot de passe vide.

-ae, --auth-extra [MOT CLE=valeur[,...]]
Certains types d'authentification permettent d'inclure des informations supplémentaires dans le
processus d'authentification. Plutôt que d'ajouter une nouvelle option pour chaque recoin de
chaque authentificateur, l'option --auth-extra permet de fournir cette information.

Le tableau suivant répertorie les mots-clés actuellement reconnus et les authentificateurs
qui les utilisent

domaine, domaine
Les mots-clés de domaine et de domaine sont synonymes. L'utilisation de l'un ou l'autre définira le "domaine"
option dans NTLM/MSN/SPA et l'option "realm" dans DIGEST-MD5

type de serveur dmd5
Le mot-clé dmd5-serv-type est utilisé par l'authentificateur DIGEST-MD5 et est utilisé, dans
part, pour construire la chaîne digest-uri-value (voir RFC2831)

hôte dmd5
Le mot-clé dmd5-host est utilisé par l'authentificateur DIGEST-MD5 et est utilisé, dans
part, pour construire la chaîne digest-uri-value (voir RFC2831)

dmd5-serv-name
Le mot-clé dmd5-serv-name est utilisé par l'authentificateur DIGEST-MD5 et est utilisé, dans
part, pour construire la chaîne digest-uri-value (voir RFC2831)

-am, --auth-map [alias-auth=type-auth[,...]]
Fournit un moyen de mapper des noms alternatifs sur des types d'authentification de base. Utile pour tout
sites qui utilisent des noms alternatifs pour les types courants. Cette fonctionnalité est réellement utilisée
en interne pour mapper les types SPA et MSN sur le type de base NTLM. La ligne de commande
L'argument pour simuler cela serait "--auth-map SPA=NTLM,MSN=NTLM". Tous les auth-
les types répertoriés ci-dessus sont des cibles valides pour le mappage, à l'exception de SPA et MSN.

-apt, --auth-texte clair
Au lieu d'afficher les chaînes AUTH encodées en base64 au fur et à mesure qu'elles sont transmises, traduisez-les
en texte clair avant impression à l'écran.

-ahp, --auth-hide-password [chaîne de remplacement]
Si cette option est spécifiée, à chaque fois qu'un mot de passe lisible sera imprimé sur le
terminal (en particulier AUTH PLAIN et AUTH LOGIN) le mot de passe est remplacé par un
chaîne factice (ou le contenu de la "chaîne de remplacement" s'il est fourni). La ficelle factice
sera codé en base64 ou ne dépendra pas de l'option --auth-plaintext.

Notez que --auth-hide-password est similaire, mais pas identique, à --protect-prompt
option. Le premier empêche l'affichage des mots de passe dans la transaction SMTP
quelle que soit la manière dont ils sont saisis. Ce dernier protège les cordes sensibles lorsque le
l'utilisateur les tape sur le terminal, quelle que soit la façon dont la chaîne serait utilisée.

XCLIENT OPTIONS

XCLIENT est une extension SMTP introduite par le projet Postfix. XCLIENT permet un
client (correctement autorisé) pour dire à un serveur d'utiliser d'autres informations, telles que l'IP
adresse ou nom d'hôte, pour le client. Cela permet des chemins beaucoup plus faciles pour tester le courrier
configuration de serveur. Tous les détails sur le protocole sont disponibles sur
http://www.postfix.org/XCLIENT_README.html.

--xclient-addr [VALEUR]
--xclient-name [VALEUR]
--xclient-port [VALEUR]
--xclient-proto [VALEUR]
--xclient-helo [VALEUR]
--xclient-login [VALEUR]
--xclient-reverse-name [VALEUR]
Ces options spécifient les attributs XCLIENT qui doivent être envoyés au serveur cible. Si
[VALUE] n'est pas fourni, swaks demandera et lira la valeur sur STDIN. Voir
http://www.postfix.org/XCLIENT_README.html pour la documentation officielle sur ce que le
les attributs signifient et leurs valeurs possibles, y compris le spécial "[UNAVAILABLE]" et
Valeurs "[TEMPUNAVAIL]".

À titre d'exemple simple, définissez "--xclient-name foo.example.com --xclient-addr
192.168.1.1" entraînera l'envoi par les swaks de la commande SMTP "XCLIENT NAME=foo.example.com
ADDR=192.168.1.1".

Notez que l'attribut "REVERSE_NAME" ne semble pas apparaître dans le
Documentation. Il existe un fil de discussion sur la liste de diffusion qui le documente, consultable sur
http://comments.gmane.org/gmane.mail.postfix.user/192623.

Ces options peuvent toutes être mélangées les unes avec les autres, et peuvent être mélangées avec le --xclient
option (voir ci-dessous).

--xclient [XCLIENT_STRING]
Il s'agit de l'option XCLIENT "forme libre". Quelle que soit la valeur fournie pour XCLIENT_STRING
sera envoyé textuellement comme argument à la commande XCLIENT smtp. Par exemple, si
"--xclient 'NAME= ADDR=192.168.1.1 FOO=bar'" est utilisé, swaks enverra la commande SMTP
"XCLIENT NAME=ADDR=192.168.1.1 FOO=bar". Le principal avantage de cela par rapport au plus
options spécifiques ci-dessus est qu'il n'y a pas de validation de syntaxe XCLIENT ici. Cette
vous permet d'envoyer un XCLIENT invalide au serveur cible pour le test. Sinon
XCLIENT_STRING est passé sur la ligne de commande, swaks demandera et lira la valeur sur
STDIN.

L'option --xclient peut être mélangée librement avec les options --xclient-* ci-dessus. Si
"--xclient-addr 192.168.0.1 --xclient 'FOO=bar NAME=wind'" est donné aux swaks, "XCLIENT
ADDR=192.168.0.1 FOO=bar NAME=wind" sera envoyé au serveur cible.

--xclient-facultatif
--xclient-facultatif-strict
En fonctionnement normal, la définition de l'une des options --xclient* entraînera un succès
La transaction XCLIENT doit avoir lieu pour continuer (c'est-à-dire que XCLIENT doit être
annoncé, tous les attributs demandés par l'utilisateur doivent avoir été annoncés, et le
le serveur doit avoir accepté la requête XCLIENT de swaks). Ces options changent cela
comportement. --xclient-facultatif indique à swaks de passer inconditionnellement au-delà du XCLIENT
étape de la transaction SMTP, qu'elle ait réussi ou non.
--xclient-facultatif-strict est similaire mais plus granulaire. La version stricte sera
continuer vers XCLIENT n'a pas été annoncé, mais échouera si XCLIENT a été tenté mais n'a pas
Ne pas réussir.

DONNEES OPTIONS

Ces options concernent le contenu de la partie DATA de la transaction SMTP.

-d, --data [portion-données]
Utilisez argument comme contenu entier de DATA, ou invitez l'utilisateur si aucun argument n'est spécifié.
Si l'argument '-' est fourni, les données seront lues à partir de STDIN. Si d'autres
est fourni et il représente le nom d'un fichier pouvant être ouvert, le contenu de
le fichier sera utilisé. Tout autre argument sera lui-même pour le contenu DATA.

La valeur peut être sur une seule ligne, avec \n (ascii 0x5c, 0x6e) représentant où
des sauts de ligne doivent être placés. Les points de départ seront cités. Le point de fermeture n'est pas
obligatoire mais autorisé. La valeur par défaut de cette option est "Date : %DATE%\nTo :
%TO_ADDRESS%\nDe : %FROM_ADDRESS%\nObjet : test %DATE%\nX-Mailer : swaks v$p_version
jetmore.org/john/code/swaks/\n%NEW_HEADERS%\n%BODY%\n".

Une analyse syntaxique très basique des jetons est effectuée sur la partie DATA. Voir --use-old-data-tokens
pour plus de détails sur les jetons à caractère unique marqués comme obsolètes. Ce qui suit
le tableau montre les jetons reconnus et leurs valeurs de remplacement :

%DE L'ADRESSE%
Remplacé par l'expéditeur de l'enveloppe. Remplace le jeton %F obsolète.

%ADRESSER%
Remplacé par le(s) destinataire(s) de l'enveloppe. Remplace le jeton %T obsolète.

%DATE%
Remplacé par l'heure actuelle dans un format adapté à l'inclusion dans la date :
entête. Notez que cela tente d'utiliser le module standard Time::Local pour le fuseau horaire
calculs. Si ce module n'est pas disponible, la chaîne de date sera en GMT.
Remplace le jeton %D obsolète.

%NEW_HEADERS%
Remplacé par le contenu de l'option --add-header. Si --add-header n'est pas
spécifié que ce jeton est simplement supprimé. Remplace le jeton %H obsolète.

%CORPS%
Remplacé par la valeur spécifiée par l'option --body. Voir --body pour la valeur par défaut.
Remplace le jeton %H obsolète.

--use-old-data-tokens
Dans les versions précédentes de swaks, les jetons DATA comme décrit dans l'option --data ci-dessus
jetons à un caractère utilisés (par exemple, %F). Ce n'était pas un bon choix pour le défaut
jetons, et s'est avéré particulièrement gênant avec les langues codées, non anglaises où
ces combinaisons de caractères peuvent être courantes. Les jetons à un caractère étaient
remplacé par les versions légèrement moins sujettes aux erreurs répertoriées ci-dessus. La rétention de
les anciens jetons et l'inclusion de cette option pour les activer sont destinés à
aide temporaire aux utilisateurs qui ont un corpus de messages existant utilisant les anciens jetons. Les
les jetons à caractère unique et l'option --use-old-data-tokens doivent être pris en compte
obsolète et susceptible d'être supprimée dans la prochaine version.

-dab, --dump-as-body
Si --dump-as-body est utilisé et qu'aucune autre option n'est utilisée pour modifier le corps par défaut de
le message, le corps est remplacé par une sortie similaire à la sortie de ce qui est
fourni par --dump. la strophe de capacité de programme initiale de --dump n'est pas affichée, et
la section "données" n'est pas incluse. De plus, --dump inclut toujours les mots de passe.
Par défaut --dump-as-body n'inclut pas les mots de passe, bien que cela puisse être modifié avec
--dump-as-body-shows-password.

-dabsp, --dump-as-body-shows-password
Faites en sorte que --dump-as-body inclue les mots de passe en clair. Cette option n'est pas recommandée.
Cette option implique --dump-as-body.

--body [spécification du corps]
Spécifiez le corps de l'e-mail. La valeur par défaut est « Ceci est un envoi test ». Sinon
argument à --body est donné, invite à en fournir un de manière interactive. Si '-' est fourni,
le corps sera lu à partir de l'entrée standard. Si un autre texte est fourni et que le texte
représente un fichier pouvant être ouvert, le contenu de ce fichier est utilisé comme corps. Si ça
ne représente pas un fichier pouvant être ouvert, le texte lui-même est utilisé comme corps.

Si le message est forcé au format MIME (voir --attach) l'argument de cette option
sera inclus non codé en tant que première partie MIME. Son type de contenu sera toujours
texte simple.

--attach [spécification de la pièce jointe]
Lorsqu'une ou plusieurs options --attach sont fournies, le message est transformé en un
message MIME en plusieurs parties/mixte. Les arguments de --attach sont traités de la même manière que
--body en ce qui concerne stdin, le contenu du fichier, etc. --attach peut être fourni plusieurs
fois pour créer plusieurs pièces jointes. Par défaut, chaque pièce jointe est jointe en tant que
fichier application/octet-stream. Voir --attach-type pour modifier ce comportement.

Si un nom de fichier est spécifié, l'encodage MIME inclura ce nom de fichier. Voir
--attach-name pour plus de détails sur la dénomination des fichiers.

Il est légal que '-' (STDIN) soit spécifié comme argument plusieurs fois (une fois pour
--body et plusieurs fois pour --attach). Dans ce cas, le même contenu sera
joint chaque fois qu'il est spécifié. Ceci est utile pour joindre le même contenu
avec plusieurs types MIME.

--attach-type [type-mime]
Par défaut, le contenu qui obtient MIME attaché à un message avec l'option --attach est
codé comme application/octet-stream. --attach-type change le type mime pour chaque
--attach option qui le suit. Il peut être spécifié plusieurs fois.

--attach-name [nom]
Cette option définit le nom de fichier qui sera inclus dans la partie MIME créée pour le
option suivante --attach. Si aucun argument n'est défini pour cette option, cela ne provoque aucun nom de fichier
informations à inclure pour la prochaine partie MIME, même si les swaks pourraient la générer
à partir du nom de fichier local.

-ah, --add-header [en-tête]
Cette option permet d'ajouter des en-têtes aux DONNÉES. Si %H est présent dans les DATA, il
est remplacé par l'argument de cette option. Si %H n'est pas présent, l'argument est
inséré entre les deux premières nouvelles lignes consécutives dans les données (c'est-à-dire qu'il est
inséré à la fin des en-têtes existants).

L'option peut être spécifiée plusieurs fois ou une seule fois avec plusieurs
en-têtes séparés par une chaîne littérale '\n'. Donc, "--add-header 'Foo: bar' --add-header
'Baz: foo'" et "--add-header 'Foo: bar\nBaz: foo'" finissent par ajouter les deux mêmes
En-têtes.

--header [en-tête-et-données], --h-En-tête [données]
Ces options permettent de modifier les en-têtes qui existent déjà dans les données. '--entête
"Subject: foo"' et '--h-Subject foo' sont équivalents. Si l'en-tête n'est pas déjà
existent dans les données, cet argument se comporte de la même manière que --add-header. Toutefois, si
l'en-tête existe déjà, il est remplacé par celui spécifié.

-g Si spécifié, swaks lira la valeur DATA pour le courrier à partir de STDIN. C'est
équivalent à "--data -". S'il y a une ligne From_ dans l'e-mail, elle sera supprimée
(mais voir l'option -nsf). Utile pour livrer un vrai message (stocké dans des fichiers) à la place
d'utiliser des exemples de messages.

--no-data-fixup, -ndf
Cette option force swaks à ne pas masser la partie DATA de l'e-mail. Cette
inclut le remplacement du jeton, la suppression de From_, l'ajout de points de fuite, --body/attachment
inclusion et tout ajout d'en-tête. Cette option n'est vraiment utile que lorsqu'elle est utilisée avec
--data, puisque la partie DATA interne par défaut utilise des jetons.

--pas de strip-from, -nsf
Ne supprimez pas la ligne From_ de la partie DATA, si elle est présente.

SORTIE OPTIONS

Par défaut, swaks fournit une transcription de ses transactions à son appelant (STDOUT/STDERR).
Cette transcription vise à être une représentation aussi fidèle que possible de la transaction
bien qu'il modifie cette sortie en ajoutant des préfixes d'information aux lignes et en
fournir des versions en texte clair des transactions TLS

Les « préfixes d'information » sont appelés indices de transaction. Ces conseils sont
initialement composé de ces lignes de marquage qui sont sorties de swaks lui-même, soit
les messages d'information ou d'erreur, et ceux qui indiquent une ligne de données effectivement envoyées ou
reçu dans une transaction. Ce tableau indique les astuces et leur signification :

=== Indique une ligne d'information générée par les swaks

*** Indique une erreur générée dans les swaks

-> Indique une ligne attendue envoyée par les swaks au serveur cible

~> Indique une ligne attendue chiffrée en TLS envoyée par les swaks au serveur cible

**> Indique une ligne inattendue envoyée par les swaks au serveur cible

*~> Indique une ligne inattendue chiffrée en TLS envoyée par les swaks au serveur cible

> Indique un morceau brut de test envoyé par les swaks à un serveur cible (voir --show-raw-text).
Il n'y a pas de notion d'"attendu" ou d'"inattendu" à ce niveau.

<- Indique une ligne attendue envoyée par le serveur cible aux swaks

<~ Indique une ligne attendue chiffrée en TLS envoyée par le serveur cible aux swaks

<** Indique une ligne inattendue envoyée par le serveur cible aux swaks

<~* Indique une ligne inattendue chiffrée en TLS envoyée par le serveur cible aux swaks

< Indique un morceau brut de texte reçu par les swaks d'un serveur cible (voir
--show-raw-text). Il n'y a pas de notion d'"attendu" ou d'"inattendu" à ce niveau.

Les options suivantes contrôlent quoi et comment la sortie est affichée à l'appelant.

-n, --suppress-données
Résume la partie DATA de la transaction SMTP au lieu d'imprimer chaque ligne.
Cette option est très utile, à la limite de l'indispensable, lors de l'utilisation de swaks pour envoyer certains
tester les e-mails. Les e-mails avec pièces jointes, par exemple, submergeront rapidement un terminal
si le DATA n'est pas supprimé.

-stl, --show-time-lapse [je]
Afficher le laps de temps entre les paires d'envoi/réception. Cette option est particulièrement utile lorsque
Time::HiRes est disponible, auquel cas le laps de temps sera affiché dans
millièmes de seconde. Si Time::HiRes n'est pas disponible ou si "i" est donné en argument
le laps de temps sera affiché en secondes entières seulement.

-nih, --no-info-hints
N'affiche pas l'indice de transaction pour les transactions d'information. C'est le plus
utile lorsqu'on a besoin de copier une partie des lignes d'information, par exemple le
sortie de certificat de --tls-get-peer-cert.

-nsh, --no-send-hints
-nrh, --no-receive-hints
-ntième, --pas d'indices
--no-send-hints et --no-receive-hints suppriment le préfixe de transaction de send et
recevoir des lignes, respectivement. Ceci est souvent utile lors de la copie d'une partie du
transaction à utiliser ailleurs (par exemple, "--no-send-hints --hide-receive
--hide-informational" est un moyen utile d'obtenir uniquement les commandes côté client pour un
transaction). --no-hints est identique à spécifier à la fois --no-send-hints et
--pas de réception d'indices.

Ne pas afficher les conseils de transaction (utile en conjonction avec -hr pour créer un copier/coller
transactions).

-raw, --show-raw-text
Cette option imprimera un vidage hexadécimal des données brutes envoyées et reçues par les swaks. Chaque hexagone
dump est le contenu d'une seule lecture ou écriture sur le réseau. Cela devrait être
identique à ce qui est déjà affiché (à l'exception des caractères \r
en cours de suppression). Cette option est utile pour voir les détails lorsque les serveurs envoient des lots
de données en paquets uniques, ou fractionner des lignes individuelles en plusieurs paquets. Si
vous avez vraiment besoin d'approfondir dans ce domaine vous êtes probablement mieux avec un paquet
renifleur, mais cette option est une bonne première étape pour voir des problèmes de connexion étranges.

--fichier de sortie
--output-file-stdout
--output-file-stderr
Ces options permettent à l'utilisateur d'envoyer la sortie vers des fichiers au lieu de stdout/stderr. Les
la première option envoie les deux dans le même fichier. Les arguments de &STDOUT et &STDERR sont
traité spécialement, en se référant aux descripteurs de fichiers "normaux", donc "--output-file-stderr
'&STDOUT'" redirigerait STDERR vers STDOUT.

-pp, --protect-invite
Ne faites pas écho à l'entrée de l'utilisateur sur les invites potentiellement sensibles (pour le moment uniquement
mot de passe d'authentification). Voir aussi --auth-hide-password

-hr, --hide-recevoir
Ne pas afficher les lignes envoyées depuis le serveur distant reçues par les swaks

-hs, --hide-send
Ne pas afficher les lignes envoyées par les swaks au serveur distant

-salut, --hide-informational
N'affiche pas les lignes d'information sans erreur de swaks lui-même.

-ha, --cacher-tout
N'affichez aucun contenu sur le terminal.

-S, --silent [niveau]
Faites que les swaks se taisent. Si aucun argument n'est donné ou si un argument de "1" est donné,
n'affiche aucune sortie à moins/jusqu'à ce qu'une erreur se produise, après quoi toutes les sorties sont affichées. Si un
l'argument de "2" est donné, seules les erreurs d'impression. Si "3" est donné, n'affiche jamais de sortie.

--Support
Capacités d'impression et sortie. Certaines fonctionnalités nécessitent des modules perl non standard.
Cette option évalue si ces modules sont présents et affiche quels
fonctionnalité est disponible et laquelle ne l'est pas, et quels modules devraient être ajoutés
pour obtenir la fonctionnalité manquante.

--décharger
Cette option force swaks à imprimer les résultats du traitement des options, juste avant
le courrier aurait été envoyé. Aucun courrier ne sera envoyé lorsque --dump est utilisé. Noter que
--dump est considéré comme un pur outil d'autodiagnostic et aucun effort n'est fait ou ne sera
jamais être fait pour masquer les mots de passe dans la sortie --dump.

--Aidez-moi
Affichez ces informations d'aide.

--version
Afficher les informations de version.

PORTABILITÉ

SYSTÈMES D'EXPLOITATION
Ce programme était principalement destiné à être utilisé sur des systèmes d'exploitation de type Unix, et il
devrait fonctionner sur toute version raisonnable de celui-ci. Il a été développé et testé sur
Solaris, Linux et Mac OS X et toutes ces fonctionnalités sont complètes.

Ce programme est connu pour démontrer les fonctionnalités de base sur Windows en utilisant
Perl d'ActiveState. Il n'a pas été entièrement testé. Connu pour fonctionner sont SMTP de base
fonctionnalités et les types d'authentification LOGIN, PLAIN et CRAM-MD5. Inconnu est un TLS
fonctionnalité et les types d'authentification NTLM/SPA et DIGEST-MD5.

Parce que ce programme devrait fonctionner partout où Perl fonctionne, j'apprécierais de connaître
tout nouveau système d'exploitation sur lequel vous avez utilisé à fond les swaks ainsi que tout problème
rencontré sur un nouveau système d'exploitation.

SERVEURS DE MAIL
Ce programme a été presque exclusivement développé contre les serveurs de messagerie Exim. C'était été
utilisé avec désinvolture par l'auteur, mais pas complètement testé, avec Sendmail, Smail,
Exchange, Oracle Collaboration Suite, qpsmtpd et Communigate. Parce que tout
la fonctionnalité de swaks est basée sur des normes connues avec lesquelles elle devrait fonctionner
serveur de messagerie moderne. En cas de problème, merci d'en avertir l'auteur à l'adresse
ci-dessous.

EXIT CODES

0 aucune erreur n'est survenue

1 erreur d'analyse des options de ligne de commande

2 erreur de connexion au serveur distant

3 type de connexion inconnu

4 lors de l'exécution avec le type de connexion "pipe", problème fatal d'écriture ou de lecture depuis
le processus enfant

5 lors de l'exécution avec le type de connexion "pipe", le processus enfant est mort de manière inattendue. Cette
peut signifier que le programme spécifié avec --pipe n'existe pas.

6 La connexion s'est fermée de manière inattendue. Si la fermeture est détectée en réponse au « QUIT »
swaks envoie suite à une réponse inattendue, le code d'erreur pour cette réponse inattendue
la réponse est utilisée à la place. Par exemple, si un serveur de messagerie renvoie une réponse 550 à un
MAIL FROM : puis ferme immédiatement la connexion, swaks détecte que le
connexion est fermée, mais utilise le code de sortie plus spécifique 23 pour détailler la nature de
l'échec. Si à la place le serveur renvoie un code 250 puis ferme immédiatement le
connexion, swaks utilisera le code de sortie 6 car il n'y a pas de sortie plus spécifique
code.

10 erreur dans les prérequis (module nécessaire non disponible)

21 erreur de lecture de la bannière initiale du serveur

22 erreur dans la transaction HELO

23 erreur dans la transaction MAIL

24 aucun RCPT accepté

25 serveur a renvoyé une erreur à la demande DATA

26 serveur n'a pas accepté le courrier suivant les données

Le serveur 27 a renvoyé une erreur après une demande de fermeture de session normale

28 erreur dans la transaction AUTH

29 erreur dans la transaction TLS

Erreur 32 dans EHLO suite à la négociation TLS

33 erreur dans la transaction XCLIENT

34 erreur dans EHLO suivant XCLIENT

A PROPOS THE Nom

Le nom "swaks" est un acronyme (en quelque sorte) pour "SWiss Army Knife Smtp". Il a été choisi pour être
assez distinct et prononçable. Alors que "swaks" est unique en tant que nom d'un logiciel
package, il a d'autres significations non logicielles. Veuillez envoyer d'autres utilisations de "swak" ou
"swaks" pour l'inclusion.

"Scellé avec un baiser"
SWAK/SWAKs apparaît occasionnellement sur Internet avec le sens "avec amour".

mauvais / pauvre / malade (afrikaans)
Vu dans le titre "SA se bes en swaks gekledes en 2011", qui a été traduit par
« le mieux et le moins bien habillé » par des locuteurs natifs. Google Translate n'aime pas les "swaks
gekledes", mais il traduira "swak" par "pauvre" et "swak geklede" par "mal habillé".

CONTACTEZ-NOUS

[email protected]
Veuillez utiliser cette adresse pour les contacts généraux, les questions, les correctifs, les demandes, etc.

[email protected]
Si vous souhaitez être inscrit sur une liste pour recevoir des notifications lorsqu'une nouvelle version de
swaks est sorti, merci d'envoyer un email à cette adresse.

http://www.jetmore.org/john/code/swaks/
Les journaux des modifications, cette aide et la dernière version se trouvent sur ce lien.

Utiliser les swaks en ligne à l'aide des services onworks.net