Apache log a url
Domain Keys vs DKIM
Domain Keys vs DKIM
DomainKeys is an authentication and validation technique for email. This blog article seeks to explain more about the underlying issues of this technology than the technology itself. However, the technology will also be explained.
Domain Keys
DomainKeys is a PGP-like protocol for validating and authenticating an email. PGP stands for Pretty Good Privacy. It is a system where you create a public and private key. You keep your private key private and give your public key to your friends. So, you encrypt your data with your private key and your friends can decrypt your message with your public key. This prevents prying eyes from seeing what’s in the data.
Domain Keys takes this idea one step further. Instead of encrypting the email, it encrypts the email headers and creates a hash value from that encryption. The hash value is placed in the header of the email. When a site receives an email, it locates the public key (located in the DNS server for the user listed in the From: line of the email) and encrypts the email once again to compare the hash value. If the hash values match after the second encryption test, the email passes validation.
So, what exactly does this do for me?
The validation test proves several things:
- The domain listed in the From: line is valid
- The domain listed in the From: line authorized / sent the email
- The email has remain unchanged since creation
- The email is not spoofed
So, the recipient can conclude that they can trust that the email is valid and is actually from the person it claims to be from. It also means the email has not been altered in transit.
Domain Keys and DKIM
There are two methodologies to this this PGP-like technique. DomainKeys is the branded name created by Yahoo (to which Yahoo has a few patents pending and/or granted surrounding this technology). Yahoo created this technique to combat spam. DKIM, on the other hand, stands for DomainKeys Identified Mail. Yes, this is confusing. It sounds like the same thing, but it isn’t. DKIM is a similar, but not identical, technique to validate email. DKIM was created by the internet community (IETF) at large in response to Yahoo’s DomainKeys. DomainKeys from Yahoo was created based on a Yahoo License agreement. The Internet community balked at that license and decided to create a separate design that works similarly, but that isn’t under Yahoo’s licensing methodology.
Unfortunately, the DKIM community failed. Yahoo’s lawyers have stated that parts of the DKIM specification do, in fact, utilize patents that Yahoo holds. Because of this legal situation surrounding DKIM, what the DKIM creators had hoped to accomplish (by separating it from Yahoo) hasn’t worked.
Fracture
Because Yahoo owns DomainKeys outright based on several patents and it also appears to claim ownership of parts of the implementation of DKIM, neither is safe to use if Yahoo chooses to require licensing fees. So, it appears that neither DKIM nor DomainKeys is gaining wide acceptance yet as a result. Unfortunately, it is unclear just how many sites are using DKIM or DomainKeys in production to validate emails. There are, however, some ISPs such as Gmail and, of course, Yahoo who are using DomainKeys. Gmail is also using DKIM.
Because Yahoo is the creator of DomainKeys, they have a vested interest in this validation methdology. It is still unclear if Yahoo is actually validating emails that have been signed with DKIM. Yahoo’s outbound servers, however, do appear to use DKIM to sign outbound emails.
What does Domain Keys or DKIM buy you?
Besides email authentication, DomainKeys is a stepping stone to getting access to more Yahoo services. For example, if you would like your IP address to be whitelisted with Yahoo, you will need to first set up DomainKeys on your domain. Note that you must set up DomainKeys on the domain that you intend to use in the ‘From’ line of your emails. If you change the From domain, then you will need to set up DomainKeys for each domain you intend to use.
As far as DKIM goes, it doesn’t appear that there’s much that DKIM buys you yet. Some places are utilizing it, but many more are not. Both DomainKeys and DKIM are somewhat cumbersome to implement, so this explains why some sites haven’t begun using it. Certain DNS hosting services, such as GoDaddy’s Total DNS, do not support the necessary TXT record size to implement DomainKeys or DKIM. Lack of proper DNS support can prevent setting up these validation technologies.
Overall
These technologies can aid recipients in distinguishing actual valid emails from phishing attempts. The problem, though, is the licensing aspects, the ease of setting it up and the overall benefit. As an email marketer, you should determine if the sites you plan to email support DKIM and/or DomainKeys. Most large ISPs support some form of DKIM/DomainKeys, but it isn’t always the inbound portions that are supported (which matter to the email marketer). Yahoo specifically supports DomainKeys, but it is as yet unclear if they are supporting DKIM on inbound email. Gmail supports DomainKeys and DKIM on outbound and inbound email according to references found on the Internet.
Corporations, on the other hand, are probably not supporting either DomainKeys or DKIM just strictly due to licensing issues that could result. If DKIM is encumbered with Yahoo’s patented techniques, it’s just a matter of time before Yahoo decides to start requiring paid licenses to use the technologies. With Microsoft looking at buying Yahoo once again, it may not be safe to invest in DKIM or DomainKeys for corporate use.
ip_conntrack: table full, dropping packet
Last week, I found myself with a server under low load, but it couldn’t make or receive network connections. When I ran dmesg, I found the following line repeating over and over:
ip_conntrack: table full, dropping packet
I’d seen this message before, but I headed over to Red Hat’s site for more details. It turns out that the server was running iptables, but it was under a very heavy load and also handling a high volume of network connections. Generally, the ip_conntrack_max is set to the total MB of RAM installed multiplied by 16. However, this server had 4GB of RAM, but ip_conntrack_max was set to 65536:
# cat /proc/sys/net/ipv4/ip_conntrack_max 65536
I logged into another server with 1GB of RAM (RHES 5, 32-bit) and another with 2GB of RAM (RHES 4, 64-bit), and both had ip_conntrack_max set to 65536. I’m not sure if this is a known Red Hat issue, or if it’s just set to a standard value out of the box.
If you want to check your server’s current tracked connections, just run the following:
# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count To make this persistent you have to add a line like ‘net.ipv4.ip_conntrack_max=131072′ to /etc/sysctl.conf
Recent Comments