[ingo] Filters are not applied

Jan Schneider jan at horde.org
Mon Sep 2 19:06:08 UTC 2013


Zitat von cjdl01 <cjdl01 at brokensolstice.com>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von cjdl01 <cjdl01 at brokensolstice.com>:
>>
>>> Hello,
>>>
>>> I'm using horde on debian Squeeze.  I have everything up to date  
>>> on the debain host, and I have everything up to date with pear  
>>> (and all horde components) as of yesterday. I am using sendmail  
>>> with procmail, and using maildir format for messages.
>>>
>>> Everything was working great, but then we noticed that new filter  
>>> rules were not getting applied.  They seemed to be added without  
>>> complaint, but when I look t the corresponding .procmailrc, the  
>>> rule was never entered (or removed, if that was the case).   
>>> Looking at the date stamps, I can see this problem has existed for  
>>> several months, but since the interface wasn't complaining, users  
>>> just assumed it was something they did.
>>>
>>> I have been fiddling with our backends.local.php for many hours  
>>> now, and nothing I try seems to make a difference.
>>>
>>> If I make a new rule, it will show up in the ingo interface, and I  
>>> get two green pop-ups indicating that the rule was made.  But,  
>>> again, it never shows up in the .procmailrc.
>>>
>>> I cannot find any errors in the horde log (and I have it set to  
>>> debug). I have tried wiping all filters and starting from scratch,  
>>> but it doesn't help.  I have checked the ingo_rules table, and I  
>>> see the rules are present there.  I check my ftp logs, and it  
>>> looks like the file transfer is occurring as it should:
>>>
>>> Sat Aug 31 11:52:29 2013 [pid 3] [george] OK UPLOAD: Client  
>>> "10.x.x.x", "/home/george/.procmailrc", 8134 bytes, 9183.07Kbyte/sec
>>> Sat Aug 31 11:53:33 2013 [pid 2] CONNECT: Client "10.x.x.x"
>>> Sat Aug 31 11:53:33 2013 [pid 1] [george] OK LOGIN: Client "10.x.x.x"
>>> Sat Aug 31 11:53:33 2013 [pid 3] [george] OK UPLOAD: Client  
>>> "10.x.x.x", "/home/george/.procmailrc", 8191 bytes,  
>>> 11956.69Kbyte/sec
>>> Sat Aug 31 11:53:41 2013 [pid 2] CONNECT: Client "127.0.0.1"
>>
>> Rather seems to be a problem with your FTP server and/or file  
>> system if uploading succeeds. The different file sizes indicate  
>> that Ingo is indeed sending different script versions. If the  
>> scripts don't change anyway, this doesn't have anything to do with  
>> Ingo.
>
> But the ftp system works perfectly fine when invoked from the  
> command line.  It is only through horde/ingo that it is having  
> problems.  The different file sizes were because they were two  
> different attempts with two different actions: one to remove a  
> filter, the other to add.  If I switch to ssh, Ingo still does not  
> work... and, prior to April this year, it was working fine.   
> Something must have changed in Ingo somewhere along the line.
>
>
>
>
>>> 10.x.x.x here is the address of the horde box.  FTP is restricted  
>>> to the local machine only.
>>>
>>> I have checked the perms on .procmailrc for the given user.  They  
>>> are appropriate.  But I noticed that if I delete .procmailrc, a  
>>> new one is never generated by ingo.  If I touch a new one (as that  
>>> user of course), the file remains empty, even when ingo states the  
>>> rule was created successfully.
>>>
>>>
>>> The only oddity I see in the logs is this occasional entry:
>>>
>>> Sat Aug 31 11:50:03 2013 [pid 1] [Administrator] FAIL LOGIN:  
>>> Client "127.0.0.1"
>>
>> The only place where this user should ever appear is when setting  
>> up Horde for the first time and using automatic login.
>>
>>> I have no idea where that is coming from... must be some component  
>>> of horde (because that is all this box is used for), but I don't  
>>> have a clue...
>>>
>>> I find this entry in the DB after creating a rule called "xxx rule":
>>>
>>> ingo_rules
>>> |     181 | george          | xxx rule    |           2 |  
>>> INBOX.Promotions |          0 |  
>>> a:1:{i:0;a:4:{s:5:"field";s:7:"Subject";s:4:"type";i:1;s:5:"match";s:8:"contains";s:5:"value";s:3:"xxx";}}
>>>
>>> Finally, here is the procmail portion of my backends.local.php:
>>>
>>> $backends['procmail'] = array(
>>>   'disabled' => false,
>>>   'transport' => array(
>>>       Ingo::RULE_ALL => array(
>>>           'driver' => 'vfs',
>>>           'params' => array(
>>>               'hostspec' => 'localhost',
>>>               'filename' => '.procmailrc',
>>>               'vfs_path' => '/home/%u',
>>>           )
>>>       ),
>>>   ),
>>>   'script' => array(
>>>       Ingo::RULE_ALL => array(
>>>           'driver' => 'procmail',
>>>           'params' => array(
>>>               'path_style' => 'maildir',
>>>               'variables' => array(
>>>               ),
>>>               'forward_string' => '"|/usr/bin/procmail"',
>>>           ),
>>>       ),
>>>   ),
>>>   'shares' => false
>>> );
>>
>> You should *NOT* copy complete examples to backends.local.php,  
>> though that's probably nothing to do with your issue.
>
> I see, I think I'm getting this now... though I still have much to  
> learn here... I changed my backends.local.php to:
>
>
> $backends['imap']['disabled'] = true;
> $backends['sieve']['disabled'] = true;
> $backends['procmail']['disabled'= false;
>
> Is that correct?

Yes, though 'sieve' is disabled by default, so you can leave it out.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/



More information about the ingo mailing list