In multiple MX situations or if you're not sure if your DNS is working yet, it is hard to test if a specific server has its TLS done correctly. It would be helpful to separate the hostname used in --verify-tls from the hostname given by -s so that a specific server can be targetted with -s.

openssl lets you do this, but it's arcane:

echo QUIT | timeout 30 openssl s_client -quiet -no_ign_eof -connect "$ip":25 -starttls smtp -verify_hostname "$mx" -verify_return_error 2>/dev/null

swaks has timeouts built in and consistent I/O choices, but the closest I can get to this specific command, unless I've misread something, is

swaks -s "$mx" -tls --tls-verify -quit "HELO"

Being able to do something like

swaks -s "$ip" -tls --tls-verify --tls-verify-hostname "$mx" -quit "HELO"

would make pinpointing deployment issues easier.

This is a very niche issue, and I wouldn't be surprised if you think it's out of scope for swaks! It's already been very helpful in its current form.

The maintainer of this distribution has indicated that it is deprecated and no longer suitable for use. https://metacpan.org/pod/IO::Socket::INET6

Therefore Swaks should not use it.

Using 20201010.0 passwords are echoed even if --protect-prompt is set. Does work with version 20190914.0.
System: Debian 10.6 (Buster), always reproducable:

$ swaks --protect-prompt --from [email protected] --to [email protected] --au username
Password: SECRET (expected: ******)

(Obvoius note: This is a security problem)

Update README.md with the changes from the last round of html fixes (234db82). The lack of link in the documentation section to the rendered version of github is what specifically caught my eye.

Requested sluka.de#martin 2014-09-05, patch provided

Currently, one of my use cases is a simple monitoring cronjob including the requirement for authentication. For security reasons, I do not want to put the password on the command line, but obviously it is no alternative to be prompted for it either.

Therefore I have modified your script so that it will try to obtain the login credentials from my ~/.netrc using the standard Net::Netrc module if authentication is required but no username and/or password is given. You may still turn this off by supplying -au respectively -ap without an argument.

Please find a patch attached. Maybe this extension is also of interest for the official swaks version. Please let me know what you think about it.

Add an additional, default header which includes some identifying information. This would be useful for tracking naive abuse of swaks. Make it very easy to remove/disable for people who know what they're doing.

Possible information to include:

• local machine ip
• local username
• date/time
• reconstructed command line (minus passwords, elided data, etc)

Add specific command line option to disable this header. Thoroughly document the header's existence and the ability to disable it. Include note about disabling it "permanently" by adding the option to disable it in bashrc.

Can you change the shebang from

#!/usr/bin/perl

to

#!/usr/bin/env perl

please?

I have no idea how to create a pull request :-)-O

el

cpan install App::Swaks should pull in at least some of the dependent modules (Net::SSLeay, Net::DNS, etc)

If I send the email with these switches:
--add-header "Content-Type: text/html; charset=UTF-8"
and
--attach-type text/html --attach-body @/something

received email is without html body.

If I send it only with --attach-type text/html --attach-body @/something, everything is ok.

Is possible to say(to write down switches): the email is in UTF-8 and it has the html attachment?

This renders incorrectly:

The value can be on one single line, with C<\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 default value for this option is C<Date: %DATE%\nTo: %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>.

Given how I have swaks' repo laid out, the auto-release github is doing is confusing for end users. See #12.

Swaks' repo has development code, then at the time of release I generate the contents of the RELEASE dir, tag it, and push it. It's tagged as a release, so github auto-populates the release section. The problem is that it sees releases as the entire repo, where it really ought to just be the contents of RELEASE. See if I can mitigate this.

• Preferentially, keep the feature but change it to only be RELEASE
• If that can't work, just shut down the auto-release stuff altogether. Not having it at all would be better than the current system

from notes:

Are there new TLS constants to add? I think the _ANY and _NEWEST (or whatever) constants are new, would be nice to support them

If we know a file must be an argument, error during option processing if it's not a readable file. We have this with OP_FROM_FILE for files that we open and process ourselves, but there are other files we don't open during argument processing (for instance --tls-key/--tls-cert/--tls-chain)

how to use with this?

