Hello tech@,
Spamd does not always detect when a connection is closed by a
legit (non-spoofed) RST packet (i.e.: read() does not return -1).
PF accepts the RST and clears state, but the kernel drops it and
the error condition of ECONNRESET is not set for the socket.
So... PF and the kernel hand
It looks like a few tools in base rely on two's complement integer
overflow for the hashing algorithm in readhash(). Overflow can easily be
observed using a manual check or a dynamic undefined behavior tool. This
function is also present in rcs(1) and cvs(1). Some code locations of
these overflows
> Well your idea for a "listen on local" is very valid and the way to go
> in my opinion, however the keyword "local" is inappropriate here as we
> have a very different meaning for it: a message coming from an address
> that is also the address of a listener.
>
> A network connection from 127.0.0.
On Tue, Feb 09, 2016 at 09:23:17AM -0500, Peter Bisroev wrote:
> Hi Gilles
>
Hi,
>
>
> > We have faced a similar issue with filters and my thoughts are that we need
> > a
> > listen on socket of some kind, similar to your listen on local.
> >
> > This has several benefits over "listen on loc
Hi Gilles
> We have faced a similar issue with filters and my thoughts are that we need a
> listen on socket of some kind, similar to your listen on local.
>
> This has several benefits over "listen on local", both in ambiguity and it
> new ways the ruleset can match sessions.
>
> If you're inte
On 9 February 2016 at 12:19, David Gwynne wrote:
>
>> On 9 Feb 2016, at 9:12 PM, Mike Belopuhov wrote:
>>
>> On 9 February 2016 at 11:31, David Gwynne wrote:
>>> On Mon, Feb 08, 2016 at 11:02:06PM +1000, David Gwynne wrote:
On Sat, Feb 06, 2016 at 04:43:28PM -0500, Anthony Eden wrote:
>
> On 9 Feb 2016, at 9:12 PM, Mike Belopuhov wrote:
>
> On 9 February 2016 at 11:31, David Gwynne wrote:
>> On Mon, Feb 08, 2016 at 11:02:06PM +1000, David Gwynne wrote:
>>> On Sat, Feb 06, 2016 at 04:43:28PM -0500, Anthony Eden wrote:
> Synopsis:
To me that behavior might su
On 9 February 2016 at 11:31, David Gwynne wrote:
> On Mon, Feb 08, 2016 at 11:02:06PM +1000, David Gwynne wrote:
>> On Sat, Feb 06, 2016 at 04:43:28PM -0500, Anthony Eden wrote:
>> > >Synopsis:
>> >
>> > To me that behavior might suggest the problem is deeper than a
>> > bookkeeping mist
On Mon, Feb 08, 2016 at 11:02:06PM +1000, David Gwynne wrote:
> On Sat, Feb 06, 2016 at 04:43:28PM -0500, Anthony Eden wrote:
> > >Synopsis:
> >
> > To me that behavior might suggest the problem is deeper than a
> > bookkeeping mistake of aligning memory in mbuf.
>
> nope, you were righ
