"Is the mail being sent to  user@broadoak.co.uk then being redirected to Mercury as SMTP mail?"

• Yes exactly that.

"If so have you told the router to send all mail for port 25 to the LAN IP address of the system running Mercury/32? "

• This has now been done - it works fine ... and I now know a lot more about how the router works.

Many thanks for your help and a Happy New Year to you.

[quote user="feamster"]I'd like to have mail end up in specific folders based on what is in the subject.  I'd prefer to have it occur at the server level instead of at the client level.  Example: If the word cnet is in the from field I can place it into my imap tech folder automatically.  I saw forwarding, copy, moving,saving to disk as actions but didn't really see anything that would do this.  Thanks[/quote]

Sorry, can't be done.  Mercury/32 knows nothing about the users mail folders when delivering the mail. 

Hello Rolf, 

I take your point and as I said, that is what we are focussing on, and I already have and use Second Copy. I just wondered if, knowing that things like interference, wireless blips etc can cause crashes, I just wondered if there is a better way to do this. I can use the software I already have, with all the different copy options: Synchronise source and destination to match exactly; Exact Copy - copy source to destination, delete obsolete files from destination.

Ellie 

I've given up at the moment on putting htdocs on the Netware volume.  Perhaps I'll try again later but at the moment I'm leaning toward reducing the dependence on Netware in case of a future upgrade to another server O/S.

I have over 5100 lines in my transflt.mer file and there are no performance problems with it.

It's possible to change the mail server account name to something else than maiser by editing the Maiser: line in mercury.ini. I haven't found a way to modify the description in the confirmation mail, though, or the sender for the welcome mail, as no headers are included in the template files. But maybe someone else knows a way.

/Rolf 

The encryption library used by Mercury for SSL can apparently only handle certificates that were created by the program itself at present. As Peter said, this is an important issue that will need to be addressed in future releases.

/Rolf 

There is some specific external reason for this behavior. A few things to check:

- Is there a real time anti-virus scanner running on the server? If it shouldn't be shut down then at least exclude Mercury directories from scanning.
- Is the disk that Mercury resides on error-free, and is there sufficient disk space available?
- Is there some broken message file stuck in the queue directory?

/Rolf
 

1 & 3. Always use the normal email address.

2. It will be intercepted by the alias and delivered locally.

4. Configuration menu, Aliases..., Add new alias

/Rolf 

Thanks.

Seems to be working well :)

Glad to hear that you have fixed it.

I assume you are running the MercuryE module for SMTP delivery? To get more information please switch on detailed logging in that module, send a short test message, switch off detailed logging again and post the result here.

Mail handler for the domain druifjes.nl is druifjes.nl with IP 72.29.64.240. mail.druifjes.nl is a CNAME for druifjes.nl, mailserver.druifjes.nl is apparently not registered in DNS. IP 72.29.64.240 is available and reports host name dime87.dizinc.com. There is however an Exim mailserver answering there, not Mercury:

220-dime87.dizinc.com ESMTP Exim 4.68 #1 Fri, 07 Dec 2007 20:39:57 -0500

/Rolf



 

Hi Rolf

Thank you for taking the time to respond.

I had increased the TCP/IP timeout to 180 seconds. That seems to work. I'm not seeing the errors now.  I'm also going to follow Thomas Stephenson's advise, and get the utility to run the MTU test.

Again, thank you.

Compton 

Hi Paul, thanks for your response.

The trial was being conducted externally.

We now know what happened - when the tester set up IMAP, instead of using the MercuryS server address for SMTP authentication, they used their own ISP. This is why they were still able to send email after the Mercury32 re-installation.

Sorry for the confusion.

When I tried I didn't manage to resolve tnl-online.net at all. The reason for that could have been that the two ns were not in synch - impossible to tell today, since they resolve now, however not valid. f.ex. delphi.tnl-online.net is cname for delphi.tnl-online.com - an mx should point to a record that has an A record - not all resolvers proceed beyond an inital cname since it's not part of the mx-rfc.

No not with aliases. But there exists a daemon that upon arrival changes the TO address form, so that it looks to be natively to the remotedomain.com and replaces the inbound job in the queue. If the MX-pointers then are in place, the message is routed off host. The daemon is called MXREDIR, located at:

> Same question (moving mercury(v4)...and possibly upgrading at same time)...but HAVE to use a different drive letter.
> Do I do a fresh install and copy over all the MAIL folder or is there more to it?

You can simply copy it across to the new drive letter and then open Mercury.ini in an ASCII editor and change all of the references to the drive letter.

Thanks for the quick response. I have turned on session logging in the mercurys and mercurye modules. I'm not sure how to identify a problematic message in the queue.

The server is operating normally now. I'll have to wait and see if the problem reccurs. No antivirus on the server, by the way. I haven't run a disk check but there are no disk errors in the event log.

Heh, just decided to read the specs - and yeah, you're right. It seems the people who designed the specs are more concerned about the weird ways people may implement the underlying system rather than the IMAP protocol itself.

If somebody doesn't know how to implement a translation layer between a protocol and whatever storage system they're using, I seriously doubt they should be writing a mail server. I think the people who wrote the specs should've focused more on clarity rather than worrying about possible implementation quirks.
 

You are right. I'd inadvertently changed to no formatting. Don't know how. Thanks for your help.

 Regards

 
John D.