Packages and Binaries:

swaks

swaks (Swiss Army Knife SMTP) is a command-line tool written in Perl for testing SMTP setups; it supports STARTTLS and SMTP AUTH (PLAIN, LOGIN, CRAM-MD5, SPA, and DIGEST-MD5). swaks allows one to stop the SMTP dialog at any stage, e.g to check RCPT TO: without actually sending a mail.

If you are spending too much time iterating “telnet foo.example 25” swaks is for you.

Installed size: 286 KB
How to install: sudo apt install swaks

  • perl
swaks

Swiss Army Knife SMTP, the all-purpose SMTP transaction tester

root@kali:~# swaks --help
SWAKS(1)                             SWAKS                            SWAKS(1)

NAME
       Swaks - Swiss Army Knife SMTP, the all-purpose SMTP transaction tester

DESCRIPTION
       Swaks' primary design goal is to be a flexible, scriptable,
       transaction-oriented SMTP test tool.  It handles SMTP features and
       extensions such as TLS, authentication, and pipelining; multiple
       version of the SMTP protocol including SMTP, ESMTP, and LMTP; and
       multiple transport methods including UNIX-domain sockets, internet-
       domain sockets, and pipes to spawned processes.  Options can be
       specified in environment variables, configuration files, and the
       command line allowing maximum configurability and ease of use for
       operators and scripters.

QUICK START
       Deliver a standard test email to user@example.com on port 25 of
       test-server.example.net:

        swaks --to user@example.com --server test-server.example.net

       Deliver a standard test email, requiring CRAM-MD5 authentication as
       user me@example.com.  An "X-Test" header will be added to the email
       body.  The authentication password will be prompted for if it cannot be
       obtained from your .netrc file.

        swaks --to user@example.com --from me@example.com --auth CRAM-MD5 --auth-user me@example.com --header-X-Test "test email"

       Test a virus scanner using EICAR in an attachment.  Don't show the
       message DATA part.:

        swaks -t user@example.com --attach - --server test-server.example.com --suppress-data </path/to/eicar.txt

       Test a spam scanner using GTUBE in the body of an email, routed via the
       MX records for example.com:

        swaks --to user@example.com --body /path/to/gtube/file

       Deliver a standard test email to user@example.com using the LMTP
       protocol via a UNIX domain socket file

        swaks --to user@example.com --socket /var/lda.sock --protocol LMTP

       Report all the recipients in a text file that are non-verifiable on a
       test server:

        for 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
        done

TERMS AND CONVENTIONS
       This document tries to be consistent and specific in its use of the
       following terms to reduce confusion.

       Target
           The target of a transaction is the thing that Swaks connects to.
           This generic term is used throughout the documentation because most
           other terms improperly imply something about the transport being
           used.

       Transport
           The transport is the underlying method used to connect to the
           target.

       Transaction
           A transaction is the opening of a connection over a transport to a
           target and using a messaging protocol to attempt to deliver a
           message.

       Protocol
           The protocol is the application language used to communicate with
           the target.  This document uses SMTP to speak generically of all
           three supported protocols unless it states that it is speaking of
           the specific 'SMTP' protocol and excluding the others.

       Message
           SMTP protocols exist to transfer messages, a set of bytes in an
           agreed-upon format that has a sender and a recipient.

       Envelope
           A message's envelope contains the "true" sender and receiver of a
           message.  It can also be referred to as its components, envelope-
           sender and envelope-recipients.  It is important to note that a
           messages envelope does not have to match its "To:" and "From:"
           headers.

       DATA
           The DATA portion of an SMTP transaction is the actual message that
           is being transported.  It consists of both the message's headers
           and its body.  DATA and body are sometimes used synonymously, but
           they are always two distinct things in this document.

       Headers
           A message's headers are defined as all the lines in the message's
           DATA section before the first blank line.  They contain information
           about the email that will be displayed to the recipient such as
           "To:", "From:", "Subject:", etc.  In this document headers will
           always be written with a capitalized first letter and a trailing
           colon.

       Body
           A message's body is the portion of its DATA section following the
           first blank line.

       Option
           An option is a flag which changes Swaks' behavior.  Always called
           an option regardless of how it is provided.  For instance,
           "--no-data-fixup" is an option.

       Argument
           When an option takes addition data beside the option itself, that
           additional data is called an argument. In "--quit-after
           <stop-point>'", "<stop-point>" is the argument to the
           "--quit-after" option.

       <literal-string>
           When used in the definition of an option, text that is inside of
           angle brackets ("<>") indicates a descriptive label for a value
           that the user should provide.  For instance, "--quit-after
           <stop-point>" indicates that "<stop-point>" should be replaced with
           a valid stop-point value.

       [<optional-value>]
           When used in the definition of an option, text inside of square
           brackets ([]) indicates that the value is optional and can be
           omitted.  For instance, "--to [<recipient>]" indicates that the
           "--to" option can be used with or without a specified
           "<recipient>".

