[quote user="PaulW"]

[quote user="Vincent Fatica"]P.S. As far as I can tell, it's either Outlook or the MS Exchange server that's providing the info "From: Maiser@... on behalf of ...".  That's not the real "From:" header in the emails.  There's no real consequence (other than upsetting folks when they see it) because replies to such emails go to the "on behalf of" person (who is also named in the real "From:" header).  All that said, perhaps the behavior isn't so bad; Maiser really was the sender, and did send the message on behalf of the person who submitted it to the list.[/quote]

I disagree that Outlook's behaviour is totally neutral.  I had considerable difficulty on my lists with some members' replies going to (and being rejected by) maiser.

I now suppress the outgoing 'Sender: Maiser@listname' header in a policy.  On a low volume mailserver that works fine, with busier servers a daemon may be better.

[/quote]

Thanks for the tip Paul.  I'll try a policy.  I haven't seen replies going to maiser (yet).  My problem is that the gals who work in the dept office of the small math dept for which I work are alarmed by it and keep harping at me.  They are the ones who use the few mailing lists and they often get replies to their messages.  I haven't the time to track down the offending clients (and am probably powerless to change their behavior).  Yet it's good policy to stay on the good side of those gals.

What determines if mail sent to a Mercury list gets such a header as:

Sender: Maiser@...

Some have it, some don't.  These headers haven't been a problem in the past, but recently, some replies to emails to a list appear to come from:

"maiser@ ... on behalf of <original From: spec>"

The Sender header (not to be confused with the From header) is added by Mercury when distributing a message to list members, and has been there since at least Mercury v. 4.01. Is there some specific email client that uses "maiser@ ... on behalf of..." as From header when replying to list messages?

/Rolf 

[quote user="Rolf Lindby"]

The Sender header (not to be confused with the From header) is added by Mercury when distributing a message to list members, and has been there since at least Mercury v. 4.01. Is there some specific email client that uses "maiser@ ... on behalf of..." as From header when replying to list messages?

/Rolf 

[/quote]

No there isn't (at least not that I know of).  But those replies to mail sent to a list are not coming through Mercury ... so somrthing alse must be doing it.

Googling turned up that I asked about the same thing in January 2007 and that I solved it with a daemon.  I could find **no** emails to myself, via lists, that contained the "Sender:" header prior to 23 June 2012, which coincides with my migrating to Win7 (but running Mercury from the same place it was in on XP,no reinstall).  Maybe I messed up my own daemon.  At that time, David Harris wrote:

"I'll consider adding an option to suppress or restructure the "Sender"

field in an upcoming version of Mercury, but initially, I'd be trying to

find out why the mail client is doing such a bizarre thing."

Does anyone know if David has made any steps in this direction?  The Mercury in question is v4.6; I could upgrade.

Thanks.

  - Vince

Here's all of what D.H. said 5 1/2 years ago:

*******************************************************

*************************************************************************

 I did manage to suppress the "Sender:" header for 5+ years with a daemon.  I don't recall exactly how; I know where the source code is but can't get at it until tomorrow.

 The funny thing is, while some client may be dumb enough to use that header, something along the way is smart (?) enough to actually send the email to the "on behalf of" address (as I said before, the replies are **not** coming through Mercury).

 Does the newest daemon toolkit describe how to modify a job's raw data?  And, as I asked before, does v4.74 have a built-in way to suppress the "Sender:" header?

 - Vince

No such option in the current release,but if you could please send me a sample of a message with  "maiser@ ... on behalf of ..." ( a .CNM file preferably) I'll be happy to bring it up again for the upcoming v5 of Mercury. Daemons basically work the same way under Windows 7 as under XP, so you should be able to get your daemon working again in the meantime.

And additionally (from the current Daemon Developer Guide):

ji_open_job: Call this function to open a job when you need to work with its contents. Until you call ji_close_job, the job will be locked and unavailable to other threads and processes – in other words, you will have exclusive access to it

 /Rolf 

I might be able to get you one but it almost certainly won't be a CNM file.  I'm not one to send mail to a list so I won't have any such replies.  I'll also try to find out what client is doing that.  It's likely to be MS's Web/Outlook thing (with which I am not familiar)

