Monthly Archives: December 2009

SMTP event sinks under Windows Server 2008 R2

Following a server meltdown our new computer serving vamsoft.com was set up with Windows Server 2008 R2 (after running on 2003 for years). The installation itself went smoothly. The IIS 7 included in 2k8 is quite different from the previous version so I had to make a few adjustments – and learn a few new things -, but the real challenge begun when I started registering the smtp event sinks.

Started with the usual registering commands in a batch file, but the result was not familiar:

cscript smtpreg.vbs /add 1 onarrival NoreplyHandler CDO.SS_SMTPOnArrivalSink “rcpt to=noreply@*”
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

Binding Display Name Specified: NoreplyHandler
** Registration Failed **
Err.Number (HRESULT) = 0×46
Err.Description = Permission denied
ProgID = CDO.SS_SMTPOnArrivalSink
COM Category = {FF3CAA23-00B9-11d2-9DFB-00C04FA322BA}
Corresponding Event = onarrival
** Have you registered your sink COM class on this machine?

The error I got is “Permission denied” – of course, I have to run it with administrative privileges. But wait, I _am_ running it with such privileges!
Had no clue on what is happening. Checked if the mentioned class (CDO.SS_SMTPOnArrivalSink) is registered or not – it was. Checked NTFS permissions on cdosys.dll – seemed OK (I even granted full access to Everyone with no luck). That was time for… wait for it… Process Monitor! (great tool, indeed)

Process Monitor - cscript.exe smtpreg.vbs access denied

Process Monitor - cscript.exe smtpreg.vbs access denied


And there it was: cscript.exe (the process running smtpreg.vbs) is failed to get write access to the registry for the entry HKCR\CLSID\{CD000005-8B95-11D1-82DB-00C04FB1625D}, which is the CLSID of “SMTP OnArrival Script Host Sink Class”. Since smtpreg.vbs is something I do not want to mess with, I decided to go with the easier solution: give write permissions to admins for the forementioned registry key.

We all know the drill: regedit, search for the CLSID, right click, Permissions, check “Full Control” for the Administrators group, Apply… and got “Cannot set permissions … – access is denied”. This is because only the TrustedInstaller user has “Full Control” permissions over these registry keys, others only has “Read” access.

The solution: take ownership of this registry entry (right click on the entry / Permissions / Advanced / Owner tab / Change ownership to administrators). After applying the changes I was able to give Full Control to Administrators and run smtpreg.vbs successfully.

cscript smtpreg.vbs /add 1 onarrival NoreplyHandler CDO.SS_SMTPOnArrivalSink “rcpt to=noreply@*”
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

Binding Display Name Specified: NoreplyHandler
Assigning priority (24575 in 32767)
** SUCCESS **
Registered Binding:
Event Name :SMTP Transport OnSubmission
Display Name:NoreplyHandler
Binding GUID:{8CA00335-FF90-47E6-A1F2-BAA29926EFDC}
ProgID :CDO.SS_SMTPOnArrivalSink
Rule :rcpt to=noreply@*
Priority :24575 (0 – 32767, default: 24575)
ComCatID :{FF3CAA23-00B9-11d2-9DFB-00C04FA322BA}

cscript smtpreg.vbs /setprop 1 onarrival NoreplyHandler Sink ScriptName “c:\smtp_ext\noreply\noreply.js”
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

Binding Display Name Specified: NoreplyHandler
set property ScriptName to c:\smtp_ext\noreply\noreply.js

The sink quoted above is a simple SMTP event sink that consumes emails sent to a given address, as we do not want to deal with emails arriving to noreply@ addresses. There are many other things that event sinks are usable for. If you are interested in this powerful technique we have a few sample event sinks on our web site to start with:
Simple Attachment Filtering
Remove Read Receipt Requests on The Server

Avast! bug affecting ORF

Yesterday, an Avast! anti-virus database update came with a serious bug. We (and others) suspect that by VPS version 091203-0, all applications written in Delphi were being marked as “Win32:Delf-MZG (Trj)”.

ORF was written in Delphi as well, so Avast! might have prevented ORF from filtering emails, or it might have moved ORF the executable(s) to the virus Chest. If you use Avast! and ORF on the same server, please make sure you restore these files as follows:

1. Right click the Avast! icon near your clock and choose Start Avast!
2. Cancel any scans Avast! tries to start
3. Click on the Chest icon: a list of quarantined files will appear
4. Right clicking on any file and select “Refresh all files” to make sure all files in the chest are listed
5. Right click on the files of ORF, select “Restore file” to restored them to their original location and at removed them from the Chest.

The bug has been fixed since by VPS version 091203-1, so make sure you use the latest definition file.