Musings from a small IPP

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?

One of my customers reported a very focused failure.

They could not receive emails from Hotmail.  Everywhere else seems to be fine, just hotmail returned immediate failure when mail was sent to them. The same hotmail account could send mail to us, and to other customers.

The thing that was different with this customer was an A record for their domain, a practice I try to discourage, because I could see this happening with mails from out of date systems, but  as far as I was aware, not an issue with major providers. The customer has the domain-level A record because their website supplier thinks it uncool to use www. in front of the website (a mistake made by WordPress-mu as well)

It was very simple to demonstrate the fault.  We removed the domain level A record from the DNS and the mail immediately started to come through.