Exchange 2003 SP2 allows you to use Sender ID to help identify potential spam. When it's enabled you can choose to include add the SPF value to the message as a MAPI property for use by IMF and pass the message along or drop the message. As I mentioned in the last issue of EMO, at this point in time Sender ID is not very useful for judging the legitimacy of a message. Not enough sites have SPF records configured in DNS, which means it can only be a small part of your anti-spam arsenal. Also, there is nothing to prevent spammers from creating SPF records, so the presence or absence of SPF records is no guarantee the message is from a spammer.

But why take my word for it when you can see the usefulness (or lack of) within your own organization? All you need to do is turn on Sender ID on the Exchange 2003 SP2 server and look at the MAPI property value assigned to your messages, using a custom form file which exposes MAPI property fields for use in a custom view.

Don't panic. It's much easier than it sounds, especially since Konstantin Ryvkin from the Exchange team did all the work for you. He posted the contents of the necessary cfg file on the Exchange team's blog, You had me at EHLO. All you have to do is copy and paste it into a text file and save it using the extension cfg then add the view to your field. Complete details are at http://blogs.technet.com/exchange/archive/2005/10/13/412487.aspx, including instructions on adding the fields to your view.

Once you add the Sender ID field to your view, you'll see a number listed in the column on all newly received email. This code corresponds with the following Sender ID values:

1 - Neutral: the domain records make no assertion that the IP address is valid for sending mail
2 - Pass: the client is authorized to send mail on behalf of the domain
3 - Fail: This means one of the following: the sending domain does not exist, the sender is not permitted, it's a malformed domain, no PRA (Purported Responsible Address) was found in the header, or the client is explicitly NOT authorized to send mail on behalf of the domain.
4 - Soft Fail: the client might not be authorized to send mail on behalf of the domain.
5 - None: No Sender ID records are published for this domain. This is the most common value at this time.

Temporary error: the receiving server encountered a transient error when performing the check
-2147483641 - Permanent error: the domain's published records couldn't be correctly interpreted.

So, how accurate is Sender ID at identifying spam? In looking at the Sender ID values on the email in my mailbox, it's not very good. Most of the messages that make it past the anti-spam filter on the server are from domains that do not have SPF records, including a number of well known sites that publish email newsletters about technology in general and Exchange specifically. I expected they would be first in line with published SPF records.

Soft failures appear to be common with hosted mail servers. Permanent error values are found on messages that qualify as solicited junk email (i.e. advertising from companies I do business with), because the sites created Sender ID records but used a format Exchange doesn't understand, such as this one for the email servers used by Handango: rm04.net text = "v=spf1 ip4:129.41.69.0/25 ip4:129.41.76.0/24 ip4:129.41.77.0/24 -all"

Because it's interesting to see who is using SPF and who isn't, I recommend enabling it in Exchange 2003 SP2 and configuring the custom form to display the values.

You can also use a cfg to expose the SCL value added by IMF...
http://www.slipstick.com/emo/2004/up040610.htm#monitor

...and display the sender's actual email address
http://cameron-webb.com/blog/archive/2005/10/20/639.aspx