I still didn't get at the source code for my daemon but I'm pretty sure it does exactly what David said I shouldn't do; it memory maps a QDF file, so I suppose it's editing the message as it sits in the queue.  Thanks for the tip, Rolf.  I'll look at the latest guide and try to write a new daemon to do it properly.  Is there any more these days than DAEMON.TXT and DAEMON.H?

 - Vince

There is a nice package with a daemon development guide, examples, and code files that can be downloaded here:

http://community.pmail.com/files/folders/mercur/entry10073.aspx 

/Rolf 

I'm a little lost.  The daemon that has worked for years (with v4.62) doesn't work now (WIN7).  There are many discrepancies.  It declares/exports

SHORT __declspec(dllexport) DAEMON (VOID *job, M_INTERFACE *mi, CHAR *address, CHAR *param)

and I supply "param" via daemon.ini.

while my daemon.txt calls the function "daemon" (lowercase).  and the newest DDK (daemon2.c)  declares it without "param".

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

My daemon loads; STARTUP (uppercase) is called.  But DAEMON is not called when there's a job.

Any tips would be appreciated.

[quote user="Vincent Fatica"]

I'm a little lost.  The daemon that has worked for years (with v4.62) doesn't work now (WIN7).  There are many discrepancies.  It declares/exports

SHORT __declspec(dllexport) DAEMON (VOID *job, M_INTERFACE *mi, CHAR *address, CHAR *param)

and I supply "param" via daemon.ini.

while my daemon.txt calls the function "daemon" (lowercase).  and the newest DDK (daemon2.c)  declares it without "param".

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

My daemon loads; STARTUP (uppercase) is called.  But DAEMON is not called when there's a job.

Any tips would be appreciated.

[/quote]

OK, I got it working.  I overlooked the fact that it needed to be in the "[Global Daemons]" section of DAEMON.INI.

But I'm still curious about the case of the name of the daemon/DAEMON function and the apparently conflicting declarations of that function given by my (v4.62) DAEMONS.TXT and the recently downloaded DDK.

Thanks!

There has been extensions to the daemon interface between versions but the basics are the same as before. Check the developer guide when in doubt:

"The primary function of a Mercury Daemon is usually to process mail as it goes through the queue – indeed, with the simplest type of Daemon, the Single Instance Daemon, this is all the Daemon can do. To implement this primary function, your Daemon, whether Single Instance, Resident or Global, needs to export a function called daemon, which has the following form:

short daemon (void *job, M_INTERFACE *m, char *address, char *parameter);"

In this case this daemon will of course have to be a global daemon, and specified as such in daemon.ini. 

/Rolf 

The DDK samples, daemon1.c and daemon2.c, one single-instance, one global, both show:

DAEMONEXPORT short daemon (void *job, M_INTERFACE *mi, char *address)
   {
   mi->logstring (20100, LOG_NORMAL, "TEST DAEMON: Daemon function called");
   return 0;
   }

They are missing the fourth parameter.  Are they in error?  The guide shows the fourth parameter.  All show "daemon" in lower-case, but mine is working (and has for a long time) with the name of that function as "DAEMON".  Of GetProcAddress(), the docs say "The spelling and case of a function name pointed to by lpProcName must be

identical to that in the EXPORTS statement of the source DLL's

module-definition (.def) file."  Do you know what's going on?  Does Mercury try for both the upper-case and lower-case names?

I haven't tested using names of exported functions uppercase as they are lowercase in the documentation (and I don't think I will), but if it works it would seem that Mercury tries it both ways. 

As for  the parameter "char *parameter" I've used it with the startup function only, but I always include it in the declaration of the daemon function anyway. I'm not sure what the effects are if a parameter is left out this way, though. The DLL will obviously ignore it as the library code doesn't know it exists. The calling program will presumably still put the parameter on the stack, and should clear it from the stack when the function returns.

/Rolf 

[quote user="Rolf Lindby"]

I haven't tested using names of exported functions uppercase as they are lowercase in the documentation (and I don't think I will), but if it works it would seem that Mercury tries it both ways. 

As for  the parameter "char *parameter" I've used it with the startup function only, but I always include it in the declaration of the daemon function anyway. I'm not sure what the effects are if a parameter is left out this way, though. The DLL will obviously ignore it as the library code doesn't know it exists. The calling program will presumably still put the parameter on the stack, and should clear it from the stack when the function returns.

