[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