I wonder if we could tweak it to be a little more verbose......killed my global move filter rule..or somesuch

Hello Forum,

Within Mercury core process every now and then I can see that a

message has been killed - see below for example.

Wed 27, 11:02:27: Job MG000228: from al***ir@*****results.co.uk (non-local)
   * Job killed by filtering rule.
 

There is no filtering rules set that should result in a job being killed in either global or general .

There does not seem to be a pattern either.

Content control is disabled.

I would like to have some control over this as it looks like it's killing the occasional v important email.

ANy ideas?

G

I had the same issue several years ago and never got to the bottom of it.

Recommendations were to check all Mercury rules. I think that sometimes a move operation may result in a job killed message. All it means is that the message has literally been copied to a different account and that the original has been deleted (or something along those lines). But, my memory is hazy - this was a long time ago...

I'm not sure if SMTP transaction rule settings might result in this message being displayed - I assume they take effect before the message can be downloaded. 

If you use a catchall account (a rule that copies all sent/received mail to an account), check to see if the message exists. If it does, it was delivered.

You can also turn on logging under the Mercury Core Module Configuration dialog > Reporting and choose the option to turn on logging. You can then examine the log created for each transaction.

Thanks Greenman -

'I think that sometimes a move operation may result in a job killed message.'

This may be the culprit....

Regarding logging - I can't see that specifically under Reporting....only stats and system message reporting level [I've set to 3]...is that what you mean or am I looking in the wrong place.....

G

You're in the right place. I have the debugging level set to 5. It results in a lot of data being recorded but it gives you a blow-by-blow account of each stage of the transaction process. I set the output folder to be at the root of the drive and different from Mercury's Logs folder e.g. \Merc-Stats\ and I clear the folder out and archive these when the server is restarted (otherwise it reuses existing files which gets confusing).

have same file set setup......will up the level to 5...let's see what occurs.

Thanks for your help - appreciated!

G

A move operation triggered by a global filter (ie, in rules.mer) results in the original job being killed (because global filtering is applied before attempting delivery to a mailbox). The manual says:

" If your global filtering rules result in the message being deleted, or moved to another user, then the core module will make no further attempt to deliver the message."

 Whereas a general filter (ie, a *.rul file) is applied when delivery to the mailbox is attempted and will only kill the messsage if you don't include a 'copy' action in the rule:

"It is legitimate to bind a general rule set to an existing, valid address on your system: doing this will invoke the rule set before delivery occurs, but will suppress delivery to the address.In order to interpose a filter set and still allow mail to be delivered to the address, you must add a Copy to user rule action to the rule set, which makes an unaltered copy of the message in the user's mailbox."