I see. Many thanks. 

Last post in this thread.

Today I sent a message to 7 local addresses. I added the addresses to the Cc field via an address book which lists all local accounts. Two accounts did not receive them. Mercury had 'killed' them.

I chose 'resend this message' and sent it to them individually and they received the messages.

Neither of these accounts are subject to mail filtering at all.

This is a PITA, but I can't see any way around it.

I've not upgraded to 4.8 yet as I have a ton of other things to do. Hopefully, that will sort this weird issue out.

No need to respond.

They may be the cause of the "still trying" messages - but in this case the messages were delivered OK.

That's basically it, switch modules and restart Mercury. I assume you already checked that the new ISP isn't blocking port 25 for outgoing messages and that there is a reasonable PTR record for the IP address.

OK so I made another test:

I opened a mailbox with IMAP, removed the connection to the network from the computer running the IMAP client, and closed the IMAP client. The connection was still up in Mercury's console, and the lock file was still there. I reconnected the network and opened the mailbox again. Mercury now showed two concurrent IMAP connections to the mailbox. The mailbox was fully accessible, except messages could not be deleted (which is expected behavior with more than one IMAP connection).

Multiple IMAP connections to the same mailbox are allowed, so if one connection is lost due to client side failure it makes no difference for creating a new one.

The best shot at finding out what actually happens when your user gets locked out is probably still to try to catch it in a session log. 

[quote user="RP_Joe"]So if you have a small office can  multiple people on workstations access the same mailbox?[/quote]

Yes, but not simultaneously.

[quote user="RP_Joe"]I am thinking about the webmail feature. 

If we set this up to pop our addresses from the web hosting company, then two of us can process the email from the local Mercury server, using webmail.  Is that possible ?

Could two of us use a imap client? [/quote]

Yes, but with some limitations, one of which being that a simultaneous IMAP connection to the same mailbox prevents either user from being able to delete messages. 

If the need is to share the same mailbox with full functionality by each user then you have no choice but to take turns.  If you just need to share messages then there are a few ways that come to mind using a multiple user configuration in Mercury.

• Use a filter in Mercury to copy messages to the second user.  Configuration can be such that it appear to recipients that replies made be each user came from the same sender.  Alternatively, the copied message could be filtered to a folder associated with a specific identity configured such that replies appear to come from the appropriate sender (assuming Pegasus Mail is the email client).  A permanent BCC in the configuration can copy the other user on all replies if that is needed.
  
• Use a filter to copy messages to a directory that is added to each users folder list as an added mailbox.  One problem with this approach is that changes made by one user (like deletes) are not reflected in the other users message list until the mailbox is manually refreshed.
  
• Create a public folder and filter messages to it.  Public folders are visible in the folder list to all users of the system.
  

A problem with the last two options is the handling of copies to self as this can not be automated if it is important that each user have access to the copies to self.  They will need to be manually directed to a copies to self folder in an added mailbox or to a second public folder (public folders can not contain trays).  Obviously the best option depends on the ultimate goal of the sharing.

Hi folks 

Can anyone confirm the following behaviour and suggest some way I may work around it? 

I'm using a SYNONYM.MER file to customise the email addresses used by Pegasus in the FROM field of outgoing emails.

My current synonym.txt file I created years ago contains 37 lines.  7 of them are like email1@example.com == username(1-7), and the other 30 are email2@example.com == username(8-37).  Therefore,  username on each of the 37 lines is different, but there are only 2 email addresses shared amongst the 37 users. 

I'm trying to change 3 of the 30 lines from email2@ to email3@, but as my subject states, the  FSYNONYM.exe program which accepts the synonym.txt file as an input and SYNONYM.MER as an output claims that 1 email address can not be mapped to multiple users.

The Mercuy help file regarding the subject hasn't changed since I last made a modification, but it seems that the FSYNONYM.exe program has, and not for the better.

Any and all help appreciated.

Thanks 

EDIT1:  After some looking I believe I see where this problem is.  I suspect the last time I ran FSYNONYM.exe I was using Mercury4.7x.  The program there states it is "Mercury File Import Synonym Database Builder v1.00".  While in Mercury 4.8x, the FSYNONYM.exe version is v2.00.  v1.00 had no issue with synonyms to multiple users, but v2.00 does.

EDIT2: Since edit1, it solution is quite obvious.  Thankfully I have a backup of the Mercury4.7x files, and used the FSYNONYM.exe from there to update my SYNONYM.MER file.  And then simply copied that file to the places it needed to be.  However, I would hope that the change in behaviour from v1.00 to v2.00 of FSYNONYM.exe was for a good reason.  So, is there a new, more suitable method to using the old program, or is this change unexpected?

