daemon not invoked when core is processing an email

Gmaper

posted Jan 22 '10 at 4:31 pm

[quote user="Peter Strömblad"]

[quote user="dms"] Is there a way to file a bug against the DDK sample? Mercury DDK\DDK Samples\Resident Daemon\daemon2.c contains the error.[/quote]

I've notified David of this issue - there is no public bug-track - thanks for your efforts.

[/quote]

I just experienced this same problem. The sample daemon2.c as distributed in the DDK still contains the error last discussed in November of 2008. Were it not for this forum chain I would have been unable to get the sample to run.

I realized that Mercury is winding down but it sure would be nice if there was a single place to find known problems and any solutions or work arounds. I'm surprised that there is no bug reporting and tracking mechanism but I guess at this stage of the product life cycle it is too late to expect change.

[quote user="Peter Strömblad"][quote user="dms"] Is there a way to file a bug against the DDK sample?&nbsp; Mercury DDK\DDK Samples\Resident Daemon\daemon2.c contains the error.[/quote] I've notified David of this issue - there is no public bug-track - thanks for your efforts.[/quote]&nbsp;I just experienced this same problem.&nbsp; The sample daemon2.c as distributed in the DDK still contains the error last discussed in November of 2008.&nbsp; Were it not for this forum chain I would have been unable to get the sample to run.&nbsp;I realized that Mercury is winding down but it sure would be nice if there was a single place to find known problems and any solutions or work arounds.&nbsp; I'm surprised that there is no bug reporting and tracking mechanism but I guess at this stage of the product life cycle it is too late to expect change. &nbsp;

dms

posted Oct 22 '08 at 10:23 am

Hi all. I'm a relatively new user to Mercury (v4.62). I'm using it to email consolidation/spam filtering/etc for my family. Simply put: MercuryD (pop3 client) collects email from a series of hosts, some global rules run on the incoming email, and then my in-house clients connect to mercury through MercuryP (pop3 server). I'd like to do some more complex rules, so I've moved to using a global daemon. Mercury is loading my daemon (confirmed that startup is being called -- I output a log string in startup), but the daemon function is never being invoked as email is retrieved through MercuryD and then core processing it without a call to 'daemon'.

Should this be possible? My bug?

Hi all.&nbsp; I'm a relatively new user to Mercury (v4.62).&nbsp; I'm using it to email consolidation/spam filtering/etc for my family.&nbsp; Simply put: MercuryD (pop3 client) collects email from a series of hosts, some global rules run on the incoming email, and then my in-house clients connect to mercury through MercuryP (pop3 server).&nbsp; I'd like to do some more complex rules, so I've moved to using a global daemon.&nbsp; Mercury is loading&nbsp;my daemon (confirmed that startup is being called --&nbsp;I output a log string in startup), but the daemon function is never being invoked as email is retrieved through MercuryD and then core processing it without a call to 'daemon'. Should this be possible?&nbsp; My bug?

PiS

posted Oct 22 '08 at 8:34 pm

I think you need to share the code ... message processing via a global daemon is possible, but there are many pitfalls.

Rolf Lindby

posted Oct 23 '08 at 2:53 am

This should be possible but as Peter says we need to see relevant parts of the code to give any useful hints. Did you test if a message received via MercuryS will invoke the daemon?

/Rolf

This should be possible but as Peter says we need to see relevant parts of the code to give any useful hints. Did you test if a message received via MercuryS will invoke the daemon?/Rolf

dms

posted Oct 23 '08 at 6:01 am

Thanks for the quick replies.

I don't actually use MercuryS to do anything, and as far as I can tell, there is never any activity for MercuryS -- certainly nothing in the status window. Pop3 client feeds email into Mercury from various sources, and the pop3 server gets them to the clients. Outgoing email (from all clients) connects directly to my ISP's SMTP server. I can outline the entire setup if that makes a difference - the short version is that I'm using other pop3 proxies like SpamBayes/SpamPal in front of mercury to spam filter, and using stunnel (to get to gmail) and freepops (to get to hotmail). I also have an imap4 server running so that I can sync a local/remote account.

The daemon I'd like to write will consist of simply examining the headers and adding some new ones -- nothing too complex. My global filter will simply key off the values in the new headers instead of trying to do some complex sorting (as it is now).

My daemon source code is very simple at this point -- pretty much the daemon2 sample from the DDK. The changes are commenting out the MsgBox on dll load, and adding a logging msg on startup. As I said, the "MercuryDaemon startup called" is logged, but I never see "MercuryDaemon invoked" as MercuryD is fetching email and core is processing them, including running through the global filter. I've confirmed that the daemon dll is loaded the whole time that Mercury is running as the file is locked. Compiled under VC9. The dll exports look right, and it is calling startup just fine.

