1SWAKS(1) User Contributed Perl Documentation SWAKS(1)
2
6 Swaks - Swiss Army Knife SMTP, the all-purpose SMTP transaction tester
7
9 Swaks' primary design goal is to be a flexible, scriptable,
10 transaction-oriented SMTP test tool. It handles SMTP features and
11 extensions such as TLS, authentication, and pipelining; multiple
12 version of the SMTP protocol including SMTP, ESMTP, and LMTP; and
13 multiple transport methods including UNIX-domain sockets, internet-
14 domain sockets, and pipes to spawned processes. Options can be
15 specified in environment variables, configuration files, and the
16 command line allowing maximum configurability and ease of use for
17 operators and scripters.
18
20 Deliver a standard test email to user@example.com on port 25 of
21 test-server.example.net:
22 swaks --to user@example.com --server test-server.example.net
24 Deliver a standard test email, requiring CRAM-MD5 authentication as
26 user me@example.com. An "X-Test" header will be added to the email
27 body. The authentication password will be prompted for.
28 swaks --to user@example.com --from me@example.com --auth CRAM-MD5 --auth-user me@example.com --header-X-Test "test email"
30 Test a virus scanner using EICAR in an attachment. Don't show the
32 message DATA part.:
33 swaks -t user@example.com --attach - --server test-server.example.com --suppress-data </path/to/eicar.txt
35 Test a spam scanner using GTUBE in the body of an email, routed via the
37 MX records for example.com:
38 swaks --to user@example.com --body /path/to/gtube/file
40 Deliver a standard test email to user@example.com using the LMTP
42 protocol via a UNIX domain socket file
43 swaks --to user@example.com --socket /var/lda.sock --protocol LMTP
45 Report all the recipients in a text file that are non-verifiable on a
47 test server:
48 for E in `cat /path/to/email/file`
50 do
51 swaks --to $E --server test-server.example.com --quit-after RCPT --hide-all
52 [ $? -ne 0 ] && echo $E
53 done
54
56 This document tries to be consistent and specific in its use of the
57 following terms to reduce confusion.
58 Transaction
60 A transaction is the opening of a connection over a transport to a
61 target and using a messaging protocol to attempt to deliver a
62 message.
63 Target
65 The target of a transaction is the thing that Swaks connects to.
66 This generic term is used throughout the documentation because most
67 other terms improperly imply something about the transport being
68 used.
69 Transport
71 The transport is the underlying method used to connect to the
72 target.
73 Protocol
75 The protocol is the application language used to communicate with
76 the target. This document uses SMTP to speak generically of all
77 three supported protocols unless it states that it is speaking of
78 the specific 'SMTP' protocol and excluding the others.
79 Message
81 SMTP protocols exist to transfer messages, a set of bytes in an
82 agreed-upon format that has a sender and a recipient.
83 Envelope
85 A message's envelope contains the "true" sender and receiver of a
86 message. It can also be referred to as its components, envelope-
87 sender and envelope-recipients. It is important to note that a
88 messages envelope does not have to match its To: and From: headers.
89 DATA
91 The DATA portion of an SMTP transaction is the actual message that
92 is being transported. It consists of both the message's headers
93 and its body. DATA and body are sometimes use synonymously, but
94 they are always two distinct things in this document.
95 Headers
97 A message's headers are defined as all the lines in the message's
98 DATA section before the first blank line. They contain information
99 about the email that will be displayed to the recipient such as
100 To:, From:, Subject:, etc. In this document headers will always be
101 written with a capitalized first letter and a trailing colon.
102 Body
104 A message's body is the portion of its DATA section following the
105 first blank line.
106
108 To prevent potential confusion in this document a flag to Swaks is
109 always referred to as an "option". If the option takes additional
110 data, that additional data is referred to as an argument to the option.
111 For example, "--from fred@example.com" might be provided to Swaks on
112 the command line, with "--from" being the option and "fred@example.com"
113 being --from's argument.
114 Options can be given to Swaks in three ways. They can be specified in
116 a configuration file, in environment variables, and on the command
117 line. Depending on the specific option and whether an argument is
118 given to it, Swaks may prompt the user for the argument.
119 When Swaks evaluates its options, it first looks for a configuration
121 file (either in a default location or specified with --config). Then
122 it evaluates any options in environment variables. Finally, it
123 evaluates command line options. At each round of processing, any
124 options set earlier will be overridden. Additionally, any option can
125 be prefixed with "no-" to cause Swaks to forget that the variable had
126 previously been set. This capability is necessary because many options
127 treat defined-but-no-argument differently than not-defined.
128 The exact mechanism and format for using each of the types is listed
130 below.
131 CONFIGURATION FILE
133 A configuration file can be used to set commonly-used or abnormally
134 verbose options. By default, Swaks looks in order for
135 $SWAKS_HOME/.swaksrc, $HOME/.swaksrc, and $LOGDIR/.swaksrc. If one
136 of those is found to exist (and --config has not been used) that
137 file is used as the configuration file.
138 Additionally, a configuration file in a non-default location can be
140 specified using --config. If this is set and not given an argument
141 Swaks will not use any configuration file, including any default
142 file. If --config points to a readable file, it is used as the
143 configuration file, overriding any default that may exist. If it
144 points to a non-readable file and error will be shown and Swaks
145 will exit.
146 A set of "portable" defaults can also be created by adding options
148 to the end of the Swaks program file. As distributed, the last
149 line of Swaks should be "__END__". Any lines added after __END__
150 will be treated as the contents of a configuration file. This
151 allows a set of user preferences to be automatically copied from
152 server to server in a single file.
153 If present and configuration files have not been explicitly turned
155 off, the __END__ config is always read. Only one other
156 configuration file will ever be used per single invocation of
157 Swaks, even if multiple configuration files are specified.
158 Specifying the --config option with no argument turns off the
159 processing of both the __END__ config and any actual config files.
160 In a configuration file lines beginning with a hash (#) are
162 ignored. All other lines are assumed to be an option to Swaks,
163 with the leading dash or dashes optional. Everything after a
164 option line's first space is assumed to be the option's argument
165 and is not shell processed. Therefore, quoting is usually unneeded
166 and will be included literally in the argument. Here is an example
167 of the contents of a configuration file:
168 # always use this sender, no matter server or logged in user
170 --from fred@example.com
171 # I prefer my test emails have a pretty from header. Note
172 # the lack of dashes on option and lack of quotes around
173 # entire argument.
174 h-From: "Fred Example" <fred@example.com>
175 ENVIRONMENT VARIABLES
177 Options can be supplied via environment variables. The variables
178 are in the form $SWAKS_OPT_name, where name is the name of the
179 option that would be specified on the command line. Because dashes
180 aren't allowed in environment variable names in most UNIX-ish
181 shells, no leading dashes should be used and any dashes inside the
182 option's name should be replaced with underscores. The following
183 would create the same options shown in the configuration file
184 example:
185 $ SWAKS_OPT_from='fred@example.com'
187 $ SWAKS_OPT_h_From='"Fred Example" <fred@example.com>'
188 Setting a variable to an empty value is the same as specifying it
190 on the command line with no argument. For instance, setting
191 SWAKS_OPT_server="" would cause Swaks to prompt the use for the
192 server to which to connect at each invocation.
193 In addition to setting the equivalent of command line options,
195 SWAKS_HOME can be set to a directory containing the default
196 .swaksrc to be used.
197 COMMAND LINE OPTIONS
199 The final method of supplying options to Swaks is via the command
200 line. The options behave in a manner consistent with most UNIX-ish
201 command line programs. Many options have both a short and long
202 form (for instance -s and --server). By convention short options
203 are specified with a single dash and long options are specified
204 with a double-dash. This is only a convention and either prefix
205 will work with either type.
206 The following demonstrates the example shown in the configuration
208 file and environment variable sections:
209 $ swaks --from fred@example.com --h-From: '"Fred Example" <fred@example.com>'
211
213 Swaks can connect to a target via UNIX pipes ("pipes"), UNIX domain
214 sockets ("UNIX sockets"), or internet domain sockets ("network
215 sockets"). Connecting via network sockets is the default behavior.
216 Because of the singular nature of the transport used, each set of
217 options in the following section is mutually exclusive. Specifying
218 more than one of --server, --pipe, or --socket will result in an error.
219 Mixing other options between transport types will only result in the
220 irrelevant options being ignored. Below is a brief description of each
221 type of transport and the options that are specific to that transport
222 type.
223 NETWORK SOCKETS
225 This transport attempts to deliver a message via TCP/IP, the
226 standard method for delivering SMTP. This is the default transport
227 for Swaks. If none of --server, --pipe, or --socket are given then
228 this transport is used and the target server is determined from the
229 recipient's domain (see --server below for more details).
230 This transport requires the IO::Socket module which is part of the
232 standard Perl distribution. If this module is not loadable,
233 attempting to use this transport will result in an error and
234 program termination.
235 IPv6 is supported when the IO::Socket::INET6 module is present.
237 -s, --server [target mail server[:port]]
239 Explicitly tell Swaks to use network sockets and specify the
240 hostname or IP address to which to connect, or prompt if no
241 argument is given. If this option is not given and no other
242 transport option is given, the target mail server is determined
243 from the appropriate DNS records for the domain of the
244 recipient email address using the Net::DNS module. If Net::DNS
245 is not available Swaks will attempt to connect to localhost to
246 deliver. The target port can optionally be set here.
247 Supported formats for this include SERVER:PORT (supporting
248 names and IPv4 addresses); [SERVER]:PORT and SERVER/PORT
249 (supporting names, IPv4 and IPv6 addresses). See also
250 --copy-routing.
251 -p, --port [port]
253 Specify which TCP port on the target is to be used, or prompt
254 if no argument is listed. The argument can be a service name
255 (as retrieved by getservbyname(3)) or a port number. The
256 default port is determined by the --protocol option. See
257 --protocol for more details.
258 -li, --local-interface [IP or hostname[:port]]
260 Use argument as the local interface for the outgoing SMTP
261 connection, or prompt user if no argument given. Argument can
262 be an IP address or a hostname. Default action is to let the
263 operating system choose the local interface. See --server for
264 additional comments on :port format.
265 -lp, --local-port, --lport [port]
267 Specify the outgoing port to originate the transaction from.
268 If this option is not specified the system will pick an
269 ephemeral port. Note that regular users cannot specify some
270 ports.
271 --copy-routing [domain]
273 The argument is interpreted as the domain part of an email
274 address and it is used to find the target server using the same
275 logic that would be used to look up the target server for a
276 recipient email address. See --to option for more details on
277 how the target is determined from the email domain.
278 -4, -6
280 Force IPv4 or IPv6.
281 UNIX SOCKETS
283 This transport method attempts to deliver messages via a UNIX-
284 domain socket file. This is useful for testing MTA/MDAs that
285 listen on socket files (for instance, testing LMTP delivery to
286 Cyrus). This transport requires the IO::Socket module which is
287 part of the standard Perl distribution. If this module is not
288 loadable, attempting to use this transport will result in an error
289 and program termination.
290 --socket [/path/to/socket/file]
292 This option takes as its argument a UNIX-domain socket file.
293 If Swaks is unable to open this socket it will display an error
294 and exit.
295 PIPES
297 This transport attempts to spawn a process and communicate with it
298 via pipes. The spawned program must be prepared to behave as a
299 mail server over STDIN/STDOUT. Any MTA designed to operate from
300 inet/xinet should support this. In addition, some MTAs provide
301 testing modes that can be communicated with via STDIN/STDOUT. This
302 transport can be used to automate that testing. For example, if
303 you implemented DNSBL checking with Exim and you wanted to make
304 sure it was working, you could run 'swaks --pipe "exim -bh
305 127.0.0.2"'. Ideally, the process you are talking to should behave
306 exactly like an SMTP server on STDIN and STDOUT. Any debugging
307 should be sent to STDERR, which will be directed to your terminal.
308 In practice, Swaks can generally handle some debug on the child's
309 STDOUT, but there are no guarantees on how much it can handle.
310 This transport requires the IPC::Open2 module which is part of the
312 standard Perl distribution. If this module is not loadable,
313 attempting to use this transport will result in an error and
314 program termination.
315 --pipe [/path/to/command and arguments]
317 Provide a process name and arguments to the process. Swaks
318 will attempt to spawn the process and communicate with it via
319 pipes. If the argument is not an executable Swaks will display
320 an error and exit.
321
323 These options are related to the protocol layer.
324 -t, --to [email-address[,email-address,...]]
326 Tells Swaks to use argument(s) as the envelope-recipient for the
327 email, or prompt for recipient if no argument provided. If
328 multiple recipients are provided and the recipient domain is needed
329 to determine routing the domain of the last recipient provided is
330 used.
331 There is no default value for this option. If no recipients are
333 provided via any means, user will be prompted to provide one
334 interactively. The only exception to this is if a --quit-after
335 value is provided which will cause the SMTP transaction to be
336 terminated before the recipient is needed.
337 -f, --from [email-address]
339 Use argument as envelope-sender for email, or prompt user if no
340 argument specified. The string <> can be supplied to mean the null
341 sender. If user does not specify a sender address a default value
342 is used. The domain-part of the default sender is a best guess at
343 the fully-qualified domain name of the local host. The method of
344 determining the local-part varies. On Windows, Win32::LoginName()
345 is used. On UNIX-ish platforms, the $LOGNAME environment variable
346 is used if it is set. Otherwise getpwuid(3) is used. See also
347 --force-getpwuid.
348 --ehlo, --lhlo, -h, --helo [helo-string]
350 String to use as argument to HELO/EHLO/LHLO command, or prompt use
351 if no argument is specified. If this option is not used a best
352 guess at the fully-qualified domain name of the local host is used.
353 If the Sys::Hostname module, which is part of the base
354 distribution, is not available the user will be prompted for a HELO
355 value. Note that Sys::Hostname has been observed to not be able to
356 find the local hostname in certain circumstances. This has the
357 same effect as if Sys::Hostname were unavailable.
358 -q, --quit, --quit-after [stop-point]
360 Point at which the transaction should be stopped. When the
361 requested stopping point is reached in the transaction, and
362 provided that Swaks has not errored out prior to reaching it, Swaks
363 will send "QUIT" and attempt to close the connection cleanly.
364 These are the valid arguments and notes about their meaning.
365 CONNECT, BANNER
367 Terminate the session after receiving the greeting banner from
368 the target.
369 FIRST-HELO, FIRST-EHLO, FIRST-LHLO
371 In a STARTTLS (but not tls-on-connect) session, terminate the
372 transaction after the first of two HELOs. In a non-STARTTLS
373 transaction, behaves the same as HELO (see below).
374 XCLIENT
376 Quit after XCLIENT is sent
377 TLS Quit the transaction immediately following TLS negotiation.
379 Note that this happens in different places depending on whether
380 STARTTLS or tls-on-connect are used. This always quits after
381 the point where TLS would have been negotiated, regardless of
382 whether it was attempted.
383 HELO, EHLO, LHLO
385 In a STARTTLS or XCLIENT session, quit after the second HELO.
386 Otherwise quit after the first and only HELO.
387 AUTH
389 Quit after authentication. This always quits after the point
390 where authentication would have been negotiated, regardless of
391 whether it was attempted.
392 MAIL, FROM
394 Quit after MAIL FROM: is sent.
395 RCPT, TO
397 Quit after RCPT TO: is sent.
398 --da, --drop-after [stop-point]
400 The option is similar to --quit-after, but instead of trying to
401 cleanly shut down the session it simply terminates the session.
402 This option accepts the same stop-points as --quit-after.
403 --das, --drop-after-send [stop-point]
405 This option is similar to --drop-after, but instead of dropping the
406 connection after reading a response to the stop-point, it drops the
407 connection immediately after sending stop-point.
408 --timeout [time]
410 Use argument as the SMTP transaction timeout, or prompt user if no
411 argument given. Argument can either be a pure digit, which will be
412 interpreted as seconds, or can have a specifier s or m (5s = 5
413 seconds, 3m = 180 seconds). As a special case, 0 means don't
414 timeout the transactions. Default value is 30s.
415 --protocol [protocol]
417 Specify which protocol to use in the transaction. Valid options
418 are shown in the table below. Currently the 'core' protocols are
419 SMTP, ESMTP, and LMTP. By using variations of these protocol types
420 one can tersely specify default ports, whether authentication
421 should be attempted, and the type of TLS connection that should be
422 attempted. The default protocol is ESMTP. This table demonstrates
423 the available arguments to --protocol and the options each sets as
424 a side effect:
425 SMTP
427 HELO, "-p 25"
428 SSMTP
430 EHLO->HELO, "-tlsc -p 465"
431 SSMTPA
433 EHLO->HELO, "-a -tlsc -p 465"
434 SMTPS
436 HELO, "-tlsc -p 465"
437 ESMTP
439 EHLO->HELO, "-p 25"
440 ESMTPA
442 EHLO->HELO, "-a -p 25"
443 ESMTPS
445 EHLO->HELO, "-tls -p 25"
446 ESMTPSA
448 EHLO->HELO, "-a -tls -p 25"
449 LMTP
451 LHLO, "-p 24"
452 LMTPA
454 LHLO, "-a -p 24"
455 LMTPS
457 LHLO, "-tls -p 24"
458 LMTPSA
460 LHLO, "-a -tls -p 24"
461 --pipeline
463 If the remote server supports it, attempt SMTP PIPELINING (RFC
464 2920).
465 --prdr
467 If the server supports it, attempt Per-Recipient Data Response
468 (PRDR) (https://tools.ietf.org/html/draft-hall-prdr-00.txt). PRDR
469 is not yet standardized, but MTAs have begun implementing the
470 proposal.
471 --force-getpwuid
473 Tell Swaks to use the getpwuid method of finding the default sender
474 local-part instead of trying $LOGNAME first.
475
477 These are options related to encrypting the transaction. These have
478 been tested and confirmed to work with all three transport methods.
479 The Net::SSLeay module is used to perform encryption when it is
480 requested. If this module is not loadable Swaks will either ignore the
481 TLS request or error out, depending on whether the request was
482 optional. STARTTLS is defined as an extension in the ESMTP protocol
483 and will be unavailable if --protocol is set to a variation of SMTP.
484 Because it is not defined in the protocol itself, --tls-on-connect is
485 available for any protocol type if the target supports it.
486 A local certificate is not required for a TLS connection to be
488 negotiated. However, some servers use client certificate checking to
489 verify that the client is allowed to connect. Swaks can be told to use
490 a specific local certificate using the --tls-cert and --tls-key
491 options.
492 -tls
494 Require connection to use STARTTLS. Exit if TLS not available for
495 any reason (not advertised, negotiations failed, etc).
496 -tlso, --tls-optional
498 Attempt to use STARTTLS if available, continue with normal
499 transaction if TLS was unable to be negotiated for any reason.
500 Note that this is a semi-useless option as currently implemented
501 because after a negotiation failure the state of the connection is
502 unknown. In some cases, like a version mismatch, the connection
503 should be left as plaintext. In others, like a verification
504 failure, the server-side may think that it should continue speaking
505 TLS while the client thinks it is plaintext. There may be an
506 attempt to add more granular state detection in the future, but for
507 now just be aware that odd things may happen with this option if
508 the TLS negotiation is attempted and fails.
509 -tlsos, --tls-optional-strict
511 Attempt to use STARTTLS if available. Proceed with transaction if
512 TLS is negotiated successfully or STARTTLS not advertised. If
513 STARTTLS is advertised but TLS negotiations fail, treat as an error
514 and abort transaction. Due to the caveat noted above, this is a
515 much saner option than --tls-optional.
516 --tlsc, --tls-on-connect
518 Initiate a TLS connection immediately on connection. Following
519 common convention, if this option is specified the default port
520 changes from 25 to 465, though this can still be overridden with
521 the --port option.
522 -tlsp, --tls-protocol SPECIFICATION
524 Specify which protocols to use (or not use) when negotiating TLS.
525 At the time of this writing, the available protocols are sslv2,
526 sslv3, tlsv1, tlsv1_1, tlsv1_2, and tlsv1_3. The availability of
527 these protocols is dependent on your underlying OpenSSL library, so
528 not all of these may be available. The list of available protocols
529 is shown in the output of --dump (assuming TLS is available at
530 all).
531 The specification string is a comma-delimited list of protocols
533 that can be used or not used. For instance 'tlsv1,tlsv1_1' will
534 only succeed if one of those two protocols is available on both the
535 client and the server. Conversely, 'no_sslv2,no_sslv3' will
536 attempt to negotiate any protocol except sslv2 and sslv3. The two
537 forms of specification cannot be mixed.
538 -tls-cipher CIPHER_STRING
540 The argument to this option is passed to the underlying OpenSSL
541 library to set the list of acceptable ciphers to the be used for
542 the connection. The format of this string is opaque to Swaks and
543 is defined in
544 http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT.
545 A brief example would be --tls-cipher '3DES:+RSA'.
546 --tls-verify
548 Tell Swaks to attempt to verify the server's certificate. If this
549 option is set and the server's certificate is not verifiable
550 (either using the system-default CA information, or custom CA
551 information (see --tls-ca-path)) TLS negotiation will not succeed.
552 By default, Swaks does not attempt certificate verification.
553 --tls-ca-path [ /path/to/CAfile | /path/to/CAdir/ ]
555 Specify an alternate location for CA information for verifying
556 server certificates. The default behavior is to use the underlying
557 OpenSSL library's default information.
558 --tls-cert /path/to/file
560 Provide a path to a file containing the local certificate Swaks
561 should use if TLS is negotiated. The file path argument is
562 required. As currently implemented the certificate in the file
563 must be in PEM format. Contact the author if there's a compelling
564 need for ASN1. If this option is set, --tls-key is also required.
565 --tls-key /path/to/file
567 Provide a path to a file containing the local private key Swaks
568 should use if TLS is negotiated. The file path argument is
569 required. As currently implemented the certificate in the file
570 must be in PEM format. Contact the author if there's a compelling
571 need for ASN1. If this option is set, --tls-cert is also required.
572 --tls-get-peer-cert [/path/to/file]
574 Get a copy of the TLS peer's certificate. If no argument is given,
575 it will be displayed to STDOUT. If an argument is given it is
576 assumed to be a filesystem path specifying where the certificate
577 should be written. The saved certificate can then be examined
578 using standard tools such as the openssl command. If a file is
579 specified its contents will be overwritten.
580
582 Swaks will attempt to authenticate to the target mail server if
583 instructed to do so. This section details available authentication
584 types, requirements, options and their interactions, and other fine
585 points in authentication usage. Because authentication is defined as
586 an extension in the ESMTP protocol it will be unavailable if --protocol
587 is set to a variation of SMTP.
588 All authentication methods require base64 encoding. If the
590 MIME::Base64 Perl module is loadable Swaks attempts to use it to
591 perform these encodings. If MIME::Base64 is not available Swaks will
592 use its own onboard base64 routines. These are slower than the
593 MIME::Base64 routines and less reviewed, though they have been tested
594 thoroughly. Using the MIME::Base64 module is encouraged.
595 If authentication is required (see options below for when it is and
597 isn't required) and the requirements aren't met for the authentication
598 type available, Swaks displays an error and exits. Two ways this can
599 happen include forcing Swaks to use a specific authentication type that
600 Swaks can't use due to missing requirements, or allowing Swaks to use
601 any authentication type, but the server only advertises types Swaks
602 can't support. In the former case Swaks errors out at option
603 processing time since it knows up front it won't be able to
604 authenticate. In the latter case Swaks will error out at the
605 authentication stage of the SMTP transaction since Swaks will not be
606 aware that it will not be able to authenticate until that point.
607 Following are the supported authentication types including any
609 individual notes and requirements.
610 The following options affect Swaks' use of authentication. These
612 options are all inter-related. For instance, specifying --auth-user
613 implies --auth and --auth-password. Specifying --auth-optional implies
614 --auth-user and --auth-password, etc.
615 -a, --auth [auth-type[,auth-type,...]]
617 Require Swaks to authenticate. If no argument is given, any
618 supported auth-types advertised by the server are tried until one
619 succeeds or all fail. If one or more auth-types are specified as
620 an argument, each that the server also supports is tried in order
621 until one succeeds or all fail. This option requires Swaks to
622 authenticate, so if no common auth-types are found or no
623 credentials succeed, Swaks displays an error and exits.
624 The following tables lists the valid auth-types
626 LOGIN, PLAIN
628 These basic authentication types are fully supported and tested
629 and have no additional requirements
630 CRAM-MD5
632 The CRAM-MD5 authenticator requires the Digest::MD5 module. It
633 is fully tested and believed to work against any server that
634 implements it.
635 DIGEST-MD5
637 The DIGEST-MD5 authenticator (RFC2831) requires the
638 Authen::SASL module. Version 20100211.0 and earlier used
639 Authen::DigestMD5 which had some protocol level errors which
640 prevented it from working with some servers. Authen::SASL's
641 DIGEST-MD5 handling is much more robust.
642 The DIGEST-MD5 implementation in Swaks is fairly immature. It
644 currently supports only the "auth" qop type, for instance. If
645 you have DIGEST-MD5 experience and would like to help Swaks
646 support DIGEST-MD5 better, please get in touch with me.
647 The DIGEST-MD5 protocol's "realm" value can be set using the
649 --auth-extra "realm" keyword. If no realm is given, a
650 reasonable default will be used.
651 The DIGEST-MD5 protocol's "digest-uri" values can be set using
653 the --auth-extra option. For instance, you could create the
654 digest-uri-value of "lmtp/mail.example.com/example.com" with
655 the option "--auth-extra
656 dmd5-serv-type=lmtp,dmd5-host=mail.example.com,dmd5-serv-name=example.com".
657 The "digest-uri-value" string and its components is defined in
658 RFC2831. If none of these values are given, reasonable
659 defaults will be used.
660 CRAM-SHA1
662 The CRAM-SHA1 authenticator requires the Digest::SHA module.
663 This type has only been tested against a non-standard
664 implementation on an Exim server and may therefore have some
665 implementation deficiencies.
666 NTLM/SPA/MSN
668 These authenticators require the Authen::NTLM module. Note
669 that there are two modules using the Authen::NTLM namespace on
670 CPAN. The Mark Bush implementation (Authen/NTLM-1.03.tar.gz)
671 is the version required by Swaks. This type has been tested
672 against Exim, Communigate, and Exchange 2007.
673 In addition to the standard username and password, this
675 authentication type can also recognize a "domain". The domain
676 can be set using the --auth-extra "domain" keyword. Note that
677 this has never been tested with a mail server that doesn't
678 ignore DOMAIN so this may be implemented incorrectly.
679 -ao, --auth-optional [auth-type[,auth-type,...]]
681 This option behaves identically to --auth except that it requests
682 authentication rather than requiring it. If no common auth-types
683 are found or no credentials succeed, Swaks proceeds as if
684 authentication had not been requested.
685 -aos, --auth-optional-strict [auth-type[,auth-type,...]]
687 This option is a compromise between --auth and --auth-optional. If
688 no common auth-types are found, Swaks behaves as if --auth-optional
689 were specified and proceeds with the transaction. If Swaks can't
690 support requested auth-type, the server doesn't advertise any
691 common auth-types, or if no credentials succeed, Swaks behaves as
692 if --auth were used and exits with an error.
693 -au, --auth-user [username]
695 Provide the username to be used for authentication, or prompt the
696 user for it if no argument is provided. The string <> can be
697 supplied to mean an empty username.
698 -ap, --auth-password [password]
700 Provide the password to be used for authentication, or prompt the
701 user for it if no argument is provided. The string <> can be
702 supplied to mean an empty password.
703 -ae, --auth-extra [KEYWORD=value[,...]]
705 Some of the authentication types allow extra information to be
706 included in the authentication process. Rather than add a new
707 option for every nook and cranny of each authenticator, the
708 --auth-extra option allows this information to be supplied.
709 The following table lists the currently recognized keywords and the
711 authenticators that use them
712 realm, domain
714 The realm and domain keywords are synonymous. Using either
715 will set the "domain" option in NTLM/MSN/SPA and the "realm"
716 option in DIGEST-MD5
717 dmd5-serv-type
719 The dmd5-serv-type keyword is used by the DIGEST-MD5
720 authenticator and is used, in part, to build the digest-uri-
721 value string (see RFC2831)
722 dmd5-host
724 The dmd5-host keyword is used by the DIGEST-MD5 authenticator
725 and is used, in part, to build the digest-uri-value string (see
726 RFC2831)
727 dmd5-serv-name
729 The dmd5-serv-name keyword is used by the DIGEST-MD5
730 authenticator and is used, in part, to build the digest-uri-
731 value string (see RFC2831)
732 -am, --auth-map [auth-alias=auth-type[,...]]
734 Provides a way to map alternate names onto base authentication
735 types. Useful for any sites that use alternate names for common
736 types. This functionality is actually used internally to map types
737 SPA and MSN onto the base type NTLM. The command line argument to
738 simulate this would be "--auth-map SPA=NTLM,MSN=NTLM". All of the
739 auth-types listed above are valid targets for mapping except SPA
740 and MSN.
741 -apt, --auth-plaintext
743 Instead of showing AUTH strings base64 encoded as they are
744 transmitted, translate them to plaintext before printing on screen.
745 -ahp, --auth-hide-password [replacement string]
747 If this option is specified, any time a readable password would be
748 printed to the terminal (specifically AUTH PLAIN and AUTH LOGIN)
749 the password is replaced with the string 'PROVIDED_BUT_REMOVED' (or
750 the contents of "replacement string" if provided). The dummy
751 string may or may not be base64 encoded, contingent on the
752 --auth-plaintext option.
753 Note that --auth-hide-password is similar, but not identical, to
755 the --protect-prompt option. The former protects passwords from
756 being displayed in the SMTP transaction regardless of how they are
757 entered. The latter protects sensitive strings when the user types
758 them at the terminal, regardless of how the string would be used.
759
761 XCLIENT is an SMTP extension introduced by the Postfix project.
762 XCLIENT allows a (properly-authorized) client to tell a server to use
763 alternate information, such as IP address or hostname, for the client.
764 This allows much easier paths for testing mail server configurations.
765 Full details on the protocol are available at
766 http://www.postfix.org/XCLIENT_README.html.
767 The XCLIENT verb can be passed to the server multiple times per SMTP
769 session with different attributes. For instance, HELO and PROTO might
770 be passed in one call and NAME and ADDR passed in a second. Because it
771 can be useful for testing, Swaks exposes some control over how the
772 attributes are grouped and in what order they are passed to the server.
773 The different options attempt to expose simplicity for those using
774 Swaks as a client, and complexity for those using Swaks to test
775 installs.
776 --xclient-addr [VALUE]
778 --xclient-name [VALUE]
779 --xclient-port [VALUE]
780 --xclient-proto [VALUE]
781 --xclient-destaddr [VALUE]
782 --xclient-destport [VALUE]
783 --xclient-helo [VALUE]
784 --xclient-login [VALUE]
785 --xclient-reverse-name [VALUE]
786 These options specify XCLIENT attributes that should be sent to the
787 target server. If [VALUE] is not provided, Swaks will prompt and
788 read the value on STDIN. See
789 http://www.postfix.org/XCLIENT_README.html for official
790 documentation for what the attributes mean and their possible
791 values, including the special "[UNAVAILABLE]" and "[TEMPUNAVAIL]"
792 values.
793 By way of simple example, setting "--xclient-name foo.example.com
795 --xclient-addr 192.168.1.1" will cause Swaks to send the SMTP
796 command "XCLIENT NAME=foo.example.com ADDR=192.168.1.1".
797 Note that the "REVERSE_NAME" attribute doesn't seem to appear in
799 the official documentation. There is a mailing list thread that
800 documents it, viewable at
801 http://comments.gmane.org/gmane.mail.postfix.user/192623.
802 These options can all be mixed with each other, and can be mixed
804 with the --xclient option (see below). By default all attributes
805 will be combined into one XCLIENT call, but see --xclient-delim.
806 --xclient-delim
808 When this option is specified, it indicates a break in XCLIENT
809 attributes to be sent. For instance, setting "--xclient-helo 'helo
810 string' --xclient-delim --xclient-name foo.example.com
811 --xclient-addr 192.168.1.1" will cause Swaks to send two XCLIENT
812 calls, "XCLIENT HELO=helo+20string" and "XCLIENT
813 NAME=foo.example.com ADDR=192.168.1.1". This option is ignored
814 where it doesn't make sense (at the start or end of XCLIENT
815 options, by itself, consecutively, etc).
816 --xclient [XCLIENT_STRING]
818 This is the "free form" XCLIENT option. Whatever value is provided
819 for XCLIENT_STRING will be sent verbatim as the argument to the
820 XCLIENT SMTP command. For example, if "--xclient 'NAME=
821 ADDR=192.168.1.1 FOO=bar'" is used, Swaks will send the SMTP
822 command "XCLIENT NAME= ADDR=192.168.1.1 FOO=bar". If no
823 XCLIENT_STRING is passed on command line, Swaks will prompt and
824 read the value on STDIN.
825 The primary advantage to this over the more specific options above
827 is that there is no XCLIENT syntax validation here. This allows
828 you to send invalid XCLIENT to the target server for testing.
829 Additionally, at least one MTA (Message Systems' Momentum, formerly
830 ecelerity) implements XCLIENT without advertising supported
831 attributes. The --xclient option allows you to skip the "supported
832 attributes" check when communicating with this type of MTA (though
833 see also --xclient-no-verify).
834 The --xclient option can be mixed freely with the --xclient-*
836 options above. If "--xclient-addr 192.168.0.1 --xclient 'FOO=bar
837 NAME=wind'" is given to Swaks, "XCLIENT ADDR=192.168.0.1 FOO=bar
838 NAME=wind" will be sent to the target server.
839 --xclient-no-verify
841 Do not enforce the requirement that an XCLIENT attribute must be
842 advertised by the server in order for Swaks to send it in an
843 XCLIENT command. This is to support servers which don't advertise
844 the attributes but still support them.
845 --xclient-before-starttls
847 If Swaks is configured to attempt both XCLIENT and STARTTLS, it
848 will do STARTTLS first. If this option is specified it will
849 attempt XCLIENT first.
850 --xclient-optional
852 --xclient-optional-strict
853 In normal operation, setting one of the --xclient* options will
854 require a successful XCLIENT transaction to take place in order to
855 proceed (that is, XCLIENT needs to be advertised, all the user-
856 requested attributes need to have been advertised, and the server
857 needs to have accepted Swaks' XCLIENT request). These options
858 change that behavior. --xclient-optional tells Swaks to proceed
859 unconditionally past the XCLIENT stage of the SMTP transaction,
860 regardless of whether it was successful. --xclient-optional-strict
861 is similar but more granular. The strict version will continue to
862 XCLIENT was not advertised, but will fail if XCLIENT was attempted
863 but did not succeed.
864
866 Swaks implements the Proxy protocol as defined in
867 http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt. Proxy
868 allows an application load balancer, such as HAProxy, to be used in
869 front of an MTA while still allowing the MTA access to the originating
870 host information. Proxy support in Swaks allows direct testing of an
871 MTA configured to expect requests from a proxy, bypassing the proxy
872 itself during testing.
873 Swaks makes no effort to ensure that the Proxy options used are
875 internally consistent. For instance, --proxy-family (in version 1) is
876 expected to be one of "TCP4" or "TCP6". While it will likely not make
877 sense to the target server, Swaks makes no attempt to ensure that
878 --proxy-source and --proxy-dest are in the same protocol family as
879 --proxy-family or each other.
880 The --proxy option is mutually exclusive with all other --proxy-*
882 options except --proxy-version.
883 When --proxy is not used, all of --proxy-family, --proxy-source,
885 --proxy-source-port, --proxy-dest, and --proxy-dest-port are required.
886 Additionally, when --proxy-version is 2, --proxy-protocol and
887 --proxy-command are optional.
888 --proxy-version [ 1 | 2 ]
890 Whether to use version 1 (human readable) or version 2 (binary) of
891 the Proxy protocol. Version 1 is the default. Version 2 is only
892 implemented through the "address block", and is roughly on par with
893 the information provided in version 1.
894 --proxy [VALUE]
896 If this option is used, its argument is passed unchanged after the
897 "PROXY " portion (or the 12-byte protocol header for version 2) of
898 the Proxy exchange. This option allows sending incomplete or
899 malformed Proxy strings to a target server for testing. No attempt
900 to translate or modify this string is made, so if used with
901 "--proxy-version 2" the argument should be in the appropriate
902 binary format. This option is mutually exclusive with all other
903 --proxy-* options which provide granular proxy information.
904 --proxy-family [VALUE]
906 For version 1, specifies both the address family and transport
907 protocol. The protocol defines TCP4 and TCP6.
908 For version 2, specifies only the address family. The protocol
910 defines AF_UNSPEC, AF_INET, AF_INET6, and AF_UNIX.
911 --proxy-protocol [VALUE]
913 For version 2, specifies the transport protocol. The protocol
914 defines UNSPEC, STREAM, and DGRAM. The default is STREAM. This
915 option is unused in version 1
916 --proxy-command [VALUE]
918 For version 2, specifies the transport protocol. The protocol
919 defines LOCAL and PROXY. The default is PROXY. This option is
920 unused in version 1
921 --proxy-source [VALUE]
923 Specify the source address of the proxied connection.
924 --proxy-source-port [VALUE]
926 Specify the source port of the proxied connection.
927 --proxy-dest [VALUE]
929 Specify the destination address of the proxied connection.
930 --proxy-dest-port [VALUE]
932 Specify the destination port of the proxied connection.
933
935 These options pertain to the contents for the DATA portion of the SMTP
936 transaction.
937 -d, --data [data-portion]
939 Use argument as the entire contents of DATA, or prompt user if no
940 argument specified. If the argument '-' is provided the data will
941 be read from STDIN. If any other argument is provided and it
942 represents the name of an open-able file, the contents of the file
943 will be used. Any other argument will be itself for the DATA
944 contents.
945 The value can be on one single line, with \n (ASCII 0x5c, 0x6e)
947 representing where line breaks should be placed. Leading dots will
948 be quoted. Closing dot is not required but is allowed. The
949 default value for this option is "Date: %DATE%\nTo:
950 %TO_ADDRESS%\nFrom: %FROM_ADDRESS%\nSubject: test
951 %DATE%\nMessage-Id: <%MESSAGEID%>\nX-Mailer: swaks v%SWAKS_VERSION
952 jetmore.org/john/code/swaks/\n%NEW_HEADERS%\n%BODY%\n".
953 Very basic token parsing is performed on the DATA portion. The
955 following table shows the recognized tokens and their replacement
956 values:
957 %FROM_ADDRESS%
959 Replaced with the envelope-sender.
960 %TO_ADDRESS%
962 Replaced with the envelope-recipient(s).
963 %DATE%
965 Replaced with the current time in a format suitable for
966 inclusion in the Date: header. Note this attempts to use the
967 standard module Time::Local for timezone calculations. If this
968 module is unavailable the date string will be in GMT.
969 %MESSAGEID%
971 Replaced with a message ID string suitable for use in a
972 Message-Id header. The value for this token will remain
973 consistent for the life of the process.
974 %SWAKS_VERSION%
976 Replaced with the version of the currently-running Swaks
977 process.
978 %NEW_HEADERS%
980 Replaced with the contents of the --add-header option. If
981 --add-header is not specified this token is simply removed.
982 %BODY%
984 Replaced with the value specified by the --body option. See
985 --body for default.
986 -dab, --dump-as-body [section[,section]]
988 If --dump-as-body is used and no other option is used to change the
989 default body of the message, the body is replaced with output
990 similar to the output of what is provided by --dump. --dump's
991 initial program capability stanza is not displayed, and the "data"
992 section is not included. Additionally, --dump always includes
993 passwords. By default --dump-as-body does not include passwords,
994 though this can be changed with --dump-as-body-shows-password.
995 --dump-as-body takes the same arguments as --dump except the
996 SUPPORT and DATA arguments are not supported.
997 -dabsp, --dump-as-body-shows-password
999 Cause --dump-as-body to include plaintext passwords. This option
1000 is not recommended. This option implies --dump-as-body.
1001 --body [body-specification]
1003 Specify the body of the email. The default is "This is a test
1004 mailing". If no argument to --body is given, prompt to supply one
1005 interactively. If '-' is supplied, the body will be read from
1006 standard input. If any other text is provided and the text
1007 represents an open-able file, the content of that file is used as
1008 the body. If it does not represent an open-able file, the text
1009 itself is used as the body.
1010 If the message is forced to MIME format (see --attach) the argument
1012 to this option will be included unencoded as the first MIME part.
1013 Its content-type will always be text/plain.
1014 --attach [attachment-specification]
1016 When one or more --attach option is supplied, the message is
1017 changed into a multipart/mixed MIME message. The arguments to
1018 --attach are processed the same as --body with respect to STDIN,
1019 file contents, etc. --attach can be supplied multiple times to
1020 create multiple attachments. By default, each attachment is
1021 attached as an application/octet-stream file. See --attach-type
1022 for changing this behavior.
1023 If a filename is specified, the MIME encoding will include that
1025 file name. See --attach-name for more detail on file naming.
1026 It is legal for '-' (STDIN) to be specified as an argument multiple
1028 times (once for --body and multiple times for --attach). In this
1029 case, the same content will be attached each time it is specified.
1030 This is useful for attaching the same content with multiple MIME
1031 types.
1032 --attach-type [mime-type]
1034 By default, content that gets MIME attached to a message with the
1035 --attach option is encoded as application/octet-stream.
1036 --attach-type changes the mime type for every --attach option which
1037 follows it. It can be specified multiple times.
1038 --attach-name [name]
1040 This option sets the filename that will be included in the MIME
1041 part created for the next --attach option. If no argument is set
1042 for this option, it causes no filename information to be included
1043 for the next MIME part, even if Swaks could generate it from the
1044 local file name.
1045 -ah, --add-header [header]
1047 This option allows headers to be added to the DATA. If %H is
1048 present in the DATA it is replaced with the argument to this
1049 option. If %H is not present, the argument is inserted between the
1050 first two consecutive newlines in the DATA (that is, it is inserted
1051 at the end of the existing headers).
1052 The option can either be specified multiple times or a single time
1054 with multiple headers separated by a literal '\n' string. So,
1055 "--add-header 'Foo: bar' --add-header 'Baz: foo'" and "--add-header
1056 'Foo: bar\nBaz: foo'" end up adding the same two headers.
1057 --header [header-and-data], --h-Header [data]
1059 These options allow a way to change headers that already exist in
1060 the DATA. '--header "Subject: foo"' and '--h-Subject foo' are
1061 equivalent. If the header does not already exist in the data then
1062 this argument behaves identically to --add-header. However, if the
1063 header already exists it is replaced with the one specified.
1064 -g If specified, Swaks will read the DATA value for the mail from
1066 STDIN. This is equivalent to "--data -". If there is a From_ line
1067 in the email, it will be removed (but see -nsf option). Useful for
1068 delivering real message (stored in files) instead of using example
1069 messages.
1070 --no-data-fixup, -ndf
1072 This option forces Swaks to do no massaging of the DATA portion of
1073 the email. This includes token replacement, From_ stripping,
1074 trailing-dot addition, --body/attachment inclusion, and any header
1075 additions. This option is only useful when used with --data, since
1076 the internal default DATA portion uses tokens.
1077 --no-strip-from, -nsf
1079 Don't strip the From_ line from the DATA portion, if present.
1080
1082 Swaks provides a transcript of its transactions to its caller
1083 (STDOUT/STDERR) by default. This transcript aims to be as faithful a
1084 representation as possible of the transaction though it does modify
1085 this output by adding informational prefixes to lines and by providing
1086 plaintext versions of TLS transactions
1087 The "informational prefixes" are referred to as transaction hints.
1089 These hints are initially composed of those marking lines that are
1090 output of Swaks itself, either informational or error messages, and
1091 those that indicate a line of data actually sent or received in a
1092 transaction. This table indicates the hints and their meanings:
1093 "==="
1095 Indicates an informational line generated by Swaks
1096 "***"
1098 Indicates an error generated within Swaks
1099 " ->"
1101 Indicates an expected line sent by Swaks to target server
1102 " ~>"
1104 Indicates a TLS-encrypted, expected line sent by Swaks to target
1105 server
1106 "**>"
1108 Indicates an unexpected line sent by Swaks to the target server
1109 "*~>"
1111 Indicates a TLS-encrypted, unexpected line sent by Swaks to target
1112 server
1113 " >"
1115 Indicates a raw chunk of text sent by Swaks to a target server (see
1116 --show-raw-text). There is no concept of "expected" or
1117 "unexpected" at this level.
1118 "<- "
1120 Indicates an expected line sent by target server to Swaks
1121 "<~ "
1123 Indicates a TLS-encrypted, expected line sent by target server to
1124 Swaks
1125 "<**"
1127 Indicates an unexpected line sent by target server to Swaks
1128 "<~*"
1130 Indicates a TLS-encrypted, unexpected line sent by target server to
1131 Swaks
1132 "< "
1134 Indicates a raw chunk of text received by Swaks from a target
1135 server (see --show-raw-text). There is no concept of "expected" or
1136 "unexpected" at this level.
1137 The following options control what and how output is displayed to the
1139 caller.
1140 -n, --suppress-data
1142 Summarizes the DATA portion of the SMTP transaction instead of
1143 printing every line. This option is very helpful, bordering on
1144 required, when using Swaks to send certain test emails. Emails
1145 with attachments, for instance, will quickly overwhelm a terminal
1146 if the DATA is not suppressed.
1147 -stl, --show-time-lapse [i]
1149 Display time lapse between send/receive pairs. This option is most
1150 useful when Time::HiRes is available, in which case the time lapse
1151 will be displayed in thousandths of a second. If Time::HiRes is
1152 unavailable or "i" is given as an argument the lapse will be
1153 displayed in integer seconds only.
1154 -nih, --no-info-hints
1156 Don't display the transaction hint for informational transactions.
1157 This is most useful when needing to copy some portion of the
1158 informational lines, for instance the certificate output from
1159 --tls-get-peer-cert.
1160 -nsh, --no-send-hints
1162 -nrh, --no-receive-hints
1163 -nth, --no-hints
1164 --no-send-hints and --no-receive-hints suppress the transaction
1165 prefix from send and receive lines, respectively. This is often
1166 useful when copying some portion of the transaction for use
1167 elsewhere (for instance, "--no-send-hints --hide-receive
1168 --hide-informational" is a useful way to get only the client-side
1169 commands for a given transaction). --no-hints is identical to
1170 specifying both --no-send-hints and --no-receive-hints.
1171 Don't show transaction hints (useful in conjunction with -hr to
1173 create copy/paste-able transactions).
1174 -raw, --show-raw-text
1176 This option will print a hex dump of raw data sent and received by
1177 Swaks. Each hex dump is the contents of a single read or write on
1178 the network. This should be identical to what is already being
1179 displayed (with the exception of the \r characters being removed).
1180 This option is useful in seeing details when servers are sending
1181 lots of data in single packets, or breaking up individual lines
1182 into multiple packets. If you really need to go in depth in that
1183 area you're probably better with a packet sniffer, but this option
1184 is a good first step to seeing odd connection issues.
1185 --output, --output-file </path/to/file>
1187 --output-file-stdout </path/to/file>
1188 --output-file-stderr </path/to/file>
1189 These options allow the user to send output to files instead of
1190 STDOUT/STDERR. The first option sends both to the same file. The
1191 arguments of &STDOUT and &STDERR are treated specially, referring
1192 to the "normal" file handles, so "--output-file-stderr '&STDOUT'"
1193 would redirect STDERR to STDOUT. These options are honored for all
1194 output except --help and --version.
1195 -pp, --protect-prompt
1197 Don't echo user input on prompts that are potentially sensitive
1198 (right now only authentication password). See also
1199 --auth-hide-password
1200 -hr, --hide-receive
1202 Don't display lines sent from the remote server being received by
1203 Swaks
1204 -hs, --hide-send
1206 Don't display lines being sent by Swaks to the remote server
1207 -hi, --hide-informational
1209 Don't display non-error informational lines from Swaks itself.
1210 -ha, --hide-all
1212 Do not display any content to the terminal.
1213 -S, --silent [level]
1215 Cause Swaks to be silent. If no argument is given or if an
1216 argument of "1" is given, print no output unless/until an error
1217 occurs, after which all output is shown. If an argument of "2" is
1218 given, only print errors. If "3" is given, show no output ever.
1219 --silent affects most output but not all. For instance, --help,
1220 --version, --dump, and --dump-mail are not affected.
1221 --support
1223 Print capabilities and exit. Certain features require non-standard
1224 Perl modules. This option evaluates whether these modules are
1225 present and displays which functionality is available and which
1226 isn't, and which modules would need to be added to gain the missing
1227 functionality.
1228 --dump-mail
1230 Cause Swaks to process all options to generate the message it would
1231 send, then print that message to STDOUT instead of sending it.
1232 This output is identical to the "data" section of --dump, except
1233 without the trailing dot.
1234 --dump [section[,section]]
1236 This option causes Swaks to print the results of option processing,
1237 immediately before mail would have been sent. No mail will be sent
1238 when --dump is used. Note that --dump is a pure self-diagnosis
1239 tool and no effort is made or will ever be made to mask passwords
1240 in the --dump output. If a section is provided as an argument to
1241 this option, only the requested section will be shown. Currently
1242 supported arguments are SUPPORT, APP, OUTPUT, TRANSPORT, PROTOCOL,
1243 XCLIENT, PROXY, TLS, AUTH, DATA, and ALL. If no argument is
1244 provided, all sections are displayed
1245 --help
1247 Display this help information.
1248 --version
1250 Display version information.
1251
1253 OPERATING SYSTEMS
1254 This program was primarily intended for use on UNIX-like operating
1255 systems, and it should work on any reasonable version thereof. It
1256 has been developed and tested on Solaris, Linux, and Mac OS X and
1257 is feature complete on all of these.
1258 This program is known to demonstrate basic functionality on Windows
1260 using ActiveState's Perl. It has not been fully tested. Known to
1261 work are basic SMTP functionality and the LOGIN, PLAIN, and
1262 CRAM-MD5 auth types. Unknown is any TLS functionality and the
1263 NTLM/SPA and DIGEST-MD5 auth types.
1264 Because this program should work anywhere Perl works, I would
1266 appreciate knowing about any new operating systems you've
1267 thoroughly used Swaks on as well as any problems encountered on a
1268 new OS.
1269 MAIL SERVERS
1271 This program was almost exclusively developed against Exim mail
1272 servers. It has been used casually by the author, though not
1273 thoroughly tested, with Sendmail, Smail, Exchange, Oracle
1274 Collaboration Suite, qpsmtpd, and Communigate. Because all
1275 functionality in Swaks is based on known standards it should work
1276 with any fairly modern mail server. If a problem is found, please
1277 alert the author at the address below.
1278
1280 0 no errors occurred
1281 1 error parsing command line options
1283 2 error connecting to remote server
1285 3 unknown connection type
1287 4 while running with connection type of "pipe", fatal problem writing
1289 to or reading from the child process
1290 5 while running with connection type of "pipe", child process died
1292 unexpectedly. This can mean that the program specified with --pipe
1293 doesn't exist.
1294 6 Connection closed unexpectedly. If the close is detected in
1296 response to the 'QUIT' Swaks sends following an unexpected
1297 response, the error code for that unexpected response is used
1298 instead. For instance, if a mail server returns a 550 response to
1299 a MAIL FROM: and then immediately closes the connection, Swaks
1300 detects that the connection is closed, but uses the more specific
1301 exit code 23 to detail the nature of the failure. If instead the
1302 server return a 250 code and then immediately closes the
1303 connection, Swaks will use the exit code 6 because there is not a
1304 more specific exit code.
1305 10 error in prerequisites (needed module not available)
1307 21 error reading initial banner from server
1309 22 error in HELO transaction
1311 23 error in MAIL transaction
1313 24 no RCPTs accepted
1315 25 server returned error to DATA request
1317 26 server did not accept mail following data
1319 27 server returned error after normal-session quit request
1321 28 error in AUTH transaction
1323 29 error in TLS transaction
1325 30 PRDR requested/required but not advertised
1327 32 error in EHLO following TLS negotiation
1329 33 error in XCLIENT transaction
1331 34 error in EHLO following XCLIENT
1333 35 error in PROXY option processing
1335 36 error sending PROXY banner
1337
1339 The name "Swaks" is a (sort-of) acronym for "SWiss Army Knife SMTP".
1340 It was chosen to be fairly distinct and pronounceable. While "Swaks"
1341 is unique as the name of a software package, it has some other, non-
1342 software meanings. Please send in other uses of "swak" or "swaks" for
1343 inclusion.
1344 "Sealed With A Kiss"
1346 SWAK/SWAKs turns up occasionally on the internet with the meaning
1347 "with love".
1348 bad / poor / ill (Afrikaans)
1350 Seen in the headline "SA se bes en swaks gekledes in 2011", which
1351 was translated as "best and worst dressed" by native speakers.
1352 Google Translate doesn't like "swaks gekledes", but it will
1353 translate "swak" as "poor" and "swak geklede" as "ill-dressed".
1354
1356 This program is free software; you can redistribute it and/or modify it
1357 under the terms of the GNU General Public License as published by the
1358 Free Software Foundation; either version 2 of the License, or (at your
1359 option) any later version.
1360 This program is distributed in the hope that it will be useful, but
1362 WITHOUT ANY WARRANTY; without even the implied warranty of
1363 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
1364 General Public License for more details.
1365 You should have received a copy of the GNU General Public License along
1367 with this program; if not, write to the Free Software Foundation, Inc.,
1368 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
1369
1371 General contact, questions, patches, requests, etc to
1372 proj-swaks@jetmore.net.
1373 Change logs, this help, and the latest version are found at
1375 http://www.jetmore.org/john/code/swaks/.
1376 Swaks is crafted with love by John Jetmore from the cornfields of
1378 Indiana, United States of America.
1379
1381 Email
1382 updates-swaks@jetmore.net
1383 If you would like to be put on a list to receive notifications when
1385 a new version of Swaks is released, please send an email to this
1386 address. There will not be a response to your email.
1387 Website
1389 http://www.jetmore.org/john/blog/c/swaks/
1390 RSS Feed
1392 http://www.jetmore.org/john/blog/c/swaks/feed/
1393 Twitter
1395 http://twitter.com/SwaksSMTP
1396perl v5.28.1 2018-11-04 SWAKS(1)