For today’s enterprise email security threats no longer consist of just nuisance Spam or Virus emails.

Do you have a mechanism in place to stop people from sending out sensitive documents, source code, trade secrets and so on via email?

The bottom line is that it is essential that we do not underestimate the need for an email security solution that can block or quarantine suspicious emails being sent from the Outside. One of the most effective ways to deal with such threats/risks and ensure data and system security is to implement an organisation-wide email policy framework. Such a solution, along with an effective and well thought out IT security policy and user education offer a good starting level for 360 degree email security.

-Protect intellectual property and sensitive and confidential business information data
-Stop Email Abuse by unauthorized Internal users within your network
-Protect Your Enterprise Against Legal Liabilities
-Prevent Internal Spamming
-Prevent Virus Attacks from infected devices in the network

Company Image:
Since building trust online is not easy, using a free email-hosting provider can make it even more difficult for people to trust you. To start with, people tend to trust more the businesses that have personalized email address that is personalized to their domain name, such as name@yourbusiness.com. The email solution which an organization chooses is a representation of their business. Deploying an enterprise class email and collaboration system sends out a message that the organization is professional and  appreciates the confidentiality of data.

Reduced Meetings and Travel Costs:
With the increase in the number of people provided access to corporate email and chat it is a lot easier to exchange information and workout solutions without have to have face to face meetings. With a drop in the number and frequency of meetings considerable amount of time and travel is saved. Improving efficiency and Reducing the overall cost.

Increased Accountability:
When a business begins to use email to manage workflow and assign work, it creates greater accountability because there now is a record of the sequence of action. This record of the sequence of action can also be examined later to fix any problems that may have occured or to improve the working of the business.

Security:
This is an important issue when a company is dealing with confidential emails from clients or important documents. You wouldn’t want any third party having access to your most important documents, with the right kind of service provider you can minimize the risks of that happening to near zero. Security threat from within the organization can also be minimised by deploying emails systems that can create a record of all the mail flow.  By storing this information in a safe environment with centralized backup the strings of communication can be retrieved easily for any investigation.

Additional Storage:
With a hosted enterprise email service you don’t have to worry about running out of storage space. Additional storage can be provisioned easily to meet your needs. So you can be sure to never miss an important email.

No Spam/Virus:
Hosted Enterprise email services include strong mail filters, which free ones may not. This means that it is very unlikely to have your inbox invaded with spam emails or viruses that may disrupt your system and cause loss of work.

Support:
When you are dealing with a free email-hosting provider, support is often non-existent. On the other hand, with a paid email hosting service, the support is easy to reach and available to provide you with the help you need to keep your emails flowing. E.g. with paid email hosting you can get a log report and analysis for any email delivery failure, which then enables you to take corrective action.

Having a few email ids to transact business is no longer sufficient for most businesses today. A reliable email service with email access provided to most people in the enterprise is now a necessity.

• Sir, Can you help me compose a reply for the ticket raised by MKS
• Ring, Ring (phone call), Hello, Sunil, I need your intervention with a ticket I raised regarding my server’s performance
• Sunil, I have a prospect on call and he is asking a highly technical question, can I just hand you phone to address his query.
• Sir, our outgoing relay IP has been blacklisted!
• Sir, you are scheduled to take a telephonic interview now.
• Sir, when can you finish that blog you promised, I need to post it on our SM sites
• Blip, Blip (chat alert), Sunil, can you give me those projection numbers for April
• Blip, Blip (chat alert), The deployment in Guwahati is stuck and I need to review further course of action

… and this goes on until I go home ( and sometimes beyond).

On a couple of days I measured these “interruptions” and found them to be in the range of 20-25. I am not counting my more than 100 mail a day which I need to attend to.

Flitting by a dictionary definition means:
1. To move about rapidly and nimbly.
2. To move quickly from one condition or location to another.
3. A fluttering or darting movement.

