Credit card numbers of Argos customers were exposed in emails sent to them.

An email snafu by an online catalogue company is a good example of why both inbound and outbound electronic correspondence should be filtered not only to ensure that nasty payloads aren’t delivered to an organization but also to prevent sensitive information from being exposed to unsavory elements.

The email blunder involved a company called Argos. It is a multi-channel retailer, based in the United Kingdom, of merchandise for the home. During its last financial year, it had more than $6.4 billion in sales, 26 percent of it from the Internet.

After a probe by PC Pro magazine, it was discovered that the High Street retailer was sending out the credit card numbers of their online customers in plaintext emails confirming purchases. Should the emails be intercepted in transit or otherwise hijacked, the credit card information could be used for fraudulent charges.

What’s worse, the emails also contain an Internet link, or URL, that contains the recipient’s name, address and credit card details. If the customer clicks on the link, the URL containing the personal information would become part of the customer’s browser history, where it could be vulnerable to cyber snoopers. Moreover, the URL would be stored in the service logs of whomever is providing the customer with Internet service–his or her employer or ISP–as well as in Argos’s web analytics software which captures URLs used to access its Web site.

Two victims of the security lapse by Argos were cited by PC pro. Paul Lomax, chief technology officer at Dennis Publishing, and Tony Graham, reader of the publication. Both reported their credit card details stolen after receiving the vulnerable emails from the retailer.

Graham discovered the gaff when searching through his email for the last four digits of his credit card number. When he checked a message from Argos that appeared in the search results, he was puzzled. No credit card numbers appeared in the text of the correspondence. It was only when he opened up the source code behind the email that he discovered the URL bursting with personal and sensitive information.

Continue reading Solid email security requires inbound and outbound filtering

I read a tip just recently that advocated the use of fake MX records as a spam deterrent.  The solution was apparently devised after struggling with the server load that was being generated by spam emails.

As we all know, spam makes up as much as 90% of global email traffic, so it is not unusual for spam load to be a serious issue for email server performance.  The natural instinct is to prevent that load from being applied to the server in the first place.  Fake MX records are not the best way to do this.

MX records are the DNS records that tell email servers where to send email that is addressed to a particular domain.  For example, if I send an email to john@company.com my email server will look up the MX record for company.com, determine the associated IP address, and transmit the message over SMTP to that IP address.

To maintain redundancy most organizations will use multiple MX records that point to multiple email servers, so that if one is unavailable the others can still receive incoming email.  MX records are given a priority, an arbitrary number that is only relative to the priority of other MX records for that domain.  The lower the number, the higher the priority.

So for the same example as above, my email server looks up the MX record for company.com and gets the following response.

company.com MX preference = 10, mail exchanger =
 maila.company.com

company.com MX preference = 20, mail exchanger =
 mailb.company.com

It knows then to send to maila.company.com first, and then try mailb.company.com if the first try is not successful.

The idea of fake MX records is to create multiple MX records (usually at least 3) of varying priority, and have the highest and lowest priority MX records be pointing to non-existent servers.  The theory is that spammer’s botnets will only try to send to the highest or lowest priority MX, and then when they get no response will give up and move on to the next victim.  Some email administrators use as many as 10 MX records with only one real one among them.

The theory has some merit.  Spammers want to send out as much email as possible so usually won’t waste time and resources by having their bots try multiple MX records for a targeted domain.  However the technique impacts legitimate senders as well. Continue reading Fake MX Records More Harm Than Good

I am in contact with system administrators, network administrators and email administrators from multiple corporations on a daily basis. Quite often I hear from administrators or their higher level directors that some of their applications are running slow.

We’ll start off with a series of diagnostic techniques that will include testing their network connections, verifying that all patches and updates are in place and then monitoring and measuring user response times with specific tools targeted at their applications.

Email applications such as Outlook will invariably slow down over time and often the problem is identified as a memory issue. The simplest solution is to throw more memory at the problem but that also involves more money, something that most companies try to avoid as a possible solution. Especially in these times of constrained budgets, budget cuts and longer, more involved approval cycles with lower and lower management-required-signature purchase thresholds.

So when a slow response time for an email application has been determined to be related to memory leaks it will be followed by a sigh of relief that the company will not require additional monies to correct this issue.

When an admin receives multiple notifications that Outlook has reached a high watermark with respect to their virtual memory limits then the admin can sometimes take corrective measures such as closing down more than a couple of other applications to free up that memory. Sometimes an admin may also need to disable some of the add-ins that are running in Outlook.

Some add-ins have a search capability which can gobble up memory like a hungry man on Thanksgiving. This issue can be indicative of an inefficient garbage collection process within an application and only remedied by going back to the software vendor with data and application scenario so that the vendor can reproduce the problem on their end. Most C# code is managed and garbage collected but sometimes the cleanup process may not be running as efficiently as possible. So further review of the code is needed and hence a good data set and description of the environment will help in the vendor diagnostics.