OPTION PROCESSING
       To prevent potential confusion in this document a flag to Swaks is
       always referred to as an "option".  If the option takes additional
       data, that additional data is referred to as an argument to the option.
       For example, "--from fred@example.com" might be provided to Swaks on
       the command line, with "--from" being the option and "fred@example.com"
       being "--from"'s argument.

       Options and arguments are the only way to provide information to Swaks.
       If Swaks finds data during option processing that is neither an option
       nor an option's argument, it will error and exit.  For instance, if
       "--no-data-fixup 1" were found on the command line, this would result
       in an error because "--no-data-fixup" does not take an argument and
       therefore Swaks would not know what to do with 1.

       Options can be given to Swaks in three ways.  They can be specified in
       a configuration file, in environment variables, and on the command
       line.  Depending on the specific option and whether an argument is
       given to it, Swaks may prompt the user for the argument.

       When Swaks evaluates its options, it first looks for a configuration
       file (either in a default location or specified with "--config").  Then
       it evaluates any options in environment variables.  Finally, it
       evaluates command line options.  At each round of processing, any
       options set earlier will be overridden.  Additionally, any option can
       be prefixed with "no-" to cause Swaks to forget that the variable had
       previously been set (either in an earlier round, or earlier in the same
       round).  This capability is necessary because many options treat
       defined-but-no-argument differently than not-defined.

       As a general rule, if the same option is given multiple time, the last
       time it is given is the one that will be used.  This applies to both
       intra-method (if "--from user1@example.com --from user2@example.com" is
       given, "user2@example.com" will be used) and inter-method (if "from
       user1@example.com" is given in a config file and "--from
       user2@example.com" is given on the command line, "user2@example.com"
       will be used)

       Each option definition ends with a parenthetical synopsis of how the
       option behaves.  The following codes can be used

       Arg-None, Arg-Optional, Arg-Required
           These three codes are mutually exclusive and describe whether or
           not the option takes an argument.  Note that this does not
           necessarily describe whether the argument is required to be
           specified directly, but rather whether an argument is required
           eventually.  For instance, "--to" is labeled as Arg-Required, but
           it is legal to specify "--to" on the command line without an
           argument.  This is because Swaks can prompt for the required
           argument if it is not directly provided.

       From-Prompt
           An option labeled with From-Prompt will prompt the user
           interactively for the argument if none is provided.

       From-File
           An option labeled with From-File will handle arguments as files in
           certain situations.

           If the initial argument is "-", the final argument is the contents
           of "STDIN".  Multiple options can all specify "STDIN", but the same
           content will be used for each of them.

           If the initial argument is prefixed with "@", the argument will be
           treated as a path to a file.  The file will be opened and the
           contents will be used as the final argument.  If the contents of
           the file can't be read, Swaks will exit.  To specify a literal
           value starting with an "@", use two "@" symbols.  The first will be
           stripped.

       Sensitive
           If an option marked Sensitive attempts to prompt the user for an
           argument and the "--protect-prompt" option is set, Swaks will
           attempt to mask the user input from being echoed on the terminal.
           Swaks tries to mask the input in several ways, but if none of them
           work program flow will continue with unmasked input.

       Deprecated
           An option labeled Deprecated has been officially deprecated and
           will be removed in a future release.  See the "DEPRECATIONS"
           section of this documentation for details about the deprecations.

       The exact mechanism and format for using each of the types is listed
       below.

       CONFIGURATION FILES
           A configuration file can be used to set commonly-used or abnormally
           verbose options.  By default, Swaks looks in order for
           $SWAKS_HOME/.swaksrc, $HOME/.swaksrc, and $LOGDIR/.swaksrc.  If one
           of those is found to exist (and "--config" has not been used) that
           file is used as the configuration file.

           Additionally, a configuration file in a non-default location can be
           specified using "--config".  If this is set and not given an
           argument Swaks will not use any configuration file, including any
           default file.  If "--config" points to a readable file, it is used
           as the configuration file, overriding any default that may exist.
           If it points to a non-readable file an error will be shown and
           Swaks will exit.

           A set of "portable" defaults can also be created by adding options
           to the end of the Swaks program file.  As distributed, the last
           line of Swaks should be "__END__".  Any lines added after "__END__"
           will be treated as the contents of a configuration file.  This
           allows a set of user preferences to be automatically copied from
           server to server in a single file.

           If configuration files have not been explicitly turned off, the
           "__END__" config is always read.  Only one other configuration file
           will ever be used per single invocation of Swaks, even if multiple
           configuration files are specified.  If the "__END__" config and
           another config are to be read, the "__END__" config will be
           processed first.  Specifying the "--config" option with no argument
           turns off the processing of both the "__END__" config and any
           actual config files.

           In a configuration file lines beginning with a hash ("#") are
           ignored.  All other lines are assumed to be an option to Swaks,
           with the leading dash or dashes optional.  Everything after an
           option line's first space is assumed to be the option's argument
           and is not shell processed.  Therefore, quoting is usually unneeded
           and will be included literally in the argument.

           There is a subtle difference between providing an option with no
           argument and providing an option with an empty argument.  If an
           option line does not have a space, the entire line is treated as an
           option and there is no argument.  If the line ends in a single
           space, it will be processed as an option with an empty argument.
           So, "apt" will be treated as "--apt", but "apt " will be treated as
           "--apt ''".

           Here is an example of the contents of a configuration file:

               # always use this sender, no matter server or logged in user
               --from fred@example.com
               # I prefer my test emails have a pretty from header.  Note
               # the lack of dashes on option and lack of quotes around
               # entire argument.
               h-From: "Fred Example" <fred@example.com>

           Options specific to configuration file:

           --config [<config-file>]
               This option provides a path to a specific configuration file to
               be used.  If specified with no argument, no automatically-found
               configuration file (via $HOME, etc, or "__END__") will be
               processed.  If the argument is a valid file, that file will be
               used as the configuration file (after "__END__" config).  If
               argument is not a valid, readable file, Swaks will error and
               exit.  This option can be specified multiple times, but only
               the first time it is specified (in environment variable and the
               command line search order) will be used. (Arg-Optional)

       CONFIGURATION ENVIRONMENT VARIABLES
           Options can be supplied via environment variables.  The variables
           are in the form $SWAKS_OPT_name, where "name" is the name of the
           option that would be specified on the command line.  Because dashes
           aren't allowed in environment variable names in most UNIX-ish
           shells, no leading dashes should be used and any dashes inside the
           option's name should be replaced with underscores.  The following
           would create the same options shown in the configuration file
           example:

               $ SWAKS_OPT_from='fred@example.com'
               $ SWAKS_OPT_h_From='"Fred Example" <fred@example.com>'

           Setting a variable to an empty value is the same as specifying it
           on the command line with no argument.  For instance, setting
           <SWAKS_OPT_server=""> would cause Swaks to prompt the user for the
           server to which to connect at each invocation.

           Because there is no inherent order in options provided by setting
           environment variables, the options are sorted before being
           processed.  This is not a great solution, but it at least defines
           the behavior, which would be otherwise undefined.  As an example,
           if both $SWAKS_OPT_from and $SWAKS_OPT_f were set, the value from
           $SWAKS_OPT_from would be used, because it sorts after $SWAKS_OPT_f.
           Also as a result of not having an inherent order in environment
           processing, unsetting options with the "no-" prefix is unreliable.
           It works if the option being turned off sorts before "no-", but
           fails if it sorts after. Because "no-" is primarily meant to
           operate between config types (for instance, unsetting from the
           command line an option that was set in a config file), this is not
           likely to be a problem.

           In addition to setting the equivalent of command line options,
           $SWAKS_HOME can be set to a directory containing the default
           .swaksrc to be used.

       COMMAND LINE OPTIONS
           The final method of supplying options to Swaks is via the command
           line.  The options behave in a manner consistent with most UNIX-ish
           command line programs.  Many options have both a short and long
           form (for instance "-s" and "--server").  By convention short
           options are specified with a single dash and long options are
           specified with a double-dash.  This is only a convention and either
           prefix will work with either type.

           The following demonstrates the example shown in the configuration
           file and environment variable sections:

               $ swaks --from fred@example.com --h-From: '"Fred Example" <fred@example.com>'

TRANSPORTS
       Swaks can connect to a target via UNIX pipes ("pipes"), UNIX domain
       sockets ("UNIX sockets"), or internet domain sockets ("network
       sockets").  Connecting via network sockets is the default behavior.
       Because of the singular nature of the transport used, each set of
       options in the following section is mutually exclusive.  Specifying
       more than one of "--server", "--pipe", or "--socket" will result in an
       error.  Mixing other options between transport types will only result
       in the irrelevant options being ignored.  Below is a brief description
       of each type of transport and the options that are specific to that
       transport type.

       NETWORK SOCKETS
           This transport attempts to deliver a message via TCP/IP, the
           standard method for delivering SMTP.  This is the default transport
           for Swaks.  If none of "--server", "--pipe", or "--socket" are
           given then this transport is used and the target server is
           determined from the recipient's domain (see "--server" below for
           more details).

           This transport requires the IO::Socket module which is part of the
           standard Perl distribution.  If this module is not loadable,
           attempting to use this transport will result in an error and
           program termination.

           IPv6 is supported when the IO::Socket::INET6 module is present.

           -s, --server [<target-server>[:<port>]]
               Explicitly tell Swaks to use network sockets and specify the
               hostname or IP address to which to connect, or prompt if no
               argument is given.  If this option is not given and no other
               transport option is given, the target mail server is determined
               from the appropriate DNS records for the domain of the
               recipient email address using the Net::DNS module.  If Net::DNS
               is not available Swaks will attempt to connect to localhost to
               deliver.  The target port can optionally be set here.
               Supported formats for this include SERVER:PORT (supporting
               names and IPv4 addresses); [SERVER]:PORT and SERVER/PORT
               (supporting names, IPv4 and IPv6 addresses).  See also
               "--copy-routing". (Arg-Required, From-Prompt)

           -p, --port [<port>]
               Specify which TCP port on the target is to be used, or prompt
               if no argument is listed.  The argument can be a service name
               (as retrieved by getservbyname(3)) or a port number.  The
               default port is smtp/25 unless influenced by the "--protocol"
               or "--tls-on-connect" options. (Arg-Required, From-Prompt)

           -li, --local-interface [<local-interface>[:<port>]]
               Use argument as the local interface for the outgoing SMTP
               connection, or prompt user if no argument given.  Argument can
               be an IP address or a hostname.  Default action is to let the
               operating system choose the local interface.  See "--server"
               for additional comments on :<port> format. (Arg-Required, From-
               Prompt)

           -lp, --local-port, --lport [<port>]
               Specify the outgoing port from which to originate the
               transaction.  The argument can be a service name (as retrieved
               by getservbyname(3)) or a port number.  If this option is not
               specified the system will pick an ephemeral port.  Note that
               regular users cannot specify some ports. (Arg-Required, From-
               Prompt)

           --copy-routing <domain>
               The argument is interpreted as the domain part of an email
               address and it is used to find the target server using the same
               logic that would be used to look up the target server for a
               recipient email address.  See "--to" option for more details on
               how the target is determined from the email domain. (Arg-
               Required)

           -4, -6
               Force IPv4 or IPv6. (Arg-None)

       UNIX SOCKETS
           This transport method attempts to deliver messages via a UNIX-
           domain socket file.  This is useful for testing MTA/MDAs that
           listen on socket files (for instance, testing LMTP delivery to
           Cyrus).  This transport requires the IO::Socket module which is
           part of the standard Perl distribution.  If this module is not
           loadable, attempting to use this transport will result in an error
           and program termination.

           --socket [<socket-file>]
               This option takes as its argument a UNIX-domain socket file.
               If Swaks is unable to open this socket it will display an error
               and exit. (Arg-Required, From-Prompt)

       PIPES
           This transport attempts to spawn a process and communicate with it
           via pipes.  The spawned program must be prepared to behave as a
           mail server over "STDIN"/"STDOUT".  Any MTA designed to operate
           from inet/xinet should support this.  In addition, some MTAs
           provide testing modes that can be communicated with via
           "STDIN"/"STDOUT".  This transport can be used to automate that
           testing.  For example, if you implemented DNSBL checking with Exim
           and you wanted to make sure it was working, you could run "swaks
           --pipe "exim -bh 127.0.0.2"".  Ideally, the process you are talking
           to should behave exactly like an SMTP server on "STDIN" and
           "STDOUT".  Any debugging should be sent to "STDERR", which will be
           directed to your terminal.  In practice, Swaks can generally handle
           some debug on the child's "STDOUT", but there are no guarantees on
           how much it can handle.

           This transport requires the IPC::Open2 module which is part of the
           standard Perl distribution.  If this module is not loadable,
           attempting to use this transport will result in an error and
           program termination.

           --pipe [<command-and-arguments>]
               Provide a process name and arguments to the process.  Swaks
               will attempt to spawn the process and communicate with it via
               pipes.  If the argument is not an executable Swaks will display
               an error and exit. (Arg-Required, From-Prompt)

