The calls are made directly to the dll you provide, there are no other files involved. So either there is a problem with the dll that makes the call fail altogether, or there could maybe be a second instance of Mercury running on the computer.

/Rolf 

Hi Sabahattin

Your mail came through without any problems, thanks for the check.

The postmaster problem remains though.

And, yes, it would be good to send plain text mail, but HTML is so useful and conveys meaning in a much better and intuitive style.

We are there although I still do not understand why this problem just surfaced after several years.

Mercury had the path to the Mailbox folder via a share in the form of \\ComputerName\MAILBOX\~8

 I changed this to J:\MAILBOX\~8 and all was well.

Thanks

Ken
 

Well, we probably wrote past each other.

Btw I moved your original post to the proper forum [;)]

Ok fellows, I think we finally have this all racked up in a pile. It looks like it's working now.

I can't find any info on how to restart Mercury. Is this closing the interface? I wasn't sure so I've been closing the interface and restarting Apache.

Regardless, I was restarting it somehow in there because the new setting took and I can sent myself mail. Here is the Session log: 

[quote]

13:21:42.046: Connection from 127.0.0.1, Fri Apr 25 13:21:42 2008<lf>
13:21:42.062: << 220 localhost ESMTP server ready.<cr><lf>
13:21:42.062: >> HELO Compaq1<cr><lf>
13:21:42.062: << 250 localhost Hello, Compaq1.<cr><lf>
13:21:42.062: >> MAIL FROM:<Admin@localhost><cr><lf>
13:21:42.078: << 250 Sender OK - send RCPTs.<cr><lf>
13:21:42.078: >> RCPT TO:<test@localhost><cr><lf>
13:21:42.078: << 250 Recipient OK - send RCPT or DATA.<cr><lf>
13:21:42.093: >> DATA<cr><lf>
13:21:42.093: << 354 OK, send data, end with CRLF.CRLF<cr><lf>
13:21:42.109: >> Date: Fri, 25 Apr 2008 13:21:42 -0400<cr><lf>
13:21:42.109: >> Subject: test11<cr><lf>
13:21:42.109: >> To: test@localhost<cr><lf>
13:21:42.109: >> From: test <this@that.com><cr><lf>
13:21:42.109: >> <cr><lf>
13:21:42.109: >> Message sent: 04.25.2008 at 13:21:41:<lf>
13:21:42.109: >> <lf>
13:21:42.109: >> From: test<lf>
13:21:42.109: >> Email: this@that.com<lf>
13:21:42.109: >> About: test11<lf>
13:21:42.109: >> <lf>
13:21:42.109: >> --------------------------- COMMENTS ---------------------------<lf>
13:21:42.109: >> <lf>
13:21:42.109: >> test test test11<lf>
13:21:42.109: >> <lf>
13:21:42.109: >> --------------------------------------------------------------------------<lf>
13:21:42.125: >> <lf>
13:21:42.125: >> <cr><lf>
13:21:42.125: >> .<cr><lf>
13:21:42.125: << 250 Data received OK.<cr><lf>
13:21:42.140: >> QUIT<cr><lf>
13:21:42.140: << 221 localhost Service closing channel.<cr><lf>
13:21:42.140: --- Connection closed normally at Fri Apr 25 13:21:42 2008. ---
13:21:42.140:
[/quote]

Thanks everyone - thank you thank you. dilberts_left_nut, I  but you're better than the right_nut.

I'm only able to send mail to users@localhost though. Is there some way to allow Mercury to send emails outside of localhost? For my purposes of testing php systems, such an email (lacking a .com and so on) gets caught.

Global rules does this.

General rules are connected to the users via the alias function.

thanx alot ................ using username instead of username@localhost works ...

i was stuck with this prob a while ...

thanx alot 

Sabahattin, that is a very useful post, thanks a lot.

I will setup a list using Mercury and see how it goes.

That 'Job OK' message will be in the 'Core' window.

That means that the message was successfully received and processed by the core process.

