Browse by Tags
All Tags »
Authentication (RSS)
Sometimes an end user wants to flag a specific sender as a safe sender, that is, they always want messages from that user to go to their inbox. You've probably seen this in some newsletters where they say at the top or bottom of the message to please
Read More...
In my other post in a Q&A excerpt with Dave Crocker by Investor's Business Daily, I'd like to now respond to some of my selected quotes. Crocker: You have to create what I call a trust overlay to the existing e-mail system. Existing senders and receivers
Read More...
We finally got around to deploying all of our new features from our latest release. As I explained a couple of months ago, I created a hybrid of SPF and SenderID in response to customer demand. I called it TMA, or Terry's Message Authentication.
Read More...
The other day I was reading Investors Business Daily and came across an article whose title you see in the subject line of this blog post. The article is a Q&A Dave Crocker of BrandenBurg InternetWorking. If you're like me and too lazy
Read More...
As I said earlier, I needed to come up with an authentication mechanism that protected the From: or Sender: address in the message headers. But, I did not want to replace SPF with SenderID. So, I came up with another solution which I call TMA. I would
Read More...
I'd now like to post something about the inspiration for this whole series on authentication. I'm not done with DomainKeys, I still have to post a little bit on DKIM and one other authentication mechanism, and then this series will be done.
Read More...
Canonicalization is the process of preparing a message for signing. This process is necessary because of the way email is handled in transit by various mail servers. For example, some mail relayers handle white space and line wraps just fine, others do
Read More...
Let's plow through a few real life examples. Here's an actual DomainKey Signature: Example 1 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type;
Read More...
This post will again be a paraphrase of that which is found in RFC 4870 . Now that we have seen how public keys are stored in DNS, we will next look at how a signing server generates the message signature. The signature of the email is stored in the "DomainKey-Signature:"
Read More...
Now that we have an overview of how DomainKeys works, we're going to look at how a service using DomainKeys generates a DomainKeys signature. When a receiving email server gets the message and sees that there is a DomainKeys header, it has to retrieve
Read More...
Now that we understand how digital signatures work, let's take a look at DomainKeys. Like SPF and SenderID, DomainKeys is a mechanism of sender authentication. DomainKeys uses public key encryption to authenticate messages. It works in the following way
Read More...
I'm taking a quick timeout from my series on explaining Sender Authentication to post some quick stats on authentication. I took an 8-hour snapshot of our logs to collect some statistics. I started tracking how often senders use SPF, DomainKeys and DKIM
Read More...
We've seen encryption, secret key encryption and public key encryption. Public key encryption allows a sender to encrypt the contents of the message and have only the intended recipient read it. They do this by encrypting with the public key and decrypting
Read More...
The basic idea behind secret key encryption is the following: You don't have to keep the algorithm a secret. You do need to keep the key a secret. To increase the security of the contents, you lengthen the size of the key. This is all well and good, except
Read More...
We saw in my previous post that substitution ciphers are a method of encoding a message such that its contents are unintelligible (much like the ramblings of many of the presidential candidates), and they are fairly easy to break with computers that can
Read More...
