Re: [milter-greylist] Little issue with conf parser
2004-06-15 by Cyril Guibourg
... My understanding of dot-atom definition in RFC2882 is that # is a valid character for smtp address.
Messages
Browse messages
Page 141 of 144 · 7199 messages matched
Re: [milter-greylist] Little issue with conf parser
2004-06-15 by Matthias Scheler
... Can t you rewrite the input function to ignore anything after a # until a newline is found? Kind regards -- Matthias Scheler
Re: [milter-greylist] Configure problem on Tru64 UNIX
2004-06-15 by manu@netbsd.org
... I m not sure I ever built milter-greylist with the native compiler on Tru64. This shouldn t be a real problem anyway. Can you edit the configure script and
Configure problem on Tru64 UNIX
2004-06-15 by attila.bruncsak@itu.int
Hello Everybody, I am new on this list. Please forgive me if I repeat some issue which was already discussed. I was configuring and compiling on Tru64 UNIX
Re: [milter-greylist] Little issue with conf parser
2004-06-14 by manu@netbsd.org
... It does not sems to work as expected, or this does not fix the problem we currently have. This will still trigger an error with this patch: addr
Re: [milter-greylist] Little issue with conf parser
2004-06-14 by manu@netbsd.org
... Yes, I know your point of view. My point of view is that I m not as comfortable as you are with writing parsers, so I prefer to work with lex & yacc. --
Re: [milter-greylist] Little issue with conf parser
2004-06-14 by Matthieu Herrb
... You can eat comments to the end of line in the lexer using C code instead of using an expression. Iirc the usual idiom for that is something like: # {
Re: [milter-greylist] Little issue with conf parser
2004-06-14 by Dan Hollis
... Make a better parser and use that instead? You dont have to _remove_ the lex/yacc parser, just dont use it :-) FWIW I still think a lex/yacc parser is
Re: [milter-greylist] Little issue with conf parser
2004-06-14 by manu@netbsd.org
... Um, true. I don t see how to fix that yet, but I m sure it s possible. Anyone has a suggestion? (remove the lex/yacc parser is a bad suggestion ... --
Re: [milter-greylist] 2 patches for autowhite.c
2004-06-14 by manu@netbsd.org
... Ok, integrated that for the next release. ... Not seen here. ... Mmmm... Don t you think this patch lack some diffs on the documentation? ... I m not sure
Re: [milter-greylist] Spoke too soon
2004-06-14 by manu@netbsd.org
Graham Dunn wrote: ... I d bet on a DNS resolver problem. If you build with BIND9, slibspf_alt uses res_nquery instead of res_query, and
Little issue with conf parser
2004-06-14 by Cyril Guibourg
According to greyist.conf manpage, comments can be placed after a statement on the same line A line like: addr 213.91.0.0/17 # Teaser / Firstream is seen by
Re: [milter-greylist] Spoke too soon
2004-06-14 by Graham Dunn
... when this starts: Jun 14 11:16:19 ureshii milter-greylist: greylist: accept() returned invalid socket (Result too large), try again Jun 14 11:16:19 ureshii
2 patches for autowhite.c
2004-06-14 by Matthieu Herrb
Hi, the attached patch (relative to 1.4) fixes 2 things: - syslogging of expired autowhitelisted entries was wrong (logged the entry that triggered the
Re: [milter-greylist] peer - reply 200
2004-06-12 by manu@netbsd.org
... I m running out of idea. Could you check that it is okay to open a FILE * on the top of a socket on your version of Solaris? (a post to the appropriate
Re: [milter-greylist] peer - reply 200
2004-06-12 by hans hm04
hi Emmanuel i did insert the following at line 205 __fpurge(peer- p_stream); as fpurge did result in an Undefined symbol at compile-time. gcc -o
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by Dan Hollis
... Somehow I don t want to receive _ALL_ mails from 192.0.2.0/24. friend@example.net should only be mailing me from 192.0.2.0/24 and nobody else from
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by manu@netbsd.org
... Sure, but here you reproduce the recipient (AND condition)* feature without the nested feature. I was thinking about providing only recipient AND (true
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by Dan Hollis
... The alternative is this, which I think is ugly too: rcpt john.doe@example.net { addr 192.0.2.0/24 from friend@example.net report none } rcpt
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by manu@netbsd.org
... could? Is there something that makes you feel you have wrote something that is not ugly? ;) Seriously speaking, the nested stuff will be complicated to
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by Dan Hollis
... What about specific addr+from combinations? Eg only a specific addr block for a specific from. I guess you d need multiple rcpt {} blocks for that. Unless
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by manu@netbsd.org
... Sure, but we can try to make milter-greylist satisfying to both kind of users. -- Emmanuel Dreyfus Il y a 10 sortes de personnes dans le monde: ceux qui
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by Dan Hollis
... For an ISP with 10 s of thousands of users, it s impossible to train even a significant portion of them to read headers and make whitelisting based on IP
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by manu@netbsd.org
... Are you sure it s a good idea to promote whitelist based on the sender address? Those can be easily forged, and they are actually forged a lot nowadays.
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by Dan Hollis
... Yes, basically. Individual users can have their own whitelists independent of everyone else. -Dan
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by manu@netbsd.org
... Yes, this one is in the queue. What does it fix? Is it just to get a per-recipient whitelist? -- Emmanuel Dreyfus Il y a 10 sortes de personnes dans le
Re: [milter-greylist] milter-greylist-1.4
2004-06-12 by Dan Hollis
... My sender+recipient patch maybe? -Dan
milter-greylist-1.4
2004-06-12 by manu@netbsd.org
Hi I branched the new stable branch and released version 1.4, it s just 1.3.9 with the version number changed. Now I ll integrate various pending patches in a
Re: [milter-greylist] Spoke too soon
2004-06-11 by manu@netbsd.org
... Not really. Use info threads, switch among them, and get the bt output for each of them. -- Emmanuel Dreyfus Il y a 10 sortes de personnes dans le monde:
Re: [milter-greylist] Spoke too soon
2004-06-11 by Graham Dunn
... ureshii# gdb milter-greylist GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public
Re: [milter-greylist] version 1.3.9 is available
2004-06-10 by manu@netbsd.org
... I don t see how we could fix that. ... Well, I d really prefer a patch to configure.ac :) -- Emmanuel Dreyfus Il y a 10 sortes de personnes dans le monde:
Re: [milter-greylist] Spoke too soon
2004-06-10 by manu@netbsd.org
... Go to the build directory, do gdb ./milter-greylist then use attach to attach the running milter-greylist. then type bt What do you have? Other
Spoke too soon
2004-06-10 by Graham Dunn
Seeing: Jun 10 14:01:46 ureshii sm-mta[74920]: i5AI1kqX074920: Milter (greylist): write(O) returned -1, expected 5: Broken pipe Jun 10 14:01:46 ureshii
Re: [milter-greylist] version 1.3.9 is available
2004-06-10 by Matthieu Herrb
... Looks OK here. I built it with both Solaris Forte 6 compiler and gcc. There are 2 remaining small problems : - configure tries to use -ansi -Wall for some
test
2004-06-10 by Cyril Guibourg
pls ignore
Re: [milter-greylist] Correct libbind with libspf_alt
2004-06-09 by Graham Dunn
... Ah ok. I ve built and installed BIND9, then rebuilt libspf_alt. The only problem I m seeing now is occasional timeouts: Jun 9 16:41:02 ureshii
Re: [milter-greylist] Correct libbind with libspf_alt
2004-06-09 by Emmanuel Dreyfus
... The problem is not your named version, it s the resolver. For instance, NetBSD 1.6.2 has a BIND 8 named, but the resolver in libc is from BIND4. Should you
Correct libbind with libspf_alt
2004-06-09 by Graham Dunn
under freebsd4.8, milter-greylist 1.3.9 ureshii# named -v named 8.3.4-REL Sat Jul 12 18:55:45 EDT 2003 gdunn@ureshii.inorth.com:/usr/obj/usr/src/usr.sbin/named
Re: [milter-greylist] version 1.3.9 is available
2004-06-08 by manu@netbsd.org
... (snip) ... Yes, it s not really a bug: you killed the milter while it was being used by sendmail. -- Emmanuel Dreyfus Il y a 10 sortes de personnes dans le
Re: [milter-greylist] version 1.3.9 is available
2004-06-08 by Matthias Scheler
... The new release works fine on NetBSD 2.0_BETA with the bundled libpthread . But I got a scary message after restarting milter-greylist : Jun 8 23:32:02
version 1.3.9 is available
2004-06-08 by Emmanuel Dreyfus
Hello everybody milter-greylist 1.3.9 is available. It just fixes serious bugs, every other patches were psotponed for later. 1.3.9: Solaris rc script from
Re: [milter-greylist] Milter Greylist's use of POSIX threads is seriously broken
2004-06-07 by Matthias Scheler
... The error is one the line below: case 0: if (pthread_cond_wait(&dump_sleepflag, &mutex) != 0) syslog(LOG_ERR, pthread_cond_wait failed: %s n ,
Re: [milter-greylist] Milter Greylist's use of POSIX threads is seriously broken
2004-06-07 by manu@netbsd.org
... It looks okay: $ grep cond_wait * dump.c: if (pthread_cond_wait(&dump_sleepflag, &mutex) != 0) dump.c: syslog(LOG_ERR,
Re: [milter-greylist] Milter Greylist's use of POSIX threads is seriously broken
2004-06-07 by Matthias Scheler
... Bad result checking? And there more error in version 1.2 which I don t have at hand any more. ... No, I m still investigating. Kind regards -- Matthias
Re: [milter-greylist] Milter Greylist's use of POSIX threads is seriously broken
2004-06-07 by manu@netbsd.org
... How do you explain the errno being equal to 0? ... Um, okay, I wasn t aware it was forbidden to destroy a locked mutex. But I have a good excuse for that:
Milter Greylist's use of POSIX threads is seriously broken
2004-06-07 by Matthias Scheler
Hello, I cannot get Milter Greylist to work with NetBSD 2.0 s pthread library. It dies very quickly because of incorrect use of POSIX thread functions,
Re: [milter-greylist] peer - reply 200
2004-06-07 by manu@netbsd.org
... Um, that may be a bit less easy to find. :) ... For some reason I can t figure yet, the data sent contains some received data. Weird. In sync.c, there are
Re: [milter-greylist] peer - reply 200
2004-06-06 by hans hm04
hi Emmanuel sorry for my late answer, but i was very busy last days. due to your first reply i did see, that i didn t ask what i want. my question should be
sender + recipient exception patch 2.0
2004-06-04 by Dan Hollis
This patch allows you to define sender+recipient exception pairs in greylist.conf. The syntax is the same as existing from clause, but you can put an
Re: [milter-greylist] Re: milter-greylist 1.4
2004-06-04 by Cyril Guibourg
... Ooops, sorry list...