Here's the code (comments removed for legibility and looks like the webform killed the tabbing):

// DAEMON2.C

// Simple Mercury/32 Daemon Process.

// Copyright (c) 1997-2008, David Harris, All Rights Reserved.

#define STRICT

#include

<windows.h>

#include

<windowsx.h>

#include

<stdio.h>

#include

<string.h>

#include

<stdlib.h>

#include

"daemon.h"

HINSTANCE hLibInstance;

// set in LibMain, used throughout the DLL

M_INTERFACE *mi;

// Global, used for "convenience macros"

#ifdef

__BORLANDC__

#pragma warn -par

#endif

// __BORLANDC__

DAEMONEXPORT

short daemon (void *job, M_INTERFACE *mi, char *address)

{

mi->logstring (20100, LOG_NORMAL,

"MercuryDaemon invoked");

return 0;

}

DAEMONEXPORT

short startup (M_INTERFACE *m, UINT_32 *flags, char *name, char *param)

{

*flags = 0;

if ((mi = (M_INTERFACE *) malloc (sizeof (M_INTERFACE))) == NULL)

return 0;

memcpy (mi, m,

sizeof (M_INTERFACE));

mi->logstring (20100, LOG_NORMAL,

"MercuryDaemon startup called");

return 1;

}

#ifdef

__VISUALC__

BOOL WINAPI DllMain (HINSTANCE hInst, DWORD reason, LPVOID reserved)

#else

BOOL WINAPI DllEntryPoint (HINSTANCE hInst, DWORD reason, LPVOID reserved)

#endif

{

if (reason == DLL_PROCESS_ATTACH)

{

//MessageBox (NULL, L"Made it into Test Daemon DllMain", L"DllMain", MB_OK);

hLibInstance = hInst;

}

return (TRUE); // Initialization went OK

}

Thanks for the quick replies. I don't actually use MercuryS to do anything, and as far as I can tell, there is never any activity for MercuryS -- certainly nothing in the status window.&nbsp; Pop3 client feeds email into Mercury from various sources, and the pop3 server gets them to the clients.&nbsp; Outgoing email (from all clients) connects directly to my ISP's SMTP server.&nbsp; I can outline the entire setup if that makes a difference - the short version is that I'm using other pop3 proxies like SpamBayes/SpamPal in front of mercury to spam filter, and using stunnel (to get to gmail) and freepops (to get to hotmail).&nbsp; I also have an imap4 server running so that I can sync a local/remote account. The daemon I'd like to write will consist of simply examining the headers and adding some new ones -- nothing too complex.&nbsp; My global filter will simply key off the values in the new headers instead of trying to do some complex sorting (as it is now). My daemon source code is very simple at this point -- pretty much the daemon2 sample from the DDK.&nbsp; The changes are commenting out the MsgBox on dll load, and adding a logging msg on startup.&nbsp; As I said, the "MercuryDaemon startup called" is logged, but I never see "MercuryDaemon invoked" as MercuryD is fetching email and core is processing them, including running through the global filter.&nbsp; I've confirmed that the daemon dll is loaded the whole time that Mercury is running as the file is locked.&nbsp; Compiled under VC9.&nbsp; The dll exports look right, and it is calling startup just fine. Here's the code (comments removed for legibility and looks like the webform&nbsp;killed the tabbing): <BLOCKQUOTE> // DAEMON2.C // Simple Mercury/32 Daemon Process. // Copyright (c) 1997-2008, David Harris, All Rights Reserved. #define STRICT #include &lt;windows.h&gt; #include &lt;windowsx.h&gt; #include &lt;stdio.h&gt; #include &lt;string.h&gt; #include &lt;stdlib.h&gt; #include "daemon.h" HINSTANCE hLibInstance; // set in LibMain, used throughout the DLL M_INTERFACE *mi; // Global, used for "convenience macros" #ifdef __BORLANDC__ #pragma warn -par #endif // __BORLANDC__ &nbsp; DAEMONEXPORT short daemon (void *job, M_INTERFACE *mi, char *address) { mi-&gt;logstring (20100, LOG_NORMAL, "MercuryDaemon invoked"); return 0; } &nbsp; DAEMONEXPORT short startup (M_INTERFACE *m, UINT_32 *flags, char *name, char *param) { *flags = 0; if ((mi = (M_INTERFACE *) malloc (sizeof (M_INTERFACE))) == NULL) return 0; memcpy (mi, m, sizeof (M_INTERFACE)); mi-&gt;logstring (20100, LOG_NORMAL, "MercuryDaemon startup called"); return 1; } &nbsp; #ifdef __VISUALC__ BOOL WINAPI DllMain (HINSTANCE hInst, DWORD reason, LPVOID reserved) #else BOOL WINAPI DllEntryPoint (HINSTANCE hInst, DWORD reason, LPVOID reserved) #endif { if (reason == DLL_PROCESS_ATTACH) { //MessageBox (NULL, L"Made it into Test Daemon DllMain", L"DllMain", MB_OK); hLibInstance = hInst; } return (TRUE); // Initialization went OK }</BLOCKQUOTE> &nbsp;

