We published a new article regarding email backscatter at

http://www.vamsoft.com/howto-stop-backscatter.asp

We tried to answer as many questions as we could, hopefully you will find this article useful.

As you may have already read on our Facebook page, we have moved to a new office, so our postal address, phone and fax numbers have changed:

Vamsoft Ltd.
Budapest
Rétköz u. 5.
H-1118
HUNGARY

Phone: (+36) 1 999 0603
Fax: (+36) 1 700 2820

I just came across an elegant alternative to our Self-Spam Agent (which stops spam sent in your name) in Alan Hardisty’s blog. While Alan’s solution takes at least Exchange 2007 and the Self-Spam agent will support Exchange 2000 and newer + IIS SMTP, it is a beautiful demonstration of what Exchange 2007 can do for you.

The ORF team will make an appearance at the annual Infosecurity exhibition in Brussels at the end of March. The event will be at the Brussels Expo on 24-25 March in Hall 8.

We will be going around the floor all day, so if you want to meet us in person send us an email (orf@vamsoft.com), we will be around on both days.

It has been a while since I last compiled our own ORF statistics using the Reporting Tool and what I am seeing is that SURBLs are taking over DNS Blacklists.

Is it just us, or are SURBLs really taking over? You can check your statistics in the Test / Summary section of any ORF report created with the ORF Reporting Tool.

UPDATE: Actually, there’s an explanation for this. Recently we switched to all-On Arrival filtering on our server and that means SURBLs are tested earlier than DNSBLs (see General Information / Test Order and Priority in the ORF Help), hence the more emphasized role for SURBLs.

That does not change the fact that SURBLs alone do a great job. ORF cleans up the the traffic step by step and 30% of what’s reaching SURBLs is cleaned up by them, leaving behind a much more legitimate traffic for DNSBLs, which cleans up another 8%.

Microsoft introduced the Edge and Hub roles in Exchange 2007. The idea was to separate the perimeter (gateway) functions in order to perform filtering before the email reaches the central server. This includes recipient validation, i.e. to reject all emails sent to non-existent recipients. This is performed by an Exchange transport agent called the “Recipient Filter Agent”.

The Active Directory-based Recipient Validation of ORF is not available on Edge servers, because the Edge server do not have direct access to the AD, so ORF cannot query the valid recipients. This would not be a problem, (since Edge will reject emails sent to non-existent recipients anyway), but the Directory Harvest Attack (DHA) Protection test of ORF relies on the recipient validation of ORF, so that test will not be available on Edge (unless you use TXT or SQL-based recipient validation).

Moreover, as the Honeypot test relies on spam emails sent to non-existent email addresses (which you published to lure spammers), that won’t work either, because Edge will reject spam before ORF could record the delivery attempt to the Honeypot database.

Luckily, we can work the latter problem around by configuring the Trasport Agent of ORF to run before the Recipient Filter Agent:

1) Start the Exchange Management Shell
2) Enter the following command:

Get-TransportAgent | Format-List

3) ORF has two agents, the “Vamsoft ORF Routing Agent” and the “Vamsoft ORF Receive Agent”. You should set their priority of the latter higher than the priority of the “Recipient Filter Agent”, so it would run first.

To change the priority (e.g. to 7), run the following command:

Set-TransportAgent -Identity “Vamsoft ORF Receive Agent” -Priority 7

4) Finally, restart the MSExchangeTransport Service to apply the changes:

Restart-Service MSExchangeTransport

This way, the Honeypot test is performed before the email is rejected by the recipient validation of Edge.