Topic: Ingo filters not working after upgrade from 7.0 to 7.1

[harshl]

I have recently upgraded from 7.0 prod to 7.1 and now when people log into the webmail interface their filters are not working.
My personal filter options are set to apply filter options when INBOX is displayed, and to allow filters on any mailbox.
I have one rule that seems to work and the rest do not, I have tried modifying the rules to do exact matches, partial matches, etc. Nothing seems to help.
I just tried deleting one of the rules completely and recreated it, I am now waiting on email to come in to see if the new rule works or not.
Anyone else had a similar experience before I report it as a bug?

Thanks,
-Landon

[mrjhb3]

I have recently upgraded from 7.0 prod to 7.1 and now when people log into the webmail interface their filters are not working.
My personal filter options are set to apply filter options when INBOX is displayed, and to allow filters on any mailbox.
I have one rule that seems to work and the rest do not, I have tried modifying the rules to do exact matches, partial matches, etc. Nothing seems to help.
I just tried deleting one of the rules completely and recreated it, I am now waiting on email to come in to see if the new rule works or not.
Anyone else had a similar experience before I report it as a bug?

Thanks,
-Landon

I can't duplicate this.  I have tested this on my test server and the rules work fine for me.  You do know that ingo rules are client side rules?  Yes, from your post, it looks like you do?

Is this a fresh install, or upgrade from 6.x to 7, then to 7.1?  If upgrade, then there is a php script you have to run to migrate your 1.x filters to 2.x.

John

JB

[harshl]

I appreciate the reply.
It is a clean install of 7.0 upgraded to 7.1. Thank you for testing it for me. I should know by tonight if the one I deleted and recreated is working or not.

Thank you,
-Landon

[harshl]

I am not sure what is going on here, but ever since I upgraded to 7.1 my Ingo webmail filters have been horribly unreliable.
Some messages get filtered others don't. If I delete one of the match string from a rule and add it back in, it will work for a while and then stop again.

Anyone else having similar behavior?

My rules are matching as follows:

Rule Name: SMEEmails
For an incoming message that matches: Any of the following
From   Contains   anonymous@domain.com
or From   Contains   sme7admin-daemon@domain.com
or From   Contains   root@domain.com
Do this: Deliver to folder   ServerStats
Mark message as: none checked
Stop checking if this rule matches: not checked

This rule worked yesterday when I deleted and recreated each of the "from contains" line items. However this morning when I logged in, some rules processed and this one (and several others) did not. None of the rules are checked to stop checking when matched, so that is not stopping it.

I have a total of 10 filters, plus the white and blacklists, the order is such that they are not affecting each other. Of the 10 filters each contains a minimum of 2 address types to match.

Anyone have any ideas?

Thanks,
-Landon

[CharlieBrady]

I am not sure what is going on here, but ever since I upgraded to 7.1 my Ingo webmail filters have been horribly unreliable.

Please report upgrade problems via the Bug Tracker, and only via the Bug Tracker. Thanks.

[harshl]

Is it a bug? That is what I am trying to verify from other users. Does the bug tracker serve the same purpose? I have never used it.

[mrjhb3]

Is it a bug? That is what I am trying to verify from other users. Does the bug tracker serve the same purpose? I have never used it.

If you are not getting the results you expect, then you should file a bug.  You will get more response there than here.   Just becuase I said I couldn't duplicate it, doesn't mean there isn't a bug.  Maybe I didn't do the exact things you did.  When you file the bug, explain exactly what you did and is much detail.

John

[harshl]

Will do, thanks!

[mrjhb3]

Landon,

You still having this issue?  I may now be running into it as well.  What I am seeing is that if I create an or rule, then the rule is only honoring the last item.  

i.e. I have a rule setup for my boys that says if from doesn't contain domaina.com or from doesn't contain domainb.com or from doesn't contain domainc.com then delete message completely.  If I send a message from domaina and domainb, then message get deleted.  If I send a message from domainc, then only is the mail is delivered.  

This is not how it worked with horde 3.0x.  I have had this rule in place for well over a year on all of my boys' accounts.  I am setting back up a test 6.5 server with the horde 3.0x components to further verify before I start asking on the ingo list.

John Bennett

[harshl]

John,

Sorry to hear you are having the same trouble. I have gone into the database, and it appears that the rules are being stored properly in the database, or at least the phrases I have told it to match are present. I have verified on my system as well that it is indeed only processing the last part of any one rule.

Let me know if you get anywhere on the Ingo mailing list. Also, if I can help in any way, if I can provide anything that would help figure out what is going on let me know.

Thanks,
-Landon

[CharlieBrady]

You still having this issue?

If anyone is, the Bug Tracker is the tool to use to track the issue. Thanks.

