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

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

Does email have a guarantee of delivery?

A client asked me earlier this week what SLAs ISPs provided for email delivery. The short answer is that there isn’t a SLA and that the only guarantee is that the email will get there when it gets there.
But as I was mentioning this to Steve, he pointed out that there was a recent change in the RFCs for email. In both RFC 821/2 and RFC 2821/2 (the original email related RFCs and the update in the early 2000’s) the RFCs stated that once a receiving MTA accepted an email that that MTA was required to either delivery the mail or generate an asynchronous bounce. While this isn’t a standard SLA, it does mean that a 2xy response after DATA meant the email would either be delivered to the user or be sent back to the sender. Despite the RFC requirements some receivers would still drop mail on the floor for various reasons, sometimes intentionally and sometimes not.
RFC 5321/2, the current SMTP standard, still says that once a server accepts the mail it must not lose that mail ‘for frivolous reasons.’ The RFC goes on to admit, though, that in recent years, SMTP servers are under a range of attacks and dropping mail on the floor is not frivolous in those cases.
 

Read More

SMTP Level Rejections

While discussing a draft of a Deliverability BCP document the issue came up of what rejections at different phases of the email delivery transaction can mean. That’s quite a big subject, but here’s a quick cheat sheet.
At initial connection
Dropped or failed connection:

Read More