socks5 127.0.0.1 1080 username password!@#

I didn't understand it through the help document

User had issue (reported via email) where \n getting replaced in message body broke S/MIME. --no-data-fixup helped, but then other stuff had to be massaged (specifically the line-endings had to be explicitly fixed).

Maybe --no-data-fixup could take an option of things not to touch. For instance trailing-dot, line-endings, tokens, etc. In this use case the use could have just run with --no-data-fixup tokens (\n is seen as a token internally) and been happy. all would induce the current behavior, and the default arg for --no-data-fixup would be all.

I would helpfull to tell swaks to try all MX records of the destination domain.
Currently it aborts if the first (lowest) MX server is down or refuses the connection.
I know I can force it via "-s dedicated-server.example.com" but I am thinking of just specifiing
"-t [email protected]" without dig-ing for the MX records first.

Background info:
I am using swaks to verify a (big) bunch of external forwarding addresses with the "--quit-after RCPT "
switch and currently it fails, if the first MX of the destination domain is down or busy.
So a switch like "--try-all-MX" would be helpfull. Maybe together with a timeout parameter "--MX-timeout "

I spent quite a bit of time trying to nail down the specific settings for sending programmatic emails through Gmail (using swaks to verify).

I figured I would document it here in case it helps anyone else.

Following this link (and enabling 2FA/two-factor-authentication), then create an app password to use for signing into the mail server.

FROM ubuntu:20.04
RUN apt update && echo y | apt install swaks vim

Finally, try test email...

swaks -4 --server smtp.gmail.com -tlsc --tls-protocol TLSv1_2 \
    --from [your full gmail account email that app password was setup for] --to [email protected],[email protected] \
    --auth LOGIN --auth-user [same as from] --auth-password [your generated app password] -apt \
    --h-Subject 'Test email' --body 'Email system test.'

The -apt argument isn't required of course, it just helped with troubleshooting. Not using "smtp-relay..." for the server as what little Google documentation exists indicated, was necessary. Do not consider this a "secured" example, merely for testing purposes.

I'll try closing this "issue" if allowed so as to not create more work for admins.

move around the args in data section (in particular, --dab and --dabsp should not be as high in the list as they are)

Both these fail. Unsure how to proceed...

lxd: net16-mailstore # swaks --local-interface=144.217.145.116 [email protected] [email protected]
=== Trying 67.195.204.73:25...
*** Error connecting 144.217.145.116 to 67.195.204.73:25:
*** 	IO::Socket::INET6: connect: No route to host

lxd: net16-mailstore # swaks --tls --local-interface=144.217.145.116 [email protected] [email protected]
=== Trying 67.195.204.73:25...
*** Error connecting 144.217.145.116 to 67.195.204.73:25:
*** 	IO::Socket::INET6: connect: No route to host

This also fails...

lxd: net16-mailstore # dig +short yahoo.com mx
1 mta5.am0.yahoodns.net.
1 mta7.am0.yahoodns.net.
1 mta6.am0.yahoodns.net.

lxd: net16-mailstore # swaks --server=mta5.am0.yahoodns.net --local-interface=144.217.145.116 [email protected] [email protected]
=== Trying mta5.am0.yahoodns.net:25...
*** Error connecting 144.217.145.116 to mta5.am0.yahoodns.net:25:
*** 	IO::Socket::INET6: connect: No route to host

lxd: net16-mailstore # swaks --server=mta6.am0.yahoodns.net --local-interface=144.217.145.116 [email protected] [email protected]
=== Trying mta6.am0.yahoodns.net:25...
*** Error connecting 144.217.145.116 to mta6.am0.yahoodns.net:25:
*** 	IO::Socket::INET6: connect: No route to host

lxd: net16-mailstore # swaks --server=mta7.am0.yahoodns.net --local-interface=144.217.145.116 [email protected] [email protected]
=== Trying mta7.am0.yahoodns.net:25...
*** Error connecting 144.217.145.116 to mta7.am0.yahoodns.net:25:
*** 	IO::Socket::INET6: connect: No route to host

If you have any insight into what's occurring, let me know.

Thanks.

