Last post in this thread.

Today I sent a message to 7 local addresses. I added the addresses to the Cc field via an address book which lists all local accounts. Two accounts did not receive them. Mercury had 'killed' them.

I chose 'resend this message' and sent it to them individually and they received the messages.

Neither of these accounts are subject to mail filtering at all.

This is a PITA, but I can't see any way around it.

I've not upgraded to 4.8 yet as I have a ton of other things to do. Hopefully, that will sort this weird issue out.

No need to respond.

Hi

I've seen this yet again and again I have no idea why a message is being 'killed'.

The most recent example was our Finance Dept., sending internal messages via a distribution list to staff concerning company pension info.

We don't use SpamHalter. Configuration > Filtering Rules forwards and moves messages, deletes messages over 25MB. *.@Localdomains are excluded from transaction processing rules.

Where should I look to find out why a message is being killed, please?

Thanks

[quote user="Greenman"]

Hi

I've seen this yet again and again I have no idea why a message is being 'killed'.

The most recent example was our Finance Dept., sending internal messages via a distribution list to staff concerning company pension info.

We don't use SpamHalter. Configuration > Filtering Rules forwards and moves messages, deletes messages over 25MB. *.@Localdomains are excluded from transaction processing rules.

Where should I look to find out why a message is being killed, please?

Thanks

[/quote]

"Job killed by filtering rule" in the Core Process window just means that a standard filter has either deleted or moved the message.  Transaction filtering in MercuryS is irrelevant once the message has got to the Core Process.

Outgoing messages get filtered by global rules. 

I have said this before but I will say it again.  I run two instances of Mercury because of the fact that I was never able to exclude outgoing messages from global rule processing.  I tried numerous different rules to try to exit rule processing on all messages originating locally but was never successful.  Handling outgoing mail with a second instance was my solution.  I would certainly benefit from getting this figured out so I could do away with the second instance.

Greeman, can you find the rule that the message triggered?  I don't know of an easy way to do this other than manually reviewing every rule trying to make a connection to the message.

[quote user="Greenman"]

The most recent example was our Finance Dept., sending internal messages via a distribution list to staff concerning company pension info.

[/quote]

Do you mean a Pegasus "distribution list" or a Mercury mailing list?  If the former then there's one message for each recipient and you need to double-check the particular list being used.

Hi

The message was originally sent out via a Pegasus Mail distribution list. When this failed the sender tried sending them out individually to each address but they were 'killed' by Mercury.

The message comprised:

Dear All

You will have recently received some correspondence from Standard Life regarding
auto-enrolement.

The new pension scheme is required as the previous pension scheme did not fulfil all the
criteria for auto enrolement.

The amount paid to the new scheme will be in the same proportion as paid to the old scheme
ie 4% by yourself and 5% by the company. Some of you pay an additional voluntary
contribution and this will continue.

The letter does state that your contribution is 0%, the reason for this is that your contribution
is deducted from your gross pay before tax and national insurance which is classed as salary
sacrifice and in this case the pension company class the contribution as being paid by the
company in total.

In summary there will be no change to the contributions made and the only change is the
contribution is paid to the new scheme.

If you are still unsure please come and see me to discuss the changes.

Kind Regards

I have since discovered that one person in the distribution list received the message while no one else did and none of the individually addressed messages were delivered.

Anyone know what has triggered a rule? There are no attachments, and no rules are triggered that I can see.

Our global filtering rules do the following:
Forward messages from @olddomain-name to @newdomain-name
Messages addressed to info@ are forwarded to a different address
Forward or move messages addressed to oldaddress@ to newaddress@

There is a size limit rule for outgoing messages. We don't use 'general' rule sets (*.RUL)

None of the rules filter messages according to body content. Most the addresses used are not affected by any of the move or forward rules (and those that are the message is delivered to the original recipient then forwarded to a GMail address), and the message comprised just the text you see so it would not have triggered an outgoing rule message which filters messages based on size (message not sent if over 25MB, sender notified, copy sent to postmaster, then message deleted). Also, all the addresses, while addressed as firstname.lastname@domain, are local.

To rule out the global rules I would temporarily disable them then send a couple of the messages.  I would add to the top of the rule list an "always exit" rule followed by an always copy to me rule (solely as a backup to identify failure of the always exit rule).