This issue of Exchange Messaging Outlook includes articles contributed by two Outlook MVPs. Judy Gleeson, from Acorn Training (http://www.acorntraining.com.au/) is big on teaching her students how to use Outlook productively. In her articles she explains how to use labels to Outlook 2003 towards this end. Jocelyn Fiorello writes about sharing calendar and contacts without the benefit of Exchange server.

These days, with a PC in just about every home and with many households equipped with computers for almost every member of the family, it's not surprising that we often see questions in the Office Community Newsgroups about sharing Outlook data and folders between family members. While Outlook 2002 and 2003 do not provide any built-in methods for sharing data between computers, there are ways it can be done - and it's quite easy to accomplish if all of the users involved are using the same PC.

If each user on a single PC has his or her own Windows login, they can choose to have all of their data separate from each other (including incoming e-mail), or they can opt to put some or all of their data in a central location so that it can be accessed by everyone. For example, suppose a family would like to create a central calendar, but none of their other data needs to be shared. As illustrated in http://www.slipstick.com/outlook/olshare1.htm, one user can set up a new calendar folder in a new .PST file (with a unique name to avoid confusion with the default file) and put that file in a folder accessible to all of the Windows users. Then, each user can add the calendar .PST file to his or her Outlook profile and it will be available to them every time they use Outlook.

Sharing data between computers is a bit trickier. A .PST file can be stored on a network share drive, but this configuration is not supported by Microsoft, and with good reason: if the share goes down while the .PST file is open in someone's copy of Outlook, the risk of data corruption is great. Another limitation of putting the .PST file in a shared location is that, without the help of a 3rd party add-in, only one copy of Outlook can open that .PST file at any given time. Fortunately, there are numerous 3rd party products on the market that provide various ways to share data between PCs without having to turn to an expensive, large-scale solution. Alternatively, if you are the primary user of all the machines in question, you may wish to simply synchronize your data between the machines rather than sharing it.

See the following Slipstick articles for more information:
http://www.slipstick.com/outlook/share.htm
http://www.slipstick.com/outlook/sync.htm

The Outlook calendar can be colour coded and printed in colour in Outlook 2002 and 2003. This function is called Labels. You can change the Labels associated with each colour by right clicking on an appointment, selecting Label and Edit Labels... You may for example, wish to colour by project name or type of work. This is useful when viewing your weekly or monthly calendar and the labels are per folder, so each calendar folder can have a different set of labels.

However, if you use the Edit Labels feature to change the text for a Label, be sure to keep a list of the original Label text and the new text. You'll need the original text if you want to filter or group by the Label field or if you want to make a new view of the Calendar that filters by Label. It's a bit daft, but if you try to group by the Label property, Outlook displays the original Label names, not your customized names.

Outlook 2003 extends the automatic formatting feature to the Day/Week/Month view using the colour Labels. Right-click anywhere in a day/week/month view calendar, and choose Automatic Formatting. For example, you can use automatic formatting to create a rule that looks for every appointment where the subject contains "birthday" and set those appointments to use the purple Birthday colour. This would also work for a key project name or a client's name.

To apply labels in bulk to existing appointment items without using automatic formatting, create a new table view and set it to group by the Label property. You can then drag items from the Label:None group to the group whose label you want to apply to those items. Remember that table views use the built-in label names and ignore the names you may have customised, so keep that list of your customisation handy.

If you have Exchange and use Public Folders, you may want to set up a Calendar that is the equivalent of a wall planner but is accessible to selected people. For example, the Calendar could show the planned marketing events in various colours depending on the type of event. Or you could make a Staff Leave calendar and use different colours for the type of leave, eg maternity leave, rostered day off, sick day, annual leave etc.

Even if you don't have Exchange, making a separate calendar where you apply coloured labels is a practical way to store data about your plans. With a colour printer, you have a nice way of seeing your plans and showing them to others. You can make a Calendar by right clicking in your folder list | New then type the name of the Calendar and make sure to change the format of the folder to Folder contains Calendar items.

Before you enable filtering for Sender ID records at your site, you should verify that you have a valid SPF record for your domain configured in DNS. This isn't because you need your own SPF records to use Sender ID with Exchange, but because it's not right to hold incoming mail to higher standards than others can apply to the email you send. Plus, it adds one more domain to the short list of domains who currently have SPF records.

If you don't already have an SPF record, create one using the wizard at http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx and enter it into your DNS records.

After creating the record in DNS, you can find out if your record is valid by sending a message to your gmail account (or another email server that supports SPF) and view the message source. If your record is correct, the message header will have a line similar to this, indicating it passed.

Received-SPF: pass (domain of [sender's address] designates [IP address] as permitted sender)

If it failed, review your SPF record for errors and try again.

Once your SPF records are in place, enable Sender ID filtering on the Exchange server. Open the Exchange System Manger and navigate to Global Settings then view the Message Delivery property sheet. Verify it is set for Accept and close the dialog.

Tip: If your Exchange server receives mail from another SMTP server within your network, add that server's IP address to the Perimeter IP list on the General tab before closing the dialog. You'll need this configured if you decide to enable other filtering options on the SMTP server.

Next, navigate to the SMTP server node and view its properties sheet. On the General tab click the Advanced button then select the IP address and click Edit. Enable Sender ID filtering, as well as any other filters you desire. Repeat as needed for each IP address assigned to the SMTP server and close the dialog. From this point forward, all mail that goes through this SMTP server should have a Sender ID value attached to it.

Once you create some custom views in Outlook, you can judge for yourself how effective Sender ID might be in your organization.