SpamAssassin in Sendmail

Sendmail is software for handling mail delivery (MTA). When installing FreeBSD the other two MTAs you can choose from are PostFix and Exim but I chose Sendmail as that's the one I'm most familiar with. The following procedures can only be used for Sendmail.

In order to use SpamAssassin and ClamAV with Sendmail there are various mechanisms which need to be defined in sendmail.cf (the configuration file). Also, definitions must be added to use RBLs (Real-time Black Lists - lists of hostnames, domains, mail addresses etc. found to be used by spammers that can be used to reject spam from these spammers).

Usually you do not directly modify sendmail.cf but rather modify the macro file (m4's .mc file format) which when parsed by m4 will generate sendmail.cf.

When you configure Sendmail on FreeBSD as described below, a macro file with its name as the server's hostname will be automatically created. Do the following:

cd /etc/mail
make

then, for example, if your machine is called mail.example.jp then a file called mail.example.jp.mc will be created in that directory. From here on I will use mail.example.jp.mc to refer to the sendmail.mc macro file as we add various configurations below, eventually leading up to the creation of the final Sendmail configuration file, sendmail.cf.

Once mail.example.jp.mc has been created it'll not be overwritten if you run make again so when you want to add/modify some configuration, edit the file directly.

0) Basic configuration

First we define what kind of e-mail address formats your mail server will receive.

The e-mail address formats mail.example.jp will receive are:

test@example.jp
test@mail.example.jp

We create a file called /etc/mail/local-host-names and add the following:

example.jp
mail.example.jp

mail.example.jp is optional because it has the same domain as the first entry (example.jp). Please make sure that there are no inconsistencies between this file and the DNS MX settings for example.jp. Regardless of which e-mail address format is used, all mail will be delivered to mail.example.jp.

Next, create /etc/mail/relay-domains and add the following to define who is allowed to send mail from this server:

example.jp
192.168.0

The second line allows any machines on the local 192.168.0.0/24 network (assuming the mail server has global and local network interfaces) to relay e-mail through this server. Change this value according to your local network.

With the above configuration basic mail delivery can now be performed.


1) Add SpamAssassin and ClamAV settings

cd /etc/mail
vi mail.example.jp.mc 

and add the following:

