Pegasus Mail & Mercury

Welcome to the Community for Pegasus Mail and
The Mercury Mail Transport System, the Internet's longest-serving PC e-mail system!
Welcome to Pegasus Mail & Mercury Sign in | Join | Help
in
Home Blogs Forums Downloads Pegasus Mail Overview Mercury Overview Wiki

Why '*Job killed by filtering rule'

Last post 07-04-2018, 17:41 by Invictus. 6 replies.
Sort Posts: Previous Next
  •  06-27-2018, 12:11

    • Invictus is not online. Last active: 07-11-2018, 9:58 Invictus
    • Top 500 Contributor
    • Joined on 09-18-2009
    • Member
    • Points 320

    Why '*Job killed by filtering rule'

    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

  •  06-27-2018, 12:24

    • Greenman is not online. Last active: 13 Jul 2018, 16:42 Greenman
    • Top 10 Contributor
    • Joined on 07-19-2007
    • UK
    • SuperStar
    • Points 13,145

    Re: Why '*Job killed by filtering rule'

    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.

  •  06-27-2018, 12:48

    • Invictus is not online. Last active: 07-11-2018, 9:58 Invictus
    • Top 500 Contributor
    • Joined on 09-18-2009
    • Member
    • Points 320

    Re: Why '*Job killed by filtering rule'

    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

  •  06-27-2018, 13:29

    • Greenman is not online. Last active: 13 Jul 2018, 16:42 Greenman
    • Top 10 Contributor
    • Joined on 07-19-2007
    • UK
    • SuperStar
    • Points 13,145

    Re: Why '*Job killed by filtering rule'

    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).
  •  06-27-2018, 13:43

    • Invictus is not online. Last active: 07-11-2018, 9:58 Invictus
    • Top 500 Contributor
    • Joined on 09-18-2009
    • Member
    • Points 320

    Re: Why '*Job killed by filtering rule'

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

    Thanks for your help - appreciated!

    G

  •  07-01-2018, 12:07

    Re: Why '*Job killed by filtering rule'

    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."

     

  •  07-04-2018, 17:41

    • Invictus is not online. Last active: 07-11-2018, 9:58 Invictus
    • Top 500 Contributor
    • Joined on 09-18-2009
    • Member
    • Points 320

    Re: Why '*Job killed by filtering rule'

    I wonder if we could tweak it to be a little more verbose......killed my global move filter rule..or somesuch
View as RSS news feed in XML

Contact | Advertise | Host provider: PraktIT | Terms of Use | Privacy Statement
Copyright © 2007-2011 David Harris / Peter Strömblad. | Pegasus Mail Home Page