I don't think you may switch, because the APIs used for sending broadcasts by Mercury are provided by the Netware Client and the use of APIs is hardcoded in Mercury. There is no output by the coremodule like "send <user> <subject>".
But may be I missunderstand your environment. I understand you're having a Novell Netware Server with Novell Accountmanagement (which ever) and Mercury configured for use of this accountmanagement. In this case Mercury assumes a Novell Netware Client for full functionality. SEND respective the Novell-APIs know about Netware Users and are capable identifiying a workstation, where the Netware user is logged in.
NET SEND only knows about local users on Windows or users in a Windows DOMAIN/Active Directory. In this case the pre-condition using NET SEND is the same username on Windowsworkstation/-domain than on Netware. But even than there is no support in Mercury for Windows Accountmanagement and in consequence no use of APIs for NET SEND.
Just set up any email client on the host system to connect with IMAP to 127.0.0.1 and see what happens.
From a networking perspective it will make no difference what folder a message being requested by IMAP is in. Can you open the new messages (.CNM files) in the mailbox with for instance Notepad or are the files corrupt?
Mercury works with any reasonably standards compliant email client, including Outlook and Thunderbird. For most uses the default settings in Mercury are OK. You will need to enter the information that you are prompted for during installation, of course. Pay special attention to getting the local domains settings right.
Most alias are pointing to non-local addresses. The problem occurs both for local and non-local real addresses, if and only if these are pointed by an alias.
The delivery confirmation works. But the QDF file contains two "BA:" entries, one of which ("BA: Postmaster") seems to be incorrect (domain part is missing). Have you checked your queue after receiving the delivery of confirmation message?.
I solved the problems I was having with Mercury I got Mercury through xampp. I just opened xampp control panel and unchecked the box for service on the Mercury mail area and it cured all my problems so far for getting in the admin area. I just thought everyone would like to know. Thanks for the help.
You could try running a "virtual SMTP server" like Loa PowerTools () on your own machine. It looks to applications on the local machine as though it's an SMTP server running on 'localhost' (or 127.0.0.1) but is connected (via Port 443, the secure http port) to a real SMTP server running elsewhere. You can find a discussion of it in connection with Port 25 blocks and ISPs atbit.ly/G46Pm and on a blog at bit.ly/bBjiNw.
I suddenly (everything was working fine for a few years) had the same problem running Mercury as service (by the help of NSSM utility), while running it as application with GUI did not reproduce the problem.
Analyzing the activity of the server with the help of Process Monitor utility, I found that it was not able to read the certificate file.
As soon as I assigned read permissions for the SYSTEM account (which is used while running as service) the problem was solved.
I am following this article about MercuryE but I changed localhost with my real public IP
If you want to run Mercury as a normal mail server the default configuration is usually the best. The installer will prompt for most of the needed information. The most important things are the hostname (Internet name for this system in Core configuration) and local domains (in Core as well). Mercury help usually gives good information in case something is unclear.
myname: [172.74.77.141] # Canonical name for this server
If you have a properly registered domain, put the domain name here instead.
MERCURYX.DLL
Disable this module unless you really need it. There is a nasty bug in the 4.72 version.
If you have a domain, HELO should preferably be domain name or hostname for this mailserver. Nameservers need to be filled in only if your Windows installation for some reason isn't providing Mercury with this information.
HELO is not needed here, remove the line. Relay must be 0 and Strict_Relay must be 1, otherwise you will be an open relay and your server will be blocked everywhere. Interface is not needed, remove the line (this applies to all other modules as well, I won't repeat it).
[Domains]
localhost: localhost
localhost: [127.0.0.1]
This is quite bad. It should look something like this:
mail: servername <-- Windows name for the server
mail: domainname <-- i.e. mydomain.com
mail: full hostname <-- i.e. mail.mydomain.com
mail: [local IP] <-- i.e. [192.168.1.10]
mail: [172.74.77.141]
A restart will be required after making the changes.
[quote user="Nikolas"]Is it true that POP3 and IMAP user names and passwords cannot be sent encrypted?[/quote]
Not really, the connection you use to the server can be an SSL/TLS encrypted tunnel so that all traffic, including the user/pass authentication, won't be accessible. Most modern clients support SSL connections.
It's not yet fixed if this server is open to the internet - these relay settings allow anyone to relay through your server and will get you on blacklists before the day is out.
Relay : 0, Strict_Relay : 1 is secure. (Equivalent to checking the top 2 boxes in MercuryS config | Connection control - Relaying)
I have removed the Interface. I don't have a local domain as such as I am using this to pull down several POP3 accounts for myself and my wife. After reading the section in Help it did not make any sense to configure those settings.
Hi! And many thanks! Once again! So, MercuryC.NLM work as should (~ designed) and problem lies in sender (mail-system)! Great support! Also, our best to mr. Harris! More thanks, Alar from Tartu Uni, Estonia. PS! I got another such a sender and there was "Reply-To: <>". And, yes, it failed autoforwarding.