INPUT_MAIL_FILTER(`spamassassin',`S=local:/var/run/spamass-milter.sock, F=, T=C:15m;S:4m;R:4m;E:10m')dnl
INPUT_MAIL_FILTER(`clmilter', `S=local:/var/run/clamav/clmilter.sock, F=, T=S:4m;R:4m')dnl
define(`confINPUT_MAIL_FILTERS', `clmilter,spamassassin')dnl

2) Settings related to reverse DNS lookups

Here we configure Sendmail to reject mail sent from hosts with no reverse DNS lookup. By doing this we're able to avoid most spam from Chinese and Korean servers which don't have reverse DNS lookup entries.

A side effect of this setting though is that mail from legit hosts maybe rejected due to bad server configuration. There are some people who are against setting their SMTP to use this mechanism. Do some research on Google yourself first before deciding if you want to set this on your mail server.

Add these settings to mail.example.jp if you want to ONLY reject hosts with no reverse DNS lookup.

OR if you want to reject both the above and hosts whose reverse DNS lookup and normal DNS lookup do not match then add these settings.

The tab characters must be preserved so be careful when copy/pasting.

If you want to be able to receive mail from hosts which do not have a reverse DNS lookup entry then you must not use these settings. Likewise, if you're likely to receive lots of legit mail from China and/or Korea (which have many such mail servers) you should avoid using these settings.


3) Setting up Sendmail RBLs

If an incoming mail is marked as spam by SpamAssassin the mail will still be delivered (and left for something else to filter it) but if you enable the RBL features in Sendmail, as we do below, then mail from a host that is rejected because of some RBL policy will not be delivered. Please keep this in mind when deciding whether to use the following.

There are various RBLs out there, we chose to use the following 4. Add this to mail.example.jp.mc:

FEATURE(dnsbl,`bl.spamcop.net')dnl
FEATURE(dnsbl,`sbl-xbl.spamhaus.org')dnl
FEATURE(dnsbl,`list.dsbl.org')dnl
FEATURE(dnsbl,`all.rbl.jp')dnl

Make sure the above lines come before MAILER(smtp) and MAILER(local) lines in mail.example.jp.mc.

There are many stories in Japanese mailing lists that too many legit addresses get registered in spamcop.net so if you are thinking on the safe side it would be okay to leave this line out.

The following 3 RBLs have not so good reputations , we don't recommend to use them.

BLARS
JAMM
SORBS

Sendmail's requests to the RBLs are done in the order listed in the configuration file. Even if all RBLs had exactly the same data, a culprit host would be rejected by the first RBL and the rejection would stop there. So only the rejection from the first RBL would be recorded in the Sendmail log file.

Just because you have a high number of RBLs configured it does not mean your server will be effective in avoiding spam. Unnecessary amounts of traffic and server load will be generated if you have too many RBLs defined so please choose an amount suitable for your mail server's purpose and intended use. Once all your configuration is done, run your server for a while, look at the mail log and see if there are one or more configured RBLs which don't appear much (or at all). This would indicate that they're not doing much in the way of contributing to rejecting hosts, most probably because they've got data in their databases similar (or the same) as one of the RBLs you've configured higher up in the list which do the rejecting first. Determine which one(s) are so and delete them.

So far, the updates we've added to mail.example.jp.mc are here. The tab characters must be preserved so make sure your browser doesn't break them if you copy/paste.

MAILER(local) and MAILER(smtp) were already in mail.example.jp.mc before we started changing it. It's important that the RBL definitions (FEATURE(...) etc) come before the MAILER(...) definitions. The order is critical. The stuff below LOCAL_RULESETS are the definitions to only reject mail from hosts which don't have a reverse DNS lookup and not when the normal and reverse DNS entries do not match.


4) Generating sendmail.cf

After the above configuration steps have been completed:

cd /etc/mail
make

and a file called mail.example.jp.cf will be made. This will now become our new Sendmail configuration file. Copy the file as follows:

cp mail.example.jp.cf sendmail.cf

Set up and secure Apache web server under CentOS

 Apache is still the most popular HTTP server on the Web. Let's see how to set up Apache securely on a CentOS server to host multiple virtual websites.

Apache is available in official CentOS repositories, so you can install it as root with the command yum install httpd. Start the httpd service and make sure that it is added to the system startup settings:

service httpd restart
chkconfig httpd on

You can verify whether Apache is running with the command #netstat -tulpn | grep httpd. If it's running, you should see output similar to

tcp       0      0 :::80                       :::*                       LISTEN      PID/httpd

By default, Apache serves TCP traffic on port 80 for HTTP and port 443 for the secure HTTPS protocol. Apache's initialization script is at /etc/init.d/httpd, while configuration files are stored under /etc/httpd/. By default the document root directory is /var/www/, while log files are stored under /var/log/httpd/ directory. We'll store files for our primary site in /var/www/html, and virtual host files in /var/www/site-a and /var/www/site-b.

Before working on the primary site, make sure that the server's host name is defined. Edit /etc/httpd/conf/httpd.conf, look for ServerName, and modify the line:

ServerName www.example.com:80

Save the file and restart the service.

Every website needs an index file, which generally contains both text and code written in HTML, PHP, or another web scripting language. For this example just create the index file manually at /var/www/html/index.html. You can then access the primary site by pointing a browser to www.example.com.

Hosting multiple sites

Sometimes you might want to host multiple sites on the same Apache server. For example, if your company needs separate websites for each department or if you want to set up multiple web applications, hosting each site on separate physical servers may not be the best option. In such cases you can host multiple sites on a single Apache server, and each of the sites can run with its own customized settings.

Apache supports name-based and IP-based virtual hosting. Name-based virtual hosts are disabled by default. To enable name-based virtual hosting, edit Apache's httpd.conf configuration file and uncomment the line with NameVirtualHost:

NameVirtualHost *:80

This parameter tells Apache to enable name-based hosting and listen on port 80 for any possible name. You can use a specific name instead of the asterisk wildcard character.
Each virtual host needs a valid DNS entry to work. To set up DNS on a production site, you must add DNS records in the authoritative DNS server. Generally, the primary website should be configured using an A record and the virtual hosts should be configured using CNAME records.

Enabling virtual hosts overrides the primary website unless you declare the primary website as a virtual host as well. The first declared virtual host has the highest priority. Any site that does not have a proper definition defaults to the first defined virtual host, so if site-a.example.com or site-b.example2.com are not properly configured, or if people try to access site-c.example.com and get directed to this Apache server, they will view www.example.com. Edit /etc/httpd/conf/httpd.conf and make sure that ServerName www.example.com is the first virtual host defined:

## start of virtual host definition ##
<VirtualHost *:80>
 ServerAdmin admin@example.com
 DocumentRoot /var/www/html/ 
 ServerName www.example.com
 ## Custom log files can be used. Apache will create the log files automatically. ##
 ErrorLog logs/www.example.com-error_log
 CustomLog logs/www.example.com-access_log common
</VirtualHost>
## end of virtual host definition ##

To set up the other virtual hosts, first create index.html files for the sites at /var/www/site-a and /var/www/site-b, then add the virtual host definitions to httpd.conf, and finally restart the httpd service:

## start of virtual host definition ##
<VirtualHost *:80>
 ServerAdmin admin@example.com
 DocumentRoot /var/www/site-a/
 ServerName site-a.example.com
 ## Custom log files can be used. Apache will create the log files automatically. ##
 ErrorLog logs/site-a.example.com-error_log
 CustomLog logs/site-a.example.com-access_log common
</VirtualHost>
## End of virtual host definition ##

## start of virtual host definition ##
<VirtualHost site-b.example2.com:8000>
 ServerAdmin admin@example2.com
 DocumentRoot /var/www/site-b/
 ServerName site-b.example2.com
 ## Custom log files can be used. Apache will create the log files automatically. ##
 ErrorLog logs/site-b.example2.com-error_log
 CustomLog logs/site-b.example2.com-access_log common
</VirtualHost>
## End of virtual host definition ##

In some cases, system administrators set up web applications on random ports to increase the security of the services, and users have to manually add the port in the URL to gain access to the web site. We've done that here – we set up site-b to run on port 8000. We therefore have to modify the Apache configuration file, adding a Listen line to httpd.conf:

Listen 80
Listen 8000

Since this is the first virtual host defined under port 8000, any other virtual host running on 8000 that lacks a proper definition will default to site-b.example2.com:8000.

Restart the Apache service for the changes to take effect.

Hardening the server against flooding attacks

Though they may live behind a firewall, HTTP servers generally are open to the public, which makes them available to attackers as well, who may attempt denial of service (DoS) attacks by flooding a server with requests. Fully hardening both Linux and Apache against attacks is beyond the scope of this article, but one way to secure a web server against a flood of requests is to limit the number of active connections for a source IP address, which you can do by changing a setting in the iptables packet filter. Although you should set the number of active sessions for a production server based on actual traffic, in this tutorial we will limit the number of concurrent connections to around 250 per five minutes for each source IP address:

service iptables stop
rmmod xt_recent
modprobe xt_recent ip_pkt_list_tot=255
service iptables start

rmmod removes the module xt_recent from the kernel. modprobe adds the module to the kernel again with modified parameters, changing the value of ip_pkt_list_tot from its default of 100 to 255.

With the updated parameter, we will create a script that modifies iptables to institute some basic security best practices. Feel free to adapt it to your needs, but make sure that the rules are compatible with your organization's security policy.

## Flush all old rules so that we can start with a fresh set ##
iptables -F

## Delete the user-defined chain 'HTTP_WHITELIST' ##
iptables -X HTTP_WHITELIST

## Create the chain 'HTTP_WHITELIST' ##
iptables -N HTTP_WHITELIST

## Define all new HTTP connections as 'HTTP' for future use within iptables ##
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set --name HTTP

## Send all new HTTP connections to the chain 'HTTP_WHITELIST' ##
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j HTTP_WHITELIST

## Log all HTTP connections. Limit connections to 250 per five minutes; drop any exceeding the limit ##
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 300 --hitcount 250 --rttl --name HTTP -j ULOG --ulog-prefix HTTP_flood_check
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 300 --hitcount 250 --rttl --name HTTP -j DROP

Make the script executable, then run it:

chmod +x firewall-script
./firewall-script

You might also want to add some trusted IP addresses or subnet to be excluded from the iptables check. For that, create a whitelisting script:

#!bin/bash
TRUSTED_HOST = 192.168.1.3
iptables -A HTTP_WHITELIST -s $TRUSTED_HOST -m recent --remove --name HTTP -j ACCEPT

Again, make the script executable, then run it:

chmod +x whitelist-script
./whitelist-script

Now the firewall will allow no more than 250 concurrent connections per five minutes to the Apache server for each source IP address, while trusted IP addresses can have an infinite number of parallel connections.

OpenSSL heartbeat information disclosure

Overview

OpenSSL 1.0.1 contains a vulnerability that could disclose private information to an attacker.

Description

OpenSSL versions 1.0.1 through 1.0.1f contain a flaw in its implementation of the TLS/DTLS heartbeat functionality (RFC6520). This flaw allows an attacker to retrieve private memory of an application that uses the vulnerable OpenSSL libssl library in chunks of 64k at a time. Note that an attacker can repeatedly leverage the vulnerability to retrieve as many 64k chunks of memory as are necessary to retrieve the intended secrets. The sensitive information that may be retrieved using this vulnerability include: Primary key material (secret keys) Secondary key material (user names and passwords used by vulnerable services) Protected content (sensitive data used by vulnerable services) Collateral (memory addresses and content that can be leveraged to bypass exploit mitigations) Please see the Heartbleed website for more details. Exploit code for this vulnerability is publicly available. Any service that supports STARTLS (imap,smtp,http,pop) may also be affected.

Impact

By attacking a service that uses a vulnerable version of OpenSSL, a remote, unauthenticated attacker may be able to retrieve sensitive information, such as secret keys. By leveraging this information, an attacker may be able to decrypt, spoof, or perform man-in-the-middle attacks on network traffic that would otherwise be protected by OpenSSL.

Solution

Apply an update This issue is addressed in OpenSSL 1.0.1g. Please contact your software vendor to check for availability of updates. Any system that may have exposed this vulnerability should regenerate any sensitive information (secret keys, passwords, etc.) with the assumption that an attacker has already used this vulnerability to obtain those items. Reports indicate that the use of mod_spdy can prevent the updated OpenSSL library from being utilized, as mod_spdy uses its own copy of OpenSSL. Please see https://code.google.com/p/mod-spdy/issues/detail?id=85 for more details.

Disable OpenSSL heartbeat support This issue can be addressed by recompiling OpenSSL with the -DOPENSSL_NO_HEARTBEATS flag. Software that uses OpenSSL, such as Apache or Nginx would need to be restarted for the changes to take effect. Use Perfect Forward Secrecy (PFS) PFS can help minimize the damage in the case of a secret key leak by making it more difficult to decrypt already-captured network traffic. However, if a ticket key is leaked, then any sessions that use that ticket could be compromised. Ticket keys may only be regenerated when a web server is restarted.

Vendor Information 

Vendor	Status	Date Notified	Date Updated
Check Point Software Technologies	Affected	07 Apr 2014	08 Apr 2014
Debian GNU/Linux	Affected	07 Apr 2014	08 Apr 2014
Fedora Project	Affected	07 Apr 2014	08 Apr 2014
FreeBSD Project	Affected	07 Apr 2014	08 Apr 2014
Gentoo Linux	Affected	07 Apr 2014	08 Apr 2014
Mandriva S. A.	Affected	07 Apr 2014	07 Apr 2014
NetBSD	Affected	07 Apr 2014	08 Apr 2014
OpenBSD	Affected	07 Apr 2014	08 Apr 2014
OpenSUSE	Affected	-	08 Apr 2014
Red Hat, Inc.	Affected	07 Apr 2014	08 Apr 2014
Slackware Linux Inc.	Affected	07 Apr 2014	07 Apr 2014
Ubuntu	Affected	07 Apr 2014	07 Apr 2014
Infoblox	Not Affected	07 Apr 2014	08 Apr 2014
m0n0wall	Not Affected	07 Apr 2014	08 Apr 2014
Peplink	Not Affected	07 Apr 2014	08 Apr 2014

Ubuntu One - Cloud storage replacement

Many of us had hoped it was an April Fool's prank. But Ubuntu One will, in fact, no longer be available as of June 1, 2014 and all data will be wiped July 31, 2014. This will leave a great number of Ubuntu users without a cloud service. Fear not, intrepid users, there are plenty of cloud services and tools available – each with native Linux clients – ready and willing to take your Ubuntu One data and keep it in the cloud.
But out of the many services, which might be the best to suit your needs? Given what happened with Ubuntu One, many are growing leery of using services hosted by smaller companies (who could easily fold in the coming years). With larger companies making it impossible for the small guys to compete, the best bet for long-term cloud storage is to go with the proven companies with a track record of keeping the lights on and the data safe. With that in mind, which of the large companies work best on the Linux platform? Let's take a look.

Google Drive (with Insync)

Because I have become more and more reliant on Google Drive, the obvious solution for me was to shift all of my Ubuntu One data to Google's cloud service. After seeing the prices (100GB for $1.99/month), it was a no brainer. There was one catch – syncing. For reasons unbeknown to me, a native Linux has yet to appear from behind the magic curtain that is Google. No problem...a company called Insync has us covered. With a robust and reliable native client for Linux, Insync easily syncs your Google Drive data onto your choice of location within your Linux box.
The Insync client is one of the best clients available to the Linux desktop. It does have a price associated with it, but for anyone looking to sync their Google Drive account with Linux, it is very much worth it. Pricing ranges from a one-time $15.00 for a single consumer account license to a business license at $15.00 per account, per year.
Installation is simple. I will walk you through the process on the Ubuntu 13.10 platform (Insync is available for Ubuntu, Debian, and Fedora). The one requirement for Insync is Python.

1. Download the .deb file into your ~/Downloads directory
   
2. Open a terminal window
   
3. Issue the command cd Downloads
   
4. Issue the command sudo dpkg -i insync_XXX_xxx.deb (Where XXX is the release number and xxx is the architecture)
   
5. Type your sudo password and hit Enter
   
6. Hit 'y' when prompted
   
7. Allow the installation to complete.
   

Once the command line installation is complete, it's time to walk through the GUI wizard. This will open up automatically. In the resulting window, click Start Insync.
You'll be required to log into your Google account to complete it and then give Insync permission to work with your Google Drive account. Click Accept, when prompted, and then click Start syncing. The synced folder will be named after the address associated with your Gmail account and will reside in your home directory. If you want to relocate this folder, click Advanced setup and you can place that folder anywhere you like. In the Advanced setup, you can also give your synced folder a different name and make sure all Google Docs are not automatically converted. Before the wizard is complete, you will be asked if you want to integrate Insync with Nautilus. I highly recommend you do this, as it will make it incredibly easy to add folders to Insync with a simple right-click within Nautilus. To integrate, just click Yes when prompted (Figure 1).

You will then be prompted for your sudo password, so Insync can download and install the necessary components for Nautilus integration. Finally, click Done in the installer window and, when prompted, click Restart Nautilus.
When Insync is running you'll see an icon in the notification area. From there you can interact with the application to check status, pause, add accounts, and more.

Dropbox

This has been the de facto standard cloud storage for a long time – with good reason. It works with nearly everything. So you can be sure to have your data synced to all of your devices – regardless of platform. The downside of Dropbox is that it's costlier than Google Drive and you're boxed into a single folder. A free account will get your 2 GB of space and for $9.99/month you get 100 GB. Not much else needs to be said about Dropbox (as it has been covered extensively); but the installation of the client is fairly simple. You will first need to sign up for an account, or have a pre-existing account to log into. Once you have that information, do the following (we'll stick with Ubuntu):

1. Download the appropriate installer file for your platform into your ~/Downloads folder
   
2. Open up a terminal window
   
3. Issue the command cd Downloads
   
4. Issue the command sudo dpkg -i dropbox_XXX_xxx.deb (Where XXX is the release number and xxx is the architecture)
   
5. Type your sudo password and hit Enter
   
6. Allow the installation to complete
   
7. When prompted click the Start Dropbox button (Figure 2)
   

Now it's time to walk through the official Dropbox install Wizard. This is quite simple – it will first ask you for your account credentials (or, if you don't have an account, allow you to set one up). When prompted, log into your Dropbox account (from within the install wizard) and then tell Dropbox where to place the syncing folder. By default, the folder will be ~/Dropbox. You cannot change the name of the folder and you can only sync that one folder. You do get to choose which Dropbox sub-folders to sync (this can be helpful if you have a large Dropbox folder and a smaller SSD drive).
Once the installation is complete, you'll be prompted to restart Nautilus. Dropbox does have limited Dropbox integration. What it allows you to do is move a folder into your Dropbox folder – you cannot sync folders outside of Dropbox.
If you're not using Google Drive, Dropbox is one of the better solutions available, for the Linux desktop – especially if you use other platforms and want to sync data across every device.

ownCloud

Is a bit different from the competition in that it requires you to connect to your own ownCloud server. On the plus side, ownCloud is open source, so anyone can set up their own cloud server. The downside to that is you will need an IP address accessible to the outside world, in order to make use of this. If you have that available, ownCloud is an incredibly powerful solution that you control. Setting up an ownCloud server is beyond the scope of this article, but installing the client is simple (again, sticking with the Ubuntu platform):

1. Open up a terminal window
   
2. Issue the command sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/xUbuntu_13.10/ /' >> /etc/apt/sources.list.d/owncloud-client.list"
   
3. Issue the command sudo apt-get update
   
4. Issue the command sudo apt-get install owncloud-client
   
5. Enter your password when prompted and hit Enter.
   

After the install completes, issue the command owncloud and then enter the server address for your ownCloud 5 or 6 server. You will then be prompted for your username and password. Upon successful authentication, you can configure where you want your ownCloud folder to exist. Once you set that folder, click Connect and the ownCloud client will prompt you to either open the ownCloud folder or the ownCloud web interface. Click Finish and you're done.
The ownCloud client also has a notification icon that allows you to Sign in, quit, or go to the ownCloud settings. The ownCloud settings window (Figure 3) allows you to: 

• Add a folder
  
• Check storage usage
  
• Set up ignored files
  
• Modify your accounts
  
• Check activity
  
• Set ownCloud to launch at start
  
• Set up a proxy
  
• Limit bandwidth
  

If you want to install your own server, you can download it and install it from the ownCloud installer page. NOTE: The web installer is the easiest method for new users. If you don't want to setup your own server, there are plenty of ownCloud service providers available. Check out this page for a listing of supported service providers. Some of the plans (such as on OwnDrive) are free (1GB of space).
Ubuntu users need not fear the loss of Ubuntu One. With so many cloud services available – most of which offer native Linux clients – there are too many choices, ready to host your data, to be concerned. Give one of these options a try and see if they don't meet your needs.

Setup Postfix with Client connect -TLS support

SSL (Secure Sockets Layer) and its descendant TLS (Transport Layer Security) are the most widely used protocols for encrypting data that is exchanged between a server and a client. These protocols often use X.509 certificates and asymmetric cryptography.
STARTTTLS is another method of securing plain-text communication. This protocol also encrypts data with SSL or TLS, but with the same port as the plain-text protocols, instead of using separate ports for SSL/TLS-encrypted communications. For example, IMAP over STARTTLS uses the same port as IMAP (143), while IMAPS (IMAP over SSL) uses a separate port 993.

Certificates needed for TLS/SSL can be self-signed, signed by a free certification authority (e.g., CAcert) or signed by a commercial authority (e.g., VeriSign), and can be generated with utilities like OpenSSL. We are going to use a self-signed certificate in this tutorial.

Enable TLS Encryption for Postfix

A self-signed certificate can be created with the following command.

# openssl req -new -x509 -days 365 -nodes -out /etc/ssl/certs/postfixcert.pem -keyout /etc/ssl/private/postfixkey.pem

The above command requests a new certificate which is of type X.509, and remains valid for 365 days. The optional -nodes parameter specifies that the private key should not be encrypted. An output certificate file is saved as postfixcert.pem, and an output key file as postfixkey.pem .
All necessary values for the certificate can be given:

Country Name (2 letter code) [AU]:BD 
State or Province Name (full name) [Some-State]:Dhaka 
Locality Name (eg, city) []:Dhaka 
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:Example.tst 
Common Name (e.g. server FQDN or YOUR name) []:mail.example.tst 
Email Address []:sarmed@example.tst 

Now that the certificate is ready, necessary parameters are adjusted in postfix configuration file.

root@mail:~# vim /etc/postfix/main.cf

### STARTTLS is enabled ###
smtpd_tls_security_level = may 

smtpd_tls_received_header = yes 
smtpd_tls_auth_only = yes 

### loglevel 3 should be used while troubleshooting ###
smtpd_tls_loglevel = 1

### path to certificate and key file
smtpd_tls_cert_file = /etc/ssl/certs/postfixcert.pem 
smtpd_tls_key_file = /etc/ssl/private/postfixkey.pem 
smtpd_use_tls=yes 

Restart postfix to enable TLS.

root@mail:~# service postfix restart

At this point, postfix is ready to encrypt data to and from the server. More details about Postfix TLS support can be found in their official README.

Enable SSL Encryption for Dovecot

Configuring dovecot for encryption is similar to postfix.
First of all, a self-signed certificate is created with openssl:

# openssl req -new -x509 -days 365 -nodes -out /etc/ssl/certs/dovecotcert.pem -keyout /etc/ssl/private/dovecotkey.pem

The above command requests a new X.509 certificate which is valid for 365 days. -nodes is an optional parameter which specifies that the stored private key should not be encrypted. An output certificate file will be dovecotcert.pem, and an output key file will be dovecotkey.pem.
All necessary parameters need to be specified in the certificate:

Country Name (2 letter code) [AU]:BD
State or Province Name (full name) [Some-State]:Dhaka
Locality Name (eg, city) []:Dhaka
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:Example.tst
Common Name (e.g. server FQDN or YOUR name) []:mail.example.tst
Email Address []:sarmed@example.tst

Next, the path to the certificate is added in dovecot configuration.

root@mail:~# vim /etc/dovecot/conf.d/10-ssl.conf

ssl_cert = </etc/ssl/certs/dovecotcert.pem
ssl_key = </etc/ssl/private/dovecotkey.pem

Finally, dovecot is restarted to enable SSL with the new certificate.

root@mail:~# service dovecot restart

Troubleshooting

First of all, make sure that all necessary ports are allowed in the firewall.
Second, try telnet to a mail server. You should be able to get through. Some examples are given below for reference.

Connect to IMAPS

$ telnet mail.example.tst 993

Trying mail.example.tst... 
Connected to mail.example.tst. 
Escape character is '^]'. 
exit 
exit 
Connection closed by foreign host. 

Connect to POP3S

$ telnet mail.example.tst 995

Trying mail.example.tst... 
Connected to mail.example.tst. 
Escape character is '^]'. 
exit 
exit 
Connection closed by foreign host. 

Connect to SMTP

$ telnet mail.example.tst 25

Trying mail.example.tst... 
Connected to mail.example.tst. 
Escape character is '^]'. 
220 mail.example.tst ESMTP Postfix (Ubuntu) 

### Command ###
ehlo mail.example.tst 
250-mail.example.tst 
250-PIPELINING 
250-SIZE 10240000 
250-VRFY 
250-ETRN 
250-STARTTLS 
250-ENHANCEDSTATUSCODES 
250-8BITMIME 
250 DSN

VMware Virtual SAN (vSAN) is out now!

VMware announced the general availability of VMware Virtual SAN, a new and radically simple storage solution optimized for virtual environments. This was done during a VMware Virtual SAN online event  of which you can view the replay here. It includes a demonstration of the product, experiences of  beta customers, and highlighted performance and scalability details.
For those of you who don’t know Virtual SAN, Virtual SAN is an object based storage system and a platform for VM Storage Policies that aims to simplify virtual machine storage placement decisions for vSphere administrators. It leverages the local storage from a number of ESXi hosts which are part of a cluster and creates a
distributed vsanDatastore. Virtual SAN is fully integrated with vSphere so it can be used for VM placement, and of course supports all the core vSphere technologies like vMotion, DRS and vSphere HA.

Scalability

VMware Virtual SAN scales up to 32 nodes in a cluster allowing for linear scalability of performance to 2 million IOPS on read-only workloads and 640,000 IOPS on mixed workloads. 
You will need at least 3 ESXi hosts to deploy Virtual SAN and you will also need at least one hard disk per host and at least one SSD per host. There are a couple of best practices I found online:

1. VMware recommends at least a 1:10 ratio of SSD vs HDD.
   When your performance demands increase, you may need to up this ratio 2:10 or 3:10.
2. VMware recommends as a best practice that all hosts in the VSAN cluster be configured similarly if not identically from a storage and compute perspective.

The choice of SSD is essential to Virtual SAN performance. VMware is providing a HCL which will grade SSDs on performance.
Because you can vary the SSD vs HDD ratio you can simply scale a vSphere cluster with Virtual SAN for capacity or performance.

Versions & licensing

Staying true to the value proposition of simplicity, VMware uses a per socket based pricing model with no limits on scalability, performance or capacity that make forecasting and budgeting significantly easier without impacting hardware components selection and node configurations.
VMware Virtual SAN is available in three editions/bundles.

All editions feature the complete set of Virtual SAN capabilities – data persistency, read/write caching, storage policy based management, etc. – and include the vSphere Distributed Switch. This means that customers can take advantage of simplified network management of vSphere Distributed Switch for their Virtual SAN storage regardless of the underlying vSphere edition they use. Data services such as snapshots, clones, linked-clones and replication are available directly through vSphere, and are already available with every vSphere edition (Essentials Plus and above).
For customers seeking to complete their storage solution with backup and recovery capabilities, VMware is offering Virtual SAN with Data Protection. A promotional bundle available for a limited time, it brings together Virtual SAN with vSphere Data Protection Advanced, VMware’s simple, efficient, and robust backup product for vSphere environments.

The VMware Virtual SAN Design and Sizing Guide can be downloaded here.
If you want a testdrive with VMware Virtual SAN, you can visit the free Hands-on Lab (HOL) which enables you to play and explore all you want.
vSphere 5.5 Update 1 which includes Virtual SAN can be downloaded here.

Useful Command for Troubleshooting - RHEL 6

• Look at the boot time kernel messages:

# less /var/log/dmesg
 

• Look at the latest kernel messages:

# dmesg|tail
 

• Look for any entries in /var/log/messages pertaining to eth0 but exclude any entries containing DHCP:

# grep -i eth0 /var/log/messages*|grep -v DHCP
​

• Look for the rsyslogd process in ps output:

# ps ax |grep rsyslogd
 

• Look for the rsyslogd or init processes in ps output:

​# ps ax | grep -E "rsyslogd|init"
 

• Look at the first line in /etc/passwd:

# head -1 /etc/passwd
 

• Look at the last two lines in /etc/passwd.

# tail -2 /etc/passwd
 

• Show the output of a command, then show it again but remove the first line (header text) only:

# swapon -s # swapon -s|tail -n +2
 

• Get the output of df (-P removes line breaks), remove the header text, and only print the last column which consists of the mounted filesystems:

# df -P | tail -n +2 |awk '{print $6}'
 

• Run the lspci command with extra verbosity:

# lspci -vvv|less