[quote user="Joerg"]

[quote user="Greenman"]Surreal. I've never used the Mercury as a service feature. [/quote] ... This is my solution for Windows Server 2016 Standard. Maybe not the best but I can live with.

Cheers

Joerg

[/quote]

I'm all for this. My comment was related to the rivalry you mentioned. I've never used the 'service' aspect simply because as a charity we do not have a license. Also, like you, I need to see what is going on. It's how I pick up on persistent unauthorised connection attempts, check that messages have been sent when Pegasus Mail leaves a sent message on screen etc.

Hi guys,

Since a few days we experience the following oddity: From time to time (4 times until now) a (local) user receives an e-mail (from the internet) which was intended for another (local) user of our Mercury domain. Normally Mercury D is polling our external mailboxes with the ISP one after another, retrieving the mails and put them into the assigned local user inboxes. The affected mails look OK, they have a valid sender, a valid recipient (the external address for the local user). Only the sorting seems to be mixed up occasionally.

Has anybody an idea what I could check to locate the problem? The mail log (system log) shows the receipt of the affected mail and its forwarding to the wrong local user. MercuryD has also been checked without any findings. Each external address is assigned to its local user correctly.

FYI: Beside the MercuryD we've got MercuryS, MercuryC and MercuryI running. Further we've got three alias addresses in place which will be forwarded to three public mailboxes. But the wrongly forwarded mails do not concern these aliases. Finally Spamhalter is activ on our system.

I saw this a few years ago. However, I can't remember precisely what the cause was. I recall that it was something to do with addressing and that the original mail was sent in reply to a different address. However, because the recipient's address had featured somehow in the cc or bcc of what was originally received by the sender, the message received (apparently in error) by the unintended recipient appeared without any other address on it - i.e. there was no cc or bcc. Looks like the sending server had split the response from the sender, creating separate messages to each recipient but without cc or bcc information. Took me several days to understand what was happening. I hope this at least points you in the right direction.

Hi Greenman,

This might be, but the sender and/or sending (or relying) mail server in the internet does not know the uninteneded user address which could mistakenly used. The sender and the sending mail server have added/used the correct intended user address and the row mail is also showing the right (intended) user only, but Mercury has put it into the wrong local inbox of an unintended user.

That's right. In our case, the messages were addressed to another mail account on our domain but delivered to the 'wrong' recipient.

The best way to track an issue is usually to create a session log, assuming the problem can be repeated. If the .CNM file still is available that could perhaps be used (basically only the headers are needed). Other than that make sure there isn't anything else active that could affect mailbox selection, such as pseudonyms, filters or daemons.

I'm pretty sure we used the session logs. Mercury is configured to save all transaction logs so we were able to trace it back.

Thanks guys,

I have re-activated the session logging for MercuryD. Now I have to wait for further irregularities. Then I will report.

Indeed, we have also a synonym.mer in place for translating all outgoing local addresses into their official internet addresses. But I have checked the synonym file for correctness. Further we've got two global filter rules in place for sorting out spam mails marked by spamhalter. And finally also one content control rule set is working. But except the synonym.mer, nothing affects the concerned local users who has received the unintended mails.

Just experienced another case. W've got different e-mail addresses (e.g. address "A") with our ISP which will be forwarded (Standard-Forwarder) to another mailbox (address "B") with our ISP without polling mailbox A. Mailbox B will be polled and mail retrieved regularly by MercuryD. Now we have received such an ISP forwarded mail, which has been retrieved when MercuryD has checked mailbox "B". So far so good. But finally Mercury has unintendendly distributed the mail to 4 different local users. I have no idea. Below please find the .MD file of MercuryD session log:

Therein I have replaced the addresses with User A, User B and senders.domain

...

New oddity: A customer has sent a mail with different attachments, where not all attachments were received by us, but the mail was received without errors. Then he repeated to send this mail and we received other attachments allthough he had attached all again. I have no idea, what happens here. Just spoken with the support of the ISP - no idea, all works fine with them.

I guess I've found the error and in most cases the person in front of the machine is the problem. [:S]

Mercury is starting at our Windows Server 2016 machine as a service. This is to ensure that the mail server is running also in case of a server restart in my absence. When I'm back in the office, I manually stop the service and start the GUI to see the Mercury console at the desktop (for checking purposes, I'm the visual type and must see what happens [:D]). It seems that the service has either been restarted automatically or I forgot to quit the Mercury service before starting the GUI, so that finally 2 instances are working simultaneously and in rivalry.

For the next release of Mercury I would wish a clear setup procedure where I could choose how the GUI is presented, for example that the service is installed and that the GUI could be started on demand but without starting an additional Mercury process.

[quote user="Joerg"] ...

When I'm back in the office, I manually stop the service and start the GUI to see the Mercury console at the desktop (for checking purposes, I'm the visual type and must see what happens [:D]). It seems that the service has either been restarted automatically or I forgot to quit the Mercury service before starting the GUI, so that finally 2 instances are working simultaneously and in rivalry. ... [/quote]

Surreal. I've never used the Mercury as a service feature. 

[quote user="Greenman"]Surreal. I've never used the Mercury as a service feature. [/quote] Mercury has to start automatically also in my absence irrespective of with GUI or without. Therefore "running as a service" would be my first choice. Of course, I could start Mercury also via a batch skript. But also in that case I never would see the GUI because the desktop is started with session "0" and any later login will get another session ID, where I never see the GUI (if I understood it correctly) In both cases I have to stop Mercury and restart it manually. Then the GUI appears in the current desktop and (surprise) also in all subsequent RDP desktop sessions for remote access. According to the frequency of MS updates I have to restart the server once a month. And for this one time in a month I restart Mercury manually to get the GUI visible for the rest of the month [:)] This is my solution for Windows Server 2016 Standard. Maybe not the best but I can live with.

Cheers

Joerg

FWIW, I had Mercury running on a PC which was configured to auto-login and auto-start loader.exe on startup (Win7).  I don't know if auto-start of an executable is possible on a server but it may be worth looking into.

I say "had" because that PC failed and I haven't been able to get the auto-login to work on its replacement.

Running Mercury as a service is indeed often preferable when possible. In v5 it will again be possible to use the GUI when in service mode. (Still no estimate on when v5 will be released though.)