PROTOCOL OPTIONS
       These options are related to the protocol layer.

       -t, --to [<email-address>[,<email-address>[,...]]]
           Tells Swaks to use argument(s) as the envelope-recipient for the
           email, or prompt for recipient if no argument provided.  If
           multiple recipients are provided and the recipient domain is needed
           to determine routing the domain of the last recipient provided is
           used.

           There is no default value for this option.  If no recipients are
           provided via any means, user will be prompted to provide one
           interactively.  The only exception to this is if a "--quit-after"
           value is provided which will cause the SMTP transaction to be
           terminated before the recipient is needed. (Arg-Required, From-
           Prompt)

       -f, --from [<email-address>]
           Use argument as envelope-sender for email, or prompt user if no
           argument specified.  The string "<>" can be supplied to mean the
           null sender.  If user does not specify a sender address a default
           value is used.  The domain-part of the default sender is a best
           guess at the fully-qualified domain name of the local host.  The
           method of determining the local-part varies.  On Windows,
           "Win32::LoginName()" is used.  On UNIX-ish platforms, the $LOGNAME
           environment variable is used if it is set.  Otherwise getpwuid(3)
           is used.  See also "--force-getpwuid".  If Swaks cannot determine a
           local hostname and the sender address is needed for the
           transaction, Swaks will error and exit.  In this case, a valid
           string must be provided via this option. (Arg-Required, From-
           Prompt)

       --ehlo, --lhlo, -h, --helo [<helo-string>]
           String to use as argument to HELO/EHLO/LHLO command, or prompt user
           if no argument is specified.  If this option is not used a best
           guess at the fully-qualified domain name of the local host is used.
           If Swaks cannot determine a local hostname and the helo string is
           needed for the transaction, Swaks will error and exit.  In this
           case, a valid string must be provided via this option. (Arg-
           Required, From-Prompt)

       -q, --quit, --quit-after <stop-point>
           Point at which the transaction should be stopped.  When the
           requested stopping point is reached in the transaction, and
           provided that Swaks has not errored out prior to reaching it, Swaks
           will send "QUIT" and attempt to close the connection cleanly.
           These are the valid arguments and notes about their meaning. (Arg-
           Required)

           CONNECT, BANNER
               Terminate the session after receiving the greeting banner from
               the target.

           FIRST-HELO, FIRST-EHLO, FIRST-LHLO
               In a STARTTLS (but not tls-on-connect) session, terminate the
               transaction after the first of two HELOs.  In a non-STARTTLS
               transaction, behaves the same as HELO (see below).

           XCLIENT
               Quit after XCLIENT is sent.

           STARTTLS, TLS
               Quit the transaction immediately following TLS negotiation.
               Note that this happens in different places depending on whether
               STARTTLS or tls-on-connect are used.  This always quits after
               the point where TLS would have been negotiated, regardless of
               whether it was attempted.

           HELO, EHLO, LHLO
               In a STARTTLS or XCLIENT session, quit after the second HELO.
               Otherwise quit after the first and only HELO.

           AUTH
               Quit after authentication.  This always quits after the point
               where authentication would have been negotiated, regardless of
               whether it was attempted.

           MAIL, FROM
               Quit after MAIL FROM: is sent.

           RCPT, TO
               Quit after RCPT TO: is sent.

       --da, --drop-after <stop-point>
           The option is similar to "--quit-after", but instead of trying to
           cleanly shut down the session it simply terminates the session.
           This option accepts the same stop-points as "--quit-after" and
           additionally accepts DATA and DOT, detailed below. (Arg-Required)

           DATA
               Quit after DATA is sent.

           DOT Quit after the final '.' of the message is sent.

       --das, --drop-after-send <stop-point>
           This option is similar to "--drop-after", but instead of dropping
           the connection after reading a response to the stop-point, it drops
           the connection immediately after sending stop-point.  It accepts
           the same stop-points as "--drop-after". (Arg-Required)

       --timeout [<time>]
           Use argument as the SMTP transaction timeout, or prompt user if no
           argument given.  Argument can either be a pure digit, which will be
           interpreted as seconds, or can have a specifier s, m, or h (5s = 5
           seconds, 3m = 180 seconds, 1h = 3600 seconds).  As a special case,
           0 means don't timeout the transactions.  Default value is 30s.
           (Arg-Required, From-Prompt)

       --protocol <protocol>
           Specify which protocol to use in the transaction.  Valid options
           are shown in the table below.  Currently the 'core' protocols are
           SMTP, ESMTP, and LMTP.  By using variations of these protocol types
           one can tersely specify default ports, whether authentication
           should be attempted, and the type of TLS connection that should be
           attempted.  The default protocol is ESMTP.  The following table
           demonstrates the available arguments to "--protocol" and the
           options each sets as a side effect.  (Arg-Required)

           SMTP
               HELO, "-p 25"

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

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

           SMTPS
               HELO, "-tlsc -p 465"

           ESMTP
               EHLO->HELO, "-p 25"

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

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

           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
           If the remote server supports it, attempt SMTP PIPELINING (RFC
           2920). (Arg-None)

       --prdr
           If the server supports it, attempt Per-Recipient Data Response
           (PRDR) (<https://tools.ietf.org/html/draft-hall-prdr-00.txt>).
           PRDR is not yet standardized, but MTAs have begun implementing the
           proposal. (Arg-None)

       --force-getpwuid
           Tell Swaks to use the getpwuid method of finding the default sender
           local-part instead of trying $LOGNAME first. (Arg-None)

TLS / ENCRYPTION
       These are options related to encrypting the transaction.  These have
       been tested and confirmed to work with all three transport methods.
       The Net::SSLeay module is used to perform encryption when it is
       requested.  If this module is not loadable Swaks will either ignore the
       TLS request or error out, depending on whether the request was
       optional.  STARTTLS is defined as an extension in the ESMTP protocol
       and will be unavailable if "--protocol" is set to a variation of SMTP.
       Because it is not defined in the protocol itself, "--tls-on-connect" is
       available for any protocol type if the target supports it.

       A local certificate is not required for a TLS connection to be
       negotiated.  However, some servers use client certificate checking to
       verify that the client is allowed to connect.  Swaks can be told to use
       a specific local certificate using the "--tls-cert" and "--tls-key"
       options.

       -tls
           Require connection to use STARTTLS.  Exit if TLS not available for
           any reason (not advertised, negotiations failed, etc). (Arg-None)

       -tlso, --tls-optional
           Attempt to use STARTTLS if available, continue with normal
           transaction if TLS was unable to be negotiated for any reason.
           Note that this is a semi-useless option as currently implemented
           because after a negotiation failure the state of the connection is
           unknown.  In some cases, like a version mismatch, the connection
           should be left as plaintext.  In others, like a verification
           failure, the server-side may think that it should continue speaking
           TLS while the client thinks it is plaintext.  There may be an
           attempt to add more granular state detection in the future, but for
           now just be aware that odd things may happen with this option if
           the TLS negotiation is attempted and fails. (Arg-None)

       -tlsos, --tls-optional-strict
           Attempt to use STARTTLS if available.  Proceed with transaction if
           TLS is negotiated successfully or STARTTLS not advertised.  If
           STARTTLS is advertised but TLS negotiations fail, treat as an error
           and abort transaction.  Due to the caveat noted above, this is a
           much saner option than "--tls-optional". (Arg-None)

       -tlsc, --tls-on-connect
           Initiate a TLS connection immediately on connection.  Following
           common convention, if this option is specified the default port
           changes from 25 to 465, though this can still be overridden with
           the --port option. (Arg-None)

       -tlsp, --tls-protocol <tls-version-specification>
           Specify which protocols to use (or not use) when negotiating TLS.
           At the time of this writing, the available protocols are sslv2,
           sslv3, tlsv1, tlsv1_1, tlsv1_2, and tlsv1_3.  The availability of
           these protocols is dependent on your underlying OpenSSL library, so
           not all of these may be available.  The list of available protocols
           is shown in the output of "--dump" (assuming TLS is available at
           all).

           The specification string is a comma-delimited list of protocols
           that can be used or not used.  For instance 'tlsv1,tlsv1_1' will
           only succeed if one of those two protocols is available on both the
           client and the server.  Conversely, 'no_sslv2,no_sslv3' will
           attempt to negotiate any protocol except sslv2 and sslv3.  The two
           forms of specification cannot be mixed. (Arg-Required)

       --tls-cipher <cipher-string>
           The argument to this option is passed to the underlying OpenSSL
           library to set the list of acceptable ciphers to the be used for
           the connection.  The format of this string is opaque to Swaks and
           is defined in
           <http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT>.
           A brief example would be "--tls-cipher '3DES:+RSA'". (Arg-Required)

       --tls-verify
           Tell Swaks to attempt to verify the server's certificate.  If this
           option is set and the server's certificate is not verifiable
           (either using the system-default CA information, or custom CA
           information (see "--tls-ca-path")) TLS negotiation will not
           succeed.  By default, Swaks does not attempt certificate
           verification. (Arg-None)

       --tls-ca-path <ca-location>
           Specify an alternate location for CA information for verifying
           server certificates.  The argument can point to a file or
           directory.  The default behavior is to use the underlying OpenSSL
           library's default information. (Arg-Required)

       --tls-cert <cert-file>
           Provide a path to a file containing the local certificate Swaks
           should use if TLS is negotiated.  The file path argument is
           required.  As currently implemented the certificate in the file
           must be in PEM format.  Contact the author if there's a compelling
           need for ASN1.  If this option is set, "--tls-key" is also
           required. (Arg-Required)

       --tls-key <key-file>
           Provide a path to a file containing the local private key Swaks
           should use if TLS is negotiated.  The file path argument is
           required.  As currently implemented the certificate in the file
           must be in PEM format.  Contact the author if there's a compelling
           need for ASN1.  If this option is set, "--tls-cert" is also
           required. (Arg-Required)

       --tls-get-peer-cert [<output-file>]
           Get a copy of the TLS peer's certificate.  If no argument is given,
           it will be displayed to "STDOUT".  If an argument is given it is
           assumed to be a filesystem path specifying where the certificate
           should be written.  The saved certificate can then be examined
           using standard tools such as the openssl command.  If a file is
           specified its contents will be overwritten. (Arg-Optional)

       --tls-sni <sni-string>
           Specify the Server Name Indication field to send when the TLS
           connection is initiated. (Arg-Required)

AUTHENTICATION
       Swaks will attempt to authenticate to the target mail server if
       instructed to do so.  This section details available authentication
       types, requirements, options and their interactions, and other fine
       points in authentication usage.  Because authentication is defined as
       an extension in the ESMTP protocol it will be unavailable if
       "--protocol" is set to a variation of SMTP.

       All authentication methods require base64 encoding.  If the
       MIME::Base64 Perl module is loadable Swaks attempts to use it to
       perform these encodings.  If MIME::Base64 is not available Swaks will
       use its own onboard base64 routines.  These are slower than the
       MIME::Base64 routines and less reviewed, though they have been tested
       thoroughly.  Using the MIME::Base64 module is encouraged.

       If authentication is required (see options below for when it is and
       isn't required) and the requirements aren't met for the authentication
       type available, Swaks displays an error and exits.  Two ways this can
       happen include forcing Swaks to use a specific authentication type that
       Swaks can't use due to missing requirements, or allowing Swaks to use
       any authentication type, but the server only advertises types Swaks
       can't support.  In the former case Swaks errors out at option
       processing time since it knows up front it won't be able to
       authenticate.  In the latter case Swaks will error out at the
       authentication stage of the SMTP transaction since Swaks will not be
       aware that it will not be able to authenticate until that point.

       Following are the supported authentication types including any
       individual notes and requirements.

       The following options affect Swaks' use of authentication.  These
       options are all inter-related.  For instance, specifying "--auth-user"
       implies "--auth" and "--auth-password".  Specifying "--auth-optional"
       implies "--auth-user" and "--auth-password", etc.

       -a, --auth [<auth-type>[,<auth-type>[,...]]]
           Require Swaks to authenticate.  If no argument is given, any
           supported auth-types advertised by the server are tried until one
           succeeds or all fail.  If one or more auth-types are specified as
           an argument, each that the server also supports is tried in order
           until one succeeds or all fail.  This option requires Swaks to
           authenticate, so if no common auth-types are found or no
           credentials succeed, Swaks displays an error and exits. (Arg-
           Optional)

           The following tables lists the valid auth-types

           LOGIN, PLAIN
               These basic authentication types are fully supported and tested
               and have no additional requirements

           CRAM-MD5
               The CRAM-MD5 authenticator requires the Digest::MD5 module.  It
               is fully tested and believed to work against any server that
               implements it.

           DIGEST-MD5
               The DIGEST-MD5 authenticator (RFC2831) requires the
               Authen::SASL module.  Version 20100211.0 and earlier used
               Authen::DigestMD5 which had some protocol level errors which
               prevented it from working with some servers.  Authen::SASL's
               DIGEST-MD5 handling is much more robust.

               The DIGEST-MD5 implementation in Swaks is fairly immature.  It
               currently supports only the "auth" qop type, for instance.  If
               you have DIGEST-MD5 experience and would like to help Swaks
               support DIGEST-MD5 better, please get in touch with me.

               The DIGEST-MD5 protocol's "realm" value can be set using the
               "--auth-extra" "realm" keyword.  If no realm is given, a
               reasonable default will be used.

               The DIGEST-MD5 protocol's "digest-uri" values can be set using
               the "--auth-extra" option.  For instance, you could create the
               digest-uri-value of "lmtp/mail.example.com/example.com" with
               the option "--auth-extra
               dmd5-serv-type=lmtp,dmd5-host=mail.example.com,dmd5-serv-name=example.com".
               The "digest-uri-value" string and its components is defined in
               RFC2831.  If none of these values are given, reasonable
               defaults will be used.

           CRAM-SHA1
               The CRAM-SHA1 authenticator requires the Digest::SHA module.
               This type has only been tested against a non-standard
               implementation on an Exim server and may therefore have some
               implementation deficiencies.

           NTLM/SPA/MSN
               These authenticators require the Authen::NTLM module.  Note
               that there are two modules using the Authen::NTLM namespace on
               CPAN.  The Mark Bush implementation (Authen/NTLM-1.03.tar.gz)
               is the version required by Swaks.  This type has been tested
               against Exim, Communigate, and Exchange 2007.

               In addition to the standard username and password, this
               authentication type can also recognize a "domain".  The domain
               can be set using the "--auth-extra" "domain" keyword.  Note
               that this has never been tested with a mail server that doesn't
               ignore DOMAIN so this may be implemented incorrectly.

       -ao, --auth-optional [<auth-type>[,<auth-type>[,...]]]
           This option behaves identically to "--auth" except that it requests
           authentication rather than requiring it.  If no common auth-types
           are found or no credentials succeed, Swaks proceeds as if
           authentication had not been requested. (Arg-Optional)

       -aos, --auth-optional-strict [<auth-type>[,<auth-type>[,...]]]
           This option is a compromise between "--auth" and "--auth-optional".
           If no common auth-types are found, Swaks behaves as if
           "--auth-optional" were specified and proceeds with the transaction.
           If Swaks can't support requested auth-type, the server doesn't
           advertise any common auth-types, or if no credentials succeed,
           Swaks behaves as if "--auth" were used and exits with an error.
           (Arg-Optional)

       -au, --auth-user [<username>]
           Provide the username to be used for authentication.  If no username
           is provided, indicate that Swaks should attempt to find the
           username via .netrc (requires the Net::Netrc module).  If no
           username is provided and cannot be found via .netrc,  the user will
           be prompted to provide one.  The string "<>" can be supplied to
           mean an empty username. (Arg-Required, From-Prompt)

       -ap, --auth-password [<password>]
           Provide the password to be used for authentication. If no password
           is provided, indicate that Swaks should attempt to find the
           password via .netrc (requires the Net::Netrc module).  If no
           password is provided and cannot be found via .netrc,  the user will
           be prompted to provide one.  The string "<>" can be supplied to
           mean an empty password. (Arg-Required, From-Prompt, Sensitive)

       -ae, --auth-extra <key-value-pair>[,<key-value-pair>[,...]]
           Some of the authentication types allow extra information to be
           included in the authentication process.  Rather than add a new
           option for every nook and cranny of each authenticator, the
           "--auth-extra" option allows this information to be supplied.  The
           format for <key-value-pair> is KEYWORD=VALUE. (Arg-Required)

           The following table lists the currently recognized keywords and the
           authenticators that use them

           realm, domain
               The realm and domain keywords are synonymous.  Using either
               will set the "domain" option in NTLM/MSN/SPA and the "realm"
               option in DIGEST-MD5

           dmd5-serv-type
               The dmd5-serv-type keyword is used by the DIGEST-MD5
               authenticator and is used, in part, to build the digest-uri-
               value string (see RFC2831)

           dmd5-host
               The dmd5-host keyword is used by the DIGEST-MD5 authenticator
               and is used, in part, to build the digest-uri-value string (see
               RFC2831)

           dmd5-serv-name
               The dmd5-serv-name keyword is used by the DIGEST-MD5
               authenticator and is used, in part, to build the digest-uri-
               value string (see RFC2831)

       -am, --auth-map <key-value-pair>[,<key-value-pair>[,...]]
           Provides a way to map alternate names onto base authentication
           types.  Useful for any sites that use alternate names for common
           types.  The format for <key-value-pair> is AUTH-ALIAS=AUTH-TYPE.
           This functionality is actually used internally to map types SPA and
           MSN onto the base type NTLM.  The command line argument to simulate
           this would be "--auth-map SPA=NTLM,MSN=NTLM".  All of the auth-
           types listed above are valid targets for mapping except SPA and
           MSN. (Arg-Required)

       -apt, --auth-plaintext
           Instead of showing AUTH strings base64 encoded as they are
           transmitted, translate them to plaintext before printing on screen.
           (Arg-None)

       -ahp, --auth-hide-password [<replacement-string>]
           If this option is specified, any time a readable password would be
           printed to the terminal (specifically AUTH PLAIN and AUTH LOGIN)
           the password is replaced with the string 'PROVIDED_BUT_REMOVED' (or
           the contents of <replacement-string> if provided).  The dummy
           string may or may not be base64 encoded, contingent on the
           "--auth-plaintext" option.

           Note that "--auth-hide-password" is similar, but not identical, to
           the "--protect-prompt" option.  The former protects passwords from
           being displayed in the SMTP transaction regardless of how they are
           entered.  The latter protects sensitive strings when the user types
           them at the terminal, regardless of how the string would be used.
           (Arg-Optional)

XCLIENT OPTIONS
       XCLIENT is an SMTP extension introduced by the Postfix project.
       XCLIENT allows a (properly-authorized) client to tell a server to use
       alternate information, such as IP address or hostname, for the client.
       This allows much easier paths for testing mail server configurations.
       Full details on the protocol are available at
       <http://www.postfix.org/XCLIENT_README.html>.

       The XCLIENT verb can be passed to the server multiple times per SMTP
       session with different attributes.  For instance, HELO and PROTO might
       be passed in one call and NAME and ADDR passed in a second. Because it
       can be useful for testing, Swaks exposes some control over how the
       attributes are grouped and in what order they are passed to the server.
       The different options attempt to expose simplicity for those using
       Swaks as a client, and complexity for those using Swaks to test
       installs.

       --xclient-addr [<string>]
       --xclient-name [<string>]
       --xclient-port [<string>]
       --xclient-proto [<string>]
       --xclient-destaddr [<string>]
       --xclient-destport [<string>]
       --xclient-helo [<string>]
       --xclient-login [<string>]
       --xclient-reverse-name [<string>]
           These options specify XCLIENT attributes that should be sent to the
           target server.  If <string> is not provided, Swaks will prompt and
           read the value on "STDIN".  See
           <http://www.postfix.org/XCLIENT_README.html> for official
           documentation for what the attributes mean and their possible
           values, including the special "[UNAVAILABLE]" and "[TEMPUNAVAIL]"
           values.

           By way of simple example, setting "--xclient-name foo.example.com
           --xclient-addr 192.168.1.1" will cause Swaks to send the SMTP
           command "XCLIENT NAME=foo.example.com ADDR=192.168.1.1".

           Note that the "REVERSE_NAME" attribute doesn't seem to appear in
           the official documentation.  There is a mailing list thread that
           documents it, viewable at
           <http://comments.gmane.org/gmane.mail.postfix.user/192623>.

           These options can all be mixed with each other, and can be mixed
           with the "--xclient" option (see below). By default all attributes
           will be combined into one XCLIENT call, but see "--xclient-delim".
           (Arg-Required, From-Prompt)

       --xclient-delim
           When this option is specified, it indicates a break in XCLIENT
           attributes to be sent.  For instance, setting "--xclient-helo 'helo
           string' --xclient-delim --xclient-name foo.example.com
           --xclient-addr 192.168.1.1" will cause Swaks to send two XCLIENT
           calls, "XCLIENT HELO=helo+20string" and "XCLIENT
           NAME=foo.example.com ADDR=192.168.1.1".  This option is ignored
           where it doesn't make sense (at the start or end of XCLIENT
           options, by itself, consecutively, etc). (Arg-None)

       --xclient [<string>]
           This is the "free form" XCLIENT option.  Whatever value is provided
           for <string> will be sent verbatim as the argument to the XCLIENT
           SMTP command.  For example, if "--xclient 'NAME= ADDR=192.168.1.1
           FOO=bar'" is used, Swaks will send the SMTP command "XCLIENT NAME=
           ADDR=192.168.1.1 FOO=bar".  If no argument is passed on command
           line, Swaks will prompt and read the value on STDIN.

           The primary advantage to this over the more specific options above
           is that there is no XCLIENT syntax validation here.  This allows
           you to send invalid XCLIENT to the target server for testing.
           Additionally, at least one MTA (Message Systems' Momentum, formerly
           ecelerity) implements XCLIENT without advertising supported
           attributes.  The "--xclient" option allows you to skip the
           "supported attributes" check when communicating with this type of
           MTA (though see also "--xclient-no-verify").

           The "--xclient" option can be mixed freely with the "--xclient-*"
           options above.  The argument to "--xclient" will be sent in its own
           command group.  For instance, if "--xclient-addr 192.168.0.1
           --xclient-port 26 --xclient 'FOO=bar NAME=wind'" is given to Swaks,
           "XCLIENT ADDR=192.168.0.1 PORT=26" and "XCLIENT FOO=bar NAME=wind"
           will both be sent to the target server. (Arg-Required, From-Prompt)

       --xclient-no-verify
           Do not enforce the requirement that an XCLIENT attribute must be
           advertised by the server in order for Swaks to send it in an
           XCLIENT command.  This is to support servers which don't advertise
           the attributes but still support them. (Arg-None)

       --xclient-before-starttls
           If Swaks is configured to attempt both XCLIENT and STARTTLS, it
           will do STARTTLS first.  If this option is specified it will
           attempt XCLIENT first. (Arg-None)

       --xclient-optional
       --xclient-optional-strict
           In normal operation, setting one of the "--xclient*" options will
           require a successful XCLIENT transaction to take place in order to
           proceed (that is, XCLIENT needs to be advertised, all the user-
           requested attributes need to have been advertised, and the server
           needs to have accepted Swaks' XCLIENT request).  These options
           change that behavior.  "--xclient-optional" tells Swaks to proceed
           unconditionally past the XCLIENT stage of the SMTP transaction,
           regardless of whether it was successful.
           "--xclient-optional-strict" is similar but more granular.  The
           strict version will continue to XCLIENT was not advertised, but
           will fail if XCLIENT was attempted but did not succeed. (Arg-None)

PROXY OPTIONS
       Swaks implements the Proxy protocol as defined in
       <http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt>.  Proxy
       allows an application load balancer, such as HAProxy, to be used in
       front of an MTA while still allowing the MTA access to the originating
       host information.  Proxy support in Swaks allows direct testing of an
       MTA configured to expect requests from a proxy, bypassing the proxy
       itself during testing.

       Swaks makes no effort to ensure that the Proxy options used are
       internally consistent.  For instance, "--proxy-family" (in version 1)
       is expected to be one of "TCP4" or "TCP6".  While it will likely not
       make sense to the target server, Swaks makes no attempt to ensure that
       "--proxy-source" and "--proxy-dest" are in the same protocol family as
       "--proxy-family" or each other.

       The "--proxy" option is mutually exclusive with all other "--proxy-*"
       options except "--proxy-version".

       When "--proxy" is not used, all of "--proxy-family", "--proxy-source",
       "--proxy-source-port", "--proxy-dest", and "--proxy-dest-port" are
       required.  Additionally, when "--proxy-version" is 2,
       "--proxy-protocol" and "--proxy-command" are optional.

       --proxy-version [ 1 | 2 ]
           Whether to use version 1 (human readable) or version 2 (binary) of
           the Proxy protocol.  Version 1 is the default.  Version 2 is only
           implemented through the "address block", and is roughly on par with
           the information provided in version 1.

       --proxy [<string>]
           If this option is used, its argument is passed unchanged after the
           "PROXY " portion (or the 12-byte protocol header for version 2) of
           the Proxy exchange.  This option allows sending incomplete or
           malformed Proxy strings to a target server for testing.  No attempt
           to translate or modify this string is made, so if used with
           "--proxy-version 2" the argument should be in the appropriate
           binary format.  This option is mutually exclusive with all other
           "--proxy-*" options which provide granular proxy information. (Arg-
           Required, From-Prompt)

       --proxy-family [<string>]
           For version 1, specifies both the address family and transport
           protocol.  The protocol defines TCP4 and TCP6.

           For version 2, specifies only the address family.  The protocol
           defines AF_UNSPEC, AF_INET, AF_INET6, and AF_UNIX. (Arg-Required,
           From-Prompt)

       --proxy-protocol [<string>]
           For version 2, specifies the transport protocol.  The protocol
           defines UNSPEC, STREAM, and DGRAM.  The default is STREAM.  This
           option is unused in version 1. (Arg-Required, From-Prompt)

       --proxy-command [<string>]
           For version 2, specifies the transport protocol.  The protocol
           defines LOCAL and PROXY.  The default is PROXY.  This option is
           unused in version 1. (Arg-Required, From-Prompt)

       --proxy-source [<string>]
           Specify the source address of the proxied connection. (Arg-
           Required, From-Prompt)

       --proxy-source-port [<string>]
           Specify the source port of the proxied connection. (Arg-Required,
           From-Prompt)

       --proxy-dest [<string>]
           Specify the destination address of the proxied connection. (Arg-
           Required, From-Prompt)

       --proxy-dest-port [<string>]
           Specify the destination port of the proxied connection. (Arg-
           Required, From-Prompt)

DATA OPTIONS
       These options pertain to the contents for the DATA portion of the SMTP
       transaction.  By default a very simple message is sent.  If the
       "--attach" or "--attach-body" options are used, Swaks attempts to
       upgrade to a MIME message.

       -d, --data [<data-portion>]
           Use argument as the entire contents of DATA.

           If no argument is provided, user will be prompted to supply value.

           If the argument "-" is provided the data will be read from "STDIN"
           with no prompt.

           If the argument starts with "@" it will be treated as a filename.
           If you would like to pass in an argument that starts with "@" and
           isn't a filename, prefix the argument with an additional "@".  For
           example, "@file.txt" will force processing of file.txt.  @@data
           will use the string '@data'.

           If the argument does not contain any literal (0x0a) or
           representative (0x5c, 0x6e or %NEWLINE%) newline characters, it
           will be treated as a filename.  If the file is open-able, the
           contents of the file will be used as the data portion.  If the file
           cannot be opened, Swaks will error and exit.  The entire behavior
           described in this paragraph is deprecated and will be removed in a
           future release.  Instead use a leading "@" to explicitly set that
           the argument is a filename.

           Any other argument will be used as the DATA contents.

           The value can be on one single line, with "\n" (ASCII 0x5c, 0x6e)
           representing where line breaks should be placed.  Leading dots will
           be quoted.  Closing dot is not required but is allowed.  The
           %TO_ADDRESS%\nFrom: %FROM_ADDRESS%\nSubject: test
           %DATE%\nMessage-Id: <%MESSAGEID%"\nX-Mailer: swaks v%SWAKS_VERSION%
           jetmore.org/john/code/swaks/\n%NEW_HEADERS%\n%BODY%\n>.

           Very basic token parsing is performed on the DATA portion.  The
           following table shows the recognized tokens and their replacement
           values. (Arg-Required, From-Prompt, From-File)

           %FROM_ADDRESS%
               Replaced with the envelope-sender.

           %TO_ADDRESS%
               Replaced with the envelope-recipient(s).

           %DATE%
               Replaced with the current time in a format suitable for
               standard module POSIX for timezone calculations.  If this
               module is unavailable the date string will be in GMT.

           %MESSAGEID%
               Replaced with a message ID string suitable for use in a
               Message-Id header.  The value for this token will remain
               consistent for the life of the process.

           %SWAKS_VERSION%
               Replaced with the version of the currently-running Swaks
               process.

           %NEW_HEADERS%
               Replaced with the contents of the "--add-header" option.  If
               "--add-header" is not specified this token is simply removed.

           %BODY%
               Replaced with the value specified by the "--body" option.  See
               "--body" for default.

           %NEWLINE%
               Replaced with carriage return, newline (0x0d, 0x0a).  This is
               identical to using "\n" (0x5c, 0x6e), but doesn't have the
               escaping concerns that the backslash can cause on the newline.

       -dab, --dump-as-body [<section>[,<section>[,...]]]
           If "--dump-as-body" is used and no other option is used to change
           the default body of the message, the body is replaced with output
           similar to the output of what is provided by "--dump".  "--dump"'s
           initial program capability stanza is not displayed, and the "data"
           section is not included.  Additionally, "--dump" always includes
           passwords.  By default "--dump-as-body" does not include passwords,
           though this can be changed with "--dump-as-body-shows-password".
           "--dump-as-body" takes the same arguments as "--dump" except the
           SUPPORT and DATA arguments are not supported. (Arg-Optional)

       -dabsp, --dump-as-body-shows-password
           Cause "--dump-as-body" to include plaintext passwords.  This option
           is not recommended.  This option implies "--dump-as-body". (Arg-
           None)

       --body [<body-specification>]
           Specify the body of the email.  The default is "This is a test
           mailing".  If no argument to "--body" is given, prompt to supply
           one interactively.  If "-" is supplied, the body will be read from
           standard input.  Arguments beginning with "@" will be treated as
           filenames containing the body data to use (see "--data" for more
           detail).

           If, after the above processing, the argument represents an open-
           able file, the content of that file is used as the body.  This is
           deprecated behavior and will be removed in a future release.
           Instead use a leading "@" to explicitly set that the argument is a
           filename.

           If the message is forced to MIME format (see "--attach") "--body
           'body text'" is the same as "--attach-type text/plain --attach-body
           'body text'".  See "--attach-body" for details on creating a
           multipart/alternative body. (Arg-Required, From-Prompt, From-File)

       --attach [<attachment-specification>]
           When one or more "--attach" option is supplied, the message is
           changed into a multipart/mixed MIME message.  The arguments to
           "--attach" are processed the same as "--body" with respect to
           "STDIN", file contents, etc.  "--attach" can be supplied multiple
           times to create multiple attachments.  By default, each attachment
           is attached as an application/octet-stream file.  See
           "--attach-type" for changing this behavior.

           If the contents of the attachment are provided via a file name, the
           MIME encoding will include that file name.  See "--attach-name" for
           more detail on file naming.

           It is legal for "-" ("STDIN") to be specified as an argument
           multiple times (once for "--body" and multiple times for
           "--attach").  In this case, the same content will be attached each
           time it is specified.  This is useful for attaching the same
           content with multiple MIME types. (Arg-Required, From-File)

       --attach-body [<body-specification>]
           This is a variation on "--attach" that is specifically for the body
           part of the email.  It behaves identically to "--attach" in that it
           takes the same arguments and forces the creation of a MIME message.
           However, it is different in that the argument will always be the
           first MIME part in the message, no matter where in option
           processing order it is encountered.  Additionally, "--attach-body"
           options stack to allow creation of multipart/alternative bodies.
           For example, "--attach-type text/plain --attach-body 'plain text
           body' --attach-type text/html --attach-body 'html body'" would
           create a multipart/alternative message body. (Arg-Required, From-
           File)

       --attach-type <mime-type>
           By default, content that gets MIME attached to a message with the
           "--attach" option is encoded as application/octet-stream (except
           for the body, which is text/plain by default).  "--attach-type"
           changes the mime type for every "--attach" option which follows it.
           It can be specified multiple times.  The current MIME type gets
           reset to application/octet-stream between processing body parts and
           other parts. (Arg-Required)

       --attach-name [<name>]
           This option sets the filename that will be included in the MIME
           part created for the next "--attach" option.  If no argument is set
           for this option, it causes no filename information to be included
           for the next MIME part, even if Swaks could generate it from the
           local file name. (Arg-Optional)

       -ah, --add-header <header>
           This option allows headers to be added to the DATA.  If
           "%NEW_HEADERS%" is present in the DATA it is replaced with the
           argument to this option.  If "%NEW_HEADERS%" is not present, the
           argument is inserted between the first two consecutive newlines in
           the DATA (that is, it is inserted at the end of the existing
           headers).

           The option can either be specified multiple times or a single time
           with multiple headers separated by a literal "\n" string.  So,
           "--add-header 'Foo: bar' --add-header 'Baz: foo'" and "--add-header
           'Foo: bar\nBaz: foo'" end up adding the same two headers. (Arg-
           Required)

       --header <header-and-data>, --h-<header> <data>
           These options allow a way to change headers that already exist in
           the DATA.  "--header 'Subject: foo'" and "--h-Subject foo" are
           equivalent.  If the header does not already exist in the data then
           this argument behaves identically to "--add-header".  However, if
           the header already exists it is replaced with the one specified.
           Negating the version of this option with the header name in the
           option (eg "--no-header-Subject") will remove all previously
           processed "--header" options, not just the ones used for 'Subject'.
           (Arg-Required)

       -g  This option is a direct alias to "--data -" (read DATA from
           "STDIN").  It is totally secondary to "--data".  Any occurrence of
           "--data" will cause "-g" to be ignored.  This option cannot be
           negated with the "no-" prefix.  This option is deprecated and will
           be removed in a future version of Swaks. (Arg-None, Deprecated)

       --no-data-fixup, -ndf
           This option forces Swaks to do no massaging of the DATA portion of
           the email.  This includes token replacement, From_ stripping,
           trailing-dot addition, "--body"/attachment inclusion, and any
           header additions.  This option is only useful when used with
           "--data", since the internal default DATA portion uses tokens.
           (Arg-None)

       --no-strip-from, -nsf
           Don't strip the From_ line from the DATA portion, if present. (Arg-
           None)