At user request, add --attach-boundary option to allow user to set MIME boundary.

The example under the "How do I send email which has an HTML-encoded body" of the "How do I send HTML email?" on http://jetmore.org/john/code/swaks/faq.html is out of date.

Current example:
swaks --body report.html --add-header "MIME-Version: 1.0" --add-header "Content-Type: text/html"

Should be something like:
swaks --attach-type text/html --attach-body report.html

The text around the example is out of date and needs to be changed also

This is an old report (2014) which was just brought back to my attention by hschlittermann. It appears to be specific to Exim compiled with gnutls, which I don't think was ever tested. "The same Exim, but compiled with OpenSSL works."

swaks --tls --pipe 'exim -bh <ip>'

LOG: TLS error on connection from (SERVERNAME) [SERVERIP] (gnutls_handshake): A TLS packet with unexpected length was received.
<-  220 TLS go ahead
*** TLS startup failed (connect(): error:00000000:lib(0):func(0):reason(0))
*** STARTTLS attempted but failed

pkg-config --modversion gnutls  ---> 2.12.20
pkg-config --modversion openssl ---> 1.0.1e

This was suggested via email in 2018 by Moritz Wilhelmy. See his email for example tarball. I didn't see the value at the time, but I now see some value to having an officially packaged version that can be installed on any platform (for instance, windows, opensuse, etc)

There are 2 scripts - at the top and inside the RELEASE dir. Which one is the proper one? As diff shows me quite a lot of differences.

Hello,

this is https://bugs.debian.org/955798 reported Russell Coker:

Swaks (oder the perl libraries it uses) does not get the start of DST right:

ametzler@argenau:~$ env LC_ALL=C TZ=Australia/Sydney faketime '2020-04-05 09:21:47'  date
Sun Apr  5 09:21:47 AEST 2020
ametzler@argenau:~$ env LC_ALL=C TZ=Australia/Sydney faketime '2020-04-05 09:21:47'  date +%z
+1000
ametzler@argenau:~$ env LC_ALL=C TZ=Australia/Sydney faketime '2020-04-05 12:59:58' swaks -s localhost -t [...]
[...]
 ~> Date: Sun, 05 Apr 2020 12:59:58 +1100
[...]
ametzler@argenau:~$ env LC_ALL=C TZ=Australia/Sydney faketime '2020-04-05 13:00:01' swaks -s localhost -t [...]
[...]
 ~> Date: Sun, 05 Apr 2020 13:00:01 +1000

The TZ offset in the date header jumps from +1100 to +1000 at about 13:00.

Russel describes the behavior as follows:
Before 13:00 Swaks is taking the current human readable time but applying the timezone offset from yesterday when daylight savings was running. [...] It seems that swaks (or maybe the Perl libraries it uses) was about 10 or 11 hours late in recognising the daylight savings change. Maybe it thought
that the early morning daylight savings time change meant early morning UTC not early morning in my timezone.

I'm not sure if this is a good idea, but someone tried it and found it didn't work. Noting it here for future consideration. Perhaps if it is added it should be off by default and turned on with --config-try-environment or something.

Repro:

mb 0 /Users/jetmore/Documents/git/swaks > cat config
--to $TO
--from [email protected]
--helo server.example.com
mb 0 /Users/jetmore/Documents/git/swaks > [email protected] ./swaks --dump protocol --config ./config
Protocol Info:
  protocol        = esmtp
  helo            = server.example.com
  from            = [email protected]
  to              = $TO
  force getpwuid  = FALSE
  quit after      =
  drop after      =
  drop after send =
  server_only     = FALSE
  timeout         = 30
  pipeline        = FALSE
  prdr            = FALSE
mb 0 /Users/jetmore/Documents/git/swaks >

If implemented, the "to" option in the output should show [email protected], not $TO

Update docs/installation.pod (other copies of the file are updated automatically at release time)

• Add a note for basic installation, specifically for any unix-like operating system. Save the file, chmod it, run it. There's some notes in base.pod that could be cribbed I think.
• add more environments.

AWS offers AUTH PLAIN LOGIN, but insists on TLS. In the following what does <** 530 mean? Is it a 530 rseponse or a comment?

