Musings from a small IPP

Recently we had a customer whose website was infected by way of one of the infamous plugins that are sometimes bundled into themes, such as TimThumb.  The result was their site became one of the foci of a world-wide bot-net which posted tiny abouts of information (greeting and e-mail addresses)  to target fairly large SPAM messages out from their site.

This ran overnight at the weekend, so by the time we had tracked it down 25,000 messages had been submitted, all properly validated as coming from the customer’s site

Fortunately 10,000 messages were still in the system outgoing queue, and we were able to purge those, but it was still around 10 days before mail was flowing properly again.

In response to the issue we are “rate limiting” email by number of recipients from each sender. In a time window  I’ve run some analysis on the traffic logs, and apart from the mailing lists we host, which would be expected to send to many recipients, and with only 8 exceptions, in the past month no-one sends to more than 10 recipients in an hour.  We’ve exempted the known high volume senders from checks, and will be setting a sliding 1 hour window to restrict every other mail account’s submission rates to slightly more than this observed high

This may affect you if you suddenly decide to do a mass mailing.  It’s easy to enable your account if you tell us in advance, also don’t forget you can have a hosted mailing list which can individualise each message for its recipient

One of the things that happens every night on a Linux server is the administrator gets an emailed log file summary from a process known as “Logwatch” with lots of useful information such as a list of sites that have tried to guess passwords, hack your web server and so on. It also tells the current disk usage , warns about things getting out of kilter…

It’s generally a good idea to find what’s causing problems and fix them, but sometimes the answer is to stop reporting the problem.

Amongst the things that are reported when you run a name service are the hosts tHat try to use your server as a recursive resolver (you don’t want to let anyone other than your own customers do this or you might become part of a DDoS attack) and the servers that give malformed responses.

Now as I run a pretty up-to date name server I tend to believe the server when it reports that it’s getting random responses, and had written code to collate the reports to make an exclusion list of servers not to talk to.

Top of the bad response list were ns?.msft.net. These are the name servers which connect you to hotmail.com and outlook.com, and while blocking them gives a noticeable improvement in SPAM volume, ultimately there are people who want to use Hotmail.com despite it’s dreadful record of accounts being hacked

We spend a lot of time trying to let legitimate mail through, and filtering problem mail into SPAM folders for our customers.  Here are a few ways you can ensure you get filtered as SPAM

• Always change the sender of each message, to each recipient, to prevent whitelisting
• Assume that the FROM line will be recognised (it will not, sender is what counts)
• Have an incorrect SPF record for where you are sending from
• Always change the sender of each message, to each recipient, to prevent whitelisting
• Make sure your customers never reply to your mail, use a “noreply” address
• Send mail to customers who report you as SPAMMING them
• Use a 3^rd party mailing list service with bought lists
• Send mail containing links to sites that are black-listed
• When doing any of the above, send lots of mail to establish a history of sending dodgy mail
• Always change the sender of each message, to each recipient, to prevent whitelisting
• Slightly less important, have a mismatch between the email sender’s domain, and the system sending it
• Carefully include keywords that trigger automatic traps e.g. “Beneficiary,” “winner.” “prescription,” etc
• Send from a misconfigured system
• Have an invalid Message-id, or none at all.
• Always change the sender of each message, to each recipient, to prevent whitelisting
• Send from a system with a dynamic IP address (home vs business broadband)
• Use words and phrases that differ greatly from the language written by the intended recipient (Bayesean check)
• And remember always change the sender of each message, to each recipient, to prevent whitelisting

After all, it’s all about tracking deliveries, not getting your message through isn’t it?

If there’s one thing that’s visible every day, it’s that users (& some administrators/developers) are easily confused.

Take for instance the “Find My Friends” misfeature on most Social Networking sites. None warn the user to go through and check that the invitations they are about to generate are really only going to their friends, and that they should only send mail directly to their friends, not to mailing lists.

I wonder how many suppliers get invitations to connect to customers whom they don’t really know on LinkedIn? How many mailing lists are invited to sign up and befriend FaceBook users? Some sites like Flickr limit their invitations to existing users, others need blocked from every mailing list.

Example setting for Mailman > Privacy > Sender filter