Email is inherently a malicious traffic stream

It’s something many people don’t think about, but the majority of the traffic coming into the SMTP port is malicious. Spam is passively malicious, in that it just uses resources and bothers people. But there is a lot of actively malicious traffic coming into the SMTP port. Email is used as a vector to spread viruses and other malware. Email is also used for phishing and scamming. Many of the major hacks we’ve heard about over the last few years, including those in the email space, started with a single user getting infected through email.
We talk a lot about delivery here with clients and primarily focus on making sure their mail looks as unlike malicious mail as possible. We focus on spam filters, but every piece of mail goes through filters that also look for viruses, phishes, malware and other malicious traffic.
Mail servers are under attack constantly. The only reason our inboxes are useful is through the hard work of many people to filter out the bad and keep users from seeing the bulk of the mess attacking them.

Related Posts

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:

Read More

LinkedIn shuts down Intro product

Intro was the LinkedIn product that created an email proxy where all email users sent went through LinkedIn servers. This week LinkedIn announced it is discontinuing the product. They promise to find new ways to worm their way into the inbox, but intercepting and modifying user mail doesn’t seem to have been a successful business model.

Read More

The best time to send email

This subject comes up over and over again. Many senders are convinced clock_at_sign that there is a best time to send email. Countless research hours have been dedicated to finding that best time to send email. Numerous blog posts discuss what the best time to send email is.
From my perspective, there are better places for senders to spend time than figuring out what the exact right time is.But, senders still ask when the best time to send mail is.
There are a lot of reasons I can come up with as to why there’s no best time to send email. But the really big one is that when you send a mail has no impact on when it gets delivered.  There are multiple steps between hitting the send button and the mail being delivered to the inbox totally outside the control of the individual sender.
Email is designed as “store-and-forward.” This means there are potential delays at multiple steps inside the process.
Sending queues are called queues for a reason. Emails are sent out individually, particularly when an ESP uses VERP as part of its sending. There is actually a time overhead for making a connection to a recipient server and sending the email.
Receivers have queues, too. They can only accept so many incoming connections at a time. They have limited resources to accept all the mail their users want.
Receivers may delay mail between accepting it at the MX and delivering it to the inbox. This isn’t ideal and it’s not usual, but it can happen.
Recipients using IMAP accounts may not check mail regularly. They may only collect mail a few times a day.
These are only a few of the reasons that send time doesn’t necessarily equate with delivery time. Of course, 99% of the time email is mostly instantaneous. The internet is robust enough that a message sent is delivered seconds later. I see it happen all the time, when colleagues and I send email during calls. But, when mail fails, it sometimes fails spectacularly. Back in the dark ages (of the early 90s) I had an email that took almost a year to get to the recipients. Best I can tell, it got stuck somewhere in the depths of a machine in the middle of the university mail system. Eventually that system fell over and someone noticed and rebooted it (maybe it was walled up somewhere?).  The reboot shook my message out of where ever it was stuck.
 

Read More