Message Recall: Not the Best Feature

March 15, 2008 – 12:11 pm

Both Microsoft Exchange and IBM Lotus Notes (Domino) have a feature called “Message Recall”. They both have serious limitations and it is only under rare exceptions do they work. They ONLY work within the local mail system (not with messages to the internet, for example) and ONLY if the recipient has not read the original and has certain settings enabled (Process requests and responses on arrival). They work so poorly and are such a bad idea, I’m not even going to go into the specifics of when they do work.

I will give this one piece of advice though: Don’t rely on “Message Recall”. Don’t fire off emails like confetti at a New Year’s party (I can think of less proper examples, like what happens to some people to end a New Year’s party). Take time composing them. Save them in your drafts folder and get some fresh air outside and then re-read them. If you are emotional (especially angry) when you write an email, save it in your drafts for at least a whole 24 hours, and re-read it when you feel more calm.

Maybe you don’t want to listen to me or feel you can’t control yourself. If that is the case, then obviously I can’t help you. Learn the hard way and then maybe cut back on the coffee and get a good book on meditation or yoga to calm yourself down.

Why Go Paperless? (For Your Business and Your Grandchildren)

March 4, 2008 – 9:58 am

Your office should go paperless. Why? Because you can save money and help make the planet cleaner. You care about your grandchildren don’t you? You want them to have trees to climb and shade to relax under and clean air to breath, right?

You can use modern technology (specifically email) to replace paper. Not only will you save money and help the environment, but it is much easier to retain, file, organize, and search through electronic documents.

Switch your office to a paperless one today and save money. Your business will save money:

  • You can stop buying so many printers.
  • You can stop buying so many toner cartridges.
  • You can stop buying so much paper.
  • Your landfill/waste bill can be reduced.

Your employees can take their laptop to meetings and view documents on-line. The youth generation won’t have the attachment to paper documents that many of us older folks have. They will be perfectly comfortable viewing reports on a screen. And many of us a bit older are willing to adjust, knowing the benefits of not using paper.

Some facts to consider:

  • Financial businesses generate over 2 pounds of paper per employee per working day.
  • Employees at American financial businesses generate about 2 lbs. of paper a day…per person! Source: The Recycler’s Handbook, 1990
  • Nearly half of typical office paper waste is comprised of high grade office paper, for which there is strong recycling demand.
  • It is possible to significantly decrease the costs of buying office paper by reducing paper use and reusing the paper you have.
  • Eliminating office paper from your waste stream can cut your waste bill by 50 percent or more.
  • Recycling one ton of paper typically saves $22 to $45 in landfill disposal costs (in 2004 dollars) and about 6.7 cubic yards of landfill space.
  • Commercial and residential paper waste accounts for over 40 percent of waste currently being landfilled. Eliminating paper from waste would almost double the lives of current landfills.
  • Every recycled ton of paper saves approximately 17 trees, which are then available for other uses, and approximately 462 gallons of oil. Recycling paper also reduces the air and water pollution due to paper manufacturing.
  • Bank of America’s recycling programs grew from an initial diversion of 1,400 tons per year of computer and white paper in 1970 to divert 14,591 tons of paper in 1997. The company saved an estimated $483,000 in trash hauling fees by recycling paper. (Figures stated are pre-merger with NationsBank.) The bank has also undertaken major source reduction such as changing report procedures, reducing forms, using two-sided copying, routing slips, and e-mail.
  • Approximately 324 L. of water is used to produce 1 KG of paper. Source: Environment Canada
  • The average American uses more than 748 pounds of paper per year. Source: American Forest and Paper Association
  • It is estimated that 95% of business information is still stored on paper. Source: International Institute for Environment and Development (IIED) Discussion Paper (IIED, London, September 1996)
  • 3 cubic yards of landfill space can be saved by one on of recycled paper. Source: 50 Simple things you Can do to Save the Earth, Jodi B., Sudbury
  • Every ton of recycled paper saves about 17 trees. Source: Purdue Research Foundation and US Environmental Protection Agency, 1996 Recycling paper
  • Dioxin is one by-product from use of elemental chlorine gas in paper bleaching. Source: Printers National Environmental Assistance Centre, Fact Sheet by Todd MacFadden, and Michael P. Vogel, Ed.D. June, 1996
  • Dioxins tend to bioaccumulate, which means their concentrations in organisms increase successively up the food chain. Source: Printers National Environmental Assistance Centre, Fact Sheet by Todd MacFadden, and Michael P. Vogel, Ed.D. June, 1996

Sources:

  • http://www.filebankinc.com/reports/reduction_tips.html
  • http://www.greenbiz.com/toolbox/essentials_third.cfm?LinkAdvID=4164

