CAPA is optional.
MikaL
On Mon, 2003-01-20 at 02:11, Jeffrey Stedfast wrote:
If that's the case, then your POP server is busted. You should complain
to Sphera Technologies about the problem.
Jeff
On Sat, 2003-01-18 at 20:03, Stephen H Carbin wrote:
At 07:48 PM 1/18/2003, you
Hmm, right. Should've checked the original message.
MikaL
On Mon, 2003-01-20 at 19:44, Jeffrey Stedfast wrote:
Never said it wasn't. The bug in his server is that it gets into a
broken state after the CAPA and will not let the client log in.
Jeff
On Mon, 2003-01-20 at 12:23, Mika
On Fri, 2003-01-17 at 13:07, Ian Watkinson wrote:
- mail checked with spamassassin (spamc)
This is through fetchmail? or piping to spamc in the filter?
The latter.
If so, care to elaborate for a newbie on exactly how this is done.
Install spammc
Configure.
I'm running debian, so the
On Thu, 2003-01-16 at 19:22, Adrian 'Dagurashibanipal' von Bidder wrote:
My setup:
- mail comes in
- mail goes through bogofilter
- mail goes through spamassassin
a spamassassin rule gives a score if bogofilter said it's spam.
- mail goes through bogofilter in learning mode
On Fri, 2003-01-17 at 02:13, Andrew Cowie wrote:
I tried quite hard to make something along these lines work, but kept
getting tripped up.
Some questions for you Mika:
1.
I must be missing something really fundamental, but how does one make
filters run WHEN MESSAGES ARRIVE?
You need to
On Tue, 2003-01-07 at 11:57, Chris Toshok wrote:
Attached is a program that runs fine on both freebsd 5.0 rc2 and linux
2.4.18-3, and gives the same output. When run like so:
$ sun_test 2 sun_test 1
you'll see:
sock2's peer = '/tmp/sock1'
sock1's peer = '/tmp/sock2'
Well, I get
On Mon, 2003-01-06 at 02:23, Not Zed wrote:
Memory bugs are sometimes hard to find ... :-/
e_thread_destroy doesn't need to lock because if anything still has a
handle to the ethread at the time it is destroyed, its already a bug.
I figured as much, but the thread lock *is* acquired right
On Sun, 2003-01-05 at 21:43, Ronald Kuetemeier wrote:
On Sun, Jan 05, 2003 at 10:41:43PM +0200, Mika Liljeberg wrote:
By the way, your patch is included in Debian unstable
[liborbit0-0.5.17-5]:
--- orbit-0.5.17.orig/src/IIOP/connection.c
+++ orbit-0.5.17/src/IIOP
Hi,
I have further information on the following bug:
http://bugzilla.ximian.com/show_bug.cgi?id=34164
Observed on Evo 1.2.0. I got this by selecting all messages in a vfolder
and trying to set a label on them.
I managed to trap this in gdb. If I read the code right, it looks like
there is a
Hi Jeff,
You'll note that EMsgPort has its own .lock member, which is acquired by
e_msgport_put(), e_msgport_get(), e_msgport_wait() and all other
routines before accessing or modifying the message port data. To me this
a pretty strong indication that this is a mailbox that is accessed by
On Sun, 2003-01-05 at 20:30, Jeffrey Stedfast wrote:
What I'm saying is that EThread.server_port's queue is not modified
outside of a EThread.mutex and so it is all safe. If that wasn't the
case, I would agree with you - then there would be a poblem, but as far
as I can tell, EThread.mutex is
Hi,
I have further information on the following bug:
http://bugzilla.ximian.com/show_bug.cgi?id=34164
Observed on Evo 1.2.0. I got this by selecting all messages in a vfolder
and trying to set a label on them.
I managed to trap this in gdb. If I read the code right, it looks like
there is a
Hi Jeff,
You'll note that EMsgPort has its own .lock member, which is acquired by
e_msgport_put(), e_msgport_get(), e_msgport_wait() and all other
routines before accessing or modifying the message port data. To me this
a pretty strong indication that this is a mailbox that is accessed by
On Sun, 2003-01-05 at 20:30, Jeffrey Stedfast wrote:
What I'm saying is that EThread.server_port's queue is not modified
outside of a EThread.mutex and so it is all safe. If that wasn't the
case, I would agree with you - then there would be a poblem, but as far
as I can tell, EThread.mutex is
By the way, your patch is included in Debian unstable
[liborbit0-0.5.17-5]:
--- orbit-0.5.17.orig/src/IIOP/connection.c
+++ orbit-0.5.17/src/IIOP/connection.c
@@ -459,6 +459,7 @@
fd_cnx-u.usock.sun_family = AF_UNIX;
getpeername(GIOP_CONNECTION_GET_FD(fd_cnx),
(struct sockaddr
On Sat, 2002-12-14 at 18:23, Mark Nelson wrote:
I've reciently added a second pop account to my evolution configuration,
I've configured the first account (account_a) to download straight into
my inbox and the second account (account_b) to download to a second
folder via the filter mechanism.
On Mon, 2002-12-16 at 02:16, Not Zed wrote:
I have similar problems with my filters [Evo1.2.0 on Debian/Sid]. For
some reason, the filters are not run automatically on my secondary mail
account, a local /var/spool/mail mbox. (Yes, the right checkbox is
ticked in mailbox settings). If I
17 matches
Mail list logo