Going by the definition, this is exactly what I do, “Flit” from one interruptions/tasks to another, desperately trying to find some free space to create something of value rather than simply “operate”. Many a times, I operate like a General Manager or COO, who is continuously handling exceptions, escalations, taking decisions and solving problems.

My day is majorly occupied with many such “flits, to a lesser extent with team reviews, and least with some free time to write/create.

This way of working is all about maintaining an already established system. Its like running the business system which has been established and dealing with exceptions which arise during the flows. However unless someone is looking at these exceptions, analysing them and asking the million dollar question: “what is the root cause of these exceptions“, “how can we improve the system to eliminate these exceptions“, this situation will continue day on day and only grows since the transactions are growing anyways.

Please note that, pending improvement in the system, all these exceptions in the system have to be handled as they arise. Someone or some team has to step in and resolve/fix situations. I am reminded of a real story about one of India’s oldest car companies. It was said that at the end of the assembly line, there was a QA division, which instead of just inspecting and ticking off the quality of the finished car, would actually initiate quick repairs to fix issues like ill fitting doors, unfinished assembly etc. So at the end of the assembly line, where it was expected that the car would arrive 100% complete and in top quality, the car actually arrived with a plethora of different problems and a team of workers would fix these defects. Ideally all these defects should have been taken care off upstream in the process (No prizes to guess which company I am talking about). On a similar note, the popular story about Toyota is that if any worker notices a problem in the assembly flow, he can raise a red flag, stop the process so that teams can come together to fix the problem before resuming the flow.

In most organisations, the teams to operate are always different from the teams who establish/improve the systems. If YOUR ORGANISATION or YOU don’t have the liberty of having a separate team to establish  and improve the business system, consider the following suggestions:
1. If you must be interrupted with queries, decisions, tasks, I would suggest that you record the input for future action (maybe on the same day) and ensure complete closure of the work in hand. By complete closure I mean a logical closure of the entire task or of a “whole” part of the task so that you can switch to another task and come back to the original task by quickly re-establishing the context and re-starting the work. Leaving a task half done is a sure way to build stress, reduce focus and give superficial attention to the task at hand. Either ways if you must switch to the NMI (non maskable Interrupt at hand), do so with rapt attention and focus so that you can ensure complete logical closure of that new task at least. Learn this by practice.
2. Recording inputs for later action will help you identify/understand the improvements to be made in the system.
3. Establish Kaizen hours, days, weeks which are dedicated only to do improvements. Its like squeezing out those moments to improve the system, which by and by adds up to reduce exceptions/interruptions. Its like starting up a positive spiral.
4. I would say that even a single dedicated person on kaizen can start freeing up resources, which add up to more improvements, all leading to a smoother running system.
5. Examine the interruptions to see if some of them are simply some members of your team trying to put the monkey on your back, whereas they should be handling it themselves. Push the responsibility down the line. Your team will grow and you will find free time.

The kaizen falls in the range of minor cleanups, realignment of resources, documentation, re-architecting the system, eliminating waste, etc.

Yes! I do flit; Currently at this moment, It is necessary; But I also know that one at a time, I need to permanently resolve issues and re-architect the system to reduce friction and smoothen the flow.

Warning: Flitting can soon become a habit (not just at work but also in other aspects of your life), which prevents you from finding uninterrupted slots of time with undivided attention to work out issues, plan for the big projects, build understanding and refine skill sets. While its a comfort zone and also gives you a feeling of superficial achievement by keeping you very busy, its not very satisfying. You are constantly running on a treadmill.

I am deliberately not touching upon tips of time management. That could be the focus of another article. The below mentioned articles are good resources for that too.

References:
A good article on building good personal habits:

http://www.slideshare.net/egarbugli/26-time-management-hacks-i-wish-id-known-at-20

http://www.gtdtimes.com/2013/03/28/what-you-dont-need-to-waste-time-on-anymore/

http://www.gtdtimes.com/2011/09/01/david-allen-on-dealing-with-interruptions/