OUTPUT OPTIONS
       Swaks provides a transcript of its transactions to its caller
       ("STDOUT"/"STDERR") by default.  This transcript aims to be as faithful
       a representation as possible of the transaction though it does modify
       this output by adding informational prefixes to lines and by providing
       plaintext versions of TLS transactions

       The "informational prefixes" are referred to as transaction hints.
       These hints are initially composed of those marking lines that are
       output of Swaks itself, either informational or error messages, and
       those that indicate a line of data actually sent or received in a
       transaction.  This table indicates the hints and their meanings:

       "==="
           Indicates an informational line generated by Swaks.

       "***"
           Indicates an error generated within Swaks.

       " ->"
           Indicates an expected line sent by Swaks to target server.

       " ~>"
           Indicates a TLS-encrypted, expected line sent by Swaks to target
           server.

       "**>"
           Indicates an unexpected line sent by Swaks to the target server.

       "*~>"
           Indicates a TLS-encrypted, unexpected line sent by Swaks to target
           server.

       "  >"
           Indicates a raw chunk of text sent by Swaks to a target server (see
           "--show-raw-text").  There is no concept of "expected" or
           "unexpected" at this level.

       "<- "
           Indicates an expected line sent by target server to Swaks.

       "<~ "
           Indicates a TLS-encrypted, expected line sent by target server to
           Swaks.

       "<**"
           Indicates an unexpected line sent by target server to Swaks.

       "<~*"
           Indicates a TLS-encrypted, unexpected line sent by target server to
           Swaks.

       "<  "
           Indicates a raw chunk of text received by Swaks from a target
           server (see "--show-raw-text").  There is no concept of "expected"
           or "unexpected" at this level.

       The following options control what and how output is displayed to the
       caller.

       -n, --suppress-data
           Summarizes the DATA portion of the SMTP transaction instead of
           printing every line.  This option is very helpful, bordering on
           required, when using Swaks to send certain test emails.  Emails
           with attachments, for instance, will quickly overwhelm a terminal
           if the DATA is not suppressed. (Arg-None)

       -stl, --show-time-lapse [i]
           Display time lapse between send/receive pairs.  This option is most
           useful when Time::HiRes is available, in which case the time lapse
           will be displayed in thousandths of a second.  If Time::HiRes is
           unavailable or "i" is given as an argument the lapse will be
           displayed in integer seconds only. (Arg-Optional)

       -nih, --no-info-hints
           Don't display the transaction hint for informational transactions.
           This is most useful when needing to copy some portion of the
           informational lines, for instance the certificate output from
           "--tls-get-peer-cert". (Arg-None)

       -nsh, --no-send-hints
       -nrh, --no-receive-hints
       -nth, --no-hints
           "--no-send-hints" and "--no-receive-hints" suppress the transaction
           hints from send and receive lines, respectively.  This is often
           useful when copying some portion of the transaction for use
           elsewhere (for instance, "--no-send-hints --hide-receive
           --hide-informational" is a useful way to get only the client-side
           commands for a given transaction).  "--no-hints" is identical to
           specifying both "--no-send-hints" and "--no-receive-hints". (Arg-
           None)

       -raw, --show-raw-text
           This option will print a hex dump of raw data sent and received by
           Swaks.  Each hex dump is the contents of a single read or write on
           the network.  This should be identical to what is already being
           displayed (with the exception of the "\r" characters being
           removed).  This option is useful in seeing details when servers are
           sending lots of data in single packets, or breaking up individual
           lines into multiple packets.  If you really need to go in depth in
           that area you're probably better with a packet sniffer, but this
           option is a good first step to seeing odd connection issues. (Arg-
           None)

       --output, --output-file <file-path>
       --output-file-stdout <file-path>
       --output-file-stderr <file-path>
           These options allow the user to send output to files instead of
           "STDOUT"/"STDERR".  The first option sends both to the same file.
           The arguments of &STDOUT and &STDERR are treated specially,
           referring to the "normal" file handles, so "--output-file-stderr
           '&STDOUT'" would redirect "STDERR" to "STDOUT".  These options are
           honored for all output except "--help" and "--version". (Arg-
           Required)

       -pp, --protect-prompt
           Don't echo user input on prompts that are potentially sensitive
           (right now only authentication password).  Very specifically, any
           option which is marked 'Sensitive' and eventually prompts for an
           argument will do its best to mask that argument from being echoed.
           See also "--auth-hide-password". (Arg-None)

       -hr, --hide-receive
           Don't display lines sent from the remote server being received by
           Swaks. (Arg-None)

       -hs, --hide-send
           Don't display lines being sent by Swaks to the remote server. (Arg-
           None)

       -hi, --hide-informational
           Don't display non-error informational lines from Swaks itself.
           (Arg-None)

       -ha, --hide-all
           Do not display any content to the terminal. (Arg-None)

       -S, --silent [ 1 | 2 | 3 ]
           Cause Swaks to be silent.  If no argument is given or if an
           argument of "1" is given, print no output unless/until an error
           occurs, after which all output is shown.  If an argument of "2" is
           given, only print errors.  If "3" is given, show no output ever.
           "--silent" affects most output but not all.  For instance,
           "--help", "--version", "--dump", and "--dump-mail" are not
           affected. (Arg-Optional)

       --support
           Print capabilities and exit.  Certain features require non-standard
           Perl modules.  This option evaluates whether these modules are
           present and displays which functionality is available and which
           isn't, and which modules would need to be added to gain the missing
           functionality. (Arg-None)

       --dump-mail
           Cause Swaks to process all options to generate the message it would
           send, then print that message to "STDOUT" instead of sending it.
           This output is identical to the "data" section of "--dump", except
           without the trailing dot. (Arg-None)

       --dump [<section>[,<section>[,...]]]
           This option causes Swaks to print the results of option processing,
           immediately before mail would have been sent.  No mail will be sent
           when "--dump" is used.  Note that "--dump" is a pure self-diagnosis
           tool and no effort is made or will ever be made to mask passwords
           in the "--dump" output. If a section is provided as an argument to
           this option, only the requested section will be shown.  Currently
           supported arguments are SUPPORT, APP, OUTPUT, TRANSPORT, PROTOCOL,
           XCLIENT, PROXY, TLS, AUTH, DATA, and ALL.  If no argument is
           provided, all sections are displayed (Arg-Optional)

       --help
           Display this help information and exit. (Arg-None)

       --version
           Display version information and exit. (Arg-None)