dms

posted Oct 23 '08 at 7:52 am

Of course, I think I could also use an event daemon, but only if MercuryD generated events. Anything in the works or available?

Of course, I think I could also use an event daemon, but only if MercuryD generated events.&nbsp; Anything in the works or available?

PiS

posted Oct 23 '08 at 10:20 am

If you uncomment the MessageBox doesn't a log message appear for each message in the main console?

// A side note, I'll see what I can add to the editor here so we can share code snippets easier //

If you uncomment the MessageBox doesn't a log message appear for each message in the main console? // A side note, I'll see what I can add to the editor here so we can share code snippets easier //

dms

posted Oct 23 '08 at 10:31 am

If I uncomment the MsgBox call, a pop up MsgBox appears once at Mercury startup -- not for each msg in the main console. This daemon is registered as a global daemon, so DllMain would only be called once on initial startup of Mercury when it loads the daemon dll. My understanding is that global daemons would not be unloaded during execution.

If I uncomment the MsgBox call, a pop up MsgBox appears once at Mercury startup -- not for each msg in the main console.&nbsp; This daemon is registered as a global daemon, so DllMain would only be called once on initial startup of Mercury when it loads the daemon dll.&nbsp; My understanding is that global daemons would not be unloaded during execution.

Thomas R. Stephenson

posted Oct 23 '08 at 6:09 pm

Of course, I think I could also use an event daemon, but only if MercuryD generated events. Anything in the works or available?

Both the Spamhalter and POPFileD daemons work with messages received from MercuryD. You might want to talk to the developers of those daemons.

<blockquote>Of course, I think I could also use an event daemon, but only if MercuryD generated events.&nbsp; Anything in the works or available? </blockquote>Both the Spamhalter and POPFileD daemons work with messages received from MercuryD.&nbsp; You might want to talk to the developers of those daemons.

Rolf Lindby

posted Oct 24 '08 at 1:07 am

I'm not sure if VC9 may require any special settings for this kind of DLL (I've only written daemons in Delphi). Doublecheck the rules mentioned on page 5-7 in the daemon manual, though. One other small test would be to have a MsgBox inside the daemon function to see if it get called at all presently.

/Rolf

I'm not sure if VC9 may require any special settings for this kind of DLL (I've only written daemons in Delphi). Doublecheck the rules mentioned on page 5-7 in the daemon manual, though. One other small test would be to have a MsgBox inside the daemon function to see if it get called at all presently./Rolf

dms

posted Oct 24 '08 at 6:55 am

Thanks for the suggestions. I've reviewed the tools notes, plus I've dumped the dll to examine the exports, etc, and everything looks right. I also note that startup is called correctly, with the logged output to the system window, so I would expect that the daemon function is being exported correctly. The dll file is locked while Mercury is running, pretty much showing that it isn't being unloaded. Plus this is pretty much the sample.

I've put the MsgBox inside the daemon function, and it does not get called when MercuryD receives email or when core processes it.

At this point, I expect that I've found a bug in Mercury with the configuration I'm using. How do I debug it further or report the repro case?

thanks

Thanks for the suggestions.&nbsp; I've reviewed the tools notes, plus I've dumped the dll to examine the exports, etc, and everything looks right.&nbsp; I also note that startup is called correctly, with the logged output to the system window, so I would expect that the daemon function is being exported correctly.&nbsp; The dll file is locked while Mercury is running, pretty much showing that it isn't being unloaded.&nbsp; Plus this is pretty much the sample. I've put the MsgBox inside the daemon function, and it does not get called when MercuryD receives email or when core processes it. At this point, I expect that I've found a bug in Mercury with the configuration I'm using.&nbsp; How do I debug it further or report the repro case? thanks

dms

posted Oct 24 '08 at 7:54 am

