headers
Kristof Pelckmans | 2 Nov 2003 09:12
Picon
Favicon

Re: Procmail Additionnal values


> This really is something that should never be allowed to be altered by a
> user.  If a user has a need for this advanced functionality, they probably
> shouldn't be using ingo.  Only an administrator should have to add variable
> information to a procmail script.  As such, it works better in the
> configuration files rather than a preference.  See the commit I just made.

I do not completely agree. First of all, modifying the procmailrc means having
an access other than webmail to the machine. I want to avoid this.

Then, we are not only talking about environment variables here : I use the
following procmailrc :

#rewrite and deliver if coming from aaa
:0
* ^From:.*kristof\.pelckmans@...\.be
{
        #fhw : this pipe is a filter on the header that your should wait for
        :0 fhw
        | $FORMAIL +1 -ds | sed -e s/DCS0[0-9].aaa/aaa.be/ -e
s/DCS0[0-9].aaa.be/aaa.be/

        :0:
        .inbox.aaa/
}
DEFAULT=$MAILDIR
#horde filter rules
INCLUDERC=$HOME/.procmailrc.horde

On could develop a web interface that permits entering a rule as mentioned
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johan FISCHER | 2 Nov 2003 14:25

Request functionnality


Hi,

I was just thinking about a button in the script display page to unactivate the
script. Because if you want to remove all the filter to test something, you
have to click manually on all the rules activation switch (which could be long
I think).

So a simple button on the script page would be great.

Cheers.
Attachment: application/pgp-keys, 1018 bytes
Permalink | Reply | 0 comments |
headers
Chuck Hagenbuch | 2 Nov 2003 16:23
Favicon
Gravatar

Re: Procmail Additionnal values

Quoting Kristof Pelckmans <kristof.pelckmans@...>:

> I do not completely agree. First of all, modifying the procmailrc means
> having an access other than webmail to the machine. I want to avoid this.

> On could develop a web interface that permits entering a rule as mentioned
> above, but it will never capture all procmail commands.

FWIW, I agree with this; it's one of the reasobs that we have the functionality
to lock preferences.

-chuck

--
Charles Hagenbuch, <chuck@...>
Born right the first time.
Permalink | Reply | 0 comments |
headers
Ben Chavet | 4 Nov 2003 17:37

Re: Request functionnality

Here is a quick patch to do this.

Files:
ingo/script.php
ingo/lib/Ingo.php
ingo/templates/script/activate.inc

--Ben

Quoting Johan FISCHER <linux@...>:

>
>
> Hi,
>
> I was just thinking about a button in the script display page to unactivate
> the
> script. Because if you want to remove all the filter to test something, you
> have to click manually on all the rules activation switch (which could be
> long
> I think).
>
> So a simple button on the script page would be great.
>
> Cheers.
>
Attachment (Ingo.php.diff): text/diff, 1502 bytes
Attachment (activate.inc.diff): text/diff, 1520 bytes
Attachment (script.php.diff): text/diff, 831 bytes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johan FISCHER | 5 Nov 2003 13:58

Re: Request functionnality


Quoting Ben Chavet <ben@...>:

> Here is a quick patch to do this.
>
> Files:
> ingo/script.php
> ingo/lib/Ingo.php
> ingo/templates/script/activate.inc
>

Thx, this helps a lot !!

Johan.
Attachment: application/pgp-keys, 1018 bytes
Permalink | Reply | 0 comments |
headers
Ronny Adsetts | 9 Nov 2003 14:55
Favicon

Trivial patch to allow spaces in folder names with procmail backend

Here we go:

Index: lib/Script/procmail.php
===================================================================
RCS file: /repository/ingo/lib/Script/procmail.php,v
retrieving revision 1.37
diff -u -r1.37 procmail.php
--- lib/Script/procmail.php     31 Oct 2003 22:08:44 -0000      1.37
+++ lib/Script/procmail.php     9 Nov 2003 13:44:13 -0000
 <at>  <at>  -547,7 +547,7  <at>  <at> 
              if (substr($folder, 0, 6) == 'INBOX.') {
                  $folder = substr($folder, 6);
              }
