SWAKS: the SMTP Swiss Army Knife

flash_m_laser_1200_900
SWAKS is a general purpose testing tool for SMTP. For basic SMTP testing it’s a more convenient, scriptable alternative to running a transaction by hand, but it also lets you test things that are difficult to do manually, such as authentication or TLS encryption.
It’s a perl script that installs fairly easily on OS X or any Linux/unix system (and can be installed on Windows, if you have perl installed there).
It’s pretty well documented, but it can be a bit overwhelming to start with. Here are some simple recipes:
Send a test email:

swaks -f you@example.net -t someone@example.com

Check to see if a recipient exists:

swaks -f you@example.net -t someone@example.com \
        --quit-after RCPT

Send via a particular server:

swaks -f you@example.net -t someone@example.com \
        --server mail.example.com

Test user authentication for a smarthost:

swaks -tls --server example.com -f you@example.com \
        -t someone@example.net  -ao --auth-user=you

Test to see if a server supports opportunistic TLS:

swaks -tls -s mail.example.com -f you@example.net \
        --ehlo your.host.name --quit-after FROM

(The backslashes are just there to split a single command line into two, so you can read it easily on this narrow blog).
SWAKS has a lot of other tricks too – adding headers, using specific protocols and ports, attaching content. It’s a very useful tool, and gets even more so when you add a little bit of shell scripting to automate your testing further.

Related Posts

Email standards at the email client

The Email Standards Project launched last week. This group is looking to lobby and encourage companies to make their email clients comply with HTML display standards. They are also identifying how different clients display email with HTML. Check out their website, and see what they’re doing.
I do apologize for the light blogging recently. I have a couple big deadlines on my plate. I hope to get back to regular blogging soon.

Read More

Troubleshooting tools

There have been a number of comments on my post about Hotmail moving to SPF authentication having to do with troubleshooting authentication failures. I have been helping clients troubleshoot these issues, and am able to take on new clients to solve authentication problems. Contact me for more information.
Of course, many of these issues can be solved with access to the right tools. Steve’s been working on a number of tools that may help the troubleshooting process and we’ve recently launched them on Emailstuff.org. The website itself contains a number of DNS and data related tools we use for investigations and thought we’d share with the public at large.
One of the really useful tools is the SPF record expander. Plug in any domain, like google.com, and see what IP addresses they authorize to send mail.

Read More

Email is store and forward

Many of us are so used to email appearing instantaneous, we forget that the underlying protocol was never designed for instant messaging. When the SMTP protocol was originally proposed it was designed to support servers that may have had intermittent connectivity. The protocol allowed for email to be spooled to disk and then sent when resources were available. In fact, almost everyone who was around more than 10 years ago knows of a case where an email took weeks, months or even years to deliver.
These days we’re spoiled. We expect the email we send to friends and relatives to show up in their mailbox within moments of sending it. We expect that sales receipt or e-ticket to show up in our mailbox within instants of a purchase. We expect that our ISPs will get us email immediately, if not sooner.
But there are a lot of things that can slow down email delivery. At several points in the process an email may be spooled to disk. It stays on the spool until the next part of the delivery process can happen. Other points of slowdown include the various anti-spam, anti-virus and anti-phishing protections that ISPs must implement. Then add in the extreme volume of email (around 10 billion messages a day) and all of a sudden email delivery is slower than many senders and recipients expect it to be. This delay is not ideal, but the system is designed so that mail is not silently discarded.
While individual emails may be delayed, most users will rarely see that delay in the email that they send. Bulk senders, who may be sending thousands or hundreds of thousands of emails a day, may see more delays in a single send than the average user sees in years of sending one-to-one email.
Email is store and forward, not instant. Sometimes that means there is a delay in getting email into the recipients inbox. And, sometimes there isn’t anything anyone can do to speed up delivery, except to adjust expectations of how email works.

Read More