> Each copy of Mercury sends its own mail directly with MercuryE.
>
> This all works perfectly well and is easy to maintain.

Personally I would use MercuryC at the branch offices to deliver all mail to the main site.  Otherwise the main site becomes the gateway host sending/receiving all mail from the domain, including the branch offices.  I do not know if this will fix the problem but since one site gets all the mail and local mail never leaves the local company LANs then it may help.  

I do not normally setup branch offices like this, I normally have all users mail delivered to local mailboxes and use Domain mailboxes to collect all the mail from the users at the branch sites.  I then use MecuryD to pull the mail for the branch offices.   

One real advantage to this is that the branch offices do not have their domain registered in the DNA since they are not getting anything directly from the internet.  You have one IP address and host name seen by the outside word.

YMMV ;-)

[quote user="Thomas R. Stephenson"]

Did not like my answer???  Why do you want to get us to answer again,

[/quote]

I did not dislike your answer; simply put, as I'm a novice, I did not understand that your answer implicitly said that my solution was not advisable...

[quote user="Thomas R. Stephenson"]

your method could work but it's not something I would do nor can I test it.

[/quote]

This is an answer that - as novice - I can understand.

Thank you and sorry for having bothered.

Best regards

Filippo

> 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