Protecting Your Privacy IS our business



Icon Buttons
Security
Egismail Security Features

SSL 

SSL: Your Key to E-commerce Security

The e-commerce business is all about making money and then finding ways to make more money. Of course, it's hard to make (more) money, when consumers don't feel safe executing a transaction on your Web site. That's where SSL (Secure Socket Layer) comes into play. Understanding how SSL affects e-commerce business can also potentially help you to unlock (more) money from your customers.

What is SSL?
Since its introduction in 1994, SSL has been the de facto standard for e-commerce transaction security, and it's likely to remain so well into the future.

SSL is all about encryption. SSL encrypts data, like credit cards numbers (as well other personally identifiable information), which prevents the "bad guys" from stealing your information for malicious intent. You know that you're on an SSL protected page when the address begins with "https" and there is a padlock icon at the bottom of the page (and in the case of Mozilla Firefox in the address bar as well).

Your browser encrypts the data and sends it to the receiving Web site using either 40-bit or 128-bit encryption. Your browser alone cannot secure the whole transaction and that's why it's incumbent upon e-commerce site builders to do their part. EgisMail uses 128-bit encryption.

SSL Certificates
At the other end of the equation, and of greatest importance to e-commerce site builders, is the SSL certificate. The SSL certificate sits on a secure server and is used to encrypt the data and to identify the Web site. The SSL certificate helps to prove the site belongs to who it says it belongs to and contains information about the certificate holder, the domain that the certificate was issued to, the name of the Certificate Authority who issued the certificate, the root and the country it was issued in.

SSL certificates come in 40-bit and 128-bit varieties, however, 40-bit encryption has been hacked. As such, we strongly recommend that you look for vendors using 128-bit certificates, like EgisMail, or if you are looking for a certificate consider getting a 128-bit certificate.

Though there is a wide variety of ways in which you could potentially acquire a 128-bit certificate, there is one key element that is often overlooked in order for full two-way 128-bit encryption to occur. According to SSL certificate vendor VeriSign, in order to have 128-bit encryption you need a certificate that has SGC (server grade cryptography) capabilities.

Key Terms To Understanding SSL

SSL
Short for Secure Sockets Layer, a protocol developed by Netscape for transmitting private documents via the Internet. SSL works by using a private key to encrypt data that's transferred over the SSL connection.

digital certificate
An attachment to an electronic message used for security purposes. The most common use of a digital certificate is to verify that a user sending a message is who he or she claims to be, and to provide the receiver with the means to encode a reply.

encryption
The translation of data into a secret code. Encryption is the most effective way to achieve data security.


DRM
Short for digital rights management, a system for protecting the copyrights of data circulated via the Internet or other digital media by enabling secure distribution and/or disabling illegal distribution of the data.

Domain Keys

Domain Keys: Proving and Protecting Email Sender Identity

Email spoofing - the forging of another person's or company's email address to get users to trust and open a message - is one of the biggest challenges facing both the Internet community and anti-spam technologists today. Without sender authentication, verification, and traceability, email providers can never know for certain if a message is legitimate or forged and will therefore have to continually make educated guesses on behalf of their users on what to deliver, what to block, and what to quarantine, in the pursuit of the best possible user experience.

Domain Keys is a technology proposal that can bring black and white back to this decision process by giving email providers a mechanism for verifying both the domain of each email sender and the integrity of the messages sent (i.e,. that they were not altered during transit). And, once the domain can be verified, it can be compared to the domain used by the sender in the From: field of the message to detect forgeries. If it's a forgery, then it's spam or fraud, and it can be dropped without impact to the user. If it's not a forgery, then the domain is known, and a persistent reputation profile can be established for that sending domain that can be tied into anti-spam policy systems, shared between service providers, and even exposed to the user.

For well-known companies that commonly send transactional email to consumers, such as banks, utilities, and e-commerce services, the benefits of verification are more profound, as it can help them protect their users from "phishing attacks" - the fraudulent solicitation for account information, such as credit card numbers and passwords, by impersonating the domain and email content of a company to which users have entrusted the storage of these data. For these companies, protecting their users from fraud emails translates directly into user protection, user satisfaction, reduced customer care costs, and brand protection.

For consumers, such as EgisMail! Mail users or a grandparent accessing email through a small mid-western ISP, industry support for sender authentication technologies will mean that they can start trusting email again, and it can resume its role as one of the most powerful communication tools of our times.

How Domain Keys Works

DomainKeys Flow Diagram

How it Works - Sending Servers

There are two steps to signing an email with Domain Keys:

  1. Set up: The domain owner (typically the team running the email systems within a company or service provider) generates a public/private key pair to use for signing all outgoing messages (multiple key pairs are allowed). The public key is published in DNS (Domain Name Servers), and the private key is made available to their Domain Key-enabled outbound email servers. This is step "A" in the diagram to the right.
  2. Signing: When each email is sent by an authorized end-user within the domain, the Domain Key-enabled email system automatically uses the stored private key to generate a digital signature of the message. This signature is then pre-pended as a header to the email, and the email is sent on to the target recipient's mail server. This is step "B" in the diagram to the right.

How it Works - Receiving Servers

There are three steps to verifying a signed email:
 

  1. Preparing: The Domain Keys-enabled receiving email system extracts the signature and claimed From: domain from the email headers and fetches the public key from DNS for the claimed From: domain. This is step "C" in the diagram to the right.
  2. Verifying: The public key from DNS is then used by the receiving mail system to verify that the signature was generated by the matching private key. This proves that the email was truly sent by, and with the permission of, the claimed sending From: domain and that its headers and content weren't altered during transfer.
  3. Delivering: The receiving email system applies local policies based on the results of the signature test. If the domain is verified and other anti-spam tests don't catch it, the email can be delivered to the user's inbox. If the signature fails to verify, or there isn't one, the email can be dropped, flagged, or quarantined. This is step "D" in the diagram on the right.

