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

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

AOL converting all FBLs to ARF

AOL announced today that they are phasing out non-ARF feedback loops. As of September 2, 2008, no new non-ARF feedback loops will be created and all existing non-ARF feedback loops will be converted to ARF.
What is ARF?
ARF stands for Abuse Reporting Format. It is a standardized format intended to make processing of automated abuse reports (or feedback loop reports) easier. Word to the Wise has published tools to help recipients process ARF formatted reports and help developers create tools to handle ARF formatted reports. Abacus also supports ARF format out of the box.

Read More

Who's publishing DMARC?

DMARC is a way for a domain owner to say “If you see this domain in a From: header and it’s not been sent straight from us, please don’t deliver the mail”. If a domain is only used for bulk and transactional mail, it can mitigate a subset of phishing attacks without causing too many problems for legitimate email.
In other cases, it can cause significant problems. Some of those problems impact discussion lists, but others cause problems for ESPs servicing small companies and individuals. ESP customers use their email addresses in the From: field; if they’re a small customer using the email address provided by their ISP, and that ISP publishes a DMARC record with p=reject, a large chunk of the mail they’re sending will bounce. When that happens recipients will stop getting their email, they’ll be removed from the mailing list due to bounces, and there’s some risk of blocks being raised against the sending IP address.
Because of that, it’s good to be able to see what consumer ISPs are doing with DMARC.
I’ve created a tool at dmarc.wordtothewise.com that regularly checks a list of large consumer ISPs and webmail providers and sees what DMARC records they’re publishing.
There are two main variants of DMARC records.
One is policy “reject” – meaning that mail that isn’t authenticated (or for which authentication has been broken in transit) will likely be rejected.
The other is policy “none” – meaning that the ISP publishing the record doesn’t want recipients to change their delivery decisions, but are asking for feedback about their mailstream, and how much of it fails authentication. That can mean that the ISP is evaluating whether or not to publish p=REJECT, or is in the process of deploying p=REJECT. Or it can just mean that they’re using DMARC to monitor where mail using their domain in the From: address is being sent from. There’s no way to tell which is the case unless they’ve made an announcement about their plans.
Hopefully this will be a useful tool to monitor DMARC deployment by consumer ISPs, and to help diagnose delivery problems that may be caused by DMARC.

Read More