[mrjhb3]

You still having this issue?

If anyone is, the Bug Tracker is the tool to use to track the issue. Thanks.

The horde list is where I will start first, then move to our bug tracker if anything is confirmed.  I don't want to be trying to track this in two different places if this turns out to be user error and not product related.

[harshl]

Agreed.

[mrjhb3]

I have opened this bug on bugs.horde.org, http://bugs.horde.org/ticket/?id=5014.  When I get an answer from it, I'll take the appropriate actions for SME.

John

[mrjhb3]

The fix is here - http://bugs.horde.org/ticket/?id=4618.  This should show up in the next version of ingo.  I have tested it and now my filters are working as I expect.

John

[harshl]

That's great thank you very much for doing the research on this!

[markseymour]

Posted: Wed Mar 14, 2007 10:06 pm

The fix is here - http://bugs.horde.org/ticket/?id=4618.  This should show up in the next version of ingo.  I have tested it and now my filters are working as I expect.

John

A few questions from a Linux and SME newbie (me):

1)  Do I assume correctly from the date that the above quote was posted that this fix did not make it into SME Server 7.1 Update 3?

2) I've read that Ingo supports server-side rule creation (Sieve, procmail). In the default installation of Horde on SME I don't see a mechanism to allow Ingo filtering rules to become Procmail rules. How can I make this happen?

3) Please direct me to a more appropriate place to ask the following, as this probably is not the best.

My desired order of filtering/virus/spam checking would be thus:

Code: [Select]

a) site-wide blacklist -> drop/delete
b) user blacklist -> drop/delete
c) virus check
d) user whitelist -> deliver
e) spamassassin
then delivery to user junkmail, or main inbox/subfolder.
Is this something that can be accomplished within the current structure of SME/qmail/qpsmtpd/spamassassin/procmail ?

Thanks,

Mark

[mrjhb3]

The updated package is in the smetest repo and will be included in sme 7.2.

Procmail isn't part of SME, so I haven't ever looked at this.  You would need to modify ingo/config/backends.php and add the procmail backend, then see how you make it work.

Number 3 is tough.  Darrel May have an alpha contrib that allows you to define white/black list though server-manager, you can also use DB commands for this.  The syntax escapes me, but if you search, you should find it.  Hopefully I get this correct.  Mail comes in, any WBL lists will be honored, checked for virus, then delivered to user.  If the mail is not on the WBL, it's scanned for spam, then virus, if mail gets tagged by spam, it's moved to the junkmail folder.  This is done before horde does anything.  Ingo filters are client side not server side.  If user is using horde, when they login to horde, their WBL will be honored, then any other filter rules will be executed.

John

[markseymour]

John,

Thanks for your reply.

Procmail isn't part of SME, ....

Ok, however, Stephen Noble's smeserver-mailsorting contrib enables Procmail (or Maildrop) and makes good use of it for user-chosen
sorting rules.  So it seems it would be readily available should a developer see value in pursuing what I'm looking for.

Here is a quote from Stephen in the bug tracker #2781

the ingo filters work,
would be nice if they could create maildrop/procmail rules
or the explaination how to do so was clearer

so, it looks like he would like to see ingo create server-side rules as well.

Number 3 is tough.  Darrel May have an alpha contrib that allows you to define white/black list though
server-manager,

I use Darrell's wbl contrib, and it works nicely on a *sitewide* basis.  I would like to add user-chosen server-side
whitelists and blacklists.  Often, one person's spam is another's ham.  I would like for users to be able to whitelist
senders and thereby avoid having subject lines modified with the ***SPAM*** tag in mail that they want to receive.
Other users could blacklist a sender for their own accounts when the same sender is whitelisted for a different user.  I
especially like the ease of addition to wbl's in Horde, and this is a key reason for wanting Ingo filtering rules to
become server-side rules.

As an intermediate step, perhaps I can interest Stephen in adding per-user w/b lists to his  mailsorting contrib.

you can also use DB commands for this.  The syntax escapes me, but if you search, you should find it.

I'll look into whether doing this per-user is within my capabilities.

Hopefully I get this correct.  Mail comes in, any WBL lists will be honored, checked for virus, then delivered to
user.  If the mail is not on the WBL, it's scanned for spam, then virus, if mail gets tagged by spam, it's moved to the
junkmail folder.  This is done before horde does anything.

I want to be certain that even mail from whitelisted senders is virus-checked.

Ingo filters are client side not server side.

But  it certainly appears from  a quick look through Ingo documentation that it is intended to be able to generate server-side rules.

We have both mentioned contributed packages as potential solutions, and perhaps I should therefore take this up in a
contribs forum. At this point I don't think I have my wishlist well enough defined and pared-down to make it a general
SME feature request.

Mark