To all,

Thank you so much for all of your help! I think that was finally the last key to the puzzle, these last three posts. I am now underway and will hopefully leave this alone to function properly from now on! If I have anything further, I will be sure to post. Thank you all once again!

Iceman

Thank you for the quick reply, Rolf.  Yes, I will be making a back-up, though at over 6.5GB, this may take a while.

Thank you for the clarification, it's a pity that the SSL options are only for Mercury S.

I would be very happy to use a VPN, which is what I have been using with my WinXP laptop.  However, the Motorola Xoom tablet, which I have recently acquired, runs Android.  This doesn't seem to be supported by Road Warrior.  There is an Android client available for OpenVPN (the VPN that I have been using), but it requires me to "root" the Xoom.  This potentially voids the warranty, which I don't want to do so soon .... I may do this in a few months.  From what I have read, the VPN situation on the Xoom is a real can of worms at the moment.

Gordon

[quote user="CitizenA"]

Current workaround is a dummy mailadress for external users which is then forwarded to the correct address.

I assume I'm not the only one with that kind of problem and hope there's better solutions within Mercury, though actually I couldn't fine anything yet ...[:'(]

Thanks

Anton

[/quote]Why use a dummy address? Just add their addresses as alias's to their real address.

Or, are you doing it wrong, and using an externally hosted domain as your local domain?

You should use local. com and have an alias list for your local users pointing abc@xyzdomain.com to abc@local.xyzdomain.com .

That way any mail from local to local will not be routed to the 'real' MX for the domain, but local to external abc@xyzdomain.com will be.

Users will need to authenticate to relay mail (they should be already!) or you can allow relaying by ip address.

The detailed instructions are in the help files :)

Edit: [quote]Mercury working in a Netware bindery environment[/quote]

I don't use a Netware environment and there may be some different options.

I have been looking at the .msr files and these reflect what PaulW said earlier in the thread. There are differences of just 1 between a couple of the dates.

So, the mail statistics that are emailed are not the same as the statistics saved by the .msr files. The number of messages sent is the same, but the value in brackets do not match.

The solution file did not work, sorry.

However, I found the error and feel rather stupid.

C:\MERCURY\Lists.mer is not the correct location, I missed it by a level C:\MERCURY\MERCURY\Lists.mer.

So now all my data files work fine.

Sorry.

I have now installed the latest version of Thunderbird and this seems to be working pretty well with Mercury.  I am not even seeing empty message bodies, which was happening before .... so far.  However, when I start up TB, a message appears saying "The IMAP server [account name] does not support the selected authentication method ......".  Despite this, messages are being downloaded by TB.  Is this normal when TB works withi Mercury?  I have set  TB to use STARTTLS.  The SSL/TLS option doesn't work.

Gordon

No I haven't found the solution for this yet, though I've been rather busy so it hasn't gotten very much attention.  I'll give your solutions a try though.  Thanks.

Hmm, the N as the third argument should apply the rule only if the Mail From: does NOT match the given text.

Presumably the SMTP envelope MAIL FROM: is being set the same as the "Sender" address?

Check with transaction logging.

edit: try "*your@address*" to account for control chars in the parsed field

This is a discussion group for the Mercury email program. You claim you received an add for a Mercury automobile. Are you sure you posted in the right forum?

I eventually bought the Motorola Xoom and am largely very happy with it.  The Android K9 mail client appears to work well with Mercury IMAP.  I am marking this question as Resolved.

Gordon

The default settings in Mercury are usually the best place to start. For Windows 7 you will need to download the WinHelp installation files from Microsoft to get the actually very useful help system working. This KB article has the download links: 

There is a PDF manual included in the standard Mercury installation too. I'm not sure if it's there in Xampp as I haven't tested that package.

The current version of Mercury is 4.73 and in most cases it's a good idea to upgrade.

If you need help with specific details about the installation please let us know a bit more about your requirements and network environment.

/Rolf  