DEPRECATIONS
       The following features are deprecated and will be removed in a future
       version of Swaks

       -g option
           Will be removed no sooner than November 1, 2021.

           The -g option is currently a less-good alias to "--data -".  Any
           uses of "-g" should be able to be directly migrated to "--data -"
           instead.

       auto-filename detection
           Will be removed no sooner than November 1, 2021.

           The "--data", "--body", "--attach", and "--attach-body" options
           currently will attempt to distinguish between an argument that is
           the actual value to use vs. an argument that represents a file
           containing the data to use.  This behavior has been superseded by
           prefixing an argument to these options with "@" to explicitly
           indicate that the argument indicates a file.  Any uses of providing
           a filename to one of these options should be moved to using "@" to
           indicate a filename is being used.

PORTABILITY
       OPERATING SYSTEMS
           This program was primarily intended for use on UNIX-like operating
           systems, and it should work on any reasonable version thereof.  It
           has been developed and tested on Solaris, Linux, and Mac OS X and
           is feature complete on all of these.

           This program is known to demonstrate basic functionality on Windows
           using ActiveState's Perl.  It has not been fully tested.  Known to
           work are basic SMTP functionality and the LOGIN, PLAIN, and
           CRAM-MD5 auth types.  Unknown is any TLS functionality and the
           NTLM/SPA and DIGEST-MD5 auth types.

           Because this program should work anywhere Perl works, I would
           appreciate knowing about any new operating systems you've
           thoroughly used Swaks on as well as any problems encountered on a
           new OS.

       MAIL SERVERS
           This program was almost exclusively developed against Exim mail
           servers.  It has been used casually by the author, though not
           thoroughly tested, with Sendmail, Smail, Exchange, Oracle
           Collaboration Suite, qpsmtpd, and Communigate.  Because all
           functionality in Swaks is based on known standards it should work
           with any fairly modern mail server.  If a problem is found, please
           alert the author at the address below.

