I believe, like other professions, a career in security is a practice, a never ending relentless pursuit of preventing information loss or compromise. It could be occurrences such as fires, disk failure, and the accidental “Reply All:” or due to a person(s) malicious intent. For the most part at this point in my topic, it all will be considered the same term, a risk. Security in an organization has to follow a few unwritten rules to be successful. Clearly defined, Easy to replicate, Effective in cost and implementation as well as being simple during its promotion. Each time I have seen or read of difficult security projects at least one of these items, if not more, were missing.

“Clearly defined security projects”, means that the project or product has a qualitative impact providing quantitative results. The final implementation needs to have observable positive differences to the “techie” and provide measurable results for the “C” levels. This can be the most difficult area to complete. After all, what kind of measurable results does whole disk encryption software provide? If you can’t answer the “measurable” question then the technology either probably doesn’t fit in your environment or there is an issue matching the product to satisfy a need such as compliance.

Easily to replicate security practices are also essential to success. A security practice should be a set of tools that is fed a problem or potential risk and in all of its glory and might turns out a refined lean statute. One that provides quality protection along with the highest possible availability to its consumers. A proper Information Security Management System (ISMS) will provide an organization with a sweet suit set of tools.

Security that is effective in cost and implementation is the make or break deal. Like any other department in a company, a sound future plan with adequate funding will ensure turn by turn navigation to successful projects/products. Security can be like insurance, it is possible to have far too much of it. A solution may seem to be the best fit for an organization, except that cost capping 120% of the security/IT budget it is just not feasible. Speaking of budgets, what is yours? If you can’t answer that, I will follow up with information that will hopefully help you figure that out.

Simple to promote means that you won’t hear that unanimous sigh of discontent moments after clicking send on the email explaining what the solution is. That is not to say that haters aren’t going to hate, because they will. “Another login, no way, I don’t care what it does, I am not doing it.” If the solution is indeed the best fit, every reasonable user will comply and see the value add from the solution. Pre-Sale as much as possible to those that will be effected most and make sure their input is heard and considered. If everyone hates the solution, no matter how great it is, trust me, it will fail.

So “What do I do?” IT Security Solutions. To many of my friends this will still translate to “computer stuff, right?”

So, I looked at the normal things that may cause that; are they on a blacklist, does the RDNS record exist and is it valid, can I email AOL/Gmail/etc (those will point out most issues), does the sending server show a clean record of delivering said items. Everything in this case proved successful. So I ran the messages, the same messages getting blocked through 2 different spam engines and look at what it was giving them a rating as. Barracuda and MailScanner/SpamAssassin showed the message in the negatives (perfectly fine) and were far from scoring a blockable item.

I started searching Microsoft’s sites to find out if there is an issue with Exchange 2007 failing to send out mail without providing an NDR. After several white papers I found that the problems were in the “Received:” and “Thread-Index:” message headers of the email. Custom rules were created at the recipient locations that blocked the message if the “Received:” routing information was not verifiable or the IP addresses in the header were anything other than the matching RDNS MX record.

There are a couple of different ways to correct this. For this specific scenario, where an Edge Transport server was utilized, removing not only the edge transport server from the permissions regarding the “Send Routing Headers” rights.

In the Exchange shell this would be:
Remove-AdPermission -identity “EdgeSync – ” -User “MS Exchange\Edge Transport Servers” -ExtendedRights MS-Exch-Send-Headers-Routing

(without an edge transport)
Remove-ADPermission -id “Organization to Internet” -User “NT Authority\Anonymous Logon” -ExtendedRights Ms-Exch-Send-Headers-Routing

This can also be accomplished by using ADSIEdit.msc and right clicking on “CN=Configuration -> CN=Services -> CN=Microsoft Exchange -> CN= -> CN=Administrative Groups -> CN=Exchange Administrative Group -> CN=Routing Groups -> CN=Exchange routing Group -> CN=Connections -> CN=”Select Send Header Name” Once there go to properties -> security -> Advanced. Here you can change the accounts permission on the Send Routing Headers and remove any “Account Unkowns”, Anonymous Logon and/or Edge Trasport users. By removing them from the permissions list it will also take them out of the Organization and Forest Header information. This seems to have takent the Thread-Index issue from getting caught as spam as well.