In general, the MTA (Mail Transport Agent: EgisMail is a MTA) expects that Domain Keys will be verified by the receiving email servers. However, end-user mail clients could also be modified to verify signatures and take action on the results.
 

Frequently Asked Questions

How will this help stop spam?

Several ways. First, it can allow receiving companies to drop or quarantine unsigned email that comes from domains that are known to always sign their emails with Domain Keys, thus impacting spam and phishing attacks. Second, the ability to verify sender domain will allow email service providers to begin to build reputation databases that can be shared with the community and also applied to spam policy. For example, one ISP could share their "spam vs. legit email ratio" for the domain www.example.com with other ISPs that may not yet have built up information about the credibility and "spamminess" of email coming from www.example.com. Last, by eliminating forged From: addresses, we can bring server-level traceability back to email (not user-level - we believe that should be a policy of the provider and the choice of the user). Spammers don't want to be traced, so they will be forced to only spam companies that aren't using verification solutions.

How will this help stop fraud/phishing attacks?

Companies that are susceptible to phishing attacks can sign all of their outgoing emails with Domain Keys and then tell the world this policy so that email service providers can watch and drop any messages that claim to come from their domain that are unsigned. For example, if the company www.example.com signs all of its outgoing email with Domain Keys, EgisMail! can add a filter to its SpamGuard system that drops any unsigned or improperly signed messages claiming to come from the domain www.example.com, thus protecting tens of millions of example.com's customers or prospective customers from these phishing attacks.

Won't spammers just sign their messages with Domain Keys?

Hopefully! If they do, they'll make it easier for the Internet community to isolate and drop/quarantine their messages using the methods described above in "How will this help stop spam?" Eliminating the uncertainty of "did this email really come from the domain example.com?" will facilitate a whole range of anti-spam solutions.

What does Domain Keys verify?

Domain Keys examines the From: and Sender: headers' domain to protect the user and deliver the best possible user experience. Desktop mail clients like Microsoft Outlook show these headers in their user interfaces. If the user establishes their trust based on the these domains, then so should any system built to verify whether that trust is warranted.

Why sign the entire message?

Domain Keys signs the entire message to allow the receiving server to also verify that the message wasn't tampered with or altered in transit. By signing the headers and the body, Domain Keys makes it impossible to reuse parts of a message from a trusted source to fool users into believing the email is from that source.
 

Does Domain Keys encrypt each message?

Domain Keys does not encrypt the actual message - it only pre-pends a "digital signature" as a header.

What public/private key technology is used for Domain Keys?

Domain Keys currently uses an RSA (RSA is an algorithm for public-key encryption) public/private key method. The key length is decided by the domain owner.

Who issues the public/private key pairs required by Domain Keys?

The domain owner, or an agent or service provider acting on their behalf, should generate the key pairs that are used for their Domain Keys-enabled mail system.

Does Domain Keys require signing of the public key by a Certificate Authority (CA)?

Domain Keys does not require a CA (Certificate Authority). Much like a trusted Notary Public, Certificate Authorities are used in public/private key systems to sign, or "endorse," public keys so that the external users of public keys can know that the public keys they receive are truly owned by the people who sent them. Since Domain Keys leverages DNS as the public key distribution system, and since only a domain owner can publish to their DNS, external users of Domain Keys know that the public key they pull is truly for that domain. The CA is not needed to verify the owner of the public key - the presence in that domain's DNS is the verification. However, it is possible that Certificate Authorities may become a valuable addition to the Domain Keys solution to add an even greater level of security and trust.

How are Domain Keys revoked?

Domain Keys allows for multiple public keys to be published in DNS at the same time. This allows companies to use different key pairs for the various mail servers they run and also to easily revoke, replace, or expire keys at their convenience. Thus, the domain owner may revoke a public key and shift to signing with a new pair at any time.

Why not just use S/MIME?

S/MIME was developed for user-to-user message signing and encryption and by design should be independent of the sending and receiving servers. We believe that Domain Keys should be a natural server-to-server complement to S/MIME and not a replacement. Additionally, since S/MIME is used by many security-conscious industries, we need to ensure that the two technologies can work together without breaking each other. Finally, S/MIME is not yet supported by many of the email services, client software, and server software used across the Internet, and in EgisMail's opinion, that standardization effort would be much more difficult than the standardization of Domain Keys.

How does Domain Keys work with mailing lists?

Mailing lists that do not change the content or re-arrange or append headers will be Domain Key compatible with no changes required. Mailing lists that change the message and headers should re-sign the message with their own private key and claim authorship of the message.

Who implements Domain Keys?

Domain Keys will typically be implemented/enabled by the team within a company, ISP, or email service provider that deploys and runs the incoming and outgoing mail servers. Some companies may have service providers that handle their email. As MTA (Mail Transport Agent, EgisMail is a MTA) vendors add support for Domain Keys to their products, the implementation of Domain Keys will become simpler.

Encrypted Log-in

Encrypted Log-in is a feature that adds layered security to our site. If you select the checkbox to encrypt the login a second encryption engine is used to hash the login as well. That means the login is encrypted as well as the SSL of the site encrypting the session. The result is that the encryption of the session is encrypted again for the login. This greatly multiplies the security of your account access and helps ensure that your account is not compromised.