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

Hi,

could it be possible that there is a length restriction of the username field in the "Edit POP3 Mailbox definition" popup ?

Whenever I enter a string (username) longer than 47 characters, it gets cut off after the 47th char !
This invalidates my username string, and the mail provider just doesn't like it anymore ... :-(

You might say: "Why's this dude using usernames with such a insane length?"
Quite easy: I am using POPFILE as mail proxy to pull mail from for POP3 mailboxes, so I need to redirect the Mercury POP3 client logins to popfile running on localhost, and pass all required stuff in the username field, like so:

POP3 Host: 127.0.0.1
Username: pop3.provider.com:Mailbox.Name;maildomain.com:ssl

As you can easily see, this adds up to a pretty long string. It works for almost all of my mailboxes, but some are longer than 47 chars, so I am lost. In the very old versions of Mercury, the MercuryD.dat config file was plaintext ASCII, so I could modify it. Nowadays, this file is encrypted (which is good to keep passwords secret), and cannot be edited anymore, so I don't see any way of working around that issue.

Is the restriction only in the GUI window when editing the mailbox definition, or a overall restriction in MercuryD ?

Thanks !

Kind Regards,
Andy

Thx, I will work through the provided links.

The new TCP/IP module could explain the network problems and therefor the crashes and it fits to my observation that this network issues did not happen before the installing the new beta.

Can you provide the "special version of mercury.exe" so that I can send the logs after the next crash?

Konrad