Blocking Port 25 to Reduce Spam and Protect Your Network

February 28, 2008 – 11:06 am

If you have an email filtering service provider like Sentinare Messaging Solutions, Inc., then all your SMTP traffic should be coming from only the filtering provider and the filtering provider only. Therefore, you don’t have to allow direct port 25 (SMTP traffic) to your email server any more and you shouldn’t allow port 25 (SMTP) traffic directly to your email server anymore. There are several reasons for this:

  1. Running a mail server which accepts connections from anywhere at all times is very dangerous. A mail server accepts unknown content of unknown size from anywhere at anytime. This is a perfect recipe for buffer overflows, hacking attempts and other SMTP-based attacks. By blocking port 25 traffic from the world and allowing it only from Sentinare Messaging Solutions, Inc., you are greatly increasing the security of your mail server and your entire network.
  2. If you are restricting port 25 traffic so that it is allowed only from your email filtering provider, you don’t have to panic the next time a new vulnerability is exposed for your email server software. You can patch the server at your users’ and your convenience, as your mail server has that strong layer of protection provided by your filtering provider.
  3. Spammers are pretty crafty and they are smart enough to direct mail to mail servers, even though they are not published as MX servers in DNS. So even though you have switched your MX records to point to your email service provider’s MX servers, you still might get spam directly to your server if you do not block port 25 traffic.

Why Not Use “mail.yourdomain.com” as the Name for Your Mail Server

February 26, 2008 – 6:09 am

Spammers will ignore MX records sometimes and use “mail.somedomainname.com” to relay spam to. If you have an off-site email filtering service provider and you set all your MX records to their server, all your mail should go to the off-site email filtering provider’s servers, according to the MX records, but this is not always the case. Spammers are smart enough to send spam directly to any machine named “mail.somedomainname.com”, because usually it is a mail server which will accept and handle mail for “somedomainname.com“, whether it is an MXed SMTP relay or not.

If you take the Best Practice Recommendation of Sentinare Messaging Solutions, you will also block SMTP port 25 inbound to your mail server and spammers won’t be able to hit your mail server anyhow, but this is also another best practice and another layer of security. There are some times that you can’t block SMTP port 25 inbound to your mail server, and in these cases you want to at least give your mail server a name other than “mail.somedomain.com”.

Email Filtering Service: Using FQDN Versus an IP Address as Destination Relay

February 21, 2008 – 1:38 pm

Email filtering service providers like Sentinare Messaging Solutions accept mail via MX records, filter out spam and viruses, and then, using SMTP, relay the email to the “destination relay”, which is your mail server at your customer site. Typically you can configure the filtering service provider to relay to either a FQDN (Fully Qualified Domain Name) or to an IP address.

There are implications with both. With a FQDN, you can change the IP and update the DNS without having to notify the email filtering service provider of the new IP address. The downside of FQDN is if you have DNS problems and the provider cannot look up the FQDN.

The upside of an IP is that it doesn’t rely on DNS. The downside is that you must notify your provider of any IP changes.

We at Sentinare Messaging Solutions prefer FQDN. You should have enough redundancy in your DNS to prevent any problems with DNS and this will make your life easier. By using FQDNs for your mail destination addresses, you have more control and flexibility. If the IP address of your mail server changes, you can control the destination server change and don’t have to notify your email filtering service provider of the IP address change.

Auditing Data Systems and Why Your ISP/ASP Must Do This

February 15, 2008 – 7:22 am

Many ISPs and ASPs have servers that are years old, with outdated and unmaintained software. This is a big problem for security because out of date software most certainly has security bugs that aren’t patched, rendering the server vulnerable to attack. Frequent system audits increase the reliability and security of any data system. They also keep the system free of “cobwebs” and the system administrators who maintain the system “fresh”. Too often, turnover and lack of audits cause certain subsystems to be forgotten.

Sentinare Messaging Solutions, Inc. audits their entire network every 6 months to coincide with the semiannual release of the next version of OpenBSD. Every server is recreated from scratch. Sometimes hardware is replaced; sometimes not, but in each case, the servers are all formatted and re-loaded with the latest version of OpenBSD and all application packages configuration files are audited. Only applications which are necessary are loaded. The systems are kept extremely clean this way and reliability and security are maximized.

How to Display Email Headers in Popular Email Clients

February 11, 2008 – 11:09 am

We’ve covered email headers in the past two posts. Today we’ll cover how to display them in two popular email clients, Microsoft Outlook and Mozilla Thunderbird.

Here is how to display the internet header in Microsoft Outlook:

  1. Right-mouse click on the email item for which you want to view the header.
  2. Click “Message Options”.
  3. At the bottom of the “Message Options” window, you will see the “Internet Headers” text box. You can copy and paste the text out of this text box if you need to send the header to your email support specialist.