ENVIRONMENT VARIABLES
       LOGNAME
           If Swaks must create a sender address, $LOGNAME is used as the
           message local-part if it is set, and unless "--force-getpwuid" is
           used.

       SWAKS_HOME
           Used when searching for a .swaksrc configuration file.  See OPTION
           PROCESSING -> "CONFIGURATION FILES" above.

       SWAKS_OPT_*
           Environment variable prefix used to specify Swaks options from
           environment variables.  See OPTION PROCESSING -> "CONFIGURATION
           ENVIRONMENT VARIABLES" above.

EXIT CODES
       0   no errors occurred

       1   error parsing command line options

       2   error connecting to remote server

       3   unknown connection type

       4   while running with connection type of "pipe", fatal problem writing
           to or reading from the child process

       5   while running with connection type of "pipe", child process died
           unexpectedly.  This can mean that the program specified with
           "--pipe" doesn't exist.

       6   Connection closed unexpectedly.  If the close is detected in
           response to the 'QUIT' Swaks sends following an unexpected
           response, the error code for that unexpected response is used
           instead.  For instance, if a mail server returns a 550 response to
           a MAIL FROM: and then immediately closes the connection, Swaks
           detects that the connection is closed, but uses the more specific
           exit code 23 to detail the nature of the failure.  If instead the
           server return a 250 code and then immediately closes the
           connection, Swaks will use the exit code 6 because there is not a
           more specific exit code.

       10  error in prerequisites (needed module not available)

       21  error reading initial banner from server

       22  error in HELO transaction

       23  error in MAIL transaction

       24  no RCPTs accepted

       25  server returned error to DATA request

       26  server did not accept mail following data

       27  server returned error after normal-session quit request

       28  error in AUTH transaction

       29  error in TLS transaction

       30  PRDR requested/required but not advertised

       32  error in EHLO following TLS negotiation

       33  error in XCLIENT transaction

       34  error in EHLO following XCLIENT

       35  error in PROXY option processing

       36  error sending PROXY banner

