Archive for the ‘Mail Service’ Category

Incoming email spam protection with SPF

Thursday, April 25th, 2013

These days, nearly all junk emails messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences, because their reputation gets affected and they have to waste their time sorting out misdirected bounce messages.

You probably have experienced one kind of abuse or another of your e-mail address yourself in the past, e.g. when you received an error message saying that a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address. Or you nay have received spam mails which have been sent from your e-mail ID.

These types of SPAM technique are called Sender address forgery or Spoof Mail. It is a threat to users and companies.

There is a Solution for that!

SPF: Sender Policy Framework

The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. More precisely, the current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages.

Even more precisely, SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together:

(1) The domain owner publishes this information in an SPF record in the domain’s DNS zone, and when someone else’s mail server receives a message claiming to come from that domain, and then,

(2) The receiving server can check whether the message complies with the domain’s stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.

Once you are confident about the authenticity of the sender address, you can finally “take it for real” and attach reputation to it. Furthermore, additional kinds of policies are planned for a future version of SPF, such as asserting that all of a domain’s outgoing mail is S/MIME or PGP signed.

An Example Policy

Let’s look at an example to give you an idea of how SPF works. Bob owns the domain domain.com. He also sometimes sends mail through his otherdomain.com account.

example.net.  TXT  “v=spf1 mx ip4:10.100.110.201 mx:domain.com  a:pluto. domain.com include:mail.otherdomain.com -all”

The parts of the SPF record mean the following:

v=spf1 : this identifies the TXT record as an SPF string. SPF version 1.

mx : the incoming mail servers (MXes) of the domain are authorized to also send mail for domain.com. If you add more MX servers in the future, they’ll automatically be allowed, too.

ip4:10.100.110.201: 10.100.110.201 is allowed to send mail from domain.com.

mx:domain.com: The MX servers for domain.com are allowed to send mail from domain.com.

a:pluto.domain.com: the Host pluto.domain.com is authorized, too send mail

include:mail.otherdomain.com: everything considered legitimate by mail.otherdomain.com (outside mail server) is legitimate for domain.com, too

-all : No other servers are allowed to send mail from domain.com. This is a good default for sites particularly concerned about forgery.

This example demonstrates but a small part of SPF’s expressiveness. Do not take it as a guideline for building your own record — things might not work out as you expect and legitimate messages might get blocked! Instead, learn more about the record syntax, or get the complete picture by studying the full specification or contact your hosting service provider.

Today Gmail, Hotmail, Rediffmail, Microsoft, Redhat, IBM, Citi Bank and most of the leading Service Providers and Companies use SPF and so do we for blocking out unwanted junk emails from reaching our clients inboxes.

Read More about SPF at:

http://www.openspf.org
http://en.wikipedia.org/wiki/Sender_Policy_Framework
http://www.microsoft.com/mscorp/safety/technologies/senderid/overview.mspx

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

Vmware Zimbra – The open source messaging alternative to Google Apps and MS Exchange

Friday, February 18th, 2011

Zimbra Collaboration Server (www.zimbra.com) is a fully featured open source messaging and collaboration application that supports email messaging,  group calendars, blackberry sync and other features using an advanced Ajax web interface that enables tool tips, drag-and-drop items, advanced searching capabilities and right-click menus in the UI. The software consists of both client and server components. Two versions of Zimbra are available: an open-source version, and a commercially supported version (“Zimbra Network”) with closed-source components such as a proprietary connector to Outlook for calendar synchronization. Zimbra has been bought over from Yahoo by Vmware and they have recently released ver 7 of the Zimbra Open source and Network editions on their website.

The Zimbra Server uses several open source projects e.g. Postfix, MySQL, OpenLDAP, Apache Tomcat (replaced by Jetty since 5.0), ClamAV, SpamAssassin, AMaViS and Amavisd-new, DSPAM, Aspell, etc. It exposes an Application programming interface (API) to all its functionality and also is an IMAP and POP3 server. The server runs on many distributions of Linux as well as on Mac OS X.

Zimbra can synchronize mail, contacts, and calendar items with open-source mail clients such as Novell Evolution and also with proprietary clients such as Microsoft Outlook and Apple Mail, but only through proprietary connectors available exclusively in the commercially supported version (“Zimbra Network Edition”). Zimbra also provides native two-way sync to many mobile devices (Nokia Eseries, BlackBerry, Windows Mobile, iPhone with 2.0 software).

Zimbra can be an ideal mail server for your organization if you are having more than 50 users and if your users require the advanced collobaration features which a groupware can offer (calendaring, shared folders, appointment tracking, web based UI, etc.). As it has full POP3 and IMAP support alongwith a robust spam filter (it segregates the suspected spam mails in a junk folder so that users can review the mails and mark the false positive mails as ‘not junk’), its very useful at organisations who want to stomp out spam mail but need the option to verify the mails which have been tagged as spam (akin to most web based email services). We have successfully implemented Zimbra for several of our clients in a virtualised environemnt and  it works well with just 2 GB RAM and Multicore processor for upto 100 users.

