What I know from write-back caching is that it is a CPU-feature. Is there a way of turning this feature off somehow?

Hi,

a couple of times now (about 5 times, spread over a period of about 6 to 8 months) we have noticed that an e-mail was sent to someone from our mailserver containing the body (DATA) from another e-mail, also originating from or destined for us. It hasn't happened that often, but it may have serious consequences..

The only reason we came to know about this is because some people responded to the e-mails stating that they were probably not meant for them. For all I know, there may have been more incidents like this.

We are using Mercury/32 V4.62, running in standalone mode in a multi-user Windows NT/2003/XP environment, our users are using Pegasus Mail V4.41 with Simple MAPI. The Pegasus-clients drop their mails in a directory on the fileserver which is a secondary queue to Mercury. The primary queue of Mercury is on it's local drive. Mercury sends all it's mail through a smarthost (Astaro V7).

I have tried looking for errors in our logfiles, but didn't find anything out of the ordinary.

Has anyone ever noticed this behavior before or perhaps know how we can trace/fix this problem?

I have never seen this.

Do you have a copy of one (or more) of these mails?

You need to examine the headers to determine where and when the mail originated, and try to match it to your logs.

Do you have any filter rules, mailing lists or aliases that could redirect mail offsite?

The only copies I have are the replies or forwards where a customer states that the mail was probably not meant for him. The original headers were not included in that mail.

I have tried to match it to our logs, but could not find any errors or timeframes where those mails could have been merged.

We do have a few filter rules, but they only add a disclaimer to every mail or copy the occasional mail to another user (the copy only occurs with mails originating internally).

I will try to find out as much as I can from the logs of my server.

Thanks for your comment.

a couple of times now (about 5 times, spread over a period of about 6

to 8 months) we have noticed that an e-mail was sent to someone from

our mailserver containing the body (DATA) from another e-mail, also

originating from or destined for us. It hasn't happened that often, but

it may have serious consequences..

How are you receiving the mail?  MercuryS?   MercuryD?

Can you find the original mail containing the body data and follow the trail through the logs?

Can you ask the false recipient to forward it to you as an attachment so you at least get the headers as it was delivered to their system.

If it did originate from your system, the only thing I can think of is possible filename collisions with the file-based message submission process. This shouldn't happen, but the universe is a random place :)

Maybe you could you submit mail by SMTP to MercS?

@Thomas: We are receiving our mail via MercuryS.

@Dilberts_left_nut: I will try to get the original mail from the client. I was thinking the same thing regarding the filenames, since Mercury splits mails up into envelope and data files (.qdf end .qcf).

[quote user="soldaat"]@Thomas: We are receiving our mail via MercuryS.

@Dilberts_left_nut: I will try to get the original mail from the client. I was thinking the same thing regarding the filenames, since Mercury splits mails up into envelope and data files (.qdf end .qcf).

A thought.  If there is anything at all working on the drive checking files then it might be causing the problem.  Are you sure there is no anti-virus software running and competing with Mercury for the files? Even the write-back caching can be causing the problem.

[/quote]

We are not using any anti-virus scanning on the mailserver anymore since the Astaro has a dual virusscanner.

What I know from write-back caching is that it is a CPU-feature. Is there a way of turning this feature off somehow?