Continue reading How to solve Outlook Memory Leak Issues

The process of making a connection between Outlook and Exchange can sometimes be problematic. Sometimes the network is not up or the connection information for either the client or the server may have changed or become corrupted.

When unable to make a connection between the client and the server a variety of error messages can be displayed: some alone and others in combination with each other. One such error message that a user or administrator may see displayed is the following:

“Exchange is currently in recovery mode. You can either connect to your Exchange server using the network, work offline, or cancel this logon.”

There are a couple different reasons for this message as well as multiple solutions. Most of the time the error message is displayed because of a difference in the cached copies of the mailboxes stored on the local client and of the cached copies stored on the Exchange server. This problem can be resolved by disabling the cached Exchange mode on Outlook, restarting Outlook and then resetting the cached Exchange mode on Outlook back to enabled status.

The “Exchange is currently in recovery mode” can also indicate that there are configuration issues with the Domain Name System (DNS) settings. This could also be the result of a connection problem either on the client or on the server. And it could also mean that the DNS server itself is down and thus not providing name resolution services.

Continue reading How to solve the Exchange in Recovery Mode Error

Outlook is a great tool for exchanging emails with friends and co-workers. Lots of times we send emails that are important enough that they need to be printed out and taken to business meetings and we usually taking the process of printing a document or email for granted.

But when we can’t print out an otherwise unimportant email then all of a sudden that print job takes on much higher priority in our lives.

Other times we are able to print out a much needed document for an important meeting and rush to grab it, run down the hall, plop ourselves down at the conference table and then start passing out copies only to discover that our print job appears discolored, grayed out or lighter in appearance than normal. We curse and say that we will never use that printer again. But later we find out that the problem was never with the printer but with problem with Outlook, particularly with Outlook 2007.

In Outlook 2007, there was a bug discovered related to color categories and printing which resulted in darker colors being printed lighter than normal.

Outlook allows the user to be able to assign Color Categories which adds another dimension to organizing your data or, in the case of email, organizing your email contents. Color Categories give your end users the ability to categorize their emails, contacts or appointments. Folders can then be created based on those categories and then filled with email messages which fit those categories. (Unfortunately IMAP accounts are not supported.)

Now let’s get back to the dark colors being printed much lighter than otherwise expected problem.

Continue reading Troubleshooting Outlook Printing Problems

The most prevalent vulnerability by overall frequency identified by the report is cross-site scripting (XSS).

Most software used by large companies in critical business applications is insecure, according to a report released by a company that tests programs for security vulnerabilities.

In a report titled “State of Software Security,” the company, Veracode, of Burlington, Mass. disclosed that when it first tested some 1600 business critical applications, 58 percent of them failed to achieve an acceptable security score.

The worst culprits were programs developed by companies for internal use. Failure rates for those applications were as high as 88 percent, the report said.

“Extrapolating from the application sample set, more than half of the software deployed in enterprises today is potentially susceptible to an application layer attack similar to that used in the recent Heartland or Google security breaches,” it noted.

The most secure software submitted to Veracode for testing originated with the financial industry or government sector. More than half the applications from those industries passed muster on their first go-round with testers, which placed them at the top of the list of 15 industries represented in the study’s data set.

The report also plugged open source software as a viable solution for businesses. The failure rate for open source programs was on par with their commercial counterparts–39 percent for open source, 38 percent for commercial wares.

What’s more, the speed at which security vulnerabilities were addressed in open source programs was far better than their competitors–36 days for open source, 48 days for internal software and 82 days for commercial apps.

In addition, open source programs contained the fewest vulnerabilities that could potentially be converted into backdoors which could be exploited by crackers for havoc. “The relative absence of potential backdoors is apparent testimony to the positive effect of transparency in the Open Source community,” the report reasoned.

Continue reading 58% of critical apps insecure

When you are transitioning from a legacy Exchange version to either Exchange 2007 or Exchange 2010 you will come to a stage in the project at which you need to plan for the migration of mailboxes to the new servers.

In small to medium size businesses the considerations are fewer than for larger enterprises, but they do share several in common.  Generally speaking you should plan for the following items.

End user interruption – when a mailbox is moved the end user will be disconnected from it.  Older versions of Outlook do not handle this very well, but even newer versions will need the end user to restart the application to connect to their new mailbox.

This means that it is often best to schedule migrations to occur outside of normal business hours.  Evenings and weekends are very common for this.  If a business operates 24 hours a day using rotating shifts then you can schedule migrations to occur so that a given user is moved when they are not rostered on duty.

