> The ISP is a University system that we send a lot of mail to.

What server???  I could try from my side if I knew what server you are talking about.  Please do not make us guess about the problem.

> I had turned session logging on for a bit and didn't see anything that stood out and basically the same as the MercuryE module window.

Could you post the session log?

> I did increase my timeout setting but that didn't seem to improve
> things.

To what?

> I don't have trouble sending mail to other domains and according to one of their email admins they have 25 inbound smtp servers.

No big deal, a lot of places have multiple mail servers.

> I just thought it was odd that MercuryE only seems to try 4 before it stops and puts the message back in queue.

I doubt it unless the first 4 servers in the list are bogus and are there to stop spammers.  What happens when you telnet in port 25 of these hosts?

If you have to access a Netware file system, then you should NOT use Mercury from a service running.

We start Mercury in a scheduled task (Windows Task Scheduler) with the special Netware and Windows account after every boot.

To access the user interface of this instance you must stop this scheduled task. Then you can start Mercury with user interface.

Torsten

Disable the configurations like Mercury B and Mercury E to start Mercury C vis versa directly in the mercury.ini before you hit mercury.exe. There is a conflicting configuration in there, that I think is a bug in the software. 

> Sir it worked already... thanks a lot!!!! Uhm just additional inquiry
> is there a way to speed up Mercury's mail sending capabilities? like
> when I press send in Pegasus, Mercury is triggered to send the mail
> immediately, not like what happens now in which I need to wait
> sebveral seconds before Mercury sends... Thanks!!!!


Mercury is going to take at least a few seconds to send.  Mail is first put in the queue by the mail client, it takes a few seconds (10 is the default) for Mercury core to see the 101 file in it queue and process it as a MO*.QCF/QDF file pair for processing by either MercuryC or MercuryE.  MercuryC/E also takes a few seconds (again 10 seconds) to see the queued mail and sent it.  This is all by design.

This can be caused by logging off the client and then shutting down Mercury before HIERARCH.PM has saved properly. It takes a minute or two on my system. The lock file MAILBOXM.LCK in the same folder disappears at that time.

The fix is as Thomas says (as is everything else!).

 Chris

# is the comment character for the ini file where Mercury stores a lot of its settings. This means that the # itself and anything after that on the line will be considered a comment rather than part of the password.

I'll bring the matter to David's attention and we'll see if there is some easy solution.

/Rolf

Here, this says it in a different way, see if it helps:

I do that with rules at the top of the list that filter for those users on the basis of the To header and exit from rule processing.

Configuration > Filtering Rules > Edit Global Rules

but you say you've checked global filters?

Hmm ... if there are replicas of NDS on that server or not should not make any sense.

Netware should have NSS or TFS as filesystem. Which filesystem did you choose for OES2? Maybe the problem is in behaviour of filesystem, if it is linuxlike.

lg   Olaf

Thanks for your help, Paul. As ever, it is appreciated.

Thanks Jim

[quote user="jbanks"]

Perhaps your rule simply doesn't do what you think it should.

 [/quote]

 You are right. I was testing the text "opt-out", while the rule is testing for the text " opt-out".

All working!

Regards

Richard

The new mailstore that will be introduced in Mercury version 5 is planned to allow moving messages directly to IMAP folders. It's not supported in the current version, so until Mercury 5 I'm afraid it will have to be done client-side.

/Rolf 

Try to track how these messages end up in the queue. Are they from a local sender, or have spammers found a way to relay through your server? Make sure strict relaying control is switched on, and that there aren't any AUTH passwords that have been compromised.

/Rolf 

[quote user="silence"]

An alternative I have been using for a while. Stable and updated frequently:

[/quote]

Thanks for the link.  I've had it up and running for 14 days without any issues.  Still no word from Nico. 

It's not likely that the daemon starts behaving differently after some time, so if some messages with less than 25 recipients are filtered there is probably some other factor that is causing it. If you can figure out what that is I can try to fix it.

Check all headers in the messages to see if there is any clue why delivery failure notifications loop. It might be a good idea to examine the Domains section in mercury.ini as well in case there is some problem there.

/Rolf 

If neither Mercury nor Outlook can connect to mail.site4test.x10.bz it's a networking problem rather than a Mercury problem. Make sure that login details for the server are entered correctly in MercuryC configuration and that port 25 isn't blocked by some firewall. To get more information you can try temporarily switching on session logging in MercuryC.

/Rolf 

Hello Rolf:

 the Problem is not soleved. Stll the same more the relay option corses a lot 550 errors for legal user send out and filter generated copies to secondary external email accounts.

BUT--- For the Moment it is too much trouble on other problems to work on this one.

Thats not what i want but i use TB as a workaround an Filter by "feet".

I will send a new answere when their is time to work on.

Thx

Gregor

Are you talking about SMTP level filtering? As rejections based on reverse DNS lookups of SMTP HELO greetings are likely to violate RFC 2821 there is no built-in function for this in MercuryS. It would be possible to write an event daemon to do PTR lookups though, but I'm not aware that any such daemon exists.

/Rolf 

Thomas

Thank you for your response.  If you are referring to in config on mercury screen it is set to ~n.

Is there something I missed was the a config file I have to generate and copy?

I have a number of domain accounts on GMail that I use MercuryD to poll. For the past week or so GMail has been having intermittent connectivity issues. This is what shows up when there's a problem.

02:39:07.781: --- Sat Sep 03 02:39:07 2011 ---
02:39:07.781: Connect to 'pop.gmail.com', timeout 30.
02:39:08.890: 22: Error -41 activating SSL session (locus 6014, type 4, code 10054, 'WSAECONNRESET: Connection was reset by the remote host execu')
02:39:08.890: --- Connection closed normally at Sat Sep 03 02:39:08 2011. ---

The problem is that this fouls up the poll that happens two SSL connections later.  See the attached screenshot to see what the MercD screen looks like.  The above log snippet is in the middle with the odd-looking D at the beginning.  The transaction for the next connection ran correctly according to the log, though the status screen is fouled up.  Mercury completely crashed on the last one.  This is a repeatable problem.  Any ideas?