> So, you do agree this is not something that should be happening, right?
No, I figure you should not log the connections you're sending to
spamd. But we can figure some way to make this a bit clearer.
On 2013-W10-4 19:20 -0700, Bob Beck wrote:
> I think this should not only be addressed in the documentation (for
> pcap-filter, spamd -M / spamlogd, pf.conf log/rdr-to / pflogd,
> tcpdump), but in the actual spamlogd code changes, too -- it should
> be smart enough to not automatically whitelis
> I think this should not only be addressed in the documentation (for
> pcap-filter, spamd -M / spamlogd, pf.conf log/rdr-to / pflogd,
> tcpdump), but in the actual spamlogd code changes, too -- it should
> be smart enough to not automatically whitelist the connections that
> are rewritten to the
On 2013-W10-4 15:08 -0700, Bob Beck wrote:
Show me your pf.conf please - I'd like to address your problem
in the documentation or another way.. I don't like a knob like
this.
According to pf.conf(5), you can only log to one pflog(4) interface
at a time, so, it's not exactly trivial to modify
Show me your pf.conf please - I'd like to address your problem
in the documentation or another way.. I don't like a knob like
this.
On Thu, Mar 07, 2013 at 12:04:22PM -0800, Constantine A. Murenin wrote:
> On 2013-W10-3 15:46 -0700, Bob Beck wrote:
> > > Yes, one could log stuff into different
On Thu, Mar 07, 2013 at 04:23:34PM -0500, Ted Unangst wrote:
> Maybe I'm just easily confused, but when I see LIST_END() I tend to
> think it's going to be the last element in the list. I think NULL is
> clearer. As per the man page, "The SLIST_END(), LIST_END(),
> SIMPLEQ_END() and TAILQ_END() ma
Maybe I'm just easily confused, but when I see LIST_END() I tend to
think it's going to be the last element in the list. I think NULL is
clearer. As per the man page, "The SLIST_END(), LIST_END(),
SIMPLEQ_END() and TAILQ_END() macros are provided for symmetry
with CIRCLEQ_END(). They expand to NU
On 2013-W10-3 15:46 -0700, Bob Beck wrote:
> > Yes, one could log stuff into different pflog interfaces, but I don't
> > understand why pf.conf `pass in ... log ... port smtp ...` is effectively
> > redefined to mean `add ` when spamlogd is running,
>
> http://www.openbsd.org/cgi-bin/man.cgi?query
On Thu, Mar 07, 2013 at 09:40:40AM -0800, Philip Guenther wrote:
> On Thu, Mar 7, 2013 at 8:36 AM, Stefan Sperling wrote:
> > On Thu, Mar 07, 2013 at 10:51:13AM -0500, Vladimir Támara Patiño wrote:
> >> Working on collations again (based on FreeBSD implementation) and
> >> reading "wcrtomb" I see
On Thu, Mar 7, 2013 at 8:36 AM, Stefan Sperling wrote:
> On Thu, Mar 07, 2013 at 10:51:13AM -0500, Vladimir Támara Patiño wrote:
>> Working on collations again (based on FreeBSD implementation) and
>> reading "wcrtomb" I see that return value of wcrtomb should be
>> either positive or (size_t)-1,
> Using puffs will induce a rewrite of all the kernel code, because the
> internals are completely different (and I think a little bit more
> complex, but this is a personal opinion...).
>
>
I might share that opinon :)
> For a libfuse support in basesystem we will need to do a librefuse
> like
On Thu, Mar 7, 2013 at 3:03 PM, Bob Beck wrote:
>
>
>
> Which is why I keep pointing people at puffs and librefuse in netbsd
>
>
Hi,
Using puffs will induce a rewrite of all the kernel code, because the
internals are completely different (and I think a little bit more
complex, but this
On Thu, Mar 07, 2013 at 10:51:13AM -0500, Vladimir Támara Patiño wrote:
> Working on collations again (based on FreeBSD implementation) and
> reading "wcrtomb" I see that return value of wcrtomb should be
> either positive or (size_t)-1, then:
>
> diff -ruN src53orig/lib/libc/citrus/citrus_none.c
Working on collations again (based on FreeBSD implementation) and reading
"wcrtomb" I see that return value of wcrtomb should be either positive or
(size_t)-1, then:
diff -ruN src53orig/lib/libc/citrus/citrus_none.c
src53coll/lib/libc/citrus/citr
us_none.c
--- src53orig/lib/libc/citrus/citrus_n
People any thought on this, whether if this is valid issue enough to
consider at all?
On Wednesday 06 March 2013 07:03 PM, sachidananda urs wrote:
Hi,
When ls -l is run on a directory which has no execute permissions, ls
fails but the return value is 0.
bash-4.2$ ls -ld /tmp/foo/
drw-r-xr-x
On Thu, Mar 7, 2013 at 6:16 AM, Gilles Chehade wrote:
> On Thu, Mar 07, 2013 at 01:10:48PM +0100, Jonathan Armani wrote:
> > On Tue, Mar 05, 2013 at 03:24:06PM +0100, Sylvestre Gallon wrote:
> >
> > > I am not quite sure but I think that only libfuse and sshfs are GPL
> > > licenced. The patches
On Thu, Mar 07, 2013 at 01:10:48PM +0100, Jonathan Armani wrote:
> On Tue, Mar 05, 2013 at 03:24:06PM +0100, Sylvestre Gallon wrote:
>
> > I am not quite sure but I think that only libfuse and sshfs are GPL
> > licenced. The patches for those two items are only present in ports.
> >
> > All the c
Am 06.03.2013 um 19:23 schrieb Stefan Sperling :
> On Wed, Mar 06, 2013 at 01:05:16PM +, Stuart Henderson wrote:
>> It's not entirely obvious that "-x509" actually means "produce a
>> csr, self-sign it (defaulting to SHA1), throw away the csr and write
>> the cert" and this had me stuck for a
On Tue, Mar 05, 2013 at 03:24:06PM +0100, Sylvestre Gallon wrote:
> I am not quite sure but I think that only libfuse and sshfs are GPL
> licenced. The patches for those two items are only present in ports.
>
> All the code present in src is ISC licenced. The kernel communicate with
> libfuse thr
19 matches
Mail list logo