Transaction Logging – a mailbox migration means that on the target server (the new server) a whole bunch of new data is being written into the databases.  This creates a very large amount of transaction logging, often much larger than what a normal day’s email traffic would generate.

There are a few ways to manage this.  Moving mailboxes in smaller batches keeps logging to a minimum but means migrations will take longer.  Provisioning large amounts of disk space on the logging volume means bigger batches can be migrated, but after the migration is finished it can mean wasted disk space that is not needed for day to day logging levels. Continue reading Planning Considerations for Exchange Mailbox Migrations

A security advisory issued this week highlighted a serious code execution vulnerability in Mozilla Firefox 3.6. The vulnerability, according to the advisory, is caused by an “unspecified error,” and can be exploited to execute arbitrary code that could be malicious and harmful. The exploit was originally highlighted by Russian security firm Intevydis.

There has been very little reported on the vulnerability to date, with some even suggesting that it is a “hoax.” Don’t believe the hoax suggestion, no matter how big a fan of Firefox you may be—in the security business, things need to be taken seriously. Not doing so is inherently dangerous. That said, there is very little data on how widely circulated the exploit has become, although some sources report an increase in the number of Firefox 3.6 crashes on February 12 and 13.

On the Mozilla blog, Mozilla does not confirm the vulnerability at this point for lack of details on how to reproduce it, but does make a point of saying, “Mozilla takes all reports of security vulnerabilities seriously,” as well they, or any other software organization, should.

The advisory brings up an important issue, which is that even when using the latest version of software and the most recent patches, security is not always bulletproof. Applying patches as they are available, preferably on an automated basis, is always good practice, and it does go a long way towards reducing the incidence of preventable attacks. However, patch management alone isn’t going to keep your systems safe. In fact, in one forum where the vulnerability is being discussed, it is noted that the “Insecure” tab—which is a cool feature, by the way—only shows programs that have patchable exploits. The Firefox exploit has not yet been addressed with a patch from Mozilla, so it isn’t shown there as being insecure.

As such, it’s a classic zero-day exploit, which is a vulnerability that is able to do its dirty work between the time it is discovered and the time when it is patched. At this point, users of Firefox should proceed with caution, and as always with any browser, take standard precautions, avoid opening up unknown or suspicious URLs, use pop-up blockers, and monitor traffic accordingly.

I have faith that readers of this blog have enough good sense not to use social networking sites to send important emails. However, some of your users may lack that good sense, and so it behooves us all to send out a common sense reminder every now and then—only use your official corporate email for anything important or sensitive! Save the Facebook email messages for updates about parties, casual observations, and idle gossip.

Wall Street Journal reporter Zach Seward got to have a glimpse of some of that idle gossip last week after Facebook made a major blunder, and some people received emails from complete strangers that were meant for somebody else. Seward gives us a glimpse of what goes on in Facebook with a few unnamed excerpts. The editor became privy to love triangles, petty jealousies, teenage parties and other truly fascinating but private missives.

The glitch was caught shortly after it started and was resolved, but not before several emails were incorrectly routed. Although there is no data being released as to how many users were affected, Facebook noted that “During our regular code push early Wednesday evening, a bug caused some misrouting to a small number of users for a short period of time.”

There have been other security blunders in the past, including a glitch in March 2008 that made it possible to publicly view photos that had been marked as private.

A report on the Wall Street Journal details the experience of a Journal editor who received several of the errant messages. According to the report, the editor received over 100 messages, ranging from ordinary to explicit.

Facebook recently redesigned its inbox interface to make it resemble Gmail.

Occasionally sending and receiving emails can pose problems for end users. One of the more serious problems is when users are unable to receive their email messages.

A sample error message related to being unable to receive emails is the following:

“Outlook is unable to connect to your outgoing (SMTP) email server”

This error message can occur if Outlook is trying to retrieve email messages from a Post Office Protocol (POP3) email server. It can also be produced if Outlook is trying to retrieve email messages from a Simple Mail Transfer Protocol (SMTP) email servers.

It is also possible that you may receive the error code 0×80042109 along with the above error message. This can happen if an end user is attempting to send a message via an email server and they are then asked to provide their login credentials. However, if the OK button is clicked again it will only result in another login prompt being displayed. And, instead of selecting the OK button, if the user hits the Cancel button then the following error message is displayed:

Task ‘<SMTP server name> – Sending and Receiving’ reported error (0×80042109): ‘Outlook is unable to connect to your outgoing (SMTP) email server. If you continue to receive this message, contact your server administrator or Internet service provider (ISP).’

A workaround for this problem is to create a new profile for the user account. The current email server is not responding to the existing user’s profile. A new profile will correct this problem.

Continue reading Troubleshooting Error Code 80042109