Microsoft Outlook Headers

Here is how to display the internet header in Mozilla Thunderbird:

  1. Select the email item for which you want to view the header.
  2. Click “Control-U”
  3. The raw text of the email will pop-up in a new window.
  4. To send the header to your support specialist, copy from the top of the message source window to just above where the message body begins.

How to Read Received Headers

February 7, 2008 – 8:15 am

Yesterday I wrote about Email Headers. Today I will zoom in on the Received headers. We will take an example header and break it down line by line. Consider the following set of received lines from an email header:

Received: from mx1.sentinare.net (lausanne [10.2.28.23])
  by mailbox01.sentinare.net (Postfix) with ESMTP id 051AE1DDA79C
  for <chris.paul@rexconsulting.net>; Thu,  7 Feb 2008 12:27:45 +0000 (GMT)
Received: from mato.luukku.com (mato.luukku.com [193.209.83.251])
  by mx1.sentinare.net (Postfix) with ESMTP id 3B0385D6484
  for <chris.paul@rexconsulting.net>; Thu,  7 Feb 2008 12:27:45 +0000 (GMT)
Received: from suksi.luukku.com (www3.i.luukku.com [10.0.1.33])
  by mta3-g.i.luukku.com (Postfix) with ESMTP id 494F57FC04
  for <chris.paul@rexconsulting.net>; Thu,  7 Feb 2008 13:44:37 +0200 (EET)
Received: from suksi.luukku.com (localhost.hard.ware.fi [127.0.0.1])
  by suksi.luukku.com (Postfix) with ESMTP id 3DE743C002
  for <chris.paul@rexconsulting.net>; Thu,  7 Feb 2008 13:44:37 +0200 (EET)
Received: from null (APointe-a-Pitre-105-1-4-28.w81-248.abo.wanadoo.fr.
  [81.248.177.28]) by www3.luukku.com (luukku.com)
  with HTTP 1.0; Thu, 7 Feb 2008 13:44:37 +0200 (EET)

Now when we read email headers, we read them from bottom to top, so we will look at the last Received header first. This Received line shows where the mail originates from.

Received: from null (APointe-a-Pitre-105-1-4-28.w81-248.abo.wanadoo.fr.
  [81.248.177.28]) by www3.luukku.com (luukku.com)
  with HTTP 1.0; Thu, 7 Feb 2008 13:44:37 +0200 (EET)

We can see that it was received from “null (APointe-a-Pitre-105-1-4-28.w81-248.abo.wanadoo.fr. [81.248.177.28])” by “www3.luuku.com”. What this demonstrates is a user using what is sitting in the Caribbean (Guadeloupe to be precise) and most probably a webmail client at “www3.luuku.com” to send mail. We know that the user is in Guadeloupe because the IP address 81.248.177.28 resolves to “APointe-a-Pitre-105-1-4-28.w81-248.abo.wanadoo.fr” and “Pointe-a-Pitre” is the concentration point for internet connections to Guadeloupe. Note also it shows that the message was sent at Thu, 7 Feb 2008 13:44:37 +0200 (EET).

The next line shows the webserver handing it off to the local mailer at “suksi.luuku.com”:

Received: from suksi.luukku.com (localhost.hard.ware.fi [127.0.0.1])
  by suksi.luukku.com (Postfix) with ESMTP id 3DE743C002
  for <chris.paul@rexconsulting.net>; Thu,  7 Feb 2008 13:44:37 +0200 (EET)

This line shows that”www3.luuku.com” is most likely also named “suksu.luuku.com”, since the mail is received from “localhost”, or suksi.luukku.com (localhost.hard.ware.fi [127.0.0.1]) by suksi.luukku.com. This is common when webservers originate mail, since the web server process (say, apache) hands it off to the local mailer (typically sendmail or postfix). In this case, we can see it is Postfix since suksi.luuku.com puts (”Postfix”) in the Received header line it adds. We can also see that the mail envelope recipient is “chris.paul@rexconsulting.net”.

The next line shows the webserver we now know as “suksi.luuku.com” relaying to what is most likely the perimeter mail relay for luuku.com, mta3-g.i.luuku.com.

Received: from suksi.luukku.com (www3.i.luukku.com [10.0.1.33])
  by mta3-g.i.luukku.com (Postfix) with ESMTP id 494F57FC04
  for <chris.paul@rexconsulting.net>; Thu,  7 Feb 2008 13:44:37 +0200 (EET)

We can see that “mta3-g.i.luuku.com” is also a Postfix server. We can see again that the mail envelope recipient is “chris.paul@rexconsulting.net”. We also see the date again and that the mail has gone this far in under a second.

