Feb 272017
 

Strictly speaking how some cloud services do mail wrong, but whilst it is not all, there are still quite a few that do which is why there are no names contained within this rant.

When you have some cloud-based service send email, it makes sense for the “From” header (i.e. what sensible normal people think of as the sender address) to contain the email address of the person using the cloud-based service.

Fair enough.

But if the real sender address or envelope sender address (which is contained within the SMTP transaction) comprises the email address of the person using the cloud-based service you may well run into problems. Many organisations publish an SPF record in their DNS to indicate what network addresses are approved for, and many mail servers check the envelope sender against the published authorised network addresses.

If the network address used by the cloud service provider does not match what is in the organisation’s SPF record then the recipient’s mail server is free to reject the mail. And they often do.

Now the most obvious “fix” for this is to add the cloud service provider’s network address to the organisation’s SPF record.

The only trouble with that is that it isn’t always possible. There are various limits to how long an SPF record can be so adding addresses to the SPF record recklessly is unwise, and a sensible DNS administrator will only add to the SPF record for important services. So if the cloud service is being evaluated or being used by something less important, or is being used for non-work related purposes, then it likely won’t meet the “important enough to get added to the SPF record” criteria.

So why not fix the source of the problem?

All that has to be done is to use a different address for the envelope sender, and you can even arrange things to send bounces back to the right place.

Set the envelope sender to something like “customer+${original email}@${cloud service address}” (obviously when replacing the ${original email} you will have to change the “@” sign to something reversible). All of a sudden you are no longer “forging” the envelope sender, and not tripping over anyone’s spam defences.

Process the bounces to “customer@${cloud service address}” and you can send the bounces to the right place.

Feb 132017
 

As an atheist, I find it difficult to be polite and not fall about laughing at things like “Intelligent Design”, but for the duration of this blog posting, I’ll try.

On one side are the scientists who spend their working lives investigating biological processes who have their theory of evolution. Now that word “theory” needs a bit of explanation; it does not mean that evolution hasn’t been accepted as fact by scientists. Evolution is one of those rare scientific theories that has never been disproved; merely refined. Essentially the word “theory” here is a challenge to disprove evolution and come up with a better theory – if you think you’re hard enough!

On the other side are a collection of religious leaders (admittedly Charles Thaxton trained as a chemist) who have spent their working lives telling people about god; and coming up with the theory of “Intelligent Design” in their spare time. The suspicion is that these people are letting their religious beliefs influence their “scientific” thinking.

When I want to know about plumbing, I ask a plumber. When I want to know about welding, I ask a boiler-maker. And when I want to know about biology, I ask a biologist.

Feb 122017
 

A very long time ago, I used to collect spam in order to graph how much spam a single mail server was likely to get over time, and almost as long ago, I lost interest in maintaining it. As a consequence I still get a ton of spam every day and after a long period of procrastination I have been slowly raising defences against spam.

This particular recipe is not really a defence against spam – it verifies that the remote server is properly DNS registered with a reverse DNS registration – in other words that the IP address it is connecting from is registered. This is a requirement for all mail servers, and as it turns out, spammers don’t care for registering their servers in the DNS.

This ACL snippet goes into the ACL for checking the recipient or for checking the message :-

 deny
   message = Your mail server is not properly DNS registered
   log_message = BLOCKED: No rDNS
   condition = ${if eq{$host_lookup_failed} {1} {1}{0}}
   # Check rDNS and block if not registered

There are three items of interest :-

  1. The message is intended to be easily read by recipients to determine what the problem is. It turns out that many people do not read NDRs, but if we get the message right at least we are doing the right thing.
  2. The log_message is intended to make automating log parsing easier.
  3. Within the condition, the $host_lookup_failed variable indicates that the reverse DNS lookup returned NXDOMAIN and not that it timed out (which would be $host_lookup_deferred).

That’s all there is to this little piece of configuration.

Feb 122017
 

Now this blog posting is not intended to defend the wrongs of colonialism; we all now accept that territorial expansion by conquest (except apparently Russia) is wrong. In fact it could be argued that Britain conquered India for commercial and not colonial reasons – for example no penal transportation to India occurred. Yes, British people went to live in India, but chiefly to do specific jobs – colonial administration, soldiering, or commercial activities.

Not mass migration.

We need to be wary of judging the past with the moral standards of today; it was not until the 20th century that conquest for territorial expansion was universally condemned. And the evils of the British Raj (and earlier) because it successfully conquered India; earlier (and there were many) attempts failed, although some were close. The very presence of islam within the Indian sub-continent is indicative of attempts to conquer.

And as for the notion that only the British Empire acted in evil ways in India, just take a look through the list of massacres in India; many of those listed had nothing to do with the British.

Does that excuse the excesses of British colonial rule? No of course it doesn’t.

But even if Europeans had not become involved with India, the evils of attempted conquest would still have occurred as they did occur before.

Feb 082017
 

One of the things that come up whenever IPv6 is mentioned on certain news sites, is that there are people out there who think that NAT solves all of the address size problems and doesn’t have any negatives. I could present a whole series of blog articles on why NAT is the work of the devil, and presents a clear and present danger to life, liberty, and the pursuit of happiness (I might be exaggerating just a touch here).

The naive approach to a security issue originating from a certain network address is to block that network address permanently, pending an appropriate response, or temporarily. Not a bad idea although it does resemble a game of hunt the wumpus, and to assist in this, there are community based collective blocklists.

But what happens when you block an address, and that address is the public address of a NAT device? You block everyone sharing that public address, which could be just a household or it could be thousands of unconnected people. For instance, I have up to 32,000 people behind a handful of public IP addresses.

And yes I do regularly see problems where blocks have been put in place, and from what I can see this is a problem that is widely shared amongst people who NAT.

And once you are blocked in this way, you may be able to get it removed if you manage to identify which blocklist you are on, stop the network abuse and it has a well-run mechanism for removal. Most blocklists (including the ones I run) don’t work this way.

Every IP address has a reputation associated with it, and if you share a public IP address that has a poor reputation, parts of the Internet will disappear for you, and these include some well known services.