On Friday 28 May 2004 11:59 am, Liron Newman wrote:
> [EMAIL PROTECTED] wrote:
> >Is anyone else interested it this scheme? Am I just being one of
> >Davide's PITA people? Davide? Supporters? Detractors? Please let me know.
> >
> >I promise if I get voted down, I'll shut-up about it (I can hear Dav
[EMAIL PROTECTED] wrote:
>Is anyone else interested it this scheme? Am I just being one of
>Davide's PITA people? Davide? Supporters? Detractors? Please let me know.
>
>I promise if I get voted down, I'll shut-up about it (I can hear Davide
>thinking: '...voted? Who said anything about xmail being
On Friday 28 May 2004 11:30 am, Tracy wrote:
> At 17:15 5/28/2004, you wrote:
> >I think it would be neat to allow replacement anywhere in an argment,
> >so you could write something like:
> >
> >"/some/path/myfilter.pl" "rcpt=@@RCPT&msg=@@FILE&from=@@FROM"
> >
> >and have the replacements done. Th
At 17:15 5/28/2004, you wrote:
>I think it would be neat to allow replacement anywhere in an argment,
>so you could write something like:
>
>"/some/path/myfilter.pl" "rcpt=@@RCPT&msg=@@FILE&from=@@FROM"
>
>and have the replacements done. Then, in this example, you could parse
>a single argument lik
Hi -
I was wondering if there is any support in the xmail community
for the following:
I would like the way '@@macro' filter/auth/etc. arguments are parsed
by xmail to be enhanced. Currently, for example, you may pass '@@macros'
to filters as arguments by setting up the filter's .tab like:
"/som
On Friday 28 May 2004 09:58 am, Davide Libenzi wrote:
> On Fri, 28 May 2004, Beau E. Cox wrote:
> > On Friday 28 May 2004 08:57 am, Davide Libenzi wrote:
> > > 1.19-pre07 adds the requested feature of showing the real rcpts in the
> > > file supplied to filters. The RCPT lines will have the format:
At 16:04 5/28/2004, you wrote:
> > It was posted here, about where in the code the real recipients were being
> > determined and where they were stored...
> >
> > In other words, I was going to locally modify pre06 to do what you
> modified
> > pre07 to do...:)
>
>/me think. Didn't I have already
On Fri, 28 May 2004, Tracy wrote:
> At 15:59 5/28/2004, you wrote:
> > > >1.19-pre07 adds the requested feature of showing the real rcpts in the
> > > >file supplied to filters. The RCPT lines will have the format:
> > > >
> > > >RCPT TO: {REAL-ADDRESS1}
> > > >RCPT TO: {REAL-ADDRESS2}
> > > >
At 15:59 5/28/2004, you wrote:
> > >1.19-pre07 adds the requested feature of showing the real rcpts in the
> > >file supplied to filters. The RCPT lines will have the format:
> > >
> > >RCPT TO: {REAL-ADDRESS1}
> > >RCPT TO: {REAL-ADDRESS2}
> > >
> > >
> > >The REAL-ADDRESS is the equivalent of
On Fri, 28 May 2004, Tracy wrote:
> At 14:57 5/28/2004, you wrote:
>
>
> >1.19-pre07 adds the requested feature of showing the real rcpts in the
> >file supplied to filters. The RCPT lines will have the format:
> >
> >RCPT TO: {REAL-ADDRESS1}
> >RCPT TO: {REAL-ADDRESS2}
> >
> >
> >The REAL-A
On Fri, 28 May 2004, Beau E. Cox wrote:
> On Friday 28 May 2004 08:57 am, Davide Libenzi wrote:
> > 1.19-pre07 adds the requested feature of showing the real rcpts in the
> > file supplied to filters. The RCPT lines will have the format:
> >
> > RCPT TO: {REAL-ADDRESS1}
> > RCPT TO: {REAL-ADDRESS2
On Friday 28 May 2004 08:57 am, Davide Libenzi wrote:
> 1.19-pre07 adds the requested feature of showing the real rcpts in the
> file supplied to filters. The RCPT lines will have the format:
>
> RCPT TO: {REAL-ADDRESS1}
> RCPT TO: {REAL-ADDRESS2}
>
>
> The REAL-ADDRESS is the equivalent of @@
At 14:57 5/28/2004, you wrote:
>1.19-pre07 adds the requested feature of showing the real rcpts in the
>file supplied to filters. The RCPT lines will have the format:
>
>RCPT TO: {REAL-ADDRESS1}
>RCPT TO: {REAL-ADDRESS2}
>
>
>The REAL-ADDRESS is the equivalent of @@RRCPT in macro substitution
On Friday 28 May 2004 09:02 am, Davide Libenzi wrote:
> On Fri, 28 May 2004, Beau E. Cox wrote:
> >
> > A little OT FYI:
> >
> > Having grown up on the east coast of the USA, I, like most 'mainland'
> > North Americans, did not consider the pressed/processed meat produc
On Fri, 28 May 2004, Beau E. Cox wrote:
>
> A little OT FYI:
>
> Having grown up on the east coast of the USA, I, like most 'mainland'
> North Americans, did not consider the pressed/processed meat product
> 'Spam' real food. I seldom ate it. Now I have been living in
Hi all -
Thanks to Harald, I fixed a minor boo-boo in bsa_filter.pl
(SpamAssassin filter). From the change log:
NAME
Change Log - Change Log for bsa_filter.pl
CHANGES
28 May 2004 - 0.3-beta
Reformat 'HAM' as well as 'SPAM' after spam check
Make the new lines RFC compatible (\r\
1.19-pre07 adds the requested feature of showing the real rcpts in the
file supplied to filters. The RCPT lines will have the format:
RCPT TO: {REAL-ADDRESS1}
RCPT TO: {REAL-ADDRESS2}
The REAL-ADDRESS is the equivalent of @@RRCPT in macro substitution. And
no, it is not possible to implem
I'm attempting to determine where, in the XMail code, alias recipients are
resolved to real local recipients. I noticed that this appears to happen in
SMTPCheckForwardPath, but I can't see anything there that is storing the
resolved recipient - it's being used to check if the mailbox is full, a
Yes, in general.
Just to adapt some to win/32
Thank you
Edinilson
-
ATINET-Professional Web Hosting
Tel Voz: (0xx11) 4412-0876
http://www.atinet.com.br
- Original Message -
From: "Tracy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
> Ok, so leaks that I saw are likely related to a kill. Hardly=20
> gethostbyname() and select() can leak. Oke doke though, leave it
> running=20 for a while.
Ok, thx, i'll let it run the whole weekend :-)
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a messag
On Fri, 28 May 2004, [iso-8859-1] S=F6nke Ruempler wrote:
> > I mean, the log is constatly updated. Does valgrind dumps it
> > continuosly=3D20 or you need to stop it to let it dump?
>=20
> i do
>=20
> valgrind options path-to-xmail xmail-options 2>/logfile &
Ok, so leaks that I saw are likely re
> I mean, the log is constatly updated. Does valgrind dumps it
> continuosly=20 or you need to stop it to let it dump?
i do
valgrind options path-to-xmail xmail-options 2>/logfile &
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
On Fri, 28 May 2004, [iso-8859-1] S=F6nke Ruempler wrote:
> > Are you killing the server to get dumps, or it just dumps by itslef?
>=20
> clean shutdown -> change valgrind opts -> start again is my procedure.
I mean, the log is constatly updated. Does valgrind dumps it continuosly=20
or you need
> Are you killing the server to get dumps, or it just dumps by itslef?
clean shutdown -> change valgrind opts -> start again is my procedure.
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in t
On Fri, 28 May 2004, [iso-8859-1] S=F6nke Ruempler wrote:
> > Sonke, can you set --num-callers=3D3D8 and redo?
>=20
> of course :-) done.
Are you killing the server to get dumps, or it just dumps by itslef?
- Davide
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the b
> Sonke, can you set --num-callers=3D8 and redo?
of course :-) done.
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
On Fri, 28 May 2004, Davide Libenzi wrote:
> On Fri, 28 May 2004, [iso-8859-1] S=F6nke Ruempler wrote:
>=20
> > > Getting closer. Now remove the "strip" lines from Makefile.lnx and
> > > rebuild=3D =3D20
> > > it (and replace the binary).
> >=20
> > Ok done.
>=20
> Good, let it run. Valgrind repla
On Fri, 28 May 2004, [iso-8859-1] S=F6nke Ruempler wrote:
> > Getting closer. Now remove the "strip" lines from Makefile.lnx and
> > rebuild=3D =3D20
> > it (and replace the binary).
>=20
> Ok done.
Good, let it run. Valgrind replaces the pthread library with his own, and=
=20
I supect that we wo
> Getting closer. Now remove the "strip" lines from Makefile.lnx and
> rebuild= =20
> it (and replace the binary).
Ok done.
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a messa
On Fri, 28 May 2004, [iso-8859-1] S=F6nke Ruempler wrote:
> > Can you add --leak-check=3D3Dyes
>=20
> done. Log is at the known location.
>=20
> I updated to pre06, too.
Getting closer. Now remove the "strip" lines from Makefile.lnx and rebuild=
=20
it (and replace the binary).
- Davide
-
To
> Better sure it to be clean. You absolutely can't run two XMail's on
> the=20 same mail root.
Maybe you could add some check in 2.0 ? ;-)
> Can you add --leak-check=3Dyes
done. Log is at the known location.
I updated to pre06, too.
-
To unsubscribe from this list: send the line "unsubscribe x
On Fri, 28 May 2004, Aseem Dayal wrote:
> Hi - I have configured my local domain accounts to be
> synched with my external domain accounts. During
> synchronization the mail is downloaded to the local
> server & deleted from the external server. How can I
> configure PSYNC to leave a copy of the m
On Fri, 28 May 2004, [iso-8859-1] S=F6nke Ruempler wrote:
> > I hope you're not saying you're running multiple copies of XMail on
> > the=3D20 same $MAIL_ROOT, do you?
>=20
> Maybe if a restart was unclean?!
Better sure it to be clean. You absolutely can't run two XMail's on the=20
same mail root
> I hope you're not saying you're running multiple copies of XMail on
> the=20 same $MAIL_ROOT, do you?
Maybe if a restart was unclean?!
> Hmm, it's confusing since it dumps all exiting processes. Can you add
> a=20 -v --num-callers=3D6 to the command line and stop it after
> 10-25 minutes= =20
On Fri, 28 May 2004, [iso-8859-1] S=F6nke Ruempler wrote:
> Hi Davide,
>=20
> > File names inside the spool/local directory are hashed and the value
> > is=3D20 "moduled" to the number of LMAIL threads. Each LMAIL thread has
> > a unique=3D20 ID (0, ..., N) and it touches only file names whole
> >
Hi - I have configured my local domain accounts to be
synched with my external domain accounts. During
synchronization the mail is downloaded to the local
server & deleted from the external server. How can I
configure PSYNC to leave a copy of the mails behind on
the external server & not delete the
Hi Davide,
> File names inside the spool/local directory are hashed and the value
> is=20 "moduled" to the number of LMAIL threads. Each LMAIL thread has
> a unique=20 ID (0, ..., N) and it touches only file names whole
> modules hash is equal= =20
> to its thread ID.
What about more instances of
37 matches
Mail list logo
