[quote user="opa56"]

Hi

Mercury as a service works fine on Windows 2008 R2 SP1 Enterprise X64

Cheers   Peter

[/quote]

 On Windows 2008 R2 SP1 Foundation also!

Well, that was rather embarrassing for a whole mornings work.  Thanks.[:'(]

In the last two days, I have received 3 notifications from Mercury that it has recovered from an "abnormal termination".  Most of the messages (all SPAM, of course) that caused this have very strange (Russian character encoding) From" headers.  I have never seen this before in several years of using Mercury .... maybe I am fortunate.  A typical From: header is:

From: ?koi8-r?B?98HMxc7Uyc4g8s/Nwc7P1yA8PT9rb2k4LXI/Qj82Y3pZMFNEd3o4Nw==?= =?koi8-r?B?UHpjSFN4ZGNnUEQwL2EyOXBPQzF5UDBJL1NVOTZRakU1VEVaNmRGUg==?= =?koi8-r?B?WmVBPT0/PQk9P2tvaTgtcj9CP1pHTm5VRVF3TDJFeU

I think that the whole From: line may be in cyrillic.  .

Does anyone know why Mercury is having to "Recover" as  a result of these messages being in the queue.  Not all of these "bad" messages have this strange From: line, but most do.

Thank you

Gordon

Double checked hotmail and found the email was sent to spasm, So it is fixed.

AOL on the other hand, not spasm but get lost for a while.  Sent 10:30 am, finally show up in the inbox at 5 pm. Novertheless, it arrived.

Thank for all the help.  We are slowly picking up how the program work.

At this point, our problem, of course, is still addressing the incoming email.  It seems our ISP only recognized the standard format.  At least the work around works.

Looks like your new ISP is blocking port 25.

You will need to change to MercC to relay through their SMTP server.

My bad. I did but it didn't make sense.

Error -32 activating SSL session (locus 6014, type 4, code 0, 'Bad server key agreement parameter signature')

Hello Rolf,

Thank you for your answer I will try your suggested webtools solution.

The windows version is Windows Server 2008.

Best regards,

Jhonny

Hello Thomas,

I have tried both solutions (just to learn .. ) and I have to agree with you the mailing list is much easier than the filter or maintain a forward file.

Thank you for your support.

Best regards,

Jhonny

Link for Island Def Jam Music Group, the current owners of Mercury Records.

Thanks for the confirmation, Thomas.  As it's the security of mobile (public AP) connections that I am most concerned about, what Xoom/K9 offers with CRAM-MD5 will do the job.  The use of CRAM-MD5 will provide protection for my logins (I will be the only mobile user using my server), specifically just the password, I suppose.  However, it seems that Mercury will still also accept plain logins.  It would seem better if CRAM-MD5 had to be used to login, but I don't know whether it is normally used in that way by IMAP4 servers.

Thank you

Gordon

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