RE:  TRANSFLT,MER:  No transaction filtering.  I checked the file with a text editor confirming that all lines are commented out.

I originally installed Mercury with the sole purpose of running it with POPFile to keep the crap out of the users mailboxes.  I created a large number of global filters to auto-delete known unwanted messages (vulgar terms, male enhancement, viagra,...) as well as rules that manipulated messages (copied, forwarded, deleted attachments, added text fragments).  The second instance was the result of me never being able to exclude outgoing messages from global rule filtering.  It worked well so I never revisited the issue.

The occasional outgoing messages that are being copied to the postmaster mailbox appear to be just flukes.  I searched 6 months worth of logs and only find the two messages that prompted this post, and they occurred months apart.  Whatever is causing it appears harmless and is so rare that it is not worth any more effort.

Thanks for your thoughts.

I have delivery failure notifications being placed in a "Mercury" user mailbox which I routinely open to filter them out of the NMF.  Occasionally I see what appear to be unsent messages in this NMF that originated from a local user.  Please provide any thoughts that could help me figure out what is happening that results in these messages ending up in this mailbox.  The headers of one of these messages are below.

Received: from spooler by dec-clt.com (Mercury/32 v4.74); 19 May 2015 12:53:49 -0400
X-Envelope-To:
From: "local_user" <local_user@our_domain.com>
To: Recipient <recipient@icloud.com>
Date: Tue, 19 May 2015 12:53:01 -0400
MIME-Version: 1.0
Subject: Re: Colors trinity
Reply-to: local_user@our_domain.com
CC:
Message-ID: <555B6A6D.25161.1053509@local_user@our_domain.com>
Priority: normal
In-reply-to: <25CB8C7F-C63D-8FA1-2769-CDC557F58F98@icloud.com>
References: <MACtv3QwrEAXjeS=7iDjvsiY2R5wXiwPmHdNugacU4KLRPX2rVB@mail.gmail.com>, <25CB8C7F-C63D-8FA1-2769-CDC557F58F98@icloud.com>
X-mailer: Pegasus Mail for Windows (4.63)
Content-type: Multipart/Related; boundary="Message-Boundary-17601"
X-PMFLAGS: 570949760 0 1 YZKMF946.CNM                      

--Message-Boundary-17601
Content-type: Multipart/Alternative; boundary="Alt-Boundary-2958.17118473"

--Alt-Boundary-2958.17118473
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Content-description: Mail message body
 

Were the messages actually sent? Also, is the X-Envelope-To: field really blank? Have you checked to make sure that the mail failure template is OK under Mercury Core Module?

It's very strange!

The X-Envelope field really is blank.

I checked the Core logs for two of these messages and found entries where they were delivered to recipients as expected but also to local user Mercury.  There is nothing in common between these two messages that I see and I do not find any filters that copy messages to Mercury.  I now know how it is happening but I don't have a clue why it is happening.

How do you tell Mercury to deliver Delivery Status Notification messages to the Mercury account?

AFAIK it has handled by the enabled option to send all errors to the postmaster.  The username of postmaster is "Mercury".

Same here. Do you have any filtering rules that pass messages to the Mercury account? If so, I wonder if one of those may need refining.

The rules was the first thing I looked at.  There are no rules in the outgoing or global sets that copy or move messages to Mercury.

I run two instances (one handles incoming, the other outgoing) and filtering is very rudimentary in the outgoing instance consisting of a rule that stops processing on messages resent from our local domain some rules that delete 550 Delivery failure messages to stop any autoforwards by a FORWARD file.

Is there anything in the Sending server's TRANSFLT.MER rules within the SMTP module that may be responsible. Is something being triggered from that? Also, you mention that you have two instances running, which instance does the Mercury (postmaster) account belong to? I expect you have a good reason to separate the sending/receiving - is it due to volume?