/Rolf 

[/quote]

I'm using "char *parameter" in DAEMON(), supplying it in DAEMON.INI after a semicolon ... it works.  I suppose the caller (Mercury) would only put it on the stack if it expected DAEMON() to take a fourth argument.  So I still wonder about the two DDK examples.  Perhaps it's OK to just omit it if it won't be used and the caller is going to clean up. I learned "C" as a vehicle to get to the Win32 API, so maybe I missed some basic "C" stuff.

At least I have quieted the complaints so I'm happy for now.  Thanks for you input Rolf.

 P.S. As far as I can tell, it's either Outlook or the MS Exchange server that's providing the info "From: Maiser@... on behalf of ...".  That's not the real "From:" header in the emails.  There's no real consequence (other than upsetting folks when they see it) because replies to such emails go to the "on behalf of" person (who is also named in the real "From:" header).  All that said, perhaps the behavior isn't so bad; Maiser really was the sender, and did send the message on behalf of the person who submitted it to the list.

Cheers!

I'd really like to bring this daemon up-to-snuff and do everything the approved way.  But I find that the DAEMON.H that came with Mercury v4.6 does not mention several of the functions I'd need.  For example it does not declare ji_access_job_data() and edit_message_headers().  I could use the newer DAEMON.H from the DDK but ... big question ... are those functions (and perhaps others which I'll need) actually implemented in Mercury v4.6?

The new Daemon Developer Kit was released in June 2008, around the same time as Mercury 4.61, so it should be OK. It might be a good idea to update Mercury anyway though.

/Rolf 

[quote user="Rolf Lindby"]

The new Daemon Developer Kit was released in June 2008, around the same time as Mercury 4.61, so it should be OK. It might be a good idea to update Mercury anyway though.

/Rolf 

[/quote]

Yes, I was thinking of that but I get a little nervous updating something that's working well.  When I moved from XP to Win7, nothing that concerns Mercury/32 changed ... Mercury's home remained d:\Mercury and the mail drop remained e:\Mail.  Win7 went on C:.  In Win7, I just started Mercury from its old home and all worked fine.  So I'm considering a simple in-place upgrade figuring that will preserve everything.  I'd make a back-up of d:\Mercury just in case.  Does that sound like a good strategy?  Do you think it will require any further configuring?

Thanks!

[quote user="Vincent Fatica"]

Yes, I was thinking of that but I get a little nervous updating something that's working well.  When I moved from XP to Win7, nothing that concerns Mercury/32 changed ... Mercury's home remained d:\Mercury and the mail drop remained e:\Mail.  Win7 went on C:.  In Win7, I just started Mercury from its old home and all worked fine.  So I'm considering a simple in-place upgrade figuring that will preserve everything.  I'd make a back-up of d:\Mercury just in case.  Does that sound like a good strategy?  Do you think it will require any further configuring?

Thanks!

[/quote]

One concern.  v4.61 was never formally "installed" on Win7 and did not use InstallShield.  Do you think this will cause any problems upgrading in-place?

Thanks.

Mercury won't require Windows to know any details about the program unless it's run as a service, so no special installation procedure is required.

Making a backup of the main Mercury folder before doing an update is always a good idea, just to be on the safe side. I've never had a problem with an update, though. There are some new settings that have been added since v4.6 so you should probably have a look at the configuration, but it should run nicely without any changes.

/Rolf 

[quote user="Vincent Fatica"]P.S. As far as I can tell, it's either Outlook or the MS Exchange server that's providing the info "From: Maiser@... on behalf of ...".  That's not the real "From:" header in the emails.  There's no real consequence (other than upsetting folks when they see it) because replies to such emails go to the "on behalf of" person (who is also named in the real "From:" header).  All that said, perhaps the behavior isn't so bad; Maiser really was the sender, and did send the message on behalf of the person who submitted it to the list.[/quote]

I disagree that Outlook's behaviour is totally neutral.  I had considerable difficulty on my lists with some members' replies going to (and being rejected by) maiser.

I now suppress the outgoing 'Sender: Maiser@listname' header in a policy.  On a low volume mailserver that works fine, with busier servers a daemon may be better.