Have a look at http://community.pmail.com/forums/post/4965.aspx

Someone wants to know what your favourite choice of MTA is.  I'm well aware that Mercury is in the definite minority, but I'm pleased to see that it's explicitly represented in the survey.  Perhaps you can add your voices and give a genuine figure on Mercury usage; it seemed a post here (someone please advise the mailing list, too) would provide an opportunity for those not already aware of this.  The URL is:

I can't be surprised that Postfix is taking the beauty spot nowadays.  Two years back it was definitely Sendmail; nowadays Postfix is pretty much all there, copycat as it is; fast, flexible and secure.  But, for sure, Sendmail is still my top choice of power MTA when a Unix-like OS is available.  Mercury is the best I can find for Windows-only or Windows-majority situations.  I would sooner use Mercury on Windows than try to convert an existing Exchange into a usable MTA, either by proxy, modification or fronting using a Unix mailer if clients are all ready to go on Windows direct to an all-in-one piece-of-cake mailer like Mercury.  (If there's any doubt, that's no insult, David, in case you read this.  Mercury rocks and is NEEDED.)

Cheers,

Sabahattin

"Subject:" is not one of the SMTP envelope headers, which is what gets logged.

You could probably use a policy to call a batch file or other program to parse the message body and extract any info you want to a file.

no problems with srvr2008 in play - I've tested MercuryS/E/P/I under load with messages up to 30MB without problems. When I test I always test on a clean system, within virtual server or the later HyperV, meaning nothing else installed than Mercury on the test machine.

Most likely as Rolf has pointed out is that you have hooks within the WinSock stack that intercepts the traffic, examines and passes it along to the next process in the chain. These process hooks cannot be turned off unless you clean the registry hooks and re-boot the machine. We had similar problems with one particular build of NOD32 v3, and it resulted in frequent but random blue screens. We uninstalled NOD32, re-booted twice for all the hooks to clear, and the problem went away. Then later we applied a newer build of NOD32 v3 and there hasn't been problems since.