=== Trying email-smtp.us-west-2.amazonaws.com:25...
=== Connected to email-smtp.us-west-2.amazonaws.com.
<-  220 email-smtp.amazonaws.com ESMTP SimpleEmailService-d-UCMGFU8F2 l8rfaVjiaG1V7Lvw7tuo
 -> EHLO STRAUSS
<-  250-email-smtp.amazonaws.com
<-  250-8BITMIME
<-  250-SIZE 10485760
<-  250-STARTTLS
<-  250-AUTH PLAIN LOGIN
<-  250 Ok
 -> AUTH LOGIN
<** 530 Must issue a STARTTLS command first
 -> AUTH PLAIN 
****credentials removed***********
<** 530 Must issue a STARTTLS command first
*** No authentication type succeeded
 -> QUIT
<-  221 Bye
=== Connection closed with remote host.

If it is a Http response, should SWAKS then try TLS?

While sendmail adds DKIM signature to outgoing emails, swaks does not
@jetmore could you look into it?

1. default all text/* types to charset="utf-8"
2. add a --attach-charset option to manually set the charset if needed

Is there any reason defaulting to uft-8 would cause problems?

--===============1390463542==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

options like --data are moving toward requiring a sigil to indicate that their contents need to be pulled from a file. We could expand this to a new sigil to indicate that the argument is a program to execute, the output of which should be used as the real content. This idea came from a user thinking that's what --pipe did. This is mostly unnecessary as backticks would usually do the same thing, but it would be nice to have the functionality on windows

Example:

--body "some contents"
  uses "some contents"

--body @file.txt
  uses contents of file.txt

--body :"tail -1 file.txt"
  uses the output of "tail -1 file.txt"

https://tools.ietf.org/html/rfc3030

This has been requested via email a couple of times

ametzler (12/18/16) It would be nice if swaks supported CHUNKING (BDAT instead of DATA). Exim has recently started supporting this (CHUNKING, but not BINARYMIME) and swaks is not yet able to test/use it.

mpurdon (6/30/14) - I'm wondering if support for Chunking could be added.

*** DEPRECATION WARNING: Inferring a filename from the argument to --attach will be removed in the future. Prefix filenames with '@' instead.

Prefixing filenames with '@' in --attach leads to @ being included in attachement filename.

/usr/bin/swaks --attach @test.txt ...

Split swaks functionality into mua mode and test mode. Swaks was designed as a test tool, but has a healthy set of uses as a straight MUA. Trying to serve two masters has lead to some compromises that are not ideal. For instance, swaks will not send AUTH unless the server advertises auth. This is correct behavior for an MUA, but hobbles an admin who wants to understand what their server does when AUTH is sent without being advertised. Conversely, we only ever try one server, which is appropriate for an admin testing specific servers, but deficient for a user who is just trying to send a mail (in which case we should try all MX records).

Items from my notes that might be related to this, or that this might be a blocker for:

• XCLIENT and XFORWARD have length limits but swaks doesn't try to enforce them (by breaking up the strings into multiple calls). Might be interesting to support them

• try more than one MX?
  If delivering via MX, keep trying MX until one succeeds
  Add new option for this, not default behavior
  how behave if receive 4xx level error?

• Swaks should be able to break rules for testing
  Subject: Force Authentication Attempt? :: Dave Page 1/16/18
  --lax mode so that checks like "make sure auth is advertised before trying auth" can work?

• in mua mode, we would do MX lookups for every recipient instead of sending every recipient to the last user's MX

• in MUA mode, require DNS be operational, do not fall back to localhost

In particular, be explicit about what transformations we perform on the argument. We mention \n and tokens, but we don't mention adding the dot, From_ stripping, line endings, etc. When adding it, explicitly mention options for turning off that behavior (--no-data-fixup, --no-strip-from, etc).

• --no-data-fixup - may need to change this, but no matter what change "massage" to manipulate, or whatever word we end up using to define the behavior in --data section

Idea from user via email

Optionally write a summary of the transaction. Rough first pass:

Attempt time: ....
Remote: [ foo.example.com | |pipe | /path/to/socket ]
Attempted: [email protected],[email protected],[email protected]
Success: [email protected]
Permanent Failure: [email protected]
Temporary Failure: [email protected]

This could optionally be sent to console or logged for later processing

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883232

I believe this will be fixed if I ever sort out the TLS rewrite, but confirm before next release

I would be good if swaks could generate test DSN (RFC 3461) notification responses.

As a minimal feature, it would be useful to be able to request a response based on one or more of failure, delay, or success. eg

swaks --to [email protected] --dsn-notify=failure,delay,success

Then, if DSN is advertised after EHLO

<-  250-DSN

the RCPT TO: command has a NOTIFY= option appended to it.

 -> RCPT TO:<[email protected]> NOTIFY=FAILURE,DELAY,SUCCESS

how can I use a socks5 with the proxy command

example
127.0.0.1:1080

current output options (--output-file, --output-file-stderr, --output-file-stdout) appear to append to the file. Should clobber the file instead

Hi there! Firstly wanted to say how great swaks is, I use it all the time.

I am currently testing behaviour with tls and xclient, and would like some clarification on the command sequence. When sending an email with both --xclient and --tls, there seems to be some unexpected behaviour. From the client, I would expect STARTTLS -> EHLO -> XCLIENT -> EHLO. It seems unexpected that we would have STARTTLS -> XCLIENT -> EHLO -> EHLO. Can you confirm whether this is the correct behaviour?

swaks -s 127.0.0.1:2506 --to test@localhost --from another-test@localhost --xclient-addr '12.13.123.0' --tls
=== Trying 127.0.0.1:2506...
=== Connected to 127.0.0.1.
<-  220 redacted ESMTP
 -> EHLO example-000506.example.net
<-  250-example-000506
<-  250-8BITMIME
<-  250-SMTPUTF8
<-  250-STARTTLS
<-  250 XCLIENT ADDR
 -> STARTTLS
<-  220 OK
=== TLS started with cipher TLS-redacted
=== TLS no local certificate set
=== TLS peer DN="redacted"
 ~> XCLIENT ADDR=12.13.123.0
<~  220 redacted ESMTP
 ~> EHLO example-000506.example.net
<~  250-example-000506
<~  250-8BITMIME
<~  250-SMTPUTF8
<~  250 XCLIENT ADDR
 ~> EHLO example-000506.example.net

When passing the --xclient-before-starttls the behaviour seems correct. XCLIENT -> EHLO -> STARTTLS -> EHLO

swaks -s 127.0.0.1:2506 --to [email protected] --from another-test@localhost --xclient-before-starttls --xclient-addr '12.13.123.0' -tls
=== Trying 127.0.0.1:2506...
=== Connected to 127.0.0.1.
<-  220 redacted ESMTP
 -> EHLO example-000506.example.net
<-  250-example-000506
<-  250-8BITMIME
<-  250-SMTPUTF8
<-  250-STARTTLS
<-  250 XCLIENT ADDR
 -> XCLIENT ADDR=12.13.123.0
<-  220 redacted ESMTP
 -> EHLO example-000506.example.net
<-  250-example-000506
<-  250-8BITMIME
<-  250-SMTPUTF8
<-  250-STARTTLS
<-  250 XCLIENT ADDR
 -> STARTTLS
<-  220 OK
=== TLS started with cipher redacted
=== TLS no local certificate set
=== TLS peer DN="redacted"
 ~> EHLO example-000506.example.net
<~  250-example-000506
<~  250-8BITMIME
<~  250-SMTPUTF8
<~  250 XCLIENT ADDR
 ~> MAIL FROM:<another-test@localhost>
<~  250 OK
 ~> RCPT TO:<test@localhost>
<~  250 OK
 ~> DATA
<~  354 <CR><LF>.<CR><LF>
 ~> Date: Fri, 31 Jul 2020 11:34:56 +0100
 ~> To: test@localhost
 ~> From: another-test@localhost
 ~> Subject: test Fri, 31 Jul 2020 11:34:56 +0100
 ~> Message-Id: <[email protected]>
 ~> X-Mailer: swaks v20190914.0 jetmore.org/john/code/swaks/
 ~> 
 ~> This is a test mailing
 ~> 
 ~> 
 ~> .
<~  250 Message Queued (68B68CDD-09B7-4850-8398-6EEDD1206BDF.1)
 ~> QUIT
<~  221 OK
=== Connection closed with remote host.

Thanks so much!!

http://www.postfix.org/XFORWARD_README.html

requested via twitter by tsturm, 12/13/17

The example in the manpage

swaks --to [email protected] --body /path/to/gtube/file

should be

swaks --to [email protected] --body @/path/to/gtube/file

as filenames without '@' prefix generate a "DEPRECATION WARNING".

User reported that utf8 strings that worked fine in 20190914.0 are now broken in 20201010.0. Still collecting data, just opening this as a placeholder

Email sent to outlook are received, but the content of any kind is unreadable

swaks --attach-type text/html --attach-body @mod.html --attach-type application/pdf --attach documentation.pdf -t "$email" --add-header "MIME:Version 1.0" --add-header "Content-Type: text/html" --h-Subject "Devis pour Visite Virtuelle Google $prix€" --h-From: '"<MY NAME>" <[email protected]>' -s smtp.gmail.com:587 -tls -au [email protected] -ap jbnymdemutvqifd -f [email protected] --tls-protocol tlsv1_3

How to set it up?

Why I think it is CRAM-MD5? Because server replies:
50-AUTH=LOGIN PLAIN CRAM-MD5

Where it works: Thunderbird with settings: SSL/TLS and "Encrypted password"

For swaks -ap argument I am using the same string as for "Encrypted password" in Thunderbird

swaks -t ... -f ... -s ... -p 465 --auth CRAM-MD5 -au user1 -ap *** -tlsc -tlsp tlsv1_2 \
--h-Subject "test" --body "email body" --h-X-TMP-B01 "script 1" -pp

=== Trying ...:465...
=== Connected to ... .
=== TLS started with cipher TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
=== TLS no local certificate set
=== TLS peer DN="..."
<~  220 ... ESMTP
 ~> EHLO ...
<~  250-...
<~  250-STARTTLS
<~  250-PIPELINING
<~  250-8BITMIME
<~  250-SIZE 104857600
<~  250-AUTH=LOGIN PLAIN CRAM-MD5
<~  250 AUTH LOGIN PLAIN CRAM-MD5
 ~> AUTH CRAM-MD5
<~  334 PDI...Pg==
 ~> cG9...Mw==
<~* 535 authentication failed
*** No authentication type succeeded
 ~> QUIT
<~  221 ...
=== Connection closed with remote host.

How can I use "Encrypted password" from Thunderbird (that is what I have) with swaks?

thunderbird: 91.2.0
os: rocky 8 (centos 8)
swaks version 20181104.0 (from epel)

Imagine a situation where a user wants to send a link to a report every night. The text of the email is static except for the link. Rather than forcing the user to rebuild the full body each night, offer the ability for the user to reference a custom token in the body, and define the custom token on the command line.

$ cat body.txt
The result of the night widget report is available and can be viewed at %REPORT_URL%
$ swaks -t [email protected] --body body.txt --token REPORT_URL:http://example.com/report/20210421.html

Not convinced about the name of --token or that argument format, but that's the idea

I had to --pipe an openssl s_client as the swaks argument --tls-sni does not seem to work. The connection opens, TLS handshake is successful, but without any SNI header sent in TLS Client Hello.

This works:

$ swaks --pipe 'openssl s_client -connect somehost.example.com:443 -servername somehost.example.com -quiet' ...ordinary arguments follow

This does not (LB redirects to a HTTP server if SNI is not given):

$ swaks -s somehost.example.com:443 -tls -tlsp tlsv1_3 -p 443 --tls-sni somehost.example.com ...ordinary arguments follow
=== Trying somehost.example.com:443...
=== Connected to somehost.example.com.
<** HTTP/1.1 408 Request Time-out
<** content-length: 110
<** cache-control: no-cache
<** content-type: text/html
<** connection: close
<** 
<** <html><body><h1>408 Request Time-out</h1>
<** Your browser didn't send a complete request in time.
<** </body></html>