Hi, i will share you my Website, where you can Download the latest OpenSSL 1.0.2x for your Mercury. Many Binary Builders switching to OpenSSL 1.1.1x so its hard to find the old LTS Version. My Build is Compiled with standard options of Openssl and is full compatible exept of the HEARTBEATS option wich is disabled. Just Download the ZIP and copy the 3 Files inside the BIN Directory, to your Mercury Folder. You have to use the VC-32 Version.

https://www.bk-net.tk/?cat=15 < Normal Build

https://www.bk-net.tk/?p=1206 < Special Mercury Build (without sslv2, sslv3 and rc4) 

No solution.  The problem is exactly as you describe.  Mercury locks the mailbox when it is being accessed by IMAP, Pegasus Mail locks the mailbox when it has access.  One thing that makes it frustratingly worse is that iDevices do not release the IMAP connection even when the device is turned off which is causing real problems for our people who what to use the Pegasus Mail client while at their desks but rely on IMAP access from a variety of iDevices when traveling. They have no choice but to ignore the lock warning of Pegasus Mail.  I think I have had to repair folder corruption only once because of this.

The questions was asked regarding why it is a problem in v4.8 but wasn't in v4.74 and the response was that v4.74 must have been broken because simultaneous mailbox access can cause corruption regardless of the type of connections.  For me it would be helpful if a connection attempt by Pegasus Mail on an IMAP locked mailbox generated an option to disconnect and block any IMAP connections during the session.  This would work because my folks already know to call in and have someone shut down their Pegasus Mail when IMAP attempts hit a locked mailbox. 

FWIW, Mercury handles all of our mail processing and spam filtering so there is no advantage for a user to leave Pegasus Mail running.

Switch on session logging for MercuryD temporarily to see exactly what happens!

Brackets are for numerical addresses only. 

It might be possible to break a loop by adding a header and having a global rule look for it, but it's of course better to avoid creating the loop in the first place. Check console or logs to see if the looping message actually is sent out by MercuryE or if it loops locally on the Mercury server. Unless the MX record for mydomain.de points to IP 11.22.33.44 there shouldn't be a loop.

I've tested forwarding messages from Mercury to another Mercury server and to a common webmail provider, and in both cases the TO: header is unchanged and the original recipient address is shown in the client. It could be that the server program used for your German MTA behaves differently though.

The rule you describe should work assuming that the message actually had a TO: header containing user123@mydomain.de. It would miss on header CC: unless that was selected too (an would definitely miss on BCC as that isn't a header). Try using action Log a console message when testing if a rule triggers or not.

I dont run real time antivirus

You're missing a few special issues with Win here:
The limited user as itself is not the problem but the way the software is started as a limited user.
Runas != normal program start as user. If you login as that user and then start the program should work OK (can't test as I have no console access and don't want to add mercury user to various groups).

Also the switch /env changes the environment to be used to "to use current environment instead of user's." Thus the Admins Temp dir for writing temporary files (*this* behavior will have changed from 4.7.4 to 4.8: in 4.7.4 mercury.ini was written directly to, now it behaves as if a temp file is created and moved.)

 Also your conclusion is wrong as  the command that reproduces the error actually *is* issued from C:\Mercury ("cd C:\Mercury").

Sorry but that's how it is over here.

Right, existing licenses are good for all v4 releases of Mercury!

There are actually a few important fixes in v4.80 final, so I would recommend to update. 

In case you didn't already see this: 

http://community.pmail.com/forums/thread/44354.aspx

As far as I can see membership files are not automatically deleted when a mailing list is removed.

Install the latest version of Mercury with default settings and modify only those settings that must be changed. It's important to define host name for the server and local domains correctly, so please read the information in the installer carefully, and check Mercury help or the PDF manual for additional information. It's actually a good idea to spend some time reading relevant parts of the manual. 

After installation you can create accounts for your users. Your firewall will need to allow access to at least port 25 (SMTP) and port 143 (IMAP). If you want the server to be reachable from the Internet you will need to forward those ports from the device that connects to the Internet (modem/router/firewall) to the server that is running Mercury.

[quote user="Rolf Lindby"]

There are a number of different ways to time sort email messages, so there isn't a single correct way to do it. The basic IMAP protocol doesn't include sorting, but there is an extension that allows it. At this time IMAP SORT isn't available in Mercury though, so it's up to the client to perform all sorting. 

[/quote]

Unfortunately our webmai client does not support sorting: it simply list on user's webpage all mail messages as they are received.

I thought that message's filenames was appended in the "_INBOX_.PNM" file neatly one after the other, and i was surprised to find all mixed.

ALex. 

Right, as Brian confirmed too, Windows 7 will handle all TCP/IP connections the same way as a server OS would, including email protocols. The difference is the number of connections to Windows resources (like file shares), and various server functionality like AD, IIS and DNS.

Found the problem!  I had a trailing comma in the Clamwall banned extension list which apparently tells Clamwall to ban any file without an extension.  Removing the comma allows files without extensions to pass.