It then needs to be sent on to the destination address by an SMTP client module, either mercuryC (via an SMTP smarthost such as your ISP's) or mercuryE (direct end-to-end delivery). Which are you using?

You will need to check the log for mercC or mercE to see what is happening with your outbound message. 

That was it.  That set of rules has been in place for years

Thank you

Gus 

[quote user="pleyraki"]I am using pop client to receive the mails. Thanks.[/quote]

That is probably why you are having the problem.  When the exact same message is received MercuryD via for multiple users only the first one  one will be processed.  You need to look at the headers of these messages to see if there is a X-Envelope-To:, or similar (but not X-Delivered-To added by Mercury/32) and use that for delivery.

From the MercuryD help:

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.
 

Thank you I'll give it a try......I had configured 0.0.0.0 refused for MercuryS, but I was getting a ton of Delivery Failure bounces for one particular user and I wasn't sure if there was something I was missing.  I'll go ahead and change it to your suggestion and see what happens.  Anything else one can do for the Delivery Failure bounces?  They're not usually this much of a problem, but this time it's a real pain!

I started this thread and then the problem seemed, for the most part, to go away.  However, in the last couple of weeks, it has returned.  Not all messages have this problem.  At the moment, the most affected messages seem to be those with attachments.  To view these problem messages, I have to start the process of forwarding the message.  TB then says iit is downloading and the message shows up, ready to be forwarded.  As you have noted, Outlook Express doesn't seem to have this problem.

A couple of things I did may have improved the situation.  In TB Account Settings/Server Settings/Advanced, I set "Maximum Server Settings to Cache" to 1 (which probably isn't the deafault) and I made sure that "Server supports folders that contain sub-foders and messages" was unchecked.  As a result of your post I checked these settings and noticed that my "Maximum Server Settings to Cache" was set to 5 (I think that this is the TB default).   This didn't used to be the setting, but I recently had to delete and then re-install the TB account in question, because I was getting indexing problems that couldn't be cured by TB's re-index facility (the wrong messages were being associated with some messages in the folder list).

Whether this helps with the Opera Mail Client, I do not know.

GordonM

Thanks for getting back to me Thomas. I've turned on session logging and will report back if I can come up with anything.Comcast is the only one I've had problems with other than a full mailbox. Hope I can get it figured out.

 Cruise
 

[quote user="RTB"]  I was wondering if the higher priority MX records would 'automatically' fall over to the one remaining DNS listing, our proper one? Thanks. [/quote]

A higher MX-priority has a _lower_ mx number. If you have more than one mx pointer you really should verify that all pointed to servers do respond for your domain, and that you do get the mail to your location from these, either by direct forwarding or by fetching them with Mercury.

Hi Rolf,

Thanks for your reply. I thought as much so. But

because our VPN users are connected directly to the company LAN - that

means a local IP is assigned whilst connected - I will try to use

Pegasus Mail also for them installing the pmgate.sys. Then this should

maybe work.

 
regards

Thanks Thomas.

Because our users occassionally 'fiddle' with their settings, the former suggestion would not guarantee each mail would be saved. I'll give the latter a go and see how it works.

Cheers!

[quote user="pleyraki"]I am sorry, it soesn't seem to be there.

You mean in Configuration>mercury imap4 folder don't you?

My mercury is ver. 3.32 (2002) sorry...
[/quote]

Upgrade immediately, there is a major flaw in MercuryS that can allow hackers to take over the system.  Mercury/32 v4.52 corrects this.  The upgrade will only take a couple of minutes depending on how long it takes to download. 

I haven't used OL2007 but the earlier versions insisted on storing 'Sent' mail locally, so yes I think lookOut is your problem [:)]

Problem solved!

 
Many thanks for the quick and correct reply.  I changed the Netware client cache settings (File Caching=Off, File Commit=On) on the XP host running Mercury32 and the problem cleared up immediately and has not reappeared in any of our traffic today.  It's peculiar that the error was most pronounced among our MSN correspondents, perhaps there's something special about the timing in the conversation with their servers.

 Your help with this is greatly appreciated.
 

David Morriss