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

Thanks very much Thomas, it worked a treat.

M

It seems to be an error generated directly by mercury.

The message headers indicate:

From: postmaster@[203.26.##.##]

To: admin@[203.26.##.##] 

The attached message has failed delivery and has been referred
to you as postmaster. The following error report or reports
were given to explain the problem:

   *** 
   Error connecting to primary server '210.9.177.134'.
   556 Too many invalid recipient requests. Closing connection.

This is Mercury/32 message back to you reporting it could not deliver the message and the error message sent by the mail.universalmagazines.com.au server.  

 Now if there were only one RCPT TO: in this particular message then I suspect that they are storing the IP addresses of the connecting hosts that send to 

a lot of invalid addresses.

Thank you, Thomas.

It was a filter. The original address does not exist on our system and a filter is used to move the message with that address in the To: and Cc: fields to 'user'.

So, each time Mercury/32 encountered it, the filtering rule kicked in.

Man, another one! D'oh! Thanks a lot for your help.

Cheers!

Your ISP is validating the MAIL FROM domain (as many do) and it can't find it.

Hi Thomas,

Thanks a lot for your always quick and good

response. After editing the hierarch.pm including removing of the

Unavailable entries my mail folders in Pmail are clean. Also the

removing of the caching folders caused no problems.

regards

Where is the test.sh file located? Try adding that directory to the PATH variable for the system, or use full path when calling it.

/Rolf 

[quote user="lieven23"] If I want to run Mercury it loads for a second then it closes  [/quote]

Locate Mercury.Ini, and remark the modules loaded, so that only the core loads. Try then to start Mercury. Mercury should not close itself immediately unless something is interfering and telling Mercury to close.

Doesn't look good, I'm afraid. With invalid entries for local user, default user and postmaster there is no place for MercuryD to deliver the mail so it will not be saved - just as you probably already realized. I hope all the messages were spam...

By the way, with a correct local account entered as local user there is no need for a default user in MercuryD as everything will be delivered to the local user anyhow.

/Rolf 

Hi,

  I kept fiddling and it seems that, despite there were no real configuration issues, MercuryC wouldn't work while the end-to-end client worked like a charm from the first unconfigured start. Odd but... it's fine to me for now :)

Thanks for pointing me out that there are actually TWO distinct smtp client daemons in Mercury.

 - Andrea

I have news from my Zencart store . Have send en email and changed the FROM area to admin@african...

and I got a message that it send the mail :-) ,however he was not received in my real email account

Was it received via MercuryS? What did the mercuryS log show?

Did Mercury core process the message?  What did the system log show?

Was it received in a Mercury/32 account?  

Was it processed by MercuryE?  What did the log show?  What did the session log show?