[quote user="Thomas R. Stephenson"] Both the Spamhalter and POPFileD daemons work with messages received from MercuryD. You might want to talk to the developers of those daemons.
[/quote]

thanks for the suggestion. How do I get in touch with those developers? I do not see these projects on SourceForge or Codeplex.

[quote user="Thomas R. Stephenson"] Both the Spamhalter and POPFileD daemons work with messages received from MercuryD.&nbsp; You might want to talk to the developers of those daemons. [/quote] &nbsp;thanks for the suggestion.&nbsp; How do I get in touch with those developers?&nbsp; I do not see these projects on SourceForge or Codeplex.

PiS

posted Oct 24 '08 at 5:05 pm

You'll find Lucas at: http://www.ararat.cz

You'll find Lucas at: <A href="http://www.ararat.cz/">http://www.ararat.cz</A>

Thomas R. Stephenson

posted Oct 24 '08 at 5:50 pm

thanks for the suggestion. How do I get in touch with those developers?

Both have posted here so you might try a search but here's the addresses I have.

POPFileD: "Eduardo Subelman" <subelman@MARKMATRIX.COM>

Spamhalter, Graywall, Clamwall: "Lukas Gebauer" <gebylist@mlp.cz>

Lukas is closer to the Mercury (and Pegasus Mail) internals but Eduardo handles English a lot better. ;-)

<blockquote>&nbsp;thanks for the suggestion.&nbsp; How do I get in touch with those developers?</blockquote>Both have posted here so you might try a search but here's the addresses I have. POPFileD:&nbsp; "Eduardo Subelman" &lt;subelman@MARKMATRIX.COM&gt;Spamhalter, Graywall, Clamwall:&nbsp; "Lukas Gebauer" &lt;gebylist@mlp.cz&gt;Lukas is closer to the Mercury (and Pegasus Mail) internals but Eduardo handles English a lot better.&nbsp; ;-)

dms

posted Oct 27 '08 at 9:28 am

Quick update: I've debugged through Mercury asm, looking at where the dll entrypoints are referenced. It appears that _startup, startup, and STARTUP are searched for (and all _cdecl calling convention), and then called when found. This is working on my daemon dll.

But there never appears to be a call to GetProcAddress, from mercury.exe, looking for "daemon" or any of the other variations as above. I've found the location in Mercury.exe where is appears to make the call, but the code is never executed.

Anyone have access to the source code? Can you check why startup would be GetProcAddr'ed and called, but 'daemon' would not be GetProcAddr'ed?

I'm thinking that I may have my daemon.ini wrong, but it doesn't look much different than popfiled's:

[Global Daemons]
DaveS Filter = c:\bin\daemon\MercuryDaemon.dll

Quick update:&nbsp; I've debugged through Mercury asm, looking at where the dll entrypoints are referenced.&nbsp; It appears that _startup, startup, and STARTUP are searched for (and all _cdecl calling convention), and then called when found.&nbsp; This is working on my daemon dll. But there never appears to be a call to GetProcAddress, from mercury.exe, looking for "daemon" or any of the other variations as above.&nbsp; I've found the location in Mercury.exe where is appears to make the call, but the code is never executed. Anyone have access to the source code?&nbsp; Can you check why startup would be GetProcAddr'ed and called, but 'daemon' would&nbsp;not&nbsp;be GetProcAddr'ed? I'm thinking that I may have my daemon.ini wrong, but it doesn't look much different than popfiled's: [Global Daemons] DaveS Filter = c:\bin\daemon\MercuryDaemon.dll &nbsp;

Rolf Lindby

posted Oct 27 '08 at 7:23 pm

One thing to try might be to have a single word as identifier for the daemon, i.e. "DaveSFilter" instead of "DaveS Filter".

(Mercury is not open source, so David Harris is the only one that has access to the source code.)

/Rolf

One thing to try might be to have a single word as identifier for the daemon, i.e. "DaveSFilter" instead of "DaveS Filter".(Mercury is not open source, so David Harris is the only one that has access to the source code.)/Rolf&nbsp;

dms

posted Oct 28 '08 at 4:07 am

Thanks Rolf. I've already tried that, and it didn't make a difference. I will continue to debug into the binary to figure this out.

Thanks Rolf.&nbsp; I've already tried that, and it didn't make a difference.&nbsp; I will continue to debug into the binary to figure this out.

dms

posted Oct 28 '08 at 9:05 am

Some more investigation. I'm hoping that this rings a bell for someone or that David is able to respond. Mercury.exe is loading at the default image base, so all addresses are the same as in the exe file.