When you turn off an Antiviral or antispy software, the dataflow still has to be passed on to the hooks (= dll's the hooks point to) but, should be just going in and back out again. But if the Dll in play has some other form of fault, memory leak etc, then you get all sorts of trouble within the windows kernel.

Once again the online community came through.  Thank you for all your help. I found that the INI file was indeed considerably smaller than the bak & bk2 files. Copied over the backup file and all is back working as normal.

Thanks again

Is it possible to have multiple instances of Mercury running on different machines, all accessing the same outbound queue?

No it is not, you will send multiple messages if you try this.  You can split and use two versions of Mercury/32 and have one doing the sending and the other doing the receiving.  This second version would be looking at the same queue directory but would only be running MercuryC or MercuryE.

 We have several really large e-mail lists and want to set up another

machine to handle outbound mail for these lists. Our concern is that

the core of the 'secondary' machine will pick up a message that was

meant for the list and not be able to process it since it doesn't have

access to the list.

You can setup the second server to only process the mail for the list by having the first server forward any list mail to the mailing list on the second server.  You would create an alias pointing to the second sever via a user@[<IP address>] address form where the server name would be [<IP address>] so it would go to maiser.  For example, you create a list called "large_list" on the second server running on IP address 192.168.1.2.  You alias mail to large_list@mydomain.com to large_list@[192.168.1.2].  Now mercury core sees the mail come in for the list, creates and outbound task and ends it to the second server.  The second server sees the match for the server name and so passes it off to maiser.  The second server now sends out the mail.

This can also be done via a domain accont and MercuryD on the second server to pull the mail from the MercuryP server.

ok, it works, thanks a lot...

[quote user="PaulW"]

Go to Configuration / Mercury core - Files tab, and ensure 'Delivery confirmation template' points to a non-existant file.

or simply leave the entry blank.

[/quote]

You can disable delivery notifications by selecting Configuration / Mercury core / Files and removing the Delivery confirmation template (just leave the field blank).

/Rolf 

Ok, Thomas, that was it! Thank you very much! [:D]

I don't know why I left this field empty. I think because the docs say somthing about PMail and I thought this would only have to be set if I would plan on using PMail which I am not. The issue is solved than. Thanks again.

I normally e-mail myself, refrain from getting the mail, then spread the .cnm file to all local users account with the utility spread.exe found in the downloads section ()

You can alter the To: and/or From: information within the cnm file at your liking.

Check the log files and see if there is something special happening before the crashes that might cause this. If you have any scheduled activities on the server, like virus scans or backup, make sure they are not interfering with Mercury. Have a look in eventViewer for system errors and check the disk(s) with Mercury (program folder and Mail folder) with ChkDsk to verify that there are no broken sectors.

 /Rolf

[quote user="Rolf Lindby"]

The more details the better!... If messages appear briefly in the mailbox directory for the user and then disappears it could perhaps be that you have file based forwarding active for this user, with some kind of incorrect forwarding address and with Deliver-Also set to N.

/Rolf 

[/quote]

No i do not have file based forwarding setup at all and have not had it setup ever on this system. 

Thanks anyway

 grasshopper

thks yr reply

ok, the local user for the postmaster role is there. your idea reg. local users and forward files sounds to be a solution. i will try it.

thks

dhf

My wife and I are both members in a club that sends notices via google

groups.  Therefore two identical e-mails arrive via MercuryD, one

addressed to her, one addressed to me.  One of these e-mails will be

suppressed, and it is luck-of-the-draw whether I get the remaining one

or she.  Is there any way to disable this feature?

Only through the use of a special header in the mail message that provides the original RCPT TO: address.  You cannot use the X-Envelope-To: header for this since it's written at the time the mail is being written to a CNM file by core.  If there is no special header then you may have to use a filter to forward the mail from the Google group to the other user.

Checking for special headers in messages

By default, MercuryD goes through the standard headers in incoming mail looking for local addresses: the fields it examines are: "To", "Cc", "BCC" and "Received". MercuryD also records the Message-ID of every message it processes and usually will not attempt to deliver the same message twice.

Unfortunately, not all ISPs use POP3 mailbox schemes that will work with this approach: some use a non-standard header to record the address of the person for whom the message was actually intended - for example, "X-Deliver-To" is one that is seen from time to time. If your ISP uses a non-standard header to record the delivery envelope address, you can tell MercuryD about it using the Headers control: type in the name of the header Mercury should examine for local addresses (so, from our example above, you would type in X-Deliver-To). The field is not case-sensitive (so, X-Deliver-To and X-DELIVER-TO are treated as identical) and you can add the colon separator at the end of the name or not as you wish. If your ISP uses more than one special header to identify the local addressee, you can enter multiple header names in this field, separated by semi-colon characters (";"). You must not type any spaces in this field.

If you check the control labelled Check only in these headers then MercuryD will no longer examine the standard To, Cc, Bcc and Received headers for local addresses and will not discard duplicate messages. Use this control only if you are sure that your ISP always adds the header to your mail.

Your ISP will usually be able to tell you if they use a special header to identify the envelope address in your messages.

You know, I do have that turned on. I have checked the TCP/IP transfers periodically when these large files come through and they seem to be clean, no retries.  So I'll try turning off the session logging and see if that makes a difference.  Never thought of that!

Thanks!

There is actually a third way as well but it involves you writing a program to process the mail.  You can setup multiple instances of Mercury/32 with neither MercuryC or MercuryE installed in the main system.  You then  write your own program to move the MO*.QCF/QDF file pairs from the main system queue to the various queues of the other Mercury/32 instances to actually send the mail.  Could be nothing more than a looping batch file that spreads the files to the share the outbound load.  Probably a lot more trouble that it's worth though. 

Now what if I were to change the domain to southlandcrossingtv.com? I

would have to change the nameserver to hostrocket which is hosting the

domain I do believe... and then would the SMTP server stay the same? or

that would change also?

 This domain has an IP address and MX records.  If this is not your IP address then you really need and MX host with a lower number 9less than 10 anyway) pointing to the host name of the Mercury/32 host.

    southlandcrossingtv.com, MX, 10, mx4.hrnoc.net
    southlandcrossingtv.com, MX, 10, mx1.hrnoc.net
    southlandcrossingtv.com, MX, 10, mx2.hrnoc.net
    southlandcrossingtv.com, MX, 10, mx3.hrnoc.net
    southlandcrossingtv.com, A, 216.120.254.131

As far as I can see in the session log the PHP script attempts to send the DATA segment without first providing any RCPTs, which is an error according to the SMTP protocol. Headers that might appear in the DATA segment won't have any relevance for SMTP delivery. It's up to the sending client to extract RCPTs and provide them in a proper way in the SMTP transaction.

/Rolf 

Moved:

http://community.pmail.com/forums/13101/ShowThread.aspx#13101