[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
 

Only through filtering and you can only put these in the new mail folder of the other account.  You would filter on the From: field of the sender to trigger a forward to the other account.

If MercuryE is working, I suspect the ASSP logs will show the outgoing mail is bypassing ASSP.  That's not necessarily a big problem.

Your logs showed ASSP was on the same machine as Mercury - that's a setup I'm familiar with, and MercuryE will only forward through ASSP is you force all mta DNS queries to localhost and use another relay beyond ASSP.

The best place to understand more about ASSP is on its mailing list or via the wiki/forum at  .  There is a diagram if you follow the link to 'configuration'.

[quote user="kjell"]

Hi,

I just started with Mercury and installed the version 4.52 provided with win-xampp. I then added some local users and started working local. (MTA and MUA on the same machine) Everything worked fine, but I realized that the E-Mails are note deleted after poping.
 
I checked the POP-Server configuration, I included local settings:

Mark read : Y
Show read : Y
Show status : Y
No delete : N
Delete is final : Y

Everything the same. I took a look into the logs:

18:41:17.296: >> DELE 1<cr><lf>
18:41:17.296: << +OK Message deleted.<cr><lf>

But the Message still exists. The only help is to delete the .cnm-file in the user folder.

I didn't find a hint searching this forum and the internet. Has anyone an idea about my mistake?

[/quote]

This indicates that the message is marked for deletion and will be deleted if the POP3 session ends without error.  If there is an error, all these deletes will be removed ands the mailbox restored to it's original state.  Make sure that the POP3 session ends normally. 

I understand! Thanks Peter.

Graham
 

In addition, I should try to increase the NTFS journal size with the chkdsk /L:kbytes option.  You may simply be blocking too early on writes - Mercury doesn't give up a good fight easily, but a bit more breathing room for delayed transactions would surely be welcome in your situation.  (Use the /L option to find the current size.  You'll have to reboot for the change to take effect.  Try double, and watch your free disk space which you really want to provide more of if at all possible.)

Cheers,

Sabahattin

[quote user="gandalf458"]..but then I got: 553 We do not relay non-local mail, sorry.[/quote]

Check the 'Connection control; section of the MercuryS configuration.  You need to have the first two 'Relaying control' boxes checked and your internal IP addresses you want to relay from as Allow entries in 'Connection control'.  If you have php running on the same machine as Mercury you may need localhost (127.0.0.1) in there.

As Thomas says you need to upgrade you version of Mercury.  Either install the latest version in the same location (it will keep all your settings), or patch your version to 4.01c level.

Well I was unable to make it crash after that.  I tried moving emails between local and remote, (and in doing so I stumbled across the Outlook Express duplicate message issue, badly), I tried sending and receiving and moving files on the same account at the same time, hitting it with multiple users on a shared account, and everything else I could think of.

So far, I am becoming to believe it is one of two things;

a) Some kind of unexpected response from the ISP's SSL-enabled server that gums it up (because it crashes fairly consistently when it fails to deliver as described above), or

b) There is a user-detector that only makes it crash when a user is using it, which turns off when they go home and I slave away at night to try to figure out what the deal is.

Next step: 

I made arrangements with another company to let me relay mail through their SMTP servers, no SSL and no restrictions.  And I will grab the mail off the encrypted POP3 accounts with a regular client for the time being.  Thus, no SSL.  And I will see if the program is stable that way.

 I'll let you know how it turns out.  Thanks for your help.

--97T-- 

P.S.  I've given up on running a mailing list using someone else's smtp and pop servers, so I'll start a more appropriately named thread for the crashing issue.

 
P.P.S> -- For those who find themselve chasing bugs, this might be a nice diversion: 

The MX record was wrong and is now fixed. My e-mail server is working, I can send and receive, even using a DHCP address. Thanks to you guys that responded. The help was greatly appreciated!

 Cruise
 

No sorry, I haven't used Netware for many moons, but this would be my first step to rule out this as a co-incidence or pinpoint the problem.

Just to let you know, Updating the software to the latest version seem to have sorted the problem. Once again thanks for your replies  [Y]