At location 0x41c4ef, there's a function that checks a bunch of stuff including, at location 0x41c546, a particular byte at offset 0x1d0 in a structure describing the daemon plug-in. The structure contains the daemon name, the dll path, and seemingly some status info, including the byte at offset 0x1d0 and the dll hmod at offset 0x1d8. For some reason, that byte is a zero for my DLL. If the value was 4 (or at least that bit set), then mercury would continue and do GetProcAddr on _daemon, daemon, and DAEMON; and call the first one of those found (at location 0x41c5c9). In other places in Mercury, there are other checks of this byte (against the values of 0, 1, 2, and 0x10). I haven't yet figured out why my damon dll isn't getting a value of 4 in this structure. If I manually change the value to 4 in a debugger, the daemon function is called.

From the asm, my guess is that the source code looks like this:

if(!global_ptr)

if(global_ptr->pDaemon->status & 0x4)

GetProcAddress (global_ptr->pDaemon->hmod, "daemon");

...

I'd really like to know what causes the status byte to have that bit set...

Some more investigation.&nbsp; I'm hoping that this rings a bell for someone or that David is able to respond.&nbsp; Mercury.exe is loading at the default image base, so all addresses are the same as in the exe file. At location 0x41c4ef, there's a function that checks a bunch of stuff including, at location 0x41c546,&nbsp;a particular byte at offset 0x1d0 in a structure describing the&nbsp;daemon plug-in.&nbsp; The structure contains the daemon name, the dll path, and seemingly some status info, including the byte at offset 0x1d0 and the dll hmod at offset 0x1d8.&nbsp; For some reason, that byte is a zero for my DLL.&nbsp; If the value was&nbsp;4 (or at least&nbsp;that bit&nbsp;set), then mercury would continue and&nbsp;do GetProcAddr&nbsp;on _daemon,&nbsp;daemon, and DAEMON; and call the first one of those found (at location 0x41c5c9).&nbsp; In other places in Mercury, there are other checks of this byte (against the values of 0, 1, 2, and 0x10).&nbsp; I haven't yet figured out why my damon dll isn't getting a value of 4 in this structure.&nbsp; If I manually change the value to 4 in a debugger, the daemon function is called. From the asm, my guess is that the source code looks like this: if(!global_ptr) &nbsp;&nbsp; if(global_ptr-&gt;pDaemon-&gt;status &amp; 0x4) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GetProcAddress (global_ptr-&gt;pDaemon-&gt;hmod, "daemon"); &nbsp;&nbsp;&nbsp;&nbsp; ... I'd really like to know what causes the status byte to have that bit set...

Thomas R. Stephenson

posted Oct 28 '08 at 3:53 pm

or that David is able to respond

Don't look for anything from David for at least two weeks. He is still in Europe for another week and probably will not be able to catchup on all his mail for at least another week.

<blockquote>or that David is able to respond </blockquote> Don't look for anything from David for at least two weeks.&nbsp; He is still in Europe for another week and probably will not be able to catchup on all his mail for at least another week.

dms

posted Nov 4 '08 at 5:55 am

Eduardo Subelman helped track down this issue: the sample code in the DDK is wrong. Specifically, in the startup function, there is a "*flags = 0;". On the call to startup, *flags == 0x4. Setting it to zero, per the sample, causes no calls to the daemon function. I'm willing to bet (but I haven't verified yet) that flags points to the value at offset 0x1d0 in the daemon structure as described in my post on 10/28 above. Commenting out the assignment in startup enables Mercury to call the daemon function with each processed email.

Thanks Eduardo!

Is there a way to file a bug against the DDK sample? Mercury DDK\DDK Samples\Resident Daemon\daemon2.c contains the error.

Now off to write my daemon...

Eduardo Subelman helped track down this issue: the sample code in the DDK is wrong.&nbsp; Specifically, in the startup function, there is a "*flags = 0;".&nbsp; On the call to startup, *flags == 0x4.&nbsp; Setting it to zero, per the sample,&nbsp;causes no calls to the daemon function.&nbsp; I'm willing to bet (but I haven't verified yet) that flags points to the value at offset 0x1d0 in the daemon structure as described in my post on 10/28 above.&nbsp; Commenting out the assignment in startup enables Mercury to call the daemon function with each processed email. Thanks Eduardo! Is there a way to file a bug against the DDK sample?&nbsp; Mercury DDK\DDK Samples\Resident Daemon\daemon2.c contains the error. Now off to write my daemon...

Related Topics

Pending draft

Confirm move posts

Insufficient permissions

Select a different topic

Edit history