Hi, Brian

I can't disable the rules because certain people rely on messages being forwarded to their company GMail app account. If I place an 'always exit' rule at the top won't it do the same thing? I've never had to set up complex rule sets - labels is as complicated as it has got in the past (but no longer). I have never used an exit rule.

I guess I am lucky in that I can test after hours by pausing MercD, disabling the rules, testing, then re-enabling everything.

FWIW, you should have a bunch of labels and always exit rules because message continue to get processed through the rule list in all cases but moves and deletes.  For some rules that is ok but for many you want the processing to end when the criteria is met.  See below.  Note the Always Exit rules before the labels and at the end of each label.  This prevents processing from falling through.  This method also provides the capability to check for an additional criteria and act accordingly as per Label3.

If Criteria1 goto Label1
If Criteria2 goto Label2
If Criteria3 goto Label3
.
.
.
Always Exit
Comment:  Begin Labels
:Label1
Always Action1
Always Exit
:Label2
Always Action2
Always Exit
:Label3
Always Action3 (can not be a move or delete if you want Criteria4 checked)
If Critera4 > Action4
Always Exit

One thing I don't know about dlists is whether every message gets acted on if just one of the recipient addresses contained within triggers a rule.  My suspicion is that they are so excluding outgoing messages from global rule processing is important.  I think it imperative for you to make that determination.

Thanks. I've got no idea what is going on here. This is one of the few things that baffles me about Mercury - if there was a traceable log that described why a message was being 'killed' and which detailed a rule number or something similar it would save a lot of time wasted trying to track this down.

[quote user="Greenman"]I have since discovered that one person in the distribution list received the message while no one else did and none of the individually addressed messages were delivered.[/quote]

That may be significant. What is different about this person's entry in the list?  Can you trace that delivery through Mercury in your logs?

Does everyone have trouble sending to a distribution list or just the Finance Dept?

[quote]Anyone know what has triggered a rule? There are no attachments, and no rules are triggered that I can see.[/quote]

As Brian has suggested - when the server is quieter you need a temporary change to your filters to log the passage of a message through the filters.  Use the action "log a console message" to see the progression through the filter.

Thanks, Paul

I did not know about that option - I will ask the original sender to resend the mail to the list and use it to record what happens. I searched for the option in the Mercury documentation but could not find anything describing this. Do you know how I will be able to identify the log file e.g. extension and the default directory the file will be saved to?

I can't really turn off the filtering rules because you can bet your boots that a message the CEO needs will be received and not forwarded to their Google apps GMail account. We also changed one of our domain names last April and rules are in place to forward mail from the old domain name to the new one so that affects most of our staff.

For what it is worth every single active filtering rule works on email addresses (mostly CT and a couple of F's), and not content or other attributes.

[Edit]

Regarding tracing the original - when I have done this in the past I've not been able to see any meaningful info. However, I now save full session logs at debugging info for all transactions (and yes, there are 1000's of log files). So, when the guy is back at work on Monday I will set up a rule at the top of the list to log the console messages and trace his message.

I know it is some time later, but did you get anywhere with this?

Hi, Paul

No, I am still stumped, and have seen this happen with another distribution list. The global rules comprise 31 'Forward Message', 6 'Copy Message' and 4 'Move Message' rules.

The forwarding forwards messages addressed to user@old-domain-name to user@new-domain-name
One of the copy rules is used to copy all messages to a catchall account. The other copy rules affect (external) sender addresses and 2 'local' addresses. The move rules affect external or non-existent addresses (which would not, therefore, be used in an internal distribution list).

I have not had the time to look further into this. I am hoping to dedicate more time to this in January.

AFAIK, moves and deletes are the only two actions that generate the "killed by filtering rule" response so that should narrow it down significantly.

Since you are copying all messages to a catchall account I assume all outgoing messages are being copied as well so perhaps an analysis of those can identify which address from the dlist is being filtered?  On second thought, this would depend on where the copy rule is in the rule list.  It is likely to be early in the rule list so is being triggered before the rule that is killing the message so this wouldn't work but what if you duplicated the dlist and used it with a "scan list" rule as the last rule and made the action one that would allow you to compare the dlist recipients with the actual messages processed at the end of the rule list.  This might be impractical if the dlist it long. 

Just grasping at straws.