A little more testing with hints from what has been happening and I am now at the point where I can reproduce the problem exactly time after time.  First things we can rule out, file caching by the Netware client, it happens exactly the same whether the caching is on of off.  The problem is related to the SSL errors we see on both Thunderbird and Mercury when Thunderbird is first started.  Specifically where on an initial attempt to connect, Thunderbird's error console reports "server does not support RFC5746, see CVE-2009-3555" and Mercury reports "SSL direct-connect failure form ....".  When Thunderbird starts up and attempts to connect, it fails with the error message noted, however the TB status bar is still "displaying Connected to test.mailserver.com".  I have always been somewhat suspect of messages in TB's status bar, however can not afford to spend the time to dig through the readily available source code to verify what is going on.  In any case if I at this point mark a number of messages in the inbox to delete in the inbox window on TB, and for the sake of test, I pick the oldest 24 so things will be looking the same in the logs as they were in the previous test and press the delete key, those 24 messages do appear to move to the trash folder on TB.  I switch to the trash folder in TB and at this point it now establishes a real connection with Mercury, which show up in the Current connections and status window on Mercury at this point.  If I at this point switch TB back to the inbox view, I now see all the messages I just deleted.  For the sake of this test, I do roll the mailbox back to its initial state by replacing all the files in the PMAIL folder of the test user in question to the exact state they were in before the test so we are always starting with everything at exactly the same point.  On the client side, the computer in question is always rolled back to a state where everything on it is back in a state where TB had successfully gotten it self in complete sync with no ongoing problems.  At this point if I delete files from the inbox in TB, they come back after switching folders. 

  If I look at the Mercury logs after this has happened and pick the oldest message that I deleted, I see it come back with a different UID.  Also if I look in the test user's PMAIL folder, I find the .CNM file from this message with the only difference between it and the original being the addition of a line as follows

X-PMFLAGS: 570949760 0 13 292DC404.CNM

This line is inserted just after all the rest of the headers and before the rest of the message, specifically the line 'This is a multi-part message in MIME format.'.

On the surface it appears that TB is moving the message to the trash folder offline and not marking it to be deleted because it does not have a connection to the server.  Once it does establish a connection to the server, which happens when the user takes some action, such as clicking on get mail or switching to a different folder, it now makes a connection and then syncs the message that it moved to the trash folder back to the server and the original is still in the inbox because a delete message was never sent due to the lack of a connection.  This would appear to be a bug in Thunderbird, however I will immediately get feedback from my users to the effect of "This never happens with other iMap servers". 

Gus

Although I have been using filtering rules for several years. I still don't think that I have a full understanding of them.  For example, as I understand it, Global Rules affect both incoming and outgoing messages.  Outgoing Rules affect outgoing messages, but there seems to be no direct way of only dealing with incoming messages.  For me, it is almost always the incoming messages only, to which I would like to apply rules.

Another thing that I am not sure about is whether all outgoing messages will be processed by Global Rules.  For example, if within a Global Rule set, I forward the message currently being processed, is this message added to the mail queue again and, therefore, gets reprocessed by the Global Rule set?  Similarly, if I call a program and that program sends a mail message (e.g. with Mercury's msendto.exe), does this message get put into Mercury's mail queue and, therefore, gets processed by the Global Rule set?

On the assumption that some messages (e.g. forwarded messages) get reprocessed by the Global Rule set as they go out, I have placed a number of rules in the Global Rule set to check whether the message is outgoing.  This isn't very satisfactory and it may not be a correct thing to do.  Even (potentially) worse, if any of these outgoing messages exit the Global Rule set are they then subject to Policy actions.  So, for example, if one of my Policy Tasks does some checking for spam, I would possibly not wish to have any messages that I am forwarding checked by the same Policy Task as I am using for incoming messages.  Do I, therefore, need to have the program, which is being called by the Policy Task, check whether it is dealing with an incoming or outgoing message?

This would all be simpler if incoming and outgoing messages could be filtered separately.

Perhaps someone could help me with these mysteries!

Thank you

Gordon

> You have made me wonder about whether I could extract the connecting
> IP address from (presumably) the Mercury log.

The log does have the IP addresses of the connecting host.

T 20110501 000410 4d9fbdca Connection from 62.20.118.73
T 20110501 000411 4d9fbdca EHLO mail.praktit.se
T 20110501 000411 4d9fbdca MAIL FROM:<NoReply@praktit.se> SIZE=4291
T 20110501 000412 4d9fbdca RCPT TO:<support@tstephenson.com>
T 20110501 000412 4d9fbdca DATA
T 20110501 000413 4d9fbdca DATA - 69 lines, 4397 bytes.
T 20110501 000413 4d9fbdca QUIT

That said, I use POPFile and POPFileD for spam and this is 99.97 percent effective.  I move the spam to a spam account that I check every so often so my false positive rate is zero.

Sure, here is a link to the Mercury Daemon developer kit:

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

/Rolf

Why not use Mercury help (or check the PDF manual) instead of searching the Internet, it's more efficient! ;)

First make sure the local domains part of Core configuration is correct. If users should be allowed to send messages to non-local recipients you should add the IP range of the LAN in MercuryS configuration, Connection control and allow relaying for that range. Verify that the ports for the email protocols you use (SMTP, POP3, IMAP...) are not blocked by firewall software on the server.

If you still can't get it to work please post your mercury.ini file here so we can check it!

/Rolf

Figured out after some digging that I was running IIS in the background, turned it off and now the world makes more sense.  Thanks for everything![Y]

Thank you Rolf, i will be waiting.