swaks – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

swaks - Swiss Army Knife SMTP, der universelle SMTP-Transaktionstester

BESCHREIBUNG

Das primäre Designziel von swaks ist ein flexibler, skriptfähiger, transaktionsorientierter SMTP-Test
Werkzeug. Es verarbeitet SMTP-Funktionen und -Erweiterungen wie TLS, Authentifizierung und
Rohrleitungen; mehrere Versionen des SMTP-Protokolls, einschließlich SMTP, ESMTP und LMTP; und
mehrere Transportmethoden, einschließlich Unix-Domain-Sockets, Internet-Domain-Sockets und
Rohre zu erzeugten Prozessen. Optionen können in Umgebungsvariablen angegeben werden,
Konfigurationsdateien und die Befehlszeile für maximale Konfigurierbarkeit und Benutzerfreundlichkeit
für Operatoren und Skripter.

SCHNELL Starte das Spiel

Senden Sie eine Standard-Test-E-Mail an [E-Mail geschützt] auf Port 25 von test-server.example.net:

swaks - zu [E-Mail geschützt] --server test-server.example.net

Liefern Sie eine Standard-Test-E-Mail, die eine CRAM-MD5-Authentifizierung als Benutzer erfordert [E-Mail geschützt] .
Dem E-Mail-Text wird ein "X-Test"-Header hinzugefügt. Das Authentifizierungspasswort lautet
dazu aufgefordert.

swaks - zu [E-Mail geschützt] --aus [E-Mail geschützt] --auth CRAM-MD5 --auth-user [E-Mail geschützt] --header-X-Test "Test-E-Mail"

Testen Sie einen Virenscanner mit EICAR in einem Anhang. DATEN-Teil der Nachricht nicht anzeigen.:

schluckt -t [E-Mail geschützt] --attach - --server test-server.example.com --suppress-data

Testen Sie einen Spam-Scanner mit GTUBE im Text einer E-Mail, die über die MX-Einträge für . geleitet wird
beispiel.com:

swaks - zu [E-Mail geschützt] --body /path/to/gtube/file

Senden Sie eine Standard-Test-E-Mail an [E-Mail geschützt] Verwendung des LMTP-Protokolls über ein UNIX
Domain-Socket-Datei

swaks - zu [E-Mail geschützt] --socket /var/lda.sock --protokoll LMTP

Melden Sie alle Empfänger in einer Textdatei, die auf einem Testserver nicht verifizierbar sind:

für E in `cat /path/to/email/file`
do
swaks --to $E --server test-server.example.com --quit-after RCPT --hide-all
[$? -ne 0 ] && echo $E
erledigt

BEDINGUNGEN UND KONVENTIONEN

Dieses Dokument versucht, die folgenden Begriffe konsistent und spezifisch zu verwenden, um
Verwirrung reduzieren.

Transaktion
Eine Transaktion ist das Öffnen einer Verbindung über einen Transport zu einem Ziel und die Verwendung eines
Messaging-Protokoll, um zu versuchen, eine Nachricht zuzustellen.

Target
Das Ziel einer Transaktion ist das Ding, mit dem sich swaks verbindet. Dieser Oberbegriff ist
wird in der gesamten Dokumentation verwendet, da die meisten anderen Begriffe fälschlicherweise etwas implizieren
über das verwendete Transportmittel.

Transport
Der Transport ist die zugrunde liegende Methode, die zum Herstellen einer Verbindung mit dem Ziel verwendet wird.

Protokoll
Das Protokoll ist die Anwendungssprache, die verwendet wird, um mit dem Ziel zu kommunizieren. Dies
Dokument verwendet SMTP, um generisch von allen drei unterstützten Protokollen zu sprechen, es sei denn, es
gibt an, dass es sich um das spezifische Protokoll „SMTP“ handelt und die anderen ausschließt.

Message
Es gibt SMTP-Protokolle, um Nachrichten zu übertragen, eine Reihe von Bytes in einem vereinbarten Format
die einen Absender und einen Empfänger hat.

Umschlag
Der Umschlag einer Nachricht enthält den "wahren" Absender und Empfänger einer Nachricht. Es kann
auch als seine Komponenten Umschlag-Sender und Umschlag-Empfänger bezeichnet werden. es ist
Wichtig zu beachten ist, dass ein Nachrichtenumschlag nicht mit seinem An: und Von:
Überschriften.

DATEN
Der DATA-Teil einer SMTP-Transaktion ist die eigentliche Nachricht, die gesendet wird
transportiert. Es besteht sowohl aus den Kopfzeilen der Nachricht als auch aus ihrem Hauptteil. DATEN und Körper
werden manchmal synonym verwendet, aber es sind immer zwei verschiedene Dinge
Dokument.

Headers
Die Kopfzeilen einer Nachricht sind definiert als alle Zeilen im DATA-Abschnitt der Nachricht vor
die erste Leerzeile. Sie enthalten Informationen über die E-Mail, die angezeigt wird
an den Empfänger wie An:, Von:, Betreff: usw. In diesem Dokument werden Kopfzeilen
immer mit einem großgeschriebenen Anfangsbuchstaben und einem abschließenden Doppelpunkt geschrieben werden.

Korpus
Der Hauptteil einer Nachricht ist der Teil ihres DATA-Abschnitts, der der ersten Leerzeile folgt.

zur Auswahl WIRD BEARBEITET

Um mögliche Verwechslungen in diesem Dokument zu vermeiden, wird ein Flag für swaks immer als . bezeichnet
eine Option". Wenn die Option zusätzliche Daten erfordert, werden diese zusätzlichen Daten als . bezeichnet
ein Argument für die Option. Zum Beispiel "--von [E-Mail geschützt] "könnte bereitgestellt werden an
swaks auf der Befehlszeile, wobei "--from" die Option ist und "[E-Mail geschützt] " Sein
--froms Argument.

Swaks können auf drei Arten Optionen gegeben werden. Sie können in einer Konfiguration angegeben werden
Datei, in Umgebungsvariablen und in der Befehlszeile. Abhängig von der spezifischen Option
und unabhängig davon, ob ihm ein Argument übergeben wurde oder nicht, kann swaks den Benutzer zur Eingabe des Arguments auffordern.

Wenn swaks seine Optionen auswertet, sucht es zuerst nach einer Konfigurationsdatei (entweder in einem
Standardspeicherort oder mit --config angegeben). Dann bewertet es alle Optionen in
Umgebungsvariablen. Schließlich wertet es Befehlszeilenoptionen aus. In jeder Runde
Verarbeitung werden alle zuvor festgelegten Optionen überschrieben. Darüber hinaus kann jede Option sein
mit "no-" vorangestellt, damit swaks vergisst, dass die Variable zuvor gesetzt wurde.
Diese Fähigkeit ist notwendig, da viele Optionen definierte, aber keine Argumente behandeln
anders als nicht definiert.

Der genaue Mechanismus und das Format für die Verwendung jedes der Typen sind unten aufgeführt.

KONFIGURATIONSDATEI
Eine Konfigurationsdatei kann verwendet werden, um häufig verwendete oder ungewöhnlich ausführliche Optionen festzulegen.
Standardmäßig sucht swaks in der Reihenfolge $SWAKS_HOME/.swaksrc, $HOME/.swaksrc und
$LOGDIR/.swaksrc. Wenn eine davon vorhanden ist (und --config nicht verwendet wurde)
diese Datei wird als Konfigurationsdatei verwendet.

Zusätzlich kann eine Konfigurationsdatei an einem nicht standardmäßigen Speicherort mit . angegeben werden
--config. Wenn dies gesetzt ist und kein Argument angegeben ist, verwendet swaks keines
Konfigurationsdatei, einschließlich aller Standarddateien. Wenn --config auf ein lesbares . verweist
Datei wird sie als Konfigurationsdatei verwendet und überschreibt eventuell vorhandene Standardeinstellungen. Wenn
es zeigt auf eine nicht lesbare Datei und ein Fehler wird angezeigt und swaks wird beendet.

Eine Reihe von "tragbaren" Standardeinstellungen kann auch erstellt werden, indem Optionen am Ende der Seite hinzugefügt werden
swaks-Programmdatei. Wie verteilt, sollte die letzte Zeile der Swaks "__END__" sein. Beliebig
Zeilen, die nach __END__ hinzugefügt werden, werden als Inhalt einer Konfigurationsdatei behandelt.
Dadurch kann eine Reihe von Benutzereinstellungen automatisch von Server zu Server kopiert werden
in einer einzigen Datei.

Falls vorhandene und Konfigurationsdateien nicht explizit deaktiviert wurden, wird das __END__
config wird immer gelesen. Pro Single wird immer nur eine andere Konfigurationsdatei verwendet
Aufruf von swaks, auch wenn mehrere Konfigurationsdateien angegeben sind. Angabe
die Option --config ohne Argument deaktiviert die Verarbeitung von __END__
config und alle aktuellen Konfigurationsdateien.

