A couple of months ago there was a long thread discussing the problem of synonyms not being used by auto-replies.  A solution was found, or so we thought.  The problem was that the From: header in the auto-reply was populated with localusername@domain.com rather than domainusername@domain.com.  It was apparent that the synonym files was ignored by the auto-reply process (triggered by a FORWARD file).  Removing the local user entries from the MercuryD configuration appeared to have solved the problem but the problem is back for me.  The only change I can think of is switching from MercuryC to MercuryE.  Does anyone know if or why this change would affect this behavior?

Edit: I got it working again on auto-replies but not on auto-forwards generated by a FORWARD file.  The emphasis during the previous discussion on this topic was to get the From: header correct in the auto-replies.  I don't recall that the Resent-from: header in auto-forwards was given much attention so it may have never worked.  It is of low importance so I consider this problem fixed.

The [MercuryE] section in my Mercury.ini file was completely missing....  I inserted the section and now it appears to be working.

Thanks Rolf 

A 32 bit version of fsynonym.exe is included with the upcoming v4.80 of Mercury. You can download it separately here: http://downloads.serieguide.se/fsynonym.exe

A FORWARD file can contain as many Forward-To lines as you like. There should only be one Deliver-Also line, though.

Alternatively you could create a mailing list and use that to distribute messages to a group of recipients, or you could point an alias to a rule set that copies the message to various local accounts. 

I haven't tested the MXREDIR daemon myself, but I believe the files still can be found here: http://fenke.home.xs4all.nl/files/

I will have to see if I have any record of the original change I made, I think it may have been a line in Mercury.ini but I have not found it yet.

The odd thisng is that all the settings in the user's Pegasus appear to be correct.

I tried catching one but was unable to because they passed through so quickly.  I didn't think to stop Core.  Thanks for the suggestion. 

I think I have my original problem solved but I may play with this just out of curiosity.

im also having this problem

Thanks for all your help - I did get what I needed using MercuryC after renaming Mercury Mail local domain.

@Rolf

I believe in order to get MercuryE working using options 1 or 2 to work I need to make adjustments to the accepting exchange server so at this time I am just going to use MercuryC.

@jbanks

Thanks for all the info on making adjustments to the exchange server end. On the DNS our server at 192.168.0.2 is also our SBS 2011 running our DNS and exchange server so the DNS so it should already be setup to point to the exchange server. The on thing I wanted to avoid if possible was having to make per user changes as I did not what to go into each current and future user settings and make custom settings. I do like having the information in case I would need it in the future as you never know what kinds of setup they may ask for in the future.

As always I gained a lot knowledge from all the help here.

Thanks again, Ron

I used the cert generated by Mercury.  I didn't check the date, I sort of assumed it would be valid or report a useful error if it wasn't.  I'll check.

CA Cert, 1024-bit RSA, valid until 2034.  Re-enabling it didn't work, but creating a new cert and enabling SSL seems to have been successful.

So yeah!  If the cert gets moldy or whatever, Mercury just stops functioning.  Good to know.  =D

Thanks for the clue, Olaf.

BTW: 4.80beta16 provided by Rolf Lindby has resolved all SSL issues here. Works like a charm for 4 weeks now.

 Thanks!

[quote user="Rolf Lindby"]

Maybe some strange IPv4 / IPv6 issue? Again, would you consider trying v4.80 and see if that makes a difference? If so I can provide a download link for the current beta.

[/quote]

Yes, I'm willing to try the beta, depending on how stable it is - this is my email link to the world after all.

oh, that was easy, Thanks!

Reasonable questions all, but I don't have old Mercury logs - I only turned on that particular logging when it became an issue. I've checked Received headers in a current message and one received six months ago, and Mercury is declaring v4.74 in both.

