by Erik Kangas, PhD, CEO

Posts Tagged ‘dns’

I came across your article entitled Split Domain Routing: Getting Email for Your Domain at Two Providers while trying to figure out why one of the people in the small 3 person company I am affiliated with got a call from our web hosting and domain name company asking him to increase his email storage capacity even though we had migrated our email service away from them 2 years ago and at that time had redirected our DNS MX records to our new email provider.

When I looked at my colleague’s email on the old service, I saw that he is still receiving spam mail there even though he is getting all his business mail through the new provider. How is it possible that he gets any mail at the old place at all now? I think the money he paid them is a completely ripoff as that is not his working email! Unfortunately I am the only one of the 3 of us that understands any of this…and that isn’t saying much. Thanks for any thoughts.

Hello! This is actually quote a common scenario. If you do not close down your account with your old email provider, then that provider will usually still accept inbound email addressed to you which arrives at its servers.

LuxSci has been partnered with easyDNS to provide DNS and domain registration services to its customers since 1999. Due to our sales volume, we have an “Enterprise DNS” portal that both LuxSci Support and its clients can access to manage their domains. LuxSci has stuck with easyDNS for all of these years due to their excellent support, the high quality of the DNS services, and the friendly and helpful attitude of easyDNS management. LuxSci also believes that by partnering with easyDNS, we are able to provide our clients with the best and most robust DNS services available. This is mission critical, because if your DNS is down, so is your business.

We have recently looked at how hackers and spammers can send forged email and then seen how these forged messages can be almost identical to legitimate messages from the purported senders. In fact, we learned that generally all you can trust in an inbound email message is the internet IP address of the server talking to your inbound email server — as this cannot realistically be forged in any way that would still enable you to receive the message.

In our previous two posts in this series, we examined how SPF and DKIM can be used to help limit forged email messages based on validating if a message was sent by an approved server by looking at the IP address delivering the email message to you and based on digitally signing messages. We found that while SPF and DKIM can work, they has many significant limitations that cause them to fall or be insufficient to stop forgeries in many cases.

However, SPF and DKIM address the forgery problem in very different and, in many respects, very complementary ways. For this reason, many organizations use both technologies.

If you are using both technologies and you have a good amount of control over where your domain’s messages are coming from, then you can step up your game by using DMARC — Domain-based Message Authentication, Reporting and Conformance.

We have recently looked at how hackers and spammers can send forged email and then seen how these forged messages can be almost identical to legitimate messages from the purported senders. In fact, we learned that generally all you can trust in an inbound email message is the internet IP address of the server talking to your inbound email server — as this cannot realistically be forged in any way that would still enable you to receive the message.

In our last post in this series, we examined how SPF can be used to help weed out forged email messages based on validating if a message was sent by an approved server by looking at the IP address delivering the email message to you. We found that while SPF can work, it has many significant limitations that cause it to fall far short of being a panacea.

So — besides looking at the sending server IP address — what else can we do to determine of a message was forged?

It turns out that there is another way — through the use of encryption techniques and digital signatures — to have the sender’s servers transparently “sign” a message in a way that you can verify upon receipt. This is called DKIM.

DKIM – Domain Keys Identified Mail: A Simple Explanation

DKIM stands for “Domain Keys Identified Mail” … or, re-writing this more verbosely, “Domain-wide validation Mail Identity through use of cryptographic Keys”. To understand DKIM, we need to back up for a second and look at what we mean by “cryptographic keys” and how that can be used.

We have recently looked at how hackers and spammers can send forged email and then seen how these forged messages can be almost identical to legitimate messages from the purported senders. In fact, we learned that generally all you can trust in an inbound email message is the internet IP address of the server talking to your inbound email server — as this cannot realistically be forged in any way that would still enable you to receive the message.

We know who the message says it is from and the address of the server that delivered it to us. How can we reliably prevent fraud by checking if the message was forged or not? Seems hard.

It turns out that there are a number (yes, more than one!) of techniques that can be used to do this. The first and simplest is SPF – Sender Policy Framework. Below, we shall look at what this does, how it works, how to set it up, and what some of its deficiencies are. In future articles, we will look at the other techniques.

SPF – Sender Policy Framework: A Super Simple Explanation

Simply put, SPF is a way for the owner of a domain, such as bankofamerica.com, to publish information indicating what servers (Internet addresses) are authorized to send email from that domain. Recipients (e.g. your spam filtering software) can check the Internet address that is trying to send you an email from bankofamerica.com against this authorization list — if it is on it, the message is probably legitimate; if not, it’s probably forged.

SMTP TLS (Transport Layer Security) is the mechanism by which two email servers, when communicating, can automatically negotiate an encrypted channel between them so that the emails transmitted are secured from eavesdroppers.

It is becoming ever more important to use a company that supports TLS for email transmission as more and more banks, health care, and other organizations who have any kind of security policy are requiring their vendors and clients to use this type of encryption for emailed communications with them. Additionally, if your email provider supports TLS for email transmission, and you are communicating with people whose providers do also, then you can be reasonably sure that all of the email traffic between you and them will be encrypted.

How do you find out if someone to whom you are sending email uses a provider who’s servers support TLS-encrypted communications? We will take you through the whole process step-by-step, but first let us note some 6 important truths about TLS connection encryption.

The Internet is rife with fake and forged email. Typically these are email messages that appear to be from a friend, relative, business acquaintance, or vendor that ask you to do something. If you trust that the message is really from this person, you are much more likely to take whatever action is requested — often to your detriment.

These are forms of social engineering — the “bad guys” trying to establish a trusted context so that you will give them information or perform actions that you otherwise would not or should not do.

Here we address some of the actions you can take to protect yourself from these attacks as best as possible. We’ll present these in the order of increasing complexity / technical difficulty.

In many ways, the Internet is still like the Wild Wild West. Email messages sent to you or from you can and do “go missing” for no apparent reason. This can happen no matter what email provider you use. So, what happened to these “AWOL” messages? How can you diagnose and solve the problem?

DNS is a cornerstone of the Internet. It is the “phonebook” that translates all those domain names, like “luxsci.com” and “google.com” into the addresses of the actual computers that you need to talk to (more details). Unfortunately, if there is an issue with the DNS for your company’s domain name, then your web site can go offline, your email can stop flowing or bounce, and other bad things can happen.

In addition to having a rock solid email and web hosting service, the reliability of your corporate email and web site depends on your DNS service being always available. However, for this very reason, attacks on DNS services by hackers are more and more common … we see them or hear about them at least once every few months these days. How do you prevent these attacks on DNS from crippling your business services?

Any time you register a domain name, you are required to provide valid contact information for the owner of the domain. This information is published and made publically available in the “WHOIS” database. Anyone can look there to see who owns the domain and to contact the domain owner if necessary.

Private Domain Registration, or WHOIS Masking, or contact privacy, is a service offered by some domain registrars where they will either (a) not publish the domain owner’s contact details, or will (b) publish “masked” details — i.e. details that point to anonymous names and addresses at the registrar.