-            return '$DEFAULT/.' . $folder . '/';
+            return '"$DEFAULT/.' . $folder . '/"';
          } else {
              if (empty($folder) || ($folder == 'INBOX')) {
                  return '$DEFAULT';

--

-- 
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com
Permalink | Reply | 0 comments |
headers
Wolfgang Rosenauer | 10 Nov 2003 12:37
Picon

Re: Ingo and Sieve IMAP flag Extension

Hi,

Daniel Eckl wrote:

> Well, I commented out the php script lines which are adding the "removeflag"
> action and since then it works like a charm.
> 
> This flag seems to work like specified in the RFC's and not "mode like".
> 
> Greets
> Daniel
>>
>>On Wed, 2003-09-24 at 18:33, Jan Schneider wrote:
>>
>>>The reason is that these flags are not single message flags but rather
>>>"modes". That means that each message that is filed after "addflag"
>>>will get this flag, not only the message handled in the if block.
>>>
>>>Jan.

after a long time, I want to track this down again ;-)
Any news from you guys about that?

As I understand the RFC the addflag option add this flag for all 
messages which will pass the addflag code.
Now if a message should be handled in two different cases and should get 
different flags this will be a problem. But I use "stop" immediately 
after "fileinto" so this message will only be handled once. Perhaps this 
is what cyrus-imapd doesn't like?
I wouldn't say mode-like to this behaviour. It's just that an addflag
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Eckl | 10 Nov 2003 12:55
Picon
Picon

Re: Ingo and Sieve IMAP flag Extension

Hi Wolfgang !

Your explanation sounds logically correct. But I'm afraid I have no time anymore
to test this in deep. Could you take this testing part and tell us? Perhaps Jan
then can confirm or negate more easily.

Thanks,
Daniel

Zitat von Wolfgang Rosenauer <wolfgang.rosenauer@...>:

> Hi,
>
> Daniel Eckl wrote:
>
> > Well, I commented out the php script lines which are adding the
> "removeflag"
> > action and since then it works like a charm.
> >
> > This flag seems to work like specified in the RFC's and not "mode like".
> >
> > Greets
> > Daniel
> >>
> >>On Wed, 2003-09-24 at 18:33, Jan Schneider wrote:
> >>
> >>>The reason is that these flags are not single message flags but rather
> >>>"modes". That means that each message that is filed after "addflag"
> >>>will get this flag, not only the message handled in the if block.
> >>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Rosenauer | 10 Nov 2003 13:44
Picon

Re: Ingo and Sieve IMAP flag Extension

Hi,

Daniel Eckl wrote:

> Your explanation sounds logically correct. But I'm afraid I have no time anymore
> to test this in deep. Could you take this testing part and tell us? Perhaps Jan
> then can confirm or negate more easily.
> 
> Zitat von Wolfgang Rosenauer <wolfgang.rosenauer@...>:
> 
>>Have anybody tested what happens if the same message will processed in a
>>later condition and should get other flags?
>>As I understand the RFC you need the removeflag then after fileinto or
>>keep. But maybe this works with cyrus?

OK, I did some testing now.
But the summary is not nice. The removeflag does always crash lmtpd with 
"virtual memory exhausted". And if the removeflag is missing the message 
still carry the flag in following conditions.
I still can't say for sure what's the problem. A bug in cyrus-imapd or 
wrong flag-handling in ingo-scripts.

CU,
  Wolfgang
Permalink | Reply | 0 comments |
headers
Ronny Adsetts | 10 Nov 2003 20:41
Favicon

Patch to schema for ingo and LDAP prefs backend

Hi,

Obviously I don't have the privileges to assign OID's, but the schema 
needs a patch when using cvs HEAD with Ingo and procmail with LDAP 
backend otherwise rules and prefs are lost between sessions... but I'm 
not bitter :-)

Attached patch against current cvs HEAD horde module.

Regards,
Ronny
--

-- 
Technical Director
Amazing Internet Ltd, London
t: +44 20 8607 9535
f: +44 20 8607 9536
w: www.amazinginternet.com
Permalink | Reply | 0 comments |

Gmane