It's possible that it's the level of problem that has changed. I've had the odd message before come to me, but I'm postmaster, so I just assumed an unknown problem and forwarded it. Now it's probably running at 20% or more of my wife's messages (haven't counted properly).

Another (possibly related) problem we have is spurious suppression of duplicate messages by Mercury. Since, in reality, we're both using the same mailbox on a given ISP, and the Envelope-to: headers are distinguishing which of us should get the mail, then if, say, we're both on the same mailing list, Mercury will suppress one copy of the message, which is infuriating, because you cannot easily work out what you've missed, or even which user missed it. At least if there were an option to turn duplicate suppression off, or even redirect duplicates for the postmaster's attention, there would be some control. I'm aware that the "Look only in these headers" setting should prevent this, but it does not appear to do so. I haven't even found a log where I can check what duplicates were suppressed. In at least one case, I'm having to use a rule in Pegasus Mail to autoforward the messages to the other account(s) and thus work around the issue, but I can only do that for mailing lists that I know are affected. I've also tried arranging for us to use different ISPs when registering on such lists, but not necessarily with great success. I'm not clear that I wouldn't even get spurious suppression sometimes if a friend included both of us in the addressees for the same message.

I'll try removing X-Envelope-to from the rules, because it seems to be irrelevant. As you say, it shouldn't make any difference, but who knows?

Happy to pass on logs and headers - should I PM you?

To state the obvious, I also have logs for messages that were delivered, including one where "duplicate" messages (from a Yahoo Group to which we both belong) were delivered properly to each of us, which is the result required. No real idea why it worked in that case and not in others.

Regards

OK Thanks

[quote user="Steen"]

Set up:
Novell 6.5sp8 server (not going to move to a later version if I can avoid it, nor going to setup a windows server instead).
Mercury 1.48nlm running all module but MercuryC (as I can't use smtp-relay any more... unless somebody knows of a free reliable one)

Usually I use a laptop win 8.1 as working machine but I do have more laptops than this. Bascially if any other runs, my win8.1 is also running. Pegasus running from all my laptops in server mode when I am at home, in local when I am out.

Now for my idea: Run Mercury/32 the E module alone in order to be able to send mails with out any relay from my win 8.1. Can this be done? What is needed? Any downsides that will backfire?[/quote]

This does work and I use it occasionally.  You need to load both MercuryE and MercuryS in your Mercury/32 version to enable it to relay from Pegasus.

[quote]I have no idea if this is possible, but I guess I should be able to use Pegasus to send to the MercuryE/32 and then that should be able to handle my mails (it is really sad that there was never an E-module to the nlm because then I would never have had to consider all of this - anybody knows a free mailer for Novell 6.5sp8 with Apache, please let me know... I am in contact with the dutch guy that did one for Novell 5.1 running the netscape webserver, to see if that can be brought to work)[/quote]

I can't help with Netware these days as my last Novell installation went about 5 years ago  :(

Ok think i am getting the hang of this. Thanks for your help Olaf

Thanks! That is what I had expected -> put everything under c:

directly as applications are still allowed to write into such folders.

For me this would mean that I have to copy my existing Mercury

installation from c:\programme\mercury to c:\mercury and therefor I

guess that I need to modify some configuration files due to the path

changes. I hope that this is possible at all!

With "virtualization" I meant the file virtualization technology from UAC like it is described here:

https://decibel.ni.com/content/groups/windows-7/blog/2009/10/02/uac-virtualization-and-how-it-affects-your-installers

Does username and/or password have some special characters (non 7bit)?

bye   Olaf

Hi,

since I'm mainly using the POP3 client to poll my mailboxes: I noticed some strange behaviour when editing the MercuryD config.

It sometimes happens whenever the MercuryD configuration is edited during a poll cycle -

Either, the list of mailboxes is incomplete (i.e. some are missing in the config window), and when the incomplete list is saved, the MercuryD.dat file is crashed/crippled/incomplete, or

While editing the list during a poll cycle, the polling process stops just at any random mailbox, and then halts until the config editor window is closed again.

This means: One can either cripple the mailbox configuration (i.e. loose configured POP3 mailboxes), or block the POP3 polling entirely until the config editor windows are all closed.

Anybody else seen tha same behaviour ? If so, it's perhaps worth a bug report ?

Kind Regards,
Andy