ABOUT THE NAME
       The name "Swaks" is a (sort-of) acronym for "SWiss Army Knife SMTP".
       It was chosen to be fairly distinct and pronounceable.  While "Swaks"
       is unique as the name of a software package, it has some other, non-
       software meanings.  Please send in other uses of "swak" or "swaks" for
       inclusion.

       "Sealed With A Kiss"
           SWAK/SWAKs turns up occasionally on the internet with the meaning
           "with love".

       bad / poor / ill (Afrikaans)
           Seen in the headline "SA se bes en swaks gekledes in 2011", which
           was translated as "best and worst dressed" by native speakers.
           Google Translate doesn't like "swaks gekledes", but it will
           translate "swak" as "poor" and "swak geklede" as "ill-dressed".

LICENSE
       This program is free software; you can redistribute it and/or modify it
       under the terms of the GNU General Public License as published by the
       Free Software Foundation; either version 2 of the License, or (at your
       option) any later version.

       This program is distributed in the hope that it will be useful, but
       WITHOUT ANY WARRANTY; without even the implied warranty of
       MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
       General Public License for more details.

       You should have received a copy of the GNU General Public License along
       with this program; if not, write to the Free Software Foundation, Inc.,
       51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.

CONTACT INFORMATION
       General contact, questions, patches, requests, etc to
       proj-swaks@jetmore.net.

       Change logs, this help, and the latest version are found at
       <http://www.jetmore.org/john/code/swaks/>.

       Swaks is crafted with love by John Jetmore from the cornfields of
       Indiana, United States of America.

NOTIFICATIONS
       Email
           updates-swaks@jetmore.net

           If you would like to be put on a list to receive notifications when
           a new version of Swaks is released, please send an email to this
           address.  There will not be a response to your email.

       Website
           <http://www.jetmore.org/john/blog/c/swaks/>

       RSS Feed
           <http://www.jetmore.org/john/blog/c/swaks/feed/>

       Twitter
           <http://twitter.com/SwaksSMTP>

perl v5.30.3                      2020-10-17                          SWAKS(1)

Updated on: 2021-Nov-26