The Kelly Company and Shamrock Logo
DAWKCo(tm) Software: e-Mail POP3 Server, SMTP Anti-Spam eMail Blocker, WebMail, Web Site Mapper, Website Design
 
Software Websites News Favorites Contact



Advanced Search

Sitemap






 
Message Board Posting: Software Topic

The content of these postings are the words of the persons posting the messages and do not necessarily reflect the views or opinions of the owners or operators of this web site.

[Software Topic Messages] [Message Board Terms Of Use]

Subject: Re: Open Relay Filter
Posted by: DAWKCo Tech Support
Date: Wed, 17 Mar 2004 17:58:42 -0500
In Reply To: Open Relay Filter posted by John Rohland on Tue, 16 Mar 2004 22:17:29 -0500
Message:

John,

It so happens that we will be releasing a blocking/filter solution for the IIS SMTP service in the near future.

However, in the interest of eradicating Spam and all other forms of mail abuse, we are willing to provide the following information for anti-spam and anti-virus software vendors and developers who wish to synchronize access to the SMTP Drop between their processes and the DAWKCo POP3 Server's MailDaemon e-Mail Routing Service process.

The DAWKCo MailDaemon service uses a system global named Mutex (Mutual Exclusion) synchronization object to synchronize access to the SMTP Drop between the multiple threads of the MailDaemon process.  Mutexes are system global objects, so they can also be used for inter-process synchronization.

The Mutex name used for synchronizing access to the SMTP Drop, as shown in the code fragments below, is:

MailDaemon/Drop

Note that Mutex names are case sensitive.

The following are some generic C++ code fragments that show how a service process can obtain a Mutex to synchronize access to the SMTP Drop.  Note that some of the DAWKCo MailDaemon service threads watch the SMTP Drop folder for changes, and when a new file is detected, they delay 77 milliseconds before attempting to get ownership of the Drop Mutex.  That is to allow for the SMTP Server to complete its processing of possibly large message files.  That 77 millisecond delay is a window of opportunity for other processes to jump in and get ownership of the Drop Mutex ahead of the MailDaemon.

It is important to note that message file processors should relinquish the Drop Mutex as soon as possible to avoid preempting the MailDaemon from routing message files due to having the SMTP Drop locked too much of the time. Message processors that perform lengthy operations should move the message files to an alternate/temporary location and relinquish the Drop Mutex prior to processing the message. Afterward, the message must be moved back into the Drop.

In that case, the file move operation should be accomplished with a Copy and Delete sequence to avoid message file loss if an error occurs, and to allow parent folder permissions to be inherited by the file.  Also, if moving message files is required, the files should be moved to (and processed) somewhere outside the SMTP mailroot folder hierarchy to avoid conflicts with the SMTP Server and DAWKCo MailDaemon services.  Note that obtaining a Drop Mutex is not necessary when a file is being copied back INTO the SMTP Drop folder.

// mdsync.cpp : C++ example code fragments demonstrating how to
//              synchronize access to the SMTP Drop between the
//              DAWKCo MailDaemon service and other processes

// compile with the /GX or /EHsc C++ compiler option
// that is, enable synchronous C++ Exception Handling

#include <windows.h>
#include <winnt.h>
#include <tchar.h>

// ...

// system global Mutex name for synchronized access to the SMTP Drop
#define MDDROP_MUTEX_NAME   _T("MailDaemon/Drop") // case sensitive

// example thread function return codes
#define ERROR_MUTEX_EXISTS      99998L // arbitrary; not a Win32 code
#define ERROR_CAUGHT_EXCEPTION  99999L // arbitrary; not a Win32 code

// ...

// generic example for an application-defined thread function
// depending on app., param may not be needed (if not, set to NULL)
DWORD WINAPI SomeThread(LPVOID lpThreadParam)
{
HANDLE hDropMutex = NULL;

try { // use C++ Exception Handling

  // init SD and SA with NULL DACL for service access to Mutex
  SECURITY_DESCRIPTOR sdSD;
  SECURITY_ATTRIBUTES saSA;
  InitializeSecurityDescriptor(&sdSD, SECURITY_DESCRIPTOR_REVISION);
  SetSecurityDescriptorDacl(&sdSD, TRUE, (PACL)NULL, FALSE);
  saSA.nLength = sizeof(saSA);
  saSA.lpSecurityDescriptor = &sdSD;
  saSA.bInheritHandle = FALSE;

  // get system global named Mutex for synchronized access to Drop
  hDropMutex = CreateMutex(&saSA, FALSE, MDDROP_MUTEX_NAME);
  if (!hDropMutex) return GetLastError(); // system error
  if (GetLastError() == ERROR_ALREADY_EXISTS) { // already owned
   CloseHandle(hDropMutex);
   return (DWORD)ERROR_MUTEX_EXISTS;
  }

  // try to get ownership of Mutex
  switch (WaitForSingleObject(hDropMutex, (DWORD)1)) { // 1 ms
   case WAIT_OBJECT_0: // OK, got clean ownership
    break;
   case WAIT_ABANDONED: // got ownership, but not reliable
    ReleaseMutex(hDropMutex);
   default: // failed--no ownership
    CloseHandle(hDropMutex);
    return (DWORD)WAIT_TIMEOUT;
  }

// do custom message Drop file processing here--move the file first
// and release/close the Mutex before doing lengthy processing

  ReleaseMutex(hDropMutex);
  CloseHandle(hDropMutex);

// NOTE:  you MUST release and close Mutex handle before exiting

  return 0; // success

} // end of try {} block
catch(...) { // handle all exceptions not otherwise handled

  // Mutex handle MUST be released and closed in all scenarios
  ReleaseMutex(hDropMutex);
  CloseHandle(hDropMutex);

} // end of catch(...) {} block
return ERROR_CAUGHT_EXCEPTION;
} // end of SomeThread


-----Original Message-----
: I recently installed a product called Open Relay Filter (Enterprise Edition) (ORF) (http://www.vamsoft.com/orf/). This is an add-on to IIS SMTP which checks email against a series of rules and open relay lists. This is a VERY nice program, however, it has a problem with POP3.
: ORF works like POP3 in that it grabs email from the DROP folder, processes it (decides if it should be deleted, etc.) or leaves it alone if it is legit. Of course ORF and POP3 are both trying to grab email from the DROP folder at the same time. Sometimes POP3 wins and sometimes ORF wins. Either way, this is a problem.
: As a temporary fix, I have SMTP dropping email into a different folder. ORF processes it from that same folder then, I have a looping batch file move the *.EML files into the DROP folder POP3 is looking at. This is not a very elegant solution.
: A programmer friend is going to write me a Win2k service to do what the batch file is doing but, I'm wondering if DawkCo can offer a better solution.
: If you want to take this to email. Please feel free to contact me at the address I am using for this posting.
: John Rohland


Post A Follow-up To This Message


Follow-ups:

[Software Topic Messages] [Message Board Terms Of Use]


Shamrock LogoHome | Software | Websites | News | Links | Contact | Sitemap | ^
Web Pages by DAWKCoTM Software
Copyright ©1996-2015 The Kelly CompanySM. All rights reserved.

Page Last Updated:  Thursday, 09-Mar-2017 19:40:01 EST