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


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: More efficient solution
Posted by: DAWKCo Tech Support
Date: Thu, 18 Mar 2004 03:44:07 -0500
In Reply To: Re: Open Relay Filter posted by DAWKCo Tech Support on Wed, 17 Mar 2004 17:58:42 -0500

Excuse this "second thought" which should have come first:

While our previous posting regarding synchronizing access to the SMTP Drop between processes was instructive, the suggested method of moving the files out of and back into the Drop is probably not the most efficient solution for your situation.

In fact, your idea of relocating the SMTP Drop to where your filter software processes the mail, and afterward moving the message files to the Drop location where the DAWKCo MailDaemon processes mail, is a more efficient solution--it requires only one move versus two--and it does not require any synchronization with the DAWKCo MailDaemon.  Remember, moving files INTO the MailDaemon Drop will not cause a conflict and does not require synchronization.

-----Original 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
:   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);
:   }
:   // 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
: } // end of SomeThread
: -----Original Message-----
: : I recently installed a product called Open Relay Filter (Enterprise Edition) (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


[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