http://www.lifehack.org/articles/lifehack/9-ways-to-handle-interruptions-like-a-pro.html

Consider the following two common situations and see if you can relate to them
1. I sent a mail but I received a bounce stating that the recipient’s mail server rejected the mail considering it to be abuse.
2. I keep receiving bounce messages for mail I never sent

When you send a mail using any client, your client (web, desktop or mobile) connects to mail server over SMTP and hands over the mail to the mail server to relay to the recipient server. The mail server in turn queues the mail and based on routes established in the setup, it may relay the message to outgoing relay servers who take each mail from the queue, resolve the recipient’s MX server, establish an SMTP connection with that server and deliver the mail.

Mail treated as abuse:
During this transaction, the recipient server does several checks to establish the authenticity of the incoming mail from the sending server. One of these checks is to establish the authenticity and reputation of the sending server’s IP address. If the sending server’s IP address has a bad reputation (is part of one of the RBLs (Resource Black lists)), the recipient’s server rejects the mail assuming it to be a spam.
This is the cause of problem #1 stated above.

Sender Address Forgery:
Another common problem today is Sender Address Forgery. Today, nearly all abusive e-mail messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences, because their reputation gets diminished and they have to disclaim liability for the abuse, or 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.

Sender address forgery is a threat to users and companies alike, and it even undermines the e-mail medium as a whole because it erodes people’s confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact.
This is the cause of problem #2 stated above.

Thus when the recipient server is about to accept a mail, it would be nice if it had a way of establishing/connecting the sending server’s IP address with the sender’s domain name (its like a power of attorney by a domain which states that all my mail are sent ONLY by these defined set of servers)

Enter SPF (Sender Policy Framework). The domain owner must specify and publish the IP addresses of the mail servers, which they use to to send mail for their mail domain.

The domain owner publishes this information in an SPF record in the domain’s DNS Zone and when the recipient server is about to accept a mail from an email id, it can verify if the mail is complying with the policy published by the domain owner i.e. the IP from which it  originates is one of the listed IPs in the SPF record of the domain.

By using SPF, you reduce rates of email forgery and greatly increase chances of delivery of the mail even if the sender’s IPs are blacklisted in RBLs.

Resources:
Reproduced in part from: http://www.openspf.org/Introduction

http://www.zdnet.com/how-does-sender-policy-framework-work-3039149352/

Live interaction in our company between the Product Manager and the Engg head

Product Manager: I gather that the release has slipped by about 3 weeks.
Engg Head: Yes, we are facing some challenges ensuring scalability of the connectors in the new chat component

Product Manager: So whats the approach your team is taking to resolve this
Engg Head: We are working on fine tuning the component to deliver better performance…but also we are looking for a more scalable connector components to blast this bottleneck.

Product Manager: Good. So by when do you think this will get resolved?
Engg Head: We have already evaluated a replacement for the chat connector component…but we still need to test its scalability by putting it through our load and stress testing system. I believe we might still be a couple of weeks from code closure.

Product Manager: Hmm…so I guess we have some time to squeeze in a few more minor improvements into the web client. Some of these improvements are simple and wouldn’t take too long. In any case, the teams are separate, so I guess it shouldn’t matter…
Engg Head: It matters. During a release, I need to consolidate the entire teams effort towards reviews, testing, documentation and overall closure. Even though the release is held up due a open issue in the chat backend, we need to start freezing the code on all the other modules and applications and free up those teams to assist in the wrap up. Any change at this stage, no matter how small it appears, would re-open that module/component and would mean another round of regressions and reviews to close it. So can we please close the webclient release now!!! ….

During every product release as we near the schedule dates for closure, debates such as these become more frequent. The Product Management team, whose job is to produce highly usable products that break new grounds in delivering value to customers and the Engineering Team, whose job it is to ensure quality in all aspects of the product like reliability, scalability, usability, serviceability and functionality, seem to be pulling in opposite directions with even greater intensity. We see this a normal ‘healthy’ stress between the teams.  But we see this as the necessary to ensure that we deliver both on the value and quality of the product.