The next line shows “mato.luuku.com” relaying it to the MX server responsible for “chris.paul@rexconsulting.net”, “mx1.sentinare.net”. Wait a minute though? The machine that it was at last was “mta3-g.i.luuku.com”! How did it get to “mato.luuku.com”? Probably because “mato.luuku.com” and “mta3-g.i.luuku.com” are the same machine. It is common for machines to have different names by which they are known on the inside and outside of their own network. “mato.luuku.com” is the name it is known by to the internet. That is the name of its external address, 193.209.83.251.

Received: from mato.luukku.com (mato.luukku.com [193.209.83.251])
  by mx1.sentinare.net (Postfix) with ESMTP id 3B0385D6484
  for <chris.paul@rexconsulting.net>; Thu,  7 Feb 2008 12:27:45 +0000 (GMT)

Note that now the timezone has changed from EET (+0200) to GMT (+0000). So we can expect a 2 hour difference in the localtime. The last received line shows a relay at 13:44:37 +0200 and this received line shows a relay at 12:27:45 +0000, so this relay took 7 seconds (or someone’s time is a little off).

The next line shows delivery to the final mailbox server:

Received: from mx1.sentinare.net (lausanne [10.2.28.23])
  by mailbox01.sentinare.net (Postfix) with ESMTP id 051AE1DDA79C
  for <chris.paul@rexconsulting.net>; Thu,  7 Feb 2008 12:27:45 +0000 (GMT)

mx1.sentinare.net, the relay server responsible for “rexconsulting.net” seems to have an internal route to “mailbox01.sentinare.net” which is the mailbox server for “chris.paul@rexconsulting.net”. We can see that the mail reached its destination 7 seconds after it was sent, even though it made all these hops.

Knowing how to read an email header is useful. Now you can check to see the path a mail took and, if there was any delay, where the delay was.












				
				

How to Read Email Headers

February 6, 2008 – 8:21 am

An email header can tell you a lot about an email. It tells you the date it was composed and the sender of course, but it also can tell you the path it took to get to your mailbox. According to the internet standard which describes email body format, RFC-2822:

Header fields are lines composed of a field name, followed by a colon    (":"), followed by a field body, and terminated by CRLF.

The message header consists of fields, usually including at least the following:

  • Return-path: This is the “envelope sender”. This is the address that a mail server will use in bouncing undeliverable mail.
  • From: The e-mail address, and usually the friendly name of the sender. This is where an email client will reply to, generally.
  • To: The e-mail address(es), and optionally the friendly name(s) of the message’s recipient(s).
  • Subject: Added by the sender, this is a summary of the email.
  • Date: The local time and date when the message was written.
  • Received: These lines describe the path an email has taken on its way to you. This originates from the bottom-most Received line. To trace an email, you read the bottom one, then the next one up, then the next one up, etc., until you see it received by your email server at the top-most Received line.

Other common header fields include (see RFC 4021 or RFC 2076 for more):

  • Cc: carbon copy
  • Bcc: Blind Carbon Copy
  • Content-Type: Information about how the message has to be displayed, usually a MIME type
  • Reply-To: Address that should be used to reply to the sender.
  • References: Message-ID of the message that this is a reply to, and the message-id of this message, etc.
  • In-Reply-To: Message-ID of the message that this is a reply to.
  • X-Face: Small icon.

Multiple Layers of Defense for Email

January 14, 2008 – 10:32 am

Relying on just one form of protection (one layer of defense) for a given service is less safe than having more than one layer of defense protecting that service. For example, there is an often repeated analogy for security plans that rely only on firewalls: This is the cookie that is hard on the outside but soft on the inside, meaning that once the hacker penetrates the firewall, he is loose on the network, since there are no other layers of security protecting the network.

With an email box, the layers of security are:

  1. The off-site email filter: One example is Sentinare Messaging Solutions, Inc. This type of service will scan all your emails, removing the spam and virus before it reaches your network and your email server.
  2. Your firewall: You should be restricting SMTP access so that inbound port 25 (SMTP) is allowed ONLY from the off-site email filter company’s servers.
  3. Your email server: You should apply all the latest security updates on your server and on the operating system on which it runs. Also consider running anti-virus software on your server.
  4. Encryption: Encrypt as many TCP channels as you can with TLS: between servers and other servers as well as between the mailbox server and the clients.
  5. The client machine: Apply all the latest security updates on all users’ workstations.
  6. Client Antivirus: Despite the fact that a good email filter company has a 100% virus detection rate, as does Sentinare, the whole idea of “Multiple Layers of Defense” means that you want to have a backup protection on the client just in case. Besides, email is not the only vector for viruses. Many viruses spread via websites today as well as email.