We have also recently migrated one of our client’s 12 GB mail box to the Zimbra Server with a single script as given below.

To migrate the mails, first you need to create all your mailboxes in zimbra server.

And after that move all your messages from Plesk Server to Zimbra server in a same folder structure.

To backup from Plesk server follow the steps.

# cd /var/qmail/mailnames/
# tar -zcvf /your/path/domain.tgz domain.com

Now move the backup file (domain.tgz) to Zimbra server with SCP or Samba share (or any other method) which ever is available. Go to the path where you have copied the backup file and extract the backup file.

# cd /your/path
# tar -zxvf domain.tgz

It will look like something as below when you list the extracted folder.

domain.com/user1
domain.com/user2

Now copy the below script in domain folder as ‘mailexport.sh’ and grant execution permission and run the script. It will add all your mails from Inbox and other custom folder to Zimbra server mailbox.

#!/bin/bash
#
# Maildir to Zimbra import
# Drop in your user root and run as superuser.
#

domain=”domain.com” # change to your domain!

for user in `ls -d1 */|sed s/\\\///`
do
echo
echo “User $user”
echo
#
#
find $user -maxdepth 10 -type d -name cur | while read line;
do
folder=`echo ${line}|cut -f3 -d”/”|sed s/\\\.//`
line2=`echo ${line/%cur/new}`
echo “FOLDER $folder”
if [ "$folder" = "cur" ]
then
/opt/zimbra/bin/zmmailbox -z -m $user@$domain addMessage Inbox $PWD/$user/Maildir/cur
/opt/zimbra/bin/zmmailbox -z -m $user@$domain addMessage Inbox $PWD/$user/Maildir/new
else
if [ "$folder" != "Sent" ] && [ "$folder" != "Drafts" ] && [ "$folder" != "Junk" ] && [ "$folder" != "Trash" ]
then
/opt/zimbra/bin/zmmailbox -z -m $user@$domain createFolder “/$folder”
fi
/opt/zimbra/bin/zmmailbox -z -m $user@$domain addMessage “/$folder” “${PWD}/${line}”
/opt/zimbra/bin/zmmailbox -z -m $user@$domain addMessage “/$folder” “${PWD}/${line2}”
fi
done

done

All done now you can get your old mails within the Zimbra server. If you are looking at an alternative messaging alternative to either Google Apps, MS Exchange or simply need a more robust messaging solution, the Zimbra collaboration suite (open source or network editions) could be a suitable solution to meet your needs.

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)
Loading ... Loading ...

Checklist of recommended best practices for your office email server

Wednesday, February 2nd, 2011

Having a latest hardware with leased internet connectivity and a feature rich email client are not the only requirements you need to setup your office email server. Unless you can send mails to your clients, partners and associates across the globe, your mail server is of no practical use. It is the trustworthiness of your mail server over the Internet that is standing between you and the recipient.

To be a trusted E-mail sender we need to follow the best practices which are highlighted below:

1.  Messages from IP (No Domain)

Messages should be from a domain and not from any IP Address. e.g. user@domain.com is a valid sender, whereas user@192.168.0.18 is an invalid sender and thus the mail will be rejected.

2.  Mail Servers on Dynamic/Dial-up Addresses

The sender server IP Address must not be a dynamic IP. Normally all IP addresses should have a correct reverse DNS, and especially email servers. Most Anti-Spam tools will reject email from places whose reverse DNS looks not to belong to an email server, but more likely to be a home or office dynamic address. If you are running an email server, make sure the Reverse DNS of the IP address reflects your domain, e.g.  ‘gateway.yourdomain.com’ or ‘mail.yourdomain.com’.

3.  Valid FROM domain

The FROM address is important as it is the address that would be used if problems were encountered delivering the message, so if the address can’t be responded to, the E-mail cannot be accepted from that address either.

e.g. user@yourdomain.com is an accepted sender but the following bad examples will get rejected:

user@localhost
user@192.168.1.200
user@myfakedomain.not

4.  The sender server must identify itself and the identification must be Valid (Valid HELO)

Most email servers and anti-spam tools will not allow mails to be received unless the above protocol is in place. This practice does not supply enough information to safely identify the server and responsible party, if a problem email is received. And almost every mail server offers this capability. This is a simple rule which just insists that the HELO (or EHLO) is sent with every email connection and it is properly formatted.

In order to ensure that messages are not stopped by this check, make sure the HELO is a FQDN.The HELO string sent should in the style of:

HELO mta1.mycompany.com

The following bad example(s) will get rejected:

HELO
HELO localhost
HELO hostnameonly
HELO 192.168.1.1 (just an IP)

If you are the one who is not receiving emails or are unable to send mail to some of your recipients, you may ask them to check if they really follow these practices.

At Diadem Technologies, we provide secure and reliable hosted email solutions on shared, dedicated and virtual servers. With over 10,000 hosted mailboxes and a decade of expertise, we have the right solution for your needs. Please visit our website or drop us a line for more details.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...