Each team is endeavoring to do its job well.

The product management team is more aligned to the market needs and competition landscape and is aware of the impact of delays in bringing certain features to the market. Its job is to squeeze in the most it can within a release cycle and gain a head start in the market.

The Engg team is tasked with ensuring that quality, performance, scalability and maintainability of the system is continuously improving with every release. It’s worst nightmare is a slippage in quality below the benchmarks established by previous releases.

While the product management team wants the kite to soar higher, the engg team wants to ensures that the thread holding the kite is secured firmly.

To ensure the we keep close to the customers needs, Mithi follows an evolutionary delivery model for software development. But this development comes with its own challenges – on one hand it runs the risks of  features drifts and on the other a degeneration of the system architecture.

After years of working with this model, we have found that what works best is to keep tight schedules. Schedule constraints not only help to reign in feature drifts but also force you to innovate on the design, engineering and technology choices. Also to ensure that the tighter schedules are met (without compromise on quality) you need to keep the architecture as clean and malleable as possible.

CLOSING a release at a fixed schedule, is like clearing up the table to make space to take up the work for the next release. It creates the space into which new ideas, design and innovation can easily flow in. Freeing up resources to move to where it is most needed. Closing a release ensures that resources and ideas do not stagnate and a continuous flow of innovation and improvements is maintained.

A solid product release, has an “additive” effect on the product capability and moves the company one notch higher and locks it there.

It becomes a new normal.

For the teams who are locked into action on Plan A, it is difficult for them think of or work on an alternative plan. In fact they are likely to get deeper and deeper into troubleshooting the track they are holding and keep feeling that they are nearing a solution.

While handling emergencies, its important for one person or a separate team to observe the proceedings and ensure that the work on Plan B kicks in on fixed schedule. Plan B could well be an alternative troubleshooting track or a fall back to the DR plan.

This coordinator’s job is to ensure results, which is in terms of increased up time for the customer.

So here are some suggestions on how to handle emergencies in a structured fashion

1. First call is received by Level 1, who does basic diagnosis to revive the service/system, sometimes even resorting to a reboot if necessary.
2. If unable to resolve using basic diagnosis or if a predefined time interval has elapsed without a solution then Level 1 team now escalates to Level 2 team for advanced diagnostics.
3. Level 2 team may involve Level 3 team after the advanced diagnostics are done or if another predefined time interval has elapsed without a solution . At this stage the Service Delivery Manager also is alerted.
4. Service Delivery Manager (SDM) takes stock of the situation, and evolves/refers to Plan B.
5. SDM aligns a separate team to work on Plan B, which is typically a recourse to a DR plan (on site or off site)
6. SDM now monitors the functioning of teams on both plans

Do you have a Plan B, C, D for the upkeep of your collaboration infrastructure?

It is a good practice to have a DR Strategy for your mail server setup, which could range from a simple server/site rebuild document, to an on site hot standby server or High availability configuration  for your servers to a complete DR site.

It is also a good practice to perform DR drills at periodic intervals, which will ensure that you have all the necessary tools and documents ready, if and when ever needed.

P.S. At the time of publishing this, the Mithi teams and HCL team (FMs on site) have successfully brought the mail server back online using Plan B and a lot of collaboration through the night. Well done guys !!!

While the reconfiguration team worked on drawing up and firming a recovery Plan B, in case the server didn’t resume normal functionality, the other teams discussed advanced diagnostics to parallely troubleshoot the issue.

As a base measure to troubleshoot the issue, we decided to stop all services and agents and kill all running/waiting application jobs and scripts to eliminate any software issue. Once this was done the server became normal. On a closer scan it was found that the /var/log/messages log file had grown beyond 3 GB and the agents and scripts which work on this log were reading and loading up the I/O. This was cyclic since the earlier agents kept getting slower and slower as the file was used more and more often. At a certain point it overloaded the server and brought it to a standstill. Now what was causing this, happened to be an internal spam attack, whose rejection lines were pushed into the log and it kept growing.

