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.

Or create a queue file and place it in the queue.

Apparently the issue isn't as solved as I hoped.

 We got several more failures over the weekend.  I was able to have one of the problem messages sent to my personal gmail account.  The attachment was in pdf format, and was 293K.  When I tried to forward that from gmail to the originally intended office address in Pegasus  I could see the message hit the SMPT server on Mercury, but it never went to the core - or to intended mailbox. 

 I spoke to the ISP (who say it is not a problem on their end) and our consultant who suggested it might be a problem with timing out.  The TCP/IP is set to 60 - should it be higher?

Also - I tried to update to v 4.01c.  I did manage to get to 4.01b (which I needed before attempting to patch to c) but I can not get the 4.01c patch to apply.  I exited Mercury.  Copied the dll file into the Mercury directory - restarted...and still show v 4.01b as the current version.  Any ideas on that?

thanks in advance

Michele

> Hi everyone,
>
>  
>
> I've recently installed Mercury Mail on a Windows XP SP2 machine. We
> are using Novell NetWare Client 4.91 for our Network.
>
> Mercury is configured correctly to work in NDS-mode and it does work
> properly. I can get my messages either with Pegasus or by using
> POP3/SMTP/IMAP/etc.
>
> Now I have set up Mercury to run as a Service with SRVANY.EXE and
> INSTSRV.EXE both from Microsoft. This still works as intended: all
> Processes are running and responding. But when I try to log in with
> telnet to test (e.g. telnet foo.example.com POP3), the process does
> answer, but when I try to login with USER usr.CONTEXT and PASS pswd, I
> get a LoginFailure. Certainly this procedure works when I do not run
> Mercury as a Service and only when I've manually logged in as a
> NetAdmin (user with sufficient rights) in Novell.
>
> In Mercury.ini i have set:
>
> [NDS]
> UserID: Netadminfoo.RWTH
> Password: barpw
>
> Is this right?
>
> Why does Mercury not login itself with the give User and is it
> possible to run Mercury as a service and with NetWare support?

Hard to say why it's not authenticating to the Netware host but IIRC the service is running as system and does not authenticate to the Netware host.  I use NT Wrapper to connect to my bindery host since it has the capability of running as a specific user to make the Netware connection.

The NT Wrapper allows standard Win32 applications or scripts to be run as a Windows NT/2000/XP/2003 Service.  

Features:
    ·    Easy configuration thru a GUI and simple INI files.  
    ·    Prioritization of sub-processes.  
    ·    Custom environments.  
    ·    CPU binding  
    ·    Redirecting of Stdout/Stderr to file  
    ·    Logging to the event log and to disk.  
    ·    The capability to run multiple applications in a
          single NT Wrapper service instance.  
    ·    Monitoring of a service in the sys-tray.  

http://www.duodata.de/ntwrapper/



>
>  
>
> Thanks for help
> Sincerely
> Horat
>  

Hello,

Mercury is used on this Win2003 Server hostname DME to send out mail from a Unix host.

DME is part of a .local domain.

The outgoing email from the Unix host always uses the same From address.

Some  jobs are sent OK but some show message loop detected - message discarded.

What should be the correct entry in the  edit local domain page for local host and internet name?

I read the help file but wasn't sure because of the .local hostname. 

Thanks,

Oded 

Hello!

What is the subject to trigger that content control rule?

I think what you want to find is a line like
Subject: [SPAM] Buy this!
i.e., a "Subject:"-line your ISP has added the "[SPAM]"-tag to.

If this is what your content control is to find, then I suggest the following content control rule:
IF SUBJECT MATCHES "[[]spam]*" WEIGHT 51 TAG "Flagged by NTL"
Note that the leading bracket in "[SPAM]" has to be masked. When used in a regular expression, "[" is considered a metacharacter; if you want to use it as a normal character, "[" has to be masked, e.g. placed within "[ ... ]".

Perhaps, you also need a leading blank space before the Spam-tag. Then, the rule could look like this:
IF SUBJECT MATCHES "[[]spam]*"
OR SUBJECT MATCHES " +[[]spam]*"
WEIGHT 51
TAG "Flagged by NTL"

[quote user="nijinski"] 116.25.87.49 this is my ip address according to whatip.org[/quote]

Rolf wrote: "I think you first need to verify that  220.112.193.167 is your current IP"

I can see your IP changes frequently. Currently your MX points to conneally.net, and conneally.net has an A record for 220.112.193.167. This would work, as long as that was your current IP, which it isn't. So somehow your dyndns isn't updating your current A record for conneally.net

Regarding the port forwarding:

First test and verify that you can reach MercuryS from your own network, by using telnet as you did: . If you do not get a response here, something within your machine is blocking inbound traffic (f.ex. windows firewall or another port blocking software)

Secondly, test and verify that you can telnet from the outside through your ADSL modem port forward based on IP number, telnet:116.25.87.49:25

Lastly, check that the DNS matches your current IP. You can easily do this with nslookup from a command  window. And when this works, telnet:conneally.net:25 and you should be through the hardest parts.

[quote user="Methuselah"]

Hi there.

I was trying to implement an autoreply using template.
( I chose failure.mer  for starters)

I tested by matching to a known webmail address, twice.

I think it worked, because I saw the Mercury Core Process display showing a message being created by postmaster@myserver.com going back to the address I sent from.
There are also 2 jobs listed under Ready: in the Outgoing Jobs: line.

  
Thing is, they never leave - no response to the sender over an hour later.

1.  Where can I view these jobs ?

2.  How can I get them to go - I guess there is some config thing I have missed.

Robin.

 [/quote]

 I assume you are replying to a non-local address and you saw core create the message for the external email address.  You should see these messages in the outbound queue as a MO*.QCF/QDF file pair.  This is assuming that MercuryC/E has not processed the outbound mail.  What do the system and the MercuryC/E logs show?