[quote user="Rolf Lindby"]

If you block all incoming messages with <> as sender you may block more than you intend to. Delivery failure messages from SMTP servers can have that as well.

/Rolf 

[/quote]

Thanx for that heads-up.
At present I am moving the messages to a black-hole mailbox that I monitor.
I'll keep an eye open for that sort of message before I institute "killfile" :)

Is there any hidden option to turn off email delivery and/or Read receipt processing ?

(Certain people have this set as a default - mostly just pointless noise back and forth)

For delivery receipts, go to: Configuration / Mercury core / Files and make sure the 'Delivery confirmation template' is blank or points to a non-existing file.

(Read confirmation is done at the client - you could try a global filter depending on how they are formatted.)

Hi there.

The messages I'm referring to are indeed ReadReceipt.
They show up in the Mercury Core Process log window as :
 hh:mm:ss Job MG0009B2: from <> (local)
   To: whoever@someplace.com (non-local) (Job MO0009B3)-OK

 I had no joy trying to catch these in the outgoing filter.
( Looking in headers where "F" (from) or "E" (sender) = "<>" (exact match)
The line in ORULES.MER  was
        If header "F" is "<>" Move "BLACKHOLE"

 
HOWEVER:  We have a winner.
    I had to resort to scanning all headers for "Return-path: <>"
    This is in global RULES.MER, not in outgoing ORULES.MER
    If expression headers matches "Return-path: <>" Move "BLACKHOLE"

I hope this post saves someone a little time.

If you block all incoming messages with <> as sender you may block more than you intend to. Delivery failure messages from SMTP servers can have that as well.

/Rolf