On Thu, 9 May 2002, Marc G. Fournier wrote:
> So, unless I'm overlooking something, is there some way of injecting 'per
> user' options at the lmtp (and beyond) level?
Sieve scripting allows such flexability:
Want to disable the filter?
Don't filter on the header that SA injects.
Want to whit
On Thu, 9 May 2002, Rob Siemborski wrote:
> On Thu, 9 May 2002, Marc G. Fournier wrote:
>
> > So, unless I'm overlooking something, is there some way of injecting 'per
> > user' options at the lmtp (and beyond) level?
>
> Sieve scripting allows such flexability:
>
> Want to disable the filter?
>
On Thu, 9 May 2002, Rob Siemborski wrote:
> On Thu, 9 May 2002, Marc G. Fournier wrote:
>
> > Of course, I could do this using the .spamassassin/userprefs configuration
> > file, but this won't work since there is no way for postfix to
> > differentiate users :(
>
> I'll grant you that the extrem
On Thu, 9 May 2002, Marc G. Fournier wrote:
> Of course, I could do this using the .spamassassin/userprefs configuration
> file, but this won't work since there is no way for postfix to
> differentiate users :(
I'll grant you that the extreme level of flexability you discuss
(modifying scores of
Date: Thu, 9 May 2002 15:15:22 -0300 (ADT)
From: "Marc G. Fournier" <[EMAIL PROTECTED]>
[...]
One of the things that I *really* like about SASL is the fact that I can
add/remove features just by deleting the various auth libraries ... too
bad there couldn't be some sort of 'programm
Date: Thu, 9 May 2002 15:50:50 -0300 (ADT)
From: "Marc G. Fournier" <[EMAIL PROTECTED]>
Cc: Rob Siemborski <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Having an idea of how hard such is to do, and how long it could take, is
there any way we can get the spam extension added as an #ifde
Having an idea of how hard such is to do, and how long it could take, is
there any way we can get the spam extension added as an #ifdef'd/configure
option so that it doesn't get lost? There are more and more sites moving
to Cyrus, due to its black box aspect, and, except in very simplistic
cases
syslog:
May 9 20:48:45 yxa imapd[7371]: open: user jas opened INBOX.msec
May 9 20:48:45 yxa master[13500]: process 7371 exited, signaled to death by 11
imap protocol dump:
1209 SELECT "INBOX.msec"
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Dra
On Thu, 9 May 2002, Lawrence Greenfield wrote:
>Date: Thu, 9 May 2002 15:50:50 -0300 (ADT)
>From: "Marc G. Fournier" <[EMAIL PROTECTED]>
>Cc: Rob Siemborski <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
>
>Having an idea of how hard such is to do, and how long it could take, is
>th
On Thu, 09 May 2002, Marc G. Fournier wrote:
> On Thu, 9 May 2002, Rob Siemborski wrote:
> > On Thu, 9 May 2002, Marc G. Fournier wrote:
> > > So, unless I'm overlooking something, is there some way of injecting 'per
> > > user' options at the lmtp (and beyond) level?
Looks like a job for a lmtp
--On Thursday, May 09, 2002 4:29 PM -0300 Henrique de Moraes Holschuh
<[EMAIL PROTECTED]> wrote:
> On Thu, 09 May 2002, Marc G. Fournier wrote:
>> On Thu, 9 May 2002, Rob Siemborski wrote:
>> > On Thu, 9 May 2002, Marc G. Fournier wrote:
>> > > So, unless I'm overlooking something, is there some
Hello,
I was wondering, what entries are needed for /etc/hosts.allow. Haven't
found anything in the manpages. I tried "master and "imapd", still no
connection was allowed (with ALL: ALL in hosts.deny). After all I was
actually quite surprised than cyrus uses those at all.
Running 2.0.16 on a s
ede,
for our service names, we use imap and imaps. like so:
imap: foo.bar.com
imaps: ALL
that's for standard imap (143/tcp) and ssl-wrapped imap (993/tcp).
cyrus doesn't follow the convention of using the program name... w/ its
current design for running ssl-wrapped imap it can't, seeing as i
On Thu, 9 May 2002, Ede Wolf wrote:
> Hello,
>
> I was wondering, what entries are needed for /etc/hosts.allow. Haven't
> found anything in the manpages. I tried "master and "imapd", still no
> connection was allowed (with ALL: ALL in hosts.deny). After all I was
> actually quite surprised than c
Alright, I'm breaking down and turning to you guys for help. I know, it's
not even about the latest cutting edge development branch but rather a
2.0.16 problem. My descendents will be cursed for generations to come
because of this, yet I have no one else to turn to. Please, loan me your
pity an
In order to use hosts.allow you must enable TCP wrappers on Cyrus
Have you done this?
--On Thursday, May 09, 2002 10:46 PM +0200 Ede Wolf
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> I was wondering, what entries are needed for /etc/hosts.allow. Haven't
> found anything in the manpages. I tried "ma
On Thu, 9 May 2002, Thaddeus Parkinson wrote:
> Things that catch my eye are the lines complaining about no CA data, and
> then, obviously, the SSL3 alert write:fatal:unknown. I don't think
> they're inter-related, since a self-signed cert should be sufficient
> for testing. Is it possible tha
On Thu, 9 May 2002, Scott M Likens wrote:
> --On Thursday, May 09, 2002 4:29 PM -0300 Henrique de Moraes Holschuh
> <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 09 May 2002, Marc G. Fournier wrote:
> >> On Thu, 9 May 2002, Rob Siemborski wrote:
> >> > On Thu, 9 May 2002, Marc G. Fournier wrote:
> >>
Marc G. Fournier wrote:
>Then again, someone mentioned in the other thread about having the perl
>check to see if a user wants the filter to do the checks or not ... but,
>in the content_filter itself, there is no concept *of* a user, so how
>would you do such a check?
>
>
In our content_filter
On Fri, 10 May 2002, Jeremy Howard wrote:
> Marc G. Fournier wrote:
>
> >Then again, someone mentioned in the other thread about having the perl
> >check to see if a user wants the filter to do the checks or not ... but,
> >in the content_filter itself, there is no concept *of* a user, so how
> >
In the last set of patches we sent to the list, we included a patch to
master.c to avoid losing track of child processes after a segfault. This
patch has a race condition that we saw triggered under high load, where
a child can be reaped before master has processed an
MASTER_SERVICE_UNAVAILABL
Marc G. Fournier wrote:
>Ya, saw someone's thought about that ... that would definitely work
>instead of the spam extensions, but I don't believe the lmtp proxy
>supports that yet, does it?
>
>
Correct. A general LMTP proxy framework doesn't exist yet. It would only
be a few hours work to take
In replying to my own message, I found the solution in the archive below...
http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrus&search
term=procmail&msg=7973
Ronnie
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 09, 2002 6:02
23 matches
Mail list logo
