On Wed, 2001-11-07 at 22:22, Lawrence Greenfield wrote:
> The other thing to consider is how to keep the Cyrus black-box
> approach. Non-administrators should be able to modify these Sieve
> scripts and name them appropriately.
>
I'm not sure I understand what you mean. By "non-administrators"
> On Wed, 7 Nov 2001 17:22:08 -0500,
> Lawrence Greenfield <[EMAIL PROTECTED]> (lg) writes:
lg> The other thing to consider is how to keep the Cyrus black-box
lg> approach. Non-administrators should be able to modify these Sieve
lg> scripts and name them appropriately.
lg> Magic directo
The other thing to consider is how to keep the Cyrus black-box
approach. Non-administrators should be able to modify these Sieve
scripts and name them appropriately.
Magic directories just don't cut it.
Larry
--On Wednesday, November 07, 2001 04:36:59 PM -0500 Lawrence Greenfield
<[EMAIL PROTECTED]> wrote:
>[...]
>That fixed the DIGEST-MD5 problem; but it seems to have broken PLAIN.
>Now DIGEST-MD5, CRAM-MD5, and LOGIN all work; but PLAIN returns:
>
> S: A01 NO bad protocol / ca
> On Wed, 7 Nov 2001 21:12:48 -,
> Ian Castle <[EMAIL PROTECTED]> (ic) writes:
ic> Oh dear. I can see a whole new imap function coming on - ". SIEVE folder
ic> script"...
Actually, in one of my more perverse moments I actually wondered
about storing the sieve scripts in the same dire
> So maybe for a post to "[EMAIL PROTECTED]",
> the script would be in /var/lib/sieve/system/public/interestingmessages/ ?
> Or would this be tooo bizarre?
>
> I'd love to have the ability of running Sieve for some of our shared
> folders, but must admit to being a tad concerned about running *al
Introduction
The following is an implementation of the facility to allow mail
delivered directly to a shared/public folder to be filtered with sieve.
For example, you might have a shared folder "public.interestingmessages"
and deliver mail to it using an address of
"[EMAIL PROTECTED]
"Justin R. Miller" wrote:
>
> [ sorry, resending w/o that In-Reply-To: header ]
>
> Before I dig into the source code (since I'm no C programmer), is anyone
> aware of any limits on the maximum number of awaiting lmtpd processes?
> I have the prefork set to five, but currently the system seems
Hi,
Bingo! Just found the error...
Just to keep a documentation on the mailing list:
cyradm fails when trying to open "/dev/tty" (my
/dev/tty had permission 622). Changing it to 666
solves the problem. The code that fails is below:
if (!defined($opts{-password})) {
my $tty =