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

Well you are of course.

Then there are spammers, whom we try to control with SPF records in the DNS to limit where your email can come from to the servers you use.

Then there are misguided websites which try to use your email address to send mail when someone fills in a form claiming to be you.  You didn’t send that mail, the website did, so the 4 players in the message should be set appropriately; they are

From — who he message purports to be from — you in this case
Sender — the website administrator
Reply address — again probably you
Error Reports — Probably should go to the website admin

Websites will usually fix this once they understand the problem.

Finally there are people doing stuff for you, for instance payment portal providers, or webservice consolidation sites such as  house or employment search services.  Most of the above applies, with the added wrinkle of you as the named responsable (EU French term for the person accountable) for the service.

The portal will correctly show you as the From address, but should not be using your email as the sending address that’s just simply wrong, if you do agree to it then the portal should provide a portal SPF record that can be included by your own SPF record, how otherwise are you supposed to maintain your email security with random contractors thinking they can send as though they are you vs someone providing a service to you?

One does not use another company’s headed notepaper after all. That’s fraud. Why then should you use another company’s email address, without making the ‘on behalf of‘ relationship clear?

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.

The last block of IP4 addresses are handed over

This was the ceremonial handover of the last block of addresses available in the Second Internet Addressing Scheme (IP4) at the London Transport Museum, Covent Garden on Tuesday 22 March 2011. This marks the end of the Internet as we knew it and the start of a lot of hard work to make the switch over to IP6 invisible to the users. There are no free address blocks remaining. The end happened about 5 years later than I expected, mainly due to the massive use of NAT in Home and Business networks.

On the right Nigel Titley accepts the addresses on behalf of the European Internet Resources Centre (RIPE) from Leo Vegoda on behalf of the Internet Assigned Numbers Authority (IANA)

This is actually a scary moment. Be afraid, be very afraid.

Things have changed a lot in the 30 years I’ve been doing e-mail systems.  In those first heady days, establishing a transport fabric was hard work, and getting a message through over a mixture of uucp, decnet, snads, and arpa protocols a miracle of managing complexity, and co-operaion.  Now in February 2010 I reject 92% of the messages offered for my customers.  Strangely few of these rejections result in contacts from customers or their contacts  about false rejections — far more contacts relate to the SPAM we’re still letting through.   (continue reading…)

I’ve been rehearsing that comment for a while, as people tell me they can’t send mail to my customers, and what am I going to do about it?

SPF is the Sender Policy Framework.  If a mail fails SPF that means that the sender (you)  has violated the policy set forth by the owner of the sending domain, or their agents, in an SPF record; the recipient is not an actor in this

By publishing an SPF record the sending domain’s owner has asked the world to make some simple checks that mail is coming from the correct place.  These checks help with avoiding being impersonated.

When a correct rejection happens, we never hear about it.  When a rejection hits someone who might legitimately expect to use the domain there are two possible causes, and one solution.

1. The mail is coming from the wrong place, such as sending work mail through a home ISP because the VPN to work has dropped, or perhaps there’s a new gateway at work which hasn’t been configured into the SPF.
   Another common case is trying to use an SPF protected address from public webmail providers who have not configured their servers in an SPF aware way.
2. Your domain’s SPF record is scrambled, so the receiving software can’t make a list of the places the mail is allowed to come from

The solution in both cases is to fix the SPF record, not to ask the recipient to special-case your mail.

There is a third case of websites doing the wrong thing which I’ve dealt with elsewhere

It’s amazing how easy it is to get something wrong when configuring complex systems. When it comes to networking the first thing that people notice is when their e-mail goes wrong, because e-mail is a fairly complex application these days that calls upon all of the underlying services in many unexpected ways. (continue reading…)

Shortcuts make life easier for us.  For administrators configuring DNS there is a great shortcut which tells the program reading the zone where it is.  This lets the administrator leave off the domain part of the thing they’re configuring.

OK that  sounds complicated, so let’s give an example – if in a DNS file I were to write

$ORIGIN X.com.

then a few lines later I can say “mail” and “mail.X.com.” will be understood.  Well and good, though often a source of problems when someone leaves off a terminating ‘.’ and gets the domain added on where they were not expecting it.

SPF also has a chance to get messed up here.   Today’s gem was a record with

"v=spf1 mx a:ironport a:sandberg"

which makes one think the administrator setting it up was expecting that shorthand to apply to those ‘a:’ elements. It’s not clear what they thought they were doing for non-matching source addresses, as they left off a closure element.

"v=spf1 mx a:ironport.X.com a:sandberg.X.com -all"

was of course what they meant, but the software isn’t meant to follow inferences, rather it fails their SPF validation with a permanent error.

Today a customer wrote to ask for help getting mail from a company — let’s call it X — hat was suddenly not getting through.

X has 4 SPF rrcords

• v=spf1 mx include:isp1 -all
• v=spf1 mx include:isp2 -all
• v=spf1 mx include:isp3 -all
• v=spf1 mx include:isp4 -all

So depending on which of these four records is randomly received first, one of their supporting ISPs is authorized to forward X’s outbound email, — and — the other three ISPs are not authorized.   Actually X also had a syntax error in one of their 4 records which seriously did not help.

The SPF record X should have is of course:

• v=spf1 mx include:isp1 include:isp2 include:isp3 include:isp4 -all