Spam doesn’t normally catch my attention, but this particular piece of spam left as a comment on this site really caught my eye. I’ve read spam emails before, but never this ridiculous.

{Dear Sir. Mr. Dr. D.I.}
i am mr simon okoye from london,,the Executive director operations intercontinental Bank plc Branch london,28years in Banking system guideline,58 years of age on earth also a married man with three children two boys and one girl,below are there name,pius okoye,peter okoye,olivia okoye,also my wife merry okoye,

So Mr and Mrs Spammer and their three little Spammer kids say hello.

Please take my good day, how are you today,I hope all is transferring very well if so doxology.

Things are transferring very well thanks, and doxology to you too.

SwitzerlandworldBank was confirm about,the money on July 3rd1997, the owner of the money late, Mr,chife, sir, rocky-tiger-king-from isreal

I want to change my job title to Rocky Tiger King now.  From Israel is optional though.

address 22 abarbanel st apt 31 {attn c/o tzur,family rishon 75309 isreal nationality isreal citizen occupations computer formal bank director , age 46 date of birth 23-02-1962 late sir,was the formal executive bank director operations at mercantile discount bank limited isreal bank ,on the years 1994,17 branch 668 rishon lezion isreal ,

I think he’s saying the guy is from Israel… land of the rocky-tiger-kings.

Help to forward this to convert all the documents with
your name backups at Intercontinental bank Plc.
(Forward needed {to i.e.} Boss/Director)
{Your picture and what your occupation is}
{Your telecommunication number}
{Your account detail address of the bank}
{Your account signature}
{Your age and also your fax number}
{Your wife age and occupation}
{The number of your children and what their occupation is}
{The age of your father}
{The age of your mother}
{Your identity card number}

Consider it done Mr Okoye!

Are a must know
1,Bankers need to keep account records
2,Doctors need to keep patient report
3,Lawyers need to keep client report
4,Engineers need to make presentation
5,Secretary need to keep office record
6,Company need to keep trues record
7,Student need to make themselves globally relevant,
this are what the lord almighty created on his world

This is after he explained in great length how the US$965 million would be paid to me in 92 installments.

I promise you that all the money would be transferred into your own account and bear this in mind that all the money would be dividend into 70% is to 20%by 10%

Deep in my heart I want to believe him!

Thanks and Topic by (SA)
Mr. Simon Okoye Director (ie) Bank, and john Anth
Confirm (Sec) Bank.
Yours faithfully,
The Lord bear with us - Amen.70%, 20%.by 10%
THE EXECUTIVE DIRECTOR OPERATIONS INTERCONTINENTAL BANK PLC BRANCH LONDON,

Amen.70%, 20%.by 10% brother.

Microsoft has released their own white paper containing guidance on configuring Exchange 2007 for Address List separation.  This is something that was pretty easy in Exchange 2003, but suddenly made a lot more complicated and less obvious in Exchange 2007.  A bunch of home brew solutions came about some time after Exchange 2007 was released and now Microsoft’s white paper has the prescriptive guidance (which is basically the same as some of the better home brews out there).

Why segregate Address Lists?

Some larger organisations look for segregated Address Lists as a means of improving the relevancy of the Address List objects that users are seeing in their Outlook address book.  Why see all 20,000 global employees when really you only need to see the 1000 employees and distribution lists in your country (especially since smart admins lock down distribution lists so people can’t send rubbish emails to “All Staff - Global” for example).  Here is Microsoft’s word on the matter:

Address list segregation is a process whereby administrators can segment their users into separate groups and implement security policies so that groups of users can see only their specific address list. The ability to restrict access to address lists in this manner may be used as part of the toolset for helping companies meet their internal security requirements and as part of a regulatory compliance strategy for meeting the requirements dictated by the Health Insurance Portability and Accountability Act (HIPPA), and the Sarbanes-Oxley Act.

It is useful to illustrate how address list segregation can be implemented by way of examples. Suppose your company, Contoso, purchases the company Fabrikam. The management team determines that they want to manage Fabrikam’s entire IT infrastructure, but they want the employees of Contoso and Fabrikam to be completely segregated so that they are only able to see other users and resources from their respective companies. By implementing address list segregation, Contoso administrators can meet this requirement for all Exchange Server 2007 functionality.

Another scenario is the “Virtual Organisations” mentioned in the White Paper title, which I think is code for hosted Exchange providers.  Last year I worked on deploying a hosted environment that included Exchange Server 2007 and that is how I encountered all of the difficulties with configuring Exchange 2007 in this fashion (and came across the home brew solutions).  Microsoft calls it “Virtual Organisations” but I think that is because they are not recommending you use this solution for hosted Exchange services.

It is also important to understand that attempting to configure Exchange 2007 as a commercial “hosting” solution is not recommended.

The configuration described in this document is complex in nature, and while it can be effective in smaller environments or in limited scope, it can become very challenging to manage such a configuration as the scope of the deployment increases if automation steps are not implemented.

It is conceivable that an organisation that has developed suitable account management scripts in their hosted environment could solve this scalability issue.

Here is the anti-spam configuration on an Exchange Server 2007 RTM server:

[PS] C:>Get-AntispamUpdates   

UpdateMode                  : Automatic
LatestContentFilterVersion  : 3.3.4604.600
SpamSignatureUpdatesEnabled : True
LatestSpamSignatureVersion  : 3.3.4604.600
IPReputationUpdatesEnabled  : True
LatestIPReputationVersion   : 3.3.4604.001
MicrosoftUpdate             : NotConfigured

And here is the same Exchange Server 2007 server immediately after upgrading to Service Pack 1:

[PS] C:>Get-AntispamUpdates   

UpdateMode                  : Disabled
LatestContentFilterVersion  : 3.3.4604.600
SpamSignatureUpdatesEnabled : False
LatestSpamSignatureVersion  : 3.3.4604.600
IPReputationUpdatesEnabled  : False
LatestIPReputationVersion   : 3.3.4604.001
MicrosoftUpdate             : NotConfigured

The Service Pack 1 installation disabled the Anti-spam engine updates. This stung me on a production system that I upgraded shortly after the SP1 release. Eventually someone in the office mentioned the ever increasing volume of spam emails to me and I subsequently made this discovery.

Sadly the Release Notes do not seem to include this issue.

In prior versions of Exchange an organisation that wished to restrict who could send outbound internet emails could apply the restriction on an SMTP connector.  In this example emails sent to the * address space are rejected by default unless sent by a group listed in the “Accept messages from:” list, for example a group named “Internet Email Users”.

Exchange Server 2007 uses Send Connectors for configuring where outbound internet email is delivered, much like an SMTP connector in Exchange 2003 Server.  However, the Send Connector is not the place to apply restrictions on who can send outbound internet email.  These restrictions are instead applied with Transport Rules.

If you are new to the concept of Transport Rules you should read Understanding How Transport Rules Are Applied In An Exchange Server 2007 Organisation.

To configure the restrictions you create a Transport Rule that follows the same “Deny by default, except if from these groups” approach as Exchange 2003 Server.

Configuring a Transport Rule to Restrict Outbound Internet Email

1. Create a distribution group through your Exchange Management Console, and give it a descriptive name such as ”Internet Email Users”.
2. In the EMC go to Organization Configuration -> Hub Transport, and click on the Transport Rules tab.
3. Create a new Transport Rule, name it something like “Restrict Internet Email”
   
4. Select “Sent to users Outside the organisation” as the first condition.
   
5. Select “Send bounce message…” as the second condition, and configure a bounce message that will be informative enough for your end users.
   
6. Select “Except when the message is from member of distribution list” as the exception criteria, and add the Internet Email Users group that was created earlier.
   
7. Complete the Transport Rule wizard so that the rule is created in the Exchange Organization.

It may take a short time for the rule to replicate to all Hub Transport servers throughout your Active Directory sites.  Because the rule is applied by Hub Transport servers, messages do not have to traverse the network all the way to the last outbound hop before being rejected by this rule.  Instead they are rejected by the Hub Transport server within the Active Directory site in which the user’s Mailbox Server is located.

The Hub Transport server caches recipient and distribution list information for four hours, so if you have a rule such as this in place and add new users to the Internet Email Users group, those users may not be able to start sending outbound internet email until the recipient cache has refreshed on the Hub Transport server.  Where this is not acceptable you can restart the “Microsoft Exchange Transport” service on each Hub Transport server which will initiate a cache refresh.

Jeff Jones posted a blog entry to celebrate Red Hat fixing their 1000th unique security vulnerability.  He also draws attention to a Red Hat post on their “Truth Happens” blog back in August, which itself quotes a post on Lxer.com.

Jeff posts quarterly statistics on his blog that show how many vulnerabilities have been patched for various operating systems.  The LXer.com post takes one of his reports and uses it to demonstrate that Linux is more secure than Windows because Linux vendors fix more security vulnerabilities.

A Microsoft vulnerability report suggests that Microsoft wasn’t able to fix more Windows flaws than the number of open software flaws fixed by the major open source companies . Red Hat, having forty times less employees than Microsoft, did the best job, by fixing and closing the most security bugs, also closing even minor bugs - where Microsoft didn’t even fix one minor bug in the same period. Even Apple did a better job than Microsoft by fixing lots of flaws in Mac OS X.

Jeff found this to be a little amusing.

Seriously, I loved this post, it made me laugh out loud!  Fixing more security vulnerabilities is apparently a good thing in the world of Red Hat Truth.

Well, for those who actively support that theory, I have some fantastic news for them!  According to my calculations, in July 2007, the Red Hat Enterprise Linux 4 team fixed their 1000th unique security vulnerability.  Now, 164 of these were Low severity and 479 were Medium severity, but still, that is a ton of work accomplished by that team, especially given that the product only shipped in February of 2005.

To put that in context, (again by my calculations) Microsoft has fixed only 649 security vulnerabilities for all supported products across the company since the year 2000.

I’m not sure what to think.  Jeff is quite clear on how his reports are generated.  Linux supporters used to tell me that fewer vulnerabilities meant a product was more secure.  Now Linux supporters want to say that more vulnerabilities means the product is more secure, or as one comment on LXer.com puts it:

You spin the data by saying “we fixed the most bugs, leaving the fewest bugs in the new code, therefore we are the best.”

Round and round we go.