In einer Konfigurationsdatei werden Zeilen, die mit einem Hash (#) beginnen, ignoriert. Alle anderen Zeilen
werden als Option für Swaks angesehen, wobei der führende Bindestrich oder die Bindestriche optional sind.
Alles nach dem ersten Leerzeichen einer Optionszeile wird als Argument der Option angenommen
und wird nicht Shell verarbeitet. Daher ist das Zitieren normalerweise nicht erforderlich und wird
wörtlich in die Argumentation aufgenommen. Hier ist ein Beispiel für den Inhalt von a
Konfigurationsdatei:

# immer diesen Absender verwenden, egal Server oder eingeloggter Benutzer
--aus [E-Mail geschützt]
# Ich bevorzuge, dass meine Test-E-Mails einen hübschen From-Header haben. Notiz
# das Fehlen von Bindestrichen bei der Option und das Fehlen von Anführungszeichen in der Umgebung
# gesamtes Argument.
h-Von: "Fred Beispiel"[E-Mail geschützt] >

UMGEBUNGSVARIABLEN
Optionen können über Umgebungsvariablen bereitgestellt werden. Die Variablen haben die Form
$SWAKS_OPT_name, wobei name der Name der Option ist, die auf der
Befehlszeile. Da Bindestriche in den meisten Umgebungsvariablennamen nicht zulässig sind
Unix-ähnliche Shells, es sollten keine führenden Bindestriche verwendet werden und alle Bindestriche innerhalb der Option
Name sollte durch Unterstriche ersetzt werden. Das Folgende würde die gleichen Optionen erstellen
im Beispiel der Konfigurationsdatei gezeigt:

$ SWAKS_OPT_from='[E-Mail geschützt] '
$ SWAKS_OPT_h_From='"Fred-Beispiel"[E-Mail geschützt] >'

Das Setzen einer Variablen auf einen leeren Wert entspricht der Angabe in der Befehlszeile
ohne Argumente. Zum Beispiel würde die Einstellung von SWAKS_OPT_server="" dazu führen, dass Swaks
fordert bei jedem Aufruf die Verwendung für den Server auf, zu dem eine Verbindung hergestellt werden soll.

Zusätzlich zum Einstellen des Äquivalents von Befehlszeilenoptionen kann SWAKS_HOME eingestellt werden
in ein Verzeichnis, das die zu verwendende Standard-.swaksrc enthält.

KOMMANDOZEILENOPTIONEN
Die letzte Methode zum Bereitstellen von Optionen an swaks erfolgt über die Befehlszeile. Die Optionen
sich auf eine Weise verhalten, die mit den meisten Unix-artigen Befehlszeilenprogrammen übereinstimmt. Viele Optionen
haben sowohl eine Kurz- als auch eine Langform (zum Beispiel -s und --server). Nach Vereinbarung kurz
Optionen werden mit einem einzelnen Bindestrich angegeben und lange Optionen werden mit einem Doppelstrich angegeben.
Bindestrich. Dies ist nur eine Konvention und jedes Präfix funktioniert mit jedem Typ.

Im Folgenden wird das in der Konfigurationsdatei und der Umgebung gezeigte Beispiel gezeigt
variable Abschnitte:

$ swaks --von [E-Mail geschützt] --h-From: '"Fred-Beispiel"[E-Mail geschützt] >'

TRANSPORT

swaks kann sich über Unix-Pipes ("pipes"), Unix-Domain-Sockets ("unix
Sockets") oder Internet-Domain-Sockets ("Netzwerk-Sockets"). Verbindung über Netzwerk-Sockets
ist das Standardverhalten. Aufgrund der Einzigartigkeit des verwendeten Transportmittels ist jedes Set
der Optionen im folgenden Abschnitt schließen sich gegenseitig aus. Angabe von mehr als einem von
--server, --pipe oder --socket führt zu einem Fehler. Mischen anderer Optionen zwischen
Transportarten führen nur dazu, dass die irrelevanten Optionen ignoriert werden. Unten ist ein
kurze Beschreibung der einzelnen Transportarten und deren spezifischen Möglichkeiten
Transportart.

NETZWERKSTECKER
Dieser Transport versucht, eine Nachricht über TCP/IP zuzustellen, die Standardmethode für
SMTP liefern. Dies ist der Standardtransport für Swaks. Wenn keiner von --server,
--pipe oder --socket angegeben ist, wird dieser Transport verwendet und der Zielserver ist
aus der Domäne des Empfängers bestimmt (siehe --server unten für weitere Details).

Dieser Transport erfordert das IO::Socket-Modul, das Teil des Standard-Perl . ist
Verteilung. Wenn dieses Modul nicht ladbar ist, wird der Versuch, dieses Transportmittel zu verwenden,
zu einem Fehler und Programmabbruch führen.

IPv6 wird unterstützt, wenn das Modul IO::Socket::INET6 vorhanden ist.

-s, --server [Ziel-Mailserver[:Port]]
Sagen Sie swaks explizit, Netzwerk-Sockets zu verwenden, und geben Sie den Hostnamen oder die IP-Adresse an
Adresse, zu der eine Verbindung hergestellt werden soll, oder Eingabeaufforderung, wenn kein Argument angegeben wird. Wenn diese Option ist
nicht angegeben und keine andere Transportoption angegeben ist, ist der Ziel-Mailserver
ermittelt aus den entsprechenden DNS-Einträgen für die Domain der Empfänger-E-Mail
Adresse mit dem Net::DNS-Modul. Wenn Net::DNS nicht verfügbar ist, wird swaks
Versuchen Sie, eine Verbindung zu localhost herzustellen, um zuzustellen. Der Zielport kann optional eingestellt werden
Hier. Unterstützte Formate hierfür sind SERVER:PORT (unterstützt Namen und IPv4
Adressen); [SERVER]:PORT und SERVER/PORT (unterstützte Namen, IPv4 und IPv6
Adressen). Siehe auch --copy-routing.

-p, --port [Port]
Geben Sie an, welcher TCP-Port auf dem Ziel verwendet werden soll, oder fragen Sie nach, wenn kein Argument angegeben ist
aufgelistet. Das Argument kann ein Dienstname sein (wie von . abgerufen getservbyname(3)) oder
eine Portnummer. Der Standardport wird durch die Option --protocol bestimmt. Sehen
--Protokoll für weitere Details.

-li, --local-interface [IP oder Hostname[:Port]]
Argument als lokale Schnittstelle für die ausgehende SMTP-Verbindung oder Eingabeaufforderung verwenden
Benutzer, wenn kein Argument angegeben ist. Argument kann eine IP-Adresse oder ein Hostname sein. Standard
Aktion besteht darin, das Betriebssystem die lokale Schnittstelle auswählen zu lassen. Siehe --server für
zusätzliche Kommentare zum :port-Format.

-lp, --local-port [Port]
Geben Sie den ausgehenden Port an, von dem die Transaktion ausgehen soll. Wenn diese Option ist
nicht angegeben, wählt das System einen kurzlebigen Port aus. Beachten Sie, dass regelmäßige Benutzer
Einige Ports können nicht angegeben werden.

--copy-routing [Domäne]
Das Argument wird als Domänenteil einer E-Mail-Adresse interpretiert und verwendet
um den Zielserver mit derselben Logik zu finden, die verwendet würde, um die
Zielserver für eine Empfänger-E-Mail-Adresse. Siehe --to-Option für weitere Details
wie das Ziel aus der E-Mail-Domäne ermittelt wird.

-4, -6
IPv4 oder IPv6 erzwingen.

UNIX-Sockets
Diese Transportmethode versucht, Nachrichten über eine Unix-Domain-Socket-Datei zuzustellen.
Dies ist nützlich zum Testen von MTA/MDAs, die auf Socket-Dateien lauschen (z
LMTP-Lieferung an Cyrus). Dieser Transport erfordert das IO::Socket-Modul, das Teil
der Standard-Perl-Distribution. Wenn dieses Modul nicht ladbar ist, versuchen Sie es zu verwenden
dieser Transport führt zu einem Fehler und Programmabbruch.

--socket [/Pfad/zu/Socket/Datei]
Diese Option verwendet als Argument eine Unix-Domain-Socket-Datei. Wenn swaks nicht möglich ist
Um diesen Socket zu öffnen, wird ein Fehler angezeigt und das Programm beendet.

ROHRE
Dieser Transport versucht, einen Prozess zu erzeugen und über Pipes mit ihm zu kommunizieren. Der
Das erzeugte Programm muss darauf vorbereitet sein, sich als Mailserver über STDIN/STDOUT zu verhalten. Beliebig
MTA, das für den Betrieb von inet/xinet entwickelt wurde, sollte dies unterstützen. Außerdem einige MTAs
bieten Testmodi, mit denen über STDIN/STDOUT kommuniziert werden kann. Dieser Transport
kann verwendet werden, um diese Tests zu automatisieren. Wenn Sie beispielsweise die DNSBL-Überprüfung implementiert haben
mit Exim und Sie wollten sicherstellen, dass es funktioniert, können Sie 'swaks --pipe . ausführen
"exim -bh 127.0.0.2"'. In einer idealen Welt sollte sich der Prozess, mit dem Sie sprechen, verhalten
genau wie ein SMTP-Server auf stdin und stdout. Jedes Debugging sollte an gesendet werden
stderr, die an Ihr Terminal weitergeleitet wird. In der realen Welt können Swaks
Behandeln Sie im Allgemeinen einige Fehler im Standard des Kindes, aber es gibt keine Garantien dafür, wie
viel kann es verarbeiten.

Dieser Transport erfordert das IPC::Open2-Modul, das Teil der Standardperl . ist
Verteilung. Wenn dieses Modul nicht ladbar ist, wird der Versuch, dieses Transportmittel zu verwenden,
zu einem Fehler und Programmabbruch führen.

--pipe [/Pfad/zu/Befehl und Argumente]
Geben Sie dem Prozess einen Prozessnamen und Argumente an. swaks werden versuchen zu spawnen
den Prozess und kommunizieren mit ihm über Pipes. Wenn das Argument kein ist
Ausführbare swaks zeigen einen Fehler an und werden beendet.

PROTOKOLL OPTIONAL

Diese Optionen beziehen sich auf die Protokollschicht.

-t, --to [E-Mail-Adresse[,E-Mail-Adresse,...]]
Weist swaks an, Argumente als Envelope-Empfänger für die E-Mail zu verwenden, oder fragt nach
Empfänger, wenn kein Argument angegeben ist. Wenn mehrere Empfänger angegeben sind und die
Empfängerdomäne wird benötigt, um das Routing der Domäne des letzten Empfängers zu bestimmen
bereitgestellt wird verwendet.

Für diese Option gibt es keinen Standardwert. Wenn keine Empfänger über irgendwelche bereitgestellt werden
bedeutet, dass der Benutzer aufgefordert wird, interaktiv einen bereitzustellen. Die einzige Ausnahme hiervon
ist, wenn ein --quit-after-Wert angegeben wird, der dazu führt, dass die SMTP-Transaktion ausgeführt wird
beendet, bevor der Empfänger benötigt wird.

-f, --from [E-Mail-Adresse]
Argument als Envelope-Sender für E-Mail verwenden oder Benutzer auffordern, wenn kein Argument angegeben ist.
Die Zeichenfolge <> kann als Nullsender angegeben werden. Wenn der Benutzer kein a angibt
Absenderadresse wird ein Standardwert verwendet. Der Domänenteil des Standardsenders ist a
Erraten Sie am besten den vollqualifizierten Domänennamen des lokalen Hosts. Die Methode von
die Bestimmung des Lokalteils variiert. Unter Windows, Win32::LoginName() wird genutzt. Unter Unix-
ish-Plattformen wird die Umgebungsvariable $LOGNAME verwendet, wenn sie gesetzt ist. Ansonsten
getpwuid(3) verwendet wird. Siehe auch --force-getpwuid.

--ehlo, --lhlo, -h, --helo [Helo-String]
String, der als Argument für den HELO/EHLO/LHLO-Befehl verwendet werden soll, oder Eingabeaufforderung, wenn kein Argument ist
angegeben. Wenn diese Option nicht verwendet wird, schätzen Sie den vollständig qualifizierten Domänennamen am besten ein
des lokalen Hosts verwendet wird. Wenn das Sys::Hostname-Modul, das Teil des Basismoduls ist,
Distribution, nicht verfügbar ist, wird der Benutzer zur Eingabe eines HELO-Wertes aufgefordert. Beachten Sie, dass
Es wurde beobachtet, dass Sys::Hostname den lokalen Hostnamen in bestimmten Fällen nicht finden kann
Umstände. Dies hat den gleichen Effekt, als ob Sys::Hostname nicht verfügbar wäre.

-q, --quit-after [Haltepunkt]
Punkt, an dem die Transaktion gestoppt werden soll. Wenn der angeforderte Haltepunkt
in der Transaktion erreicht wird und vorausgesetzt, dass swaks nicht zuvor fehlgeschlagen ist
Wenn Sie es erreichen, sendet swaks "QUIT" und versucht, die Verbindung sauber zu schließen.
Dies sind die gültigen Argumente und Hinweise zu ihrer Bedeutung.

VERBINDEN, BANNER
Beenden Sie die Sitzung, nachdem Sie das Begrüßungsbanner vom Ziel erhalten haben.

ERSTER-HELO, ERSTER-EHLO, ERSTER-LHLO
Beenden Sie in einer STARTTLS-Sitzung (aber nicht tls-on-connect) die Transaktion nach
der erste von zwei HELOs. Verhält sich in einer Nicht-STARTTLS-Transaktion genauso wie HELO
(siehe unten).

XKUNDE
Beenden, nachdem XCLIENT gesendet wurde

TLS Beenden Sie die Transaktion unmittelbar nach der TLS-Aushandlung. Beachten Sie, dass dies
passiert an verschiedenen Stellen, je nachdem ob STARTTLS oder tls-on-connect sind
Gebraucht. Dies endet immer nach dem Punkt, an dem TLS ausgehandelt worden wäre,
egal ob es versucht wurde.

HALLO, EHLO, LHLO
Beenden Sie in einer STARTTLS- oder XCLIENT-Sitzung nach dem zweiten HELO. Ansonsten hör auf
nach dem ersten und einzigen HELO.

AUTH
Beenden Sie nach der Authentifizierung. Dies wird immer nach dem Punkt beendet, an dem die Authentifizierung
verhandelt worden wäre, unabhängig davon, ob es versucht wurde.

MAIL VON
Beenden, nachdem MAIL FROM: gesendet wurde.

RCPT, ZU
Beenden, nachdem RCPT TO: gesendet wurde.

--timeout [Zeit]
Argument als SMTP-Transaktionszeitlimit verwenden oder Benutzer auffordern, wenn kein Argument angegeben ist.
Argument kann entweder eine reine Ziffer sein, die als Sekunden interpretiert wird, oder kann
einen Spezifizierer s oder m haben (5s = 5 Sekunden, 3m = 180 Sekunden). Als Sonderfall 0
bedeutet, dass die Transaktionen nicht unterbrochen werden. Der Standardwert ist 30s.

--Protokoll [Protokoll]
Geben Sie an, welches Protokoll in der Transaktion verwendet werden soll. Gültige Optionen werden im angezeigt
Tabelle unten. Derzeit sind die „Kern“-Protokolle SMTP, ESMTP und LMTP. Durch die Nutzung
Variationen dieser Protokolltypen kann man in Kürze Standardports angeben, ob
Authentifizierung versucht werden sollte, und die Art der TLS-Verbindung, die sein sollte
versucht. Das Standardprotokoll ist ESMTP. Diese Tabelle zeigt die verfügbaren
Argumente für --protocol und die jeweils gesetzten Optionen als Nebeneffekt:

SMTP
HALLO, "-S. 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, "-S. 24"

LMTPA
LHLO, "-a -p 24"

LMTPS
LHLO, "-tls -p 24"

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

--Pipeline
Wenn der Remoteserver dies unterstützt, versuchen Sie es mit SMTP PIPELINING (RFC 2920). Das ist ein
jüngere Option, wenn Sie Probleme damit haben, benachrichtigen Sie bitte den Autor.
Zu den möglichen Problembereichen gehören Server, die DATEN akzeptieren, obwohl keine gültigen vorhanden sind
Empfänger (Swaks sollten in diesem Fall einen leeren Körper senden, nicht QUIT) und Deadlocks verursacht
durch Senden von Paketen außerhalb der TCP-Fenstergröße.

--force-getpwuid
Sagen Sie swaks, dass es stattdessen die Methode getpwuid verwenden soll, um den standardmäßigen lokalen Teil des Absenders zu finden
zuerst $LOGNAME versuchen.

TLS / VERSCHLÜSSELUNG

Dies sind Optionen im Zusammenhang mit der Verschlüsselung der Transaktion. Diese wurden getestet und
bestätigt, dass sie mit allen drei Transportmethoden funktioniert. Das Net::SSLeay-Modul wird verwendet, um
Verschlüsselung durchführen, wenn sie angefordert wird. Wenn dieses Modul nicht ladbar ist, wird es auch swaks
Ignorieren Sie die TLS-Anforderung oder führen Sie einen Fehler aus, je nachdem, ob die Anforderung optional war.
STARTTLS ist als Erweiterung im ESMTP-Protokoll definiert und nicht verfügbar, wenn
--protocol ist auf eine Variante von smtp eingestellt. Weil es im Protokoll nicht definiert ist
selbst, --tls-on-connect ist für jeden Protokolltyp verfügbar, wenn das Ziel dies unterstützt.

Für die Aushandlung einer TLS-Verbindung ist kein lokales Zertifikat erforderlich. Einige
Server verwenden die Client-Zertifikatsprüfung, um zu überprüfen, ob der Client eine Verbindung herstellen darf.
swaks kann durch die Verwendung von --tls-cert . angewiesen werden, ein bestimmtes lokales Zertifikat zu verwenden
und --tls-key-Optionen.

-tls
Verbindung erforderlich, um STARTTLS zu verwenden. Beenden, wenn TLS aus irgendeinem Grund nicht verfügbar ist (nicht
ausgeschrieben, Verhandlungen gescheitert usw.).

-tlso, --tls-optional
Versuchen Sie, STARTTLS zu verwenden, falls verfügbar, fahren Sie mit der normalen Transaktion fort, wenn TLS war
kann aus irgendeinem Grund nicht verhandelt werden. Beachten Sie, dass dies eine halb nutzlose Option ist, da
derzeit implementiert, da nach einem Verhandlungsfehler der Zustand der Verbindung
ist unbekannt. In einigen Fällen, z. B. bei einer nicht übereinstimmenden Version, sollte die Verbindung als . belassen werden
Klartext. In anderen Fällen, wie bei einem Verifizierungsfehler, kann die Serverseite denken, dass es
sollte weiterhin TLS sprechen, während der Client denkt, dass es sich um Klartext handelt. Es kann ein
Versuchen Sie, in Zukunft eine genauere Zustandserkennung hinzuzufügen, aber seien Sie sich vorerst bewusst
dass bei dieser Option seltsame Dinge passieren können, wenn die TLS-Aushandlung versucht wird und
fehlschlägt.

-tlsos, --tls-optional-strict
Versuchen Sie, STARTTLS zu verwenden, falls verfügbar. Fahren Sie mit der Transaktion fort, wenn TLS ausgehandelt wird
erfolgreich oder STARTTLS nicht beworben. Wenn STARTTLS beworben wird, aber TLS
Verhandlungen scheitern, als Fehler behandeln und Transaktion abbrechen. Aufgrund des Vorbehalts
oben ist dies eine viel vernünftigere Option als --tls-optional.

--tlsc, --tls-on-connect
Initiieren Sie sofort nach der Verbindung eine TLS-Verbindung. Nach allgemeiner Konvention, wenn
diese Option ist angegeben, der Standardport ändert sich von 25 auf 465, obwohl dies möglich ist
immer noch mit der Option --port überschrieben werden.

-tlsp, --tls-protocol SPEZIFIKATION
Geben Sie an, welche Protokolle beim Aushandeln von TLS verwendet (oder nicht) werden sollen. Zu diesem Zeitpunkt
Beim Schreiben sind die verfügbaren Protokolle sslv2, sslv3, tlsv1, tlsv1_1 und tlsv1_2. Der
Die Verfügbarkeit dieser Protokolle hängt von Ihrer zugrunde liegenden OpenSSL-Bibliothek ab
möglicherweise sind nicht alle davon verfügbar. Die Liste der verfügbaren Protokolle wird in der
Ausgabe von --dump (vorausgesetzt, TLS ist überhaupt verfügbar).

Die Spezifikationszeichenfolge ist eine durch Kommas getrennte Liste von Protokollen, die verwendet werden können oder
nicht benutzt. Zum Beispiel wird 'tlsv1,tlsv1_1' nur erfolgreich sein, wenn einer von diesen beiden
Protokolle sind sowohl auf dem Client als auch auf dem Server verfügbar. Umgekehrt,
'no_sslv2,no_sslv3' versucht, jedes Protokoll außer sslv2 und sslv3 auszuhandeln.
Die beiden Spezifikationsformen können nicht gemischt werden.

-tls-chiffre CIPHER_STRING
Das Argument dieser Option wird an die zugrunde liegende OpenSSL-Bibliothek übergeben, um die Liste zu setzen
von akzeptablen Verschlüsselungen, die für die Verbindung verwendet werden sollen. Das Format dieser Zeichenfolge ist
undurchsichtig für Swaks und ist definiert in
http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT. Ein kurzes Beispiel
wäre --tls-chiffre '3DES:+RSA'.

--tls-verify
Standardmäßig führt swaks keine Zertifikatsüberprüfung durch. Einstellung --tls-verify will
veranlassen, dass swaks versucht, das Zertifikat des Servers zu überprüfen. Wenn diese Option gesetzt ist und
das Zertifikat des Servers ist nicht überprüfbar (entweder mit der systemeigenen CA
Informationen oder benutzerdefinierte CA-Informationen (siehe --tls-ca-path)) TLS-Aushandlung wird nicht
gelingen.

--tls-ca-path [ /path/to/CAfile | /Pfad/zu/CAdir/ ]
Standardmäßig verwendet swaks die Standard-CA-Informationen der zugrunde liegenden OpenSSL-Bibliothek für
Überprüfung der Serverzertifikate. --tls-ca-path ermöglicht es Ihnen, eine Alternative anzugeben
Lage. Sehen http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html für den
Details zum Inhalt der Datei/des Verzeichnisses.

--tls-cert /Pfad/zur/Datei
Geben Sie einen Pfad zu einer Datei an, die die lokalen Zertifikatsswaks enthält, die verwendet werden sollen, wenn TLS . ist
ausgehandelt. Das Argument Dateipfad ist erforderlich. Wie derzeit implementiert die
Zertifikat in der Datei muss im PEM-Format vorliegen. Kontaktieren Sie den Autor, wenn es ein
zwingende Notwendigkeit für ASN1. Wenn diese Option gesetzt ist, ist auch --tls-key erforderlich.

--tls-key /Pfad/zur/Datei
Geben Sie einen Pfad zu einer Datei an, die die lokalen privaten Schlüssel enthält, die Swaks verwenden sollten, wenn TLS . ist
ausgehandelt. Das Argument Dateipfad ist erforderlich. Wie derzeit implementiert die
Zertifikat in der Datei muss im PEM-Format vorliegen. Kontaktieren Sie den Autor, wenn es ein
zwingende Notwendigkeit für ASN1. Wenn diese Option gesetzt ist, ist auch --tls-cert erforderlich.

--tls-get-peer-cert [/Pfad/zu/Datei]
Holen Sie sich eine Kopie des Zertifikats des TLS-Peers. Wenn kein Argument angegeben wird, ist es
auf STDOUT angezeigt. Wenn ein Argument angegeben wird, wird davon ausgegangen, dass es sich um einen Dateisystempfad handelt
Angabe, wo das Zertifikat ausgestellt werden soll. Das gespeicherte Zertifikat kann dann
mit Standardtools wie dem Befehl openssl untersucht. Wenn eine Datei angegeben ist, ist es
Inhalte werden überschrieben.

AUTHENTIFIZIERUNG

swaks wird versuchen, sich beim Ziel-Mailserver zu authentifizieren, wenn er dazu aufgefordert wird. Dies
Abschnitt beschreibt verfügbare Authentifizierungstypen, Anforderungen, Optionen und deren
Interaktionen und andere Feinheiten bei der Authentifizierungsverwendung. Denn Authentifizierung ist
als Erweiterung im ESMTP-Protokoll definiert, ist es nicht verfügbar, wenn --protocol gesetzt ist
zu einer variante von smtp.

Alle Authentifizierungsmethoden erfordern eine base64-Codierung. Wenn das MIME::Base64 Perl-Modul ist
loadable swaks versucht, es zu verwenden, um diese Codierungen durchzuführen. Wenn MIME::Base64 nicht ist
verfügbare swaks verwenden ihre eigenen integrierten base64-Routinen. Diese sind langsamer als die
MIME::Base64-Routinen und weniger überprüft, obwohl sie gründlich getestet wurden. Verwenden von
das MIME::Base64-Modul wird empfohlen.

Wenn eine Authentifizierung erforderlich ist (siehe Optionen unten, wann sie erforderlich ist und nicht) und
die Anforderungen für den verfügbaren Authentifizierungstyp nicht erfüllt sind, zeigt swaks einen Fehler an
und Ausfahrten. Dies kann auf zwei Arten geschehen, indem man swaks dazu zwingt, ein bestimmtes . zu verwenden
Authentifizierungstyp, den swaks aufgrund fehlender Anforderungen nicht verwenden kann oder swaks dies zulässt
Verwenden Sie einen beliebigen Authentifizierungstyp, aber der Server gibt nur Typen bekannt, die swaks nicht unterstützen kann. In
der erstere Fall schaltet Fehler zur Optionsverarbeitungszeit aus, da er es im Voraus weiß
wird sich nicht authentifizieren können. Im letzteren Fall wird swaks beim
Authentifizierungsphase der SMTP-Transaktion, da swaks nicht weiß, dass dies der Fall ist
kann sich bis dahin nicht authentifizieren.

Im Folgenden sind die unterstützten Authentifizierungstypen einschließlich aller individuellen Notizen und
Anforderungen.

Die folgenden Optionen wirken sich auf die Verwendung der Authentifizierung durch swaks aus. Diese Optionen sind alle inter-
verbunden. Beispielsweise impliziert die Angabe von --auth-user --auth und --auth-password.
Die Angabe von --auth-optional impliziert --auth-user und --auth-password usw.

-a, --auth [Authentifizierungstyp[,Authentifizierungstyp,...]]
Erfordert Swaks zur Authentifizierung. Wenn kein Argument angegeben wird, alle unterstützten Authentifizierungstypen
die vom Server angekündigt werden, werden versucht, bis eine erfolgreich ist oder alle fehlschlagen. Wenn einer oder mehrere
auth-types werden als Argument angegeben, jeder, der auch vom Server unterstützt wird, wird ausprobiert
in der richtigen Reihenfolge, bis einer erfolgreich ist oder alle scheitern. Diese Option erfordert Swaks zur Authentifizierung,
Wenn also keine gemeinsamen Authentifizierungstypen gefunden werden oder keine Anmeldeinformationen erfolgreich sind, zeigt swaks ein . an
Fehler und beendet.

In den folgenden Tabellen sind die gültigen Authentifizierungstypen aufgeführt

ANMELDEN, PLAIN
Diese grundlegenden Authentifizierungstypen werden vollständig unterstützt und getestet und haben keine
zusätzliche Anforderungen

CRAM-MD5
Der CRAM-MD5-Authentifikator erfordert das Digest::MD5-Modul. Es ist vollständig getestet
und es wird angenommen, dass es gegen jeden Server funktioniert, der es implementiert.

DIGEST-MD5
Der DIGEST-MD5-Authentifikator (RFC2831) erfordert das Authen::SASL-Modul. Ausführung
20100211.0 und früher verwendeten Authen::DigestMD5, das einige Fehler auf Protokollebene aufwies
was verhinderte, dass es mit einigen Servern funktioniert. Authen::SASL's DIGEST-MD5
Die Handhabung ist viel robuster.

Die DIGEST-MD5-Implementierung in swaks ist ziemlich unausgereift. Es unterstützt derzeit
nur der qop-Typ "auth". Wenn Sie DIGEST-MD5-Erfahrung haben und
möchte swaks dabei helfen DIGEST-MD5 besser zu unterstützen, bitte kontaktiere mich.

Der "realm"-Wert des DIGEST-MD5-Protokolls kann mit dem --auth-extra "realm" eingestellt werden.
Stichwort. Wenn kein Realm angegeben ist, wird ein angemessener Standardwert verwendet.

Die "digest-uri"-Werte des DIGEST-MD5-Protokolls können mit --auth-extra . eingestellt werden
Möglichkeit. Sie können beispielsweise den Digest-uri-Wert von . erstellen
"lmtp/mail.example.com/example.com" mit der Option "--auth-extra
dmd5-serv-type=lmtp,dmd5-host=mail.example.com,dmd5-serv-name=example.com".
Die Zeichenfolge "digest-uri-value" und ihre Komponenten sind in RFC2831 definiert. Wenn keiner von
diese Werte angegeben sind, werden angemessene Standardwerte verwendet.

CRAM-SHA1
Der CRAM-SHA1-Authentifikator erfordert das Digest::SHA-Modul. Dieser Typ hat nur
wurde gegen eine nicht standardmäßige Implementierung auf einem Exim-Server getestet und kann
haben daher einige Umsetzungsmängel.

NTLM/SPA/MSN
Diese Authentifikatoren erfordern das Authen::NTLM-Modul. Beachten Sie, dass es zwei gibt
Module, die den Authen::NTLM-Namespace auf CPAN verwenden. Die Mark Bush-Implementierung
(Authen/NTLM-1.03.tar.gz) ist die von swaks benötigte Version. Dieser Typ wurde
getestet gegen Exim, Communigate und Exchange 2007.

Zusätzlich zum Standard-Benutzernamen und -Passwort kann dieser Authentifizierungstyp
auch eine "Domäne" erkennen. Die Domain kann mit dem --auth-extra "domain" eingestellt werden
Stichwort. Beachten Sie, dass dies noch nie mit einem Mailserver getestet wurde, der dies nicht tut
ignorieren Sie DOMAIN, damit dies möglicherweise falsch implementiert wird.

-ao, --auth-optional [Authentifizierungstyp[,Authentifizierungstyp,...]]
Diese Option verhält sich identisch zu --auth, außer dass sie eine Authentifizierung anfordert
anstatt es zu verlangen. Wenn keine gemeinsamen Authentifizierungstypen oder keine Anmeldeinformationen gefunden werden
erfolgreich ist, fährt swaks fort, als ob keine Authentifizierung angefordert worden wäre.

-aos, --auth-optional-strict [Authentifizierungstyp[,Authentifizierungstyp,...]]
Diese Option ist ein Kompromiss zwischen --auth und --auth-optional. Wenn keine gemeinsame Auth-
Typen gefunden werden, verhält sich swaks so, als ob --auth-optional angegeben wäre und fährt fort mit
die Transaktion. Wenn swaks den angeforderten Authentifizierungstyp nicht unterstützen kann, tut der Server dies nicht
alle gängigen Authentifizierungstypen ankündigen, oder wenn keine Anmeldeinformationen erfolgreich sind, verhält sich swaks so, als ob
--auth wurden verwendet und wird mit einem Fehler beendet.

-au, --auth-user [Benutzername]
Geben Sie den für die Authentifizierung zu verwendenden Benutzernamen an oder fordern Sie den Benutzer auf, wenn nein
Argument geliefert wird. Die Zeichenfolge <> kann als leerer Benutzername angegeben werden.

-ap, --auth-password [Passwort]
Geben Sie das für die Authentifizierung zu verwendende Passwort an oder fordern Sie den Benutzer auf, es einzugeben, wenn nein
Argument geliefert wird. Die Zeichenfolge <> kann als leeres Kennwort angegeben werden.

-ae, --auth-extra [SCHLÜSSELWORT=Wert[,...]]
Einige der Authentifizierungstypen ermöglichen die Aufnahme zusätzlicher Informationen in die
Authentifizierungsprozess. Anstatt für jeden Winkel und jede Ecke von . eine neue Option hinzuzufügen
jedem Authentifikator ermöglicht die Option --auth-extra die Bereitstellung dieser Informationen.

In der folgenden Tabelle sind die aktuell erkannten Schlüsselwörter und die Authentifikatoren aufgeführt
die sie benutzen

Bereich, Domäne
Die Schlüsselwörter Realm und Domain sind synonym. Wenn Sie eines von beiden verwenden, wird die "Domäne" festgelegt.
Option in NTLM/MSN/SPA und die "Realm"-Option in DIGEST-MD5

dmd5-serv-type
Das Schlüsselwort dmd5-serv-type wird vom DIGEST-MD5-Authentifikator verwendet und verwendet, in
part, um den digest-uri-value String zu erstellen (siehe RFC2831)

dmd5-Host
Das Schlüsselwort dmd5-host wird vom DIGEST-MD5-Authentifikator verwendet und wird verwendet, in
part, um den digest-uri-value String zu erstellen (siehe RFC2831)

dmd5-Serv-Name
Das Schlüsselwort dmd5-serv-name wird vom DIGEST-MD5-Authentifikator verwendet und verwendet, in
part, um den digest-uri-value String zu erstellen (siehe RFC2831)

-am, --auth-map [auth-alias=auth-type[,...]]
Bietet eine Möglichkeit, den Basisauthentifizierungstypen alternative Namen zuzuordnen. Nützlich für alle
Websites, die alternative Namen für allgemeine Typen verwenden. Diese Funktionalität wird tatsächlich verwendet
intern die Typen SPA und MSN auf den Basistyp NTLM abzubilden. Die Befehlszeile
Argument um dies zu simulieren wäre "--auth-map SPA=NTLM,MSN=NTLM". Alle Authentifizierungs-
Die oben aufgeführten Typen sind gültige Ziele für die Zuordnung außer SPA und MSN.

-apt, --auth-plaintext
Anstatt AUTH-Strings base64-codiert anzuzeigen, während sie übertragen werden, übersetzen Sie sie
in Klartext vor dem Drucken auf dem Bildschirm.

-ahp, --auth-hide-password [Ersatzzeichenfolge]
Wenn diese Option angegeben ist, wird jederzeit ein lesbares Passwort auf dem
Terminal (insbesondere AUTH PLAIN und AUTH LOGIN) wird das Passwort durch a . ersetzt
Dummy-String (oder der Inhalt von "Ersatz-String", falls vorhanden). Der Dummy-String
wird base64-codiert oder nicht von der Option --auth-plaintext abhängig.

Beachten Sie, dass --auth-hide-password der --protect-prompt ähnlich, aber nicht identisch ist
Möglichkeit. Ersteres schützt Passwörter davor, in der SMTP-Transaktion angezeigt zu werden
unabhängig davon, wie sie eingegeben werden. Letzterer schützt empfindliche Saiten, wenn die
Der Benutzer gibt sie am Terminal ein, unabhängig davon, wie die Zeichenfolge verwendet werden würde.

XKUNDE OPTIONAL

XCLIENT ist eine SMTP-Erweiterung, die vom Postfix-Projekt eingeführt wurde. XCLIENT ermöglicht a
(ordnungsgemäß autorisierter) Client, um einen Server anzuweisen, alternative Informationen wie IP zu verwenden
Adresse oder Hostname für den Client. Dies ermöglicht viel einfachere Pfade zum Testen von E-Mails
Serverkonfigurationen. Ausführliche Informationen zum Protokoll finden Sie unter
http://www.postfix.org/XCLIENT_README.html.

--xclient-addr [WERT]
--xclient-name [WERT]
--xclient-port [WERT]
--xclient-proto [WERT]
--xclient-helo [WERT]
--xclient-login [WERT]
--xclient-reverse-name [WERT]
Diese Optionen geben XCLIENT-Attribute an, die an den Zielserver gesendet werden sollen. Wenn
[VALUE] wird nicht bereitgestellt, swaks fordert Sie auf und liest den Wert auf STDIN. Sehen
http://www.postfix.org/XCLIENT_README.html für offizielle Dokumentation für das, was die
Attribute bedeuten und ihre möglichen Werte, einschließlich des speziellen "[UNAVAILABLE]" und
"[TEMPUNAVAIL]"-Werte.

Als einfaches Beispiel kann die Einstellung "--xclient-name foo.example.com --xclient-addr
192.168.1.1" veranlasst swaks, den SMTP-Befehl "XCLIENT NAME=foo.example.com" zu senden
ADDR=192.168.1.1".

Beachten Sie, dass das Attribut "REVERSE_NAME" im offiziellen nicht auftaucht
Dokumentation. Es gibt einen Mailinglisten-Thread, der dies dokumentiert, einsehbar unter
http://comments.gmane.org/gmane.mail.postfix.user/192623.

Diese Optionen können alle miteinander gemischt werden und können mit dem --xclient . gemischt werden
Möglichkeit (siehe unten).

--xclient [XCLIENT_STRING]
Dies ist die XCLIENT-Option "freier Form". Welcher Wert auch immer für XCLIENT_STRING bereitgestellt wird
wird wörtlich als Argument an den XCLIENT-smtp-Befehl gesendet. Zum Beispiel, wenn
"--xclient 'NAME= ADDR=192.168.1.1 FOO=bar'" wird verwendet, swaks sendet den SMTP-Befehl
"XCLIENT NAME= ADDR=192.168.1.1 FOO=bar". Der Hauptvorteil gegenüber den mehr
Spezifische Optionen oben ist, dass es hier keine XCLIENT-Syntaxüberprüfung gibt. Dies
ermöglicht es Ihnen, ungültige XCLIENT zum Testen an den Zielserver zu senden. Wenn nein
XCLIENT_STRING wird auf der Kommandozeile übergeben, swaks fordert dazu auf und liest den Wert auf
STDIN.

Die Option --xclient kann frei mit den obigen Optionen --xclient-* gemischt werden. Wenn
"--xclient-addr 192.168.0.1 --xclient 'FOO=bar NAME=wind'" wird an swaks übergeben, "XCLIENT
ADDR=192.168.0.1 FOO=bar NAME=wind" wird an den Zielserver gesendet.

--xclient-optional
--xclient-optional-strict
Im Normalbetrieb führt das Setzen einer der --xclient*-Optionen zu einem erfolgreichen
XCLIENT-Transaktion stattfinden muss, um fortzufahren (d. h., XCLIENT muss
beworben worden sein, müssen alle vom Benutzer angeforderten Attribute beworben worden sein, und die
Server muss die XCLIENT-Anfrage von swaks akzeptiert haben). Diese Optionen ändern das
Verhalten. --xclient-optional weist swaks an, bedingungslos am XCLIENT vorbeizugehen
Phase der SMTP-Transaktion, unabhängig davon, ob sie erfolgreich war.
--xclient-optional-strict ist ähnlich, aber detaillierter. Die strenge Version wird
weiter zu XCLIENT wurde nicht beworben, schlägt aber fehl, wenn XCLIENT versucht wurde, es aber tat
nicht bestanden.

DATEN OPTIONAL

Diese Optionen beziehen sich auf den Inhalt des DATA-Teils der SMTP-Transaktion.

-d, --data [Datenteil]
Argument als gesamten Inhalt von DATA verwenden oder Benutzer auffordern, wenn kein Argument angegeben ist.
Bei Angabe des Arguments '-' werden die Daten aus STDIN gelesen. Falls sonst
Argument angegeben und stellt den Namen einer öffenbaren Datei dar, den Inhalt von
die Datei wird verwendet. Jedes andere Argument ist selbst für den DATA-Inhalt.

Der Wert kann in einer einzigen Zeile stehen, wobei \n (ascii 0x5c, 0x6e) darstellt, wo
Zeilenumbrüche sollten gesetzt werden. Führende Punkte werden zitiert. Schlusspunkt ist nicht
erforderlich, aber erlaubt. Der Standardwert für diese Option ist "Datum: %DATE%\nBis:
%TO_ADDRESS%\nVon: %FROM_ADDRESS%\nBetreff: Test %DATE%\nX-Mailer: swaks v$p_version
jetmore.org/john/code/swaks/\n%NEW_HEADERS%\n%BODY%\n".

Im DATA-Teil wird ein sehr grundlegendes Token-Parsing durchgeführt. Siehe --use-old-data-tokens
Einzelheiten zu den als veraltet markierten Einzelzeichen-Tokens. Die folgende
Tabelle zeigt die erkannten Token und ihre Ersatzwerte:

%VON DER ADRESSE%
Ersetzt durch den Umschlag-Absender. Ersetzt das veraltete %F-Token.

%TO_ADDRESS%
Ersetzt durch den/die Umschlagempfänger. Ersetzt das veraltete %T-Token.

%DATUM%
Ersetzt durch die aktuelle Uhrzeit in einem Format, das für die Aufnahme in das Datum geeignet ist:
Header. Beachten Sie, dass dies versucht, das Standardmodul Time::Local für die Zeitzone zu verwenden
Berechnungen. Wenn dieses Modul nicht verfügbar ist, wird die Datumszeichenfolge in GMT angezeigt.
Ersetzt das veraltete %D-Token.

%NEW_HEADERS%
Durch den Inhalt der Option --add-header ersetzt. Wenn --add-header nicht ist
angegeben, wird dieses Token einfach entfernt. Ersetzt das veraltete %H-Token.

%KAROSSERIE%
Durch den durch die Option --body angegebenen Wert ersetzt. Siehe --body für Standardwerte.
Ersetzt das veraltete %H-Token.

--use-old-data-tokens
In früheren Versionen von swaks die DATA-Token wie in der Option --data oben beschrieben
verwendet Einzelzeichen-Token (zB %F). Diese waren keine gute Wahl für die Standardeinstellung
Token und erwies sich als besonders problematisch bei codierten, nicht englischen Sprachen, bei denen
diese Zeichenkombinationen können häufig vorkommen. Die Einzelzeichen-Token waren
durch die oben aufgeführten, etwas weniger fehleranfälligen Versionen ersetzt. Die Aufbewahrung von
die alten Token und die Aufnahme dieser Option, um sie zu aktivieren, sind als a . gedacht
vorübergehende Hilfe für Benutzer, die über einen bestehenden Nachrichtenkorpus verfügen, der die alten Token verwendet. Der
Einzelzeichen-Token und die Option --use-old-data-tokens sollten in Betracht gezogen werden
veraltet und werden wahrscheinlich in der nächsten Version entfernt.

-dab, --dump-as-body
Wenn --dump-as-body verwendet wird und keine andere Option verwendet wird, um den Standardtext von . zu ändern
die Nachricht, der Körper wird durch eine Ausgabe ersetzt, die der Ausgabe von was ist
bereitgestellt von --dump. --dumps anfängliche Programmfunktionszeile wird nicht angezeigt, und
der Abschnitt "Daten" ist nicht enthalten. Außerdem enthält --dump immer Passwörter.
Standardmäßig enthält --dump-as-body keine Passwörter, dies kann jedoch mit geändert werden
--dump-as-body-shows-password.

-dabsp, --dump-as-body-shows-password
Veranlassen Sie --dump-as-body, Klartext-Passwörter einzuschließen. Diese Option wird nicht empfohlen.
Diese Option impliziert --dump-as-body.

--body [Körper-Spezifikation]
Geben Sie den Text der E-Mail an. Der Standardwert ist "Dies ist ein Testmailing". Wenn nein
Argument für --body wird angegeben, Aufforderung zur interaktiven Bereitstellung. Wenn '-' angegeben wird,
der Körper wird von der Standardeingabe gelesen. Wenn ein anderer Text bereitgestellt wird und der Text
eine öffenbare Datei darstellt, wird der Inhalt dieser Datei als Hauptteil verwendet. Wenn es
stellt keine öffenbare Datei dar, der Text selbst wird als Hauptteil verwendet.

Wenn die Nachricht in das MIME-Format gezwungen wird (siehe --attach) das Argument zu dieser Option
wird unverschlüsselt als erster MIME-Teil eingefügt. Sein Inhaltstyp wird immer sein
Text/einfach.

--attach [Anhang-Spezifikation]
Wenn eine oder mehrere --attach-Optionen angegeben werden, wird die Nachricht in a . geändert
mehrteilige/gemischte MIME-Nachricht. Die Argumente für --attach werden genauso verarbeitet wie
--body bzgl. stdin, Dateiinhalt etc. --attach kann mehrfach geliefert werden
Mal, um mehrere Anhänge zu erstellen. Standardmäßig wird jeder Anhang als a . angehängt
application/octet-stream-Datei. Siehe --attach-type zum Ändern dieses Verhaltens.

Wenn ein Dateiname angegeben wird, enthält die MIME-Codierung diesen Dateinamen. Sehen
--attach-name für weitere Details zur Dateibenennung.

Es ist zulässig, dass '-' (STDIN) mehrmals als Argument angegeben wird (einmal für
--body und mehrfach für --attach). In diesem Fall wird der gleiche Inhalt
wird bei jeder Angabe beigefügt. Dies ist nützlich, um denselben Inhalt anzuhängen
mit mehreren MIME-Typen.

--attach-type [MIME-Typ]
Standardmäßig ist Inhalt, der MIME mit der Option --attach an eine Nachricht angehängt bekommt,
codiert als Anwendungs-/Oktett-Stream. --attach-type ändert den Mime-Typ für alle
--attach-Option, die darauf folgt. Sie kann mehrfach angegeben werden.

--attach-name [Name]
Diese Option legt den Dateinamen fest, der in den MIME-Teil aufgenommen wird, der für die . erstellt wurde
next --attach-Option. Wenn für diese Option kein Argument festgelegt ist, verursacht sie keinen Dateinamen
Informationen, die für den nächsten MIME-Teil eingefügt werden sollen, auch wenn Swaks diese generieren könnten
aus dem lokalen Dateinamen.

-ah, --add-header [Header]
Diese Option ermöglicht das Hinzufügen von Headern zu den DATA. Wenn %H in den DATA vorhanden ist, ist es
wird durch das Argument dieser Option ersetzt. Wenn %H nicht vorhanden ist, lautet das Argument
zwischen den ersten beiden aufeinanderfolgenden Zeilenumbrüchen in den DATA eingefügt (d. h. es ist
am Ende der bestehenden Kopfzeilen eingefügt).

Die Option kann entweder mehrfach oder einmalig mit mehreren angegeben werden
Header, die durch eine literale '\n'-Zeichenfolge getrennt sind. Also, "--add-header 'Foo: bar' --add-header
'Baz: foo'" und "--add-header 'Foo: bar\nBaz: foo'" fügen am Ende dieselben beiden hinzu
Überschriften.

--header [Header-und-Daten], --h-Header [Daten]
Diese Optionen ermöglichen es, Header zu ändern, die bereits in den DATA vorhanden sind. '--Header
"Betreff: foo"' und '--h-Betreff foo' sind gleichwertig. Falls die Kopfzeile noch nicht vorhanden ist
in den Daten existieren, verhält sich dieses Argument identisch zu --add-header. wie auch immer, falls
der Header existiert bereits, er wird durch den angegebenen ersetzt.

-g Wenn angegeben, liest swaks den DATA-Wert für die Mail von STDIN. Das ist
entspricht "--data -". Wenn die E-Mail eine From_-Zeile enthält, wird sie entfernt
(aber siehe Option -nsf). Nützlich, um stattdessen echte Nachrichten (in Dateien gespeichert) zu übermitteln
Beispielnachrichten zu verwenden.

--no-data-fixup, -ndf
Diese Option zwingt swaks, den DATA-Teil der E-Mail nicht zu massieren. Dies
beinhaltet Token-Ersetzung, From_ Stripping, Trailing-Dot-Addition, --body/attachment
Inklusion und alle Header-Ergänzungen. Diese Option ist wirklich nur sinnvoll, wenn sie mit verwendet wird
--data, da der interne Standard-DATA-Teil Token verwendet.

--no-strip-from, -nsf
Entfernen Sie die From_-Zeile nicht aus dem DATA-Teil, falls vorhanden.

AUSGABE OPTIONAL

Standardmäßig stellt swaks seinem Aufrufer (STDOUT/STDERR) ein Transkript seiner Transaktionen zur Verfügung.
Dieses Transkript soll die Transaktion so getreu wie möglich wiedergeben
obwohl es diese Ausgabe modifiziert, indem es den Zeilen Informationspräfixe hinzufügt und um
Bereitstellung von Klartextversionen von TLS-Transaktionen

Die "Informationspräfixe" werden als Transaktionshinweise bezeichnet. Diese Hinweise sind
zunächst bestehend aus den Markierungslinien, die von Swaks selbst ausgegeben werden, entweder
Informations- oder Fehlermeldungen und solche, die eine tatsächlich gesendete Datenzeile anzeigen oder
in einer Transaktion erhalten. In dieser Tabelle sind die Hinweise und ihre Bedeutung aufgeführt:

=== Zeigt eine von swaks generierte Informationszeile an

*** Zeigt einen Fehler an, der innerhalb von Swaks generiert wurde

-> Zeigt eine erwartete Zeile an, die von swaks an den Zielserver gesendet wird

~> Zeigt eine TLS-verschlüsselte, erwartete Zeile an, die von swaks an den Zielserver gesendet wird

**> Weist auf eine unerwartete Zeile hin, die von swaks an den Zielserver gesendet wurde

*~> Zeigt eine TLS-verschlüsselte, unerwartete Zeile an, die von swaks an den Zielserver gesendet wird

> Zeigt einen rohen Testblock an, der von swaks an einen Zielserver gesendet wird (siehe --show-raw-text).
Auf dieser Ebene gibt es kein Konzept von "erwartet" oder "unerwartet".

<- Zeigt eine erwartete Zeile an, die vom Zielserver an swaks gesendet wird

<~ Gibt eine TLS-verschlüsselte, erwartete Zeile an, die vom Zielserver an swaks gesendet wird

<** Zeigt eine unerwartete Zeile an, die vom Zielserver an swaks gesendet wurde

<~* Zeigt eine TLS-verschlüsselte, unerwartete Zeile an, die vom Zielserver an swaks gesendet wurde

< Zeigt einen rohen Textblock an, der von swaks von einem Zielserver empfangen wurde (siehe
--show-raw-text). Auf dieser Ebene gibt es kein Konzept von "erwartet" oder "unerwartet".

Die folgenden Optionen steuern, was und wie die Ausgabe dem Anrufer angezeigt wird.

-n, --suppress-data
Fasst den DATA-Teil der SMTP-Transaktion zusammen, anstatt jede Zeile zu drucken.
Diese Option ist sehr hilfreich und grenzt an erforderlich, wenn Sie Swaks verwenden, um bestimmte . zu senden
E-Mails testen. E-Mails mit Anhängen zum Beispiel überfordern ein Terminal schnell
wenn die DATEN nicht unterdrückt werden.

-stl, --show-time-lapse [i]
Anzeige der Zeitspanne zwischen Sende-/Empfangspaaren. Diese Option ist am nützlichsten, wenn
Time::HiRes ist verfügbar, in diesem Fall wird der Zeitraffer in angezeigt
Tausendstelsekunden. Wenn Time::HiRes nicht verfügbar ist oder "i" als Argument angegeben wird
der Verfall wird nur in ganzzahligen Sekunden angezeigt.

-nih, --no-info-hints
Zeigen Sie den Transaktionshinweis nicht für Informationstransaktionen an. Das ist am meisten
nützlich, wenn Sie einige Teile der Informationszeilen kopieren müssen, zum Beispiel die
Zertifikatausgabe von --tls-get-peer-cert.

-nsh, --no-send-hints
-nrh, --no-receive-hints
-nth, --no-hints
--no-send-hints und --no-receive-hints unterdrücken das Transaktionspräfix von send und
Empfangsleitungen bzw. Dies ist oft nützlich, wenn Sie einen Teil der
Transaktion zur Verwendung an anderer Stelle (zum Beispiel "--no-send-hints --hide-receive
--hide-informational" ist eine nützliche Methode, um nur die clientseitigen Befehle für eine bestimmte Funktion abzurufen
Transaktion). --no-hints ist identisch mit der Angabe von --no-send-hints und
--no-receive-hints.

Keine Transaktionshinweise anzeigen (nützlich in Verbindung mit -hr, um kopier-/einfügbar zu erstellen
Transaktionen).

-raw, --show-raw-text
Diese Option druckt einen Hex-Dump der von Swaks gesendeten und empfangenen Rohdaten. Jedes Hex
dump ist der Inhalt eines einzelnen Lese- oder Schreibvorgangs im Netzwerk. Das sollte sein
identisch mit dem, was bereits angezeigt wird (mit Ausnahme der \r-Zeichen
entfernt wird). Diese Option ist nützlich, um Details anzuzeigen, wenn Server Lose senden
von Daten in einzelne Pakete oder das Aufteilen einzelner Leitungen in mehrere Pakete. Wenn
du musst in diesem Bereich wirklich in die Tiefe gehen, du bist wahrscheinlich besser mit einem Paket
Sniffer, aber diese Option ist ein guter erster Schritt, um seltsame Verbindungsprobleme zu erkennen.

--output-file
--output-file-stdout
--output-file-stderr
Diese Optionen ermöglichen es dem Benutzer, die Ausgabe an Dateien statt an stdout/stderr zu senden. Der
Die erste Option sendet beide an dieselbe Datei. Die Argumente von &STDOUT und &STDERR sind
speziell behandelt, bezogen auf die "normalen" Datei-Handles, also "--output-file-stderr
'&STDOUT'" würde STDERR zu STDOUT umleiten.

-pp, --protect-prompt
Geben Sie keine Benutzereingaben bei potenziell sensiblen Eingabeaufforderungen wieder (nur jetzt .)
Authentifizierungspasswort). Siehe auch --auth-hide-password

-hr, --hide-receive
Zeigen Sie keine Zeilen an, die vom Remote-Server gesendet werden und von swaks empfangen werden

-hs, --hide-senden
Zeigen Sie keine Zeilen an, die von Swaks an den Remote-Server gesendet werden

-hi, --hide-informational
Zeigen Sie keine fehlerfreien Informationszeilen von Swaks selbst an.

-ha, --hide-all
Zeigen Sie keine Inhalte auf dem Terminal an.

-S, --silent [Stufe]
Veranlasse Swaks, zu schweigen. Wenn kein Argument angegeben wird oder wenn ein Argument von "1" angegeben wird,
keine Ausgabe drucken, es sei denn,/bis ein Fehler auftritt, wonach alle Ausgaben angezeigt werden. Wenn ein
Argument "2" angegeben, nur Druckfehler. Wenn "3" angegeben ist, wird nie eine Ausgabe angezeigt.

--Unterstützung
Druckfunktionen und Beenden. Bestimmte Funktionen erfordern nicht standardmäßige Perl-Module.
Diese Option wertet aus, ob diese Module vorhanden sind und zeigt an, welche
Funktionalität verfügbar ist und welche nicht und welche Module müssten hinzugefügt werden
um die fehlende Funktionalität zu erhalten.

--entsorgen
Diese Option bewirkt, dass swaks die Ergebnisse der Optionsverarbeitung unmittelbar vor . druckt
Mail wäre verschickt worden. Bei Verwendung von --dump wird keine E-Mail gesendet. Beachten Sie, dass
--dump gilt als reines Selbstdiagnose-Tool und es werden keine Anstrengungen unternommen oder gemacht
jemals dazu gebracht werden, Passwörter in der --dump-Ausgabe zu maskieren.

--help
Zeigen Sie diese Hilfeinformationen an.

--Version
Versionsinformationen anzeigen.

PORTABILITÄT

BETRIEBSSYSTEME
Dieses Programm war in erster Linie für die Verwendung auf Unix-ähnlichen Betriebssystemen gedacht, und es
sollte an jeder vernünftigen Version davon arbeiten. Es wurde entwickelt und getestet auf
Solaris, Linux und Mac OS X und ist für alle diese Funktionen vollständig.

Dieses Programm ist dafür bekannt, grundlegende Funktionen unter Windows zu demonstrieren
Perl von ActiveState. Es wurde nicht vollständig getestet. Als funktionierend bekannt sind grundlegende SMTP
Funktionalität und die Authentifizierungstypen LOGIN, PLAIN und CRAM-MD5. Unbekannt ist ein TLS
Funktionalität und die Authentifizierungstypen NTLM/SPA und DIGEST-MD5.

Da dieses Programm überall dort funktionieren sollte, wo Perl funktioniert, würde ich mich freuen, wenn ich etwas darüber erfahren würde
alle neuen Betriebssysteme, auf denen Sie swaks gründlich verwendet haben, sowie alle Probleme
auf einem neuen Betriebssystem angetroffen.

MAIL-SERVER
Dieses Programm wurde fast ausschließlich für Exim-Mailserver entwickelt. Es war gewesen
vom Autor beiläufig verwendet, jedoch nicht gründlich getestet, mit Sendmail, Smail,
Exchange, Oracle Collaboration Suite, qpsmtpd und Communigate. Denn alle
Die Funktionalität in Swaks basiert auf bekannten Standards und sollte mit jedem einigermaßen funktionieren
moderner Mailserver. Wenn ein Problem gefunden wird, benachrichtigen Sie bitte den Autor unter der Adresse
unten mit.

EXIT CODES

0 keine Fehler aufgetreten

1 Fehler beim Analysieren der Befehlszeilenoptionen

2 Fehler beim Verbinden mit dem Remote-Server

3 unbekannter Verbindungstyp

4 während des Betriebs mit Verbindungstyp "Pipe", fatales Problem beim Schreiben auf oder Lesen von
der Kindprozess

5 während der Ausführung mit dem Verbindungstyp "pipe" ist der untergeordnete Prozess unerwartet gestorben. Dies
kann bedeuten, dass das mit --pipe angegebene Programm nicht existiert.

6 Verbindung wurde unerwartet geschlossen. Wenn die Schließung als Reaktion auf 'QUIT' erkannt wird
swaks sendet nach einer unerwarteten Antwort den Fehlercode für diese unerwartete
Stattdessen wird eine Antwort verwendet. Wenn beispielsweise ein Mailserver eine 550-Antwort an a . zurückgibt
MAIL FROM: und schließt dann sofort die Verbindung, swaks erkennt, dass die
Verbindung wird geschlossen, verwendet jedoch den spezifischeren Exit-Code 23, um die Art von . zu beschreiben
der Fehlschlag. Wenn der Server stattdessen einen 250-Code zurückgibt und dann sofort die
Verbindung verwendet swaks den Exit-Code 6, da es keinen genaueren Exit gibt
Code.

10 Fehler in den Voraussetzungen (benötigtes Modul nicht verfügbar)

21 Fehler beim Lesen des ersten Banners vom Server

22 Fehler in HELO Transaktion

23 Fehler in der MAIL-Transaktion

24 keine RCPTs akzeptiert

25 Server hat Fehler bei DATA-Anfrage zurückgegeben

26 Server hat keine E-Mail mit folgenden Daten akzeptiert

27 Server hat nach Aufforderung zum Beenden der normalen Sitzung einen Fehler zurückgegeben

28 Fehler in der AUTH-Transaktion

29 Fehler in der TLS-Transaktion

32 Fehler in EHLO nach TLS-Aushandlung

33 Fehler in der XCLIENT-Transaktion

34 Fehler in EHLO nach XCLIENT

ÜBER UNS NAME/FUNKTION

Der Name "Swaks" ist ein (eine Art) Akronym für "SWiss Army Knife Smtp". Es wurde gewählt, um zu sein
ziemlich deutlich und aussprechbar. Während "swaks" als Name einer Software einzigartig ist
Paket, es hat einige andere, nicht-softwarebezogene Bedeutungen. Bitte senden Sie andere Verwendungen von "swak" oder
"swaks" für die Aufnahme.

"Versiegelt mit einem Kuss"
SWAK/SWAKs taucht gelegentlich im Internet mit der Bedeutung "mit Liebe" auf.

schlecht / arm / krank (Afrikaans)
Gesehen in der Schlagzeile "SA se bes en swaks gekledes im Jahr 2011", was übersetzt wurde als
"am besten und schlechtesten angezogen" von Muttersprachlern. Google Übersetzer mag "swaks" nicht
gekledes", aber es wird "swak" als "arm" und "swak geklede" als "schlecht gekleidet" übersetzen.

KONTAKT

[E-Mail geschützt]
Bitte verwenden Sie diese Adresse für allgemeine Kontaktaufnahme, Fragen, Patches, Anfragen usw.

[E-Mail geschützt]
Wenn Sie in eine Liste aufgenommen werden möchten, um Benachrichtigungen zu erhalten, wenn eine neue Version von
swaks ist erschienen, bitte schicke eine E-Mail an diese Adresse.

http://www.jetmore.org/john/code/swaks/
Änderungsprotokolle, diese Hilfe und die neueste Version finden Sie unter diesem Link.

Verwenden Sie swaks online mit den onworks.net-Diensten