We could get this under control in the matter of a couple of hours due to deep collaboration between the teams. Using chat allowed teams to perform tasks, copy paste results and commands, while keeping their hands free from holding the phone. Not forgetting to mention the saving in phone bills.

Using the group chat, there were 4 different teams and a coordinator working on the issue, with the clear transparent flow of information to keep all the team members up to date. So while Level 3 instructed on the diagnosis steps, Level 2 actually performed the instructions, while asking Level 1 to monitor the parameters. During the discussions a lot of ideas were also thrown in how to have prevented this or the steps to diagnose or forming an improved checklist for monitoring. All this with only an initiation call and no more. And whats more is that this chat discussion is now archived as well. It would serve as a base for the troubleshooting documents and preventive work allocation

Mithi’s Connect Xf product supports enterprise grade secure chat

Live Scenario 2:
One of our customers recently complained of mail queues between their site servers getting stuck. Mail were flushing but very slowly and most mail were deferred in the queue with a timeout error while connecting to the recipient site server. It was noted that there was no change in the environment and the servers. After we audited and cleared the application configuration, we asked the customer’s network team to scan the network for any problems. We even got the servers rebooted, and the routers and switches rebooted. But it didnt help. The network teams report was all clear. The connections between the servers were over a VPN. We suspected the VPN and to prove this hypothesis, we routed the mail between the servers over the Internet. This helped temporarily and then again, within an hour or so, the same phenomena was observed – mail stuck in queue, flushing very slowly and deferring with a timeout error. Somehow during all this, none of the teams could think of asking the ISP to do some diagnosis on the Internet links or the VPN. They were invisible. As a last resort, and after recalling some previous experiences, we decided to route mails over another port (not port 25, we had to map another port on the MTA). Viola, the mail flow resumed normalcy and is working fine now. This only means that the ISPs have proxied port 25 to intercept messages and/or put some rate control on it. Its strange that they didn’t think of at least informing the customers of this change

Live Scenario 3:
BSNL has blocked port 25 entirely. This means that on the last mile links supplied by BSNL, the devices cannot connect over port 25. When this happened, a lot of our users who were on BSNL links, lost the ability send mail from their desktop clients. As a result, we had a lot of support calls to map another port on our mail servers, affected by this change. The users then had to use this other port in their desktop client configuration, outgoing SMTP server settings to resume normal functioning.

Live Scenario 4:
A while back, when our users would travel to foreign destinations like USA, Europe or Dubai, they complained that they were unable to send mail from their mail servers, which were back in India. This problem was because most international ISPs, have proxied port 25 to intercept email traffic and redirect the traffic to the MX servers of the sender’s mail domain. Normally MX servers dont expect mail “from” a domain which is hosted on that server itself. Hence our users were stuck. This was rectified with a solution similar to the one explained in Live Scenario 3. We had to map another port to the MTA and get users to change their desktop client configurations to use this new port for outgoing SMTP connections.

Why block port 25?
Its now clear that across the world (India included), ISPs are intercepting/choking or blocking port 25 access. The main reason for this is because when a computer gets infected by a virus it can be hijacked by the virus writers to send out thousands, if not millions of spam emails – the ISPs have to prevent this from happening or else it would clog up their precious bandwidth, in turn providing a poor experience to their users. Blocking the port is the only real solution.

Whats the impact of this on my setup?
All users of email clients like Thunderbird, Outlook, etc, who connect to their mail servers over Internet links which they may use like broadband, or leased lines, may experience problems sending mail if the provider of their Internet link is blocking port 25. (Refer Live Scenario 3 and 4)

All mail servers which are hosted at Data centers (professional IDCs or in premise) typically send mails to other servers over SMTP port 25 ONLY. This is done since it is a standard and there is no real way of knowing the port of a recipient server if its not standard. In this situation if your ISP has blocked port 25, then your mail server can never deliver mail to any other server. This will render an In premise setup as useless. (Refer Live Scenario 1 and 2)

So what next?
We have no option but to accept it and work around it. Possible working solutions are given below:

A. For clients connecting to the mail server (who could be using a broadband from their office, or a wireless broadband modem, or a leased line from home, etc), change the port of access for SMTP to any other port other than port 25. This is a very simple configuration in Connect Xf and most other mail servers.

B. Since this problem is mostly in last mile connections, landing at an office or a home, its quite possible that you may encounter this issue even with mail flow between servers and mail which is relayed directly from the servers in your location (since those mail will be sent to the recipient servers over port 25)…refer Live Scenario 1 and Live Scenario 2. The solution to this problem is to route all mail between local servers over another port, other than port 25 and for outgoing mail, use the relaying services of an email hosting provider (who would be hosted at an IDC and their links don’t have such restrictions since they serve large racks of servers and are providing controlled bandwidth to customers). Relay all outgoing mail to the Mail service provider’s relay servers over another port (other than port 25) and let them relay to the recipient servers over port 25.  In other words we recommend a setup similar to Mithi’s Cruise solution which is a hybrid between an hosted email setup and a local mail gateway server setup.

I recently wrote a note on how network problems are difficult to diagnose or prove.

As for the services community, IT teams, I recommend that they must look at the ISPs as a very important part of the stack during their troubleshooting.

Many a times, we get trouble tickets, announcing that the Mithi mail server has slowed down and is exhibiting high CPU utilisation and load. The server would also exhibit a high I/O wait, which in turn causes higher load averages and also impacts CPU use. But what then causes high I/O wait. On closer inspection it turns out that the POP service is hovering on “top” is taking longer than normal to process requests. So why is that? POP is visibly the fastest responding service and even during peak times the concurrency used would not cross 10 connections. The core cause is that POP requests for large inboxes (POP with leave copy configured in the clients) are taking very long to complete and also loading up the I/O since the POP client has to compare a big list of emails already downloaded with a big list of mail in the server Inbox to determine what to download (or not to download). This happens for every pop connection and grows progressively slower since more and more mail are collected in the inbox. After a certain threshold, the server exhibits performance bottlenecks which are felt by most of the users. This is easily solved by reducing the size of the inboxes for all such users (delete mail older than 7 days and move it to a personal folder). While the overall size of the storage hasn’t changed, the size of the Inbox is what matters for POP requests.

POP stands for Post Office Protocol and is a simple set of instructions that let your email client retrieve messages from the mail server. The POP client asks the server if there is any new mail, and if your mailbox on the server has messages, then POP usually downloads them to your computer and deletes them off the server.

IMAP stands for Internet Mail Access Protocol and allows a “client” email program to access a message stored at a remote location as if they were on the local computer. Email stored on an IMAP server can be manipulated from a desktop computer at home, a workstation at the office, or a notebook computer or mobile device while traveling, without the need to transfer messages or files back and forth between these computers.

Modern email usage scenario

• Most users now access their mail using different methods and from different locations as per convenience i.e. mobile devices,  desktops and browser. They would like to see the same view of the mailbox (including sent items, drafts and other personal folders) from any device.
• Users would like to organise their mail into folders.
• Users don’t want to be concerned with the backup and management of the mailbox.

Limitations of POP

POP is essentially an older protocol, which runs into the following limitations in todays scenarios

• POP clients only understand the presense of the Inbox folder on the server. It cannot download mail from the other folders.
• Once  a mail is POPped of the server, it is usually deleted unless the user chooses to leave a copy of the mail on the server. The same mail is now not visible from the web client or any other client.
• Mail sent from POP clients, stay on the client and are not synced to the server’s sent items. Similarly if a mail is sent using the web client or mobile, the sent mail are not visible in the desktop pop client.
• Many users who choose to leave a copy on the server infinitely, progressively experience a slower POP response since the POP client has to compare a bigger and bigger list to decide what mail to download.
• A large Inbox, which is being accessed from POP also loads the server I/O and reduces the server response. This is normally not a visible cause during troubleshooting of performance issues.

Verdict: Essentially using POP ensures that you will get an inconsistent experience if you access your mailbox from different clients. POP (without leave copy or leavy copy only for a limited period) is best suited in situations where the user is base stationed and uses only one device for accessing mail and agrees to maintain the mail which have been downloaded (backups, etc).

Success of IMAP

IMAP is a modern protocol which

• Allows parallel multiple client access by ensuring that the server mailbox is in sync with all the IMAP clients connecting to it.
• Mail sent from any client/device are synced to the sent items on the mailbox on the server. This ensures that the sent items are now visible to all clients.
• Is resource efficient, since it syncs incrementally only the new/changed mail.
• Allows the mail backups etc to be managed centrally at the server level. In case of a client crash, the mailbox can simply be resynced to the freshly built or new client.

Verdict: To allow users to have a consistent and uniform experience, when they access their email from different devices and locations, it is advisable to use the IMAP protocol.

Additional Note: A combination of personal archival to store old mail and IMAP for the live mail access is the best solution for easy mailbox management and also provides end users the security and safety for their data. The IT team of course has to work harder to deploy sufficient storage and establish systems to ensure availability of the storage.

According to a recent report (2012) by INT Media Research on “Enterprise Instant Messaging: A Baseline Study of Business Trends,” there is a large and growing interest in deploying some form of IM for corporate use. Among the report’s findings:

47% of businesses surveyed indicated employees use IM at work; 24% use a secure, proprietary IM system and 76% use a third-party free system.

65% of businesses surveyed believe it is at least somewhat important to provide IM as a tool for internal communications; 6% of those surveyed said IM systems are not at all important to their businesses.

18% of the businesses surveyed indicated they would be ready to purchase internally networked IM services in the near-term.

Another independent research instant messaging experts, ProcessOne, has revealed that 60% of mobile users would send less text messages if they were better educated about how to use mobile instant messaging (IM) services.

Challenges/ Risks faced by enterprises for implementing IM that corporate IT departments need to watch out for:

Lack of namespace control
Most enterprise IM users still use consumer-grade clients that are freely available from Microsoft, Google et. al and these IM client operate independently from a corporate directory enterprises have. This results in two major problems.

1. Using an IM account that does not carry corporate identity has a negative impact on the brand and reputation of an enterprise.
2. The employees can continue to use the IM account even after leaving the organizations which can result in potential liabilities for an employer.

Lack of security

• Lack of auditing and logging capabilities: Consumer-grade IM clients typically do not provide any sort of logging of IM conversations when the parties to an IM conversation leave the session, the content of their conversation is lost unless the text thread is manually copied and saved. This can result in significant problems for an enterprise that archives employees electronic communications, particularly for those that are required by statute to do so. Further, it leaves an enterprise vulnerable if the archived content of an IM conversation is modified after the fact. This risk is a particularly important consideration in the context of increased corporate scrutiny imposed by regulations and audit.
• Potential for incursion by viruses and worms: Consumer-grade IM clients don’t provide secure messaging capabilities and they have also shown to be more prone to malware (virus/spam etc) which results in security threats. Unmanaged IM represents a key avenue through which viruses, worms and other malware can enter a corporate network.

Some of the must-have features listed by Gartner for IM hygiene include:

• Archiving in a secure, searchable repository, or integration with leading third-party email archiving systems.
• Centralized management, including IM monitoring and enforcement of user authorization and other IM usage policies for both groups and individuals.
• Reporting capabilities for regulatory compliance.

So, if you’re planning to introduce Enterprise grade IM setup within your organization it is imperative to choose a product that will address the above security concerns to be able to establish an effective and safe communication channel for Business to collaborate.

Footnote : Look out for Mithi’s new Web Chat feature in Baya as a solution for the IM requirement for your enterprise.