On 8/28/19 9:23 AM, gil...@poolp.org wrote:
> 28 août 2019 09:04 "Martijn van Duren" a
> écrit:
>
>> Currently looking into writing an spf filter based on libopensmtpd.
>> While working through the spec I found in RFC7208 section 7.3 that:
>> The "r" macro expands to the name of the receiving
28 août 2019 09:04 "Martijn van Duren" a
écrit:
> Currently looking into writing an spf filter based on libopensmtpd.
> While working through the spec I found in RFC7208 section 7.3 that:
> The "r" macro expands to the name of the receiving MTA.
> In other words the hostname presented in the
On 8/28/19 9:23 AM, gil...@poolp.org wrote:
> 28 août 2019 09:04 "Martijn van Duren" a
> écrit:
>
>> Currently looking into writing an spf filter based on libopensmtpd.
>> While working through the spec I found in RFC7208 section 7.3 that:
>> The "r" macro expands to the name of the receiving
Currently looking into writing an spf filter based on libopensmtpd.
While working through the spec I found in RFC7208 section 7.3 that:
The "r" macro expands to the name of the receiving MTA.
In other words the hostname presented in the banner. Unfortunately we
also support the hostnames
On Wed, Aug 28, 2019 at 10:33:29AM +0200, Martijn van Duren wrote:
> On 8/28/19 9:23 AM, gil...@poolp.org wrote:
> > 28 ao??t 2019 09:04 "Martijn van Duren" a
> > ??crit:
> >
> >> Currently looking into writing an spf filter based on libopensmtpd.
> >> While working through the spec I found in
28 août 2019 14:07 "Martijn van Duren" a
écrit:
>>
>> So my understanding is that you'd like a filter to be able to use the
>> result from an SPF lookup to reject a message in your filter and have
>> the hostname that was used in the banner part of the message.
>
> Yes, because that's the only
28 août 2019 15:10 "Martijn van Duren" a
écrit:
> On 8/28/19 2:52 PM, gil...@poolp.org wrote:
>
>> Yes sorry my bad, but this still covers the textstring argument:
>>
>> We need to be able to reject at banner and this is going to be implemented
>> as a filter phase, so basically if we expect
28 août 2019 12:26 "Gilles Chehade" a écrit:
> On Wed, Aug 28, 2019 at 10:33:29AM +0200, Martijn van Duren wrote:
>
>> On 8/28/19 9:23 AM, gil...@poolp.org wrote:
>> 28 ao??t 2019 09:04 "Martijn van Duren" a
>> ??crit:
>>
>> Currently looking into writing an spf filter based on libopensmtpd.
On 8/28/19 2:52 PM, gil...@poolp.org wrote:
>
> Yes sorry my bad, but this still covers the textstring argument:
>
> We need to be able to reject at banner and this is going to be implemented
> as a filter phase, so basically if we expect people to need it for filters
> the proper place to pass
On Mon, Aug 26, 2019 at 12:04:06PM +0200, Martijn van Duren wrote:
> On 8/26/19 11:42 AM, Sebastien Marie wrote:
> > On Sun, Aug 25, 2019 at 07:01:01AM +0200, Martijn van Duren wrote:
> >> Right now all we get is "Misbehaving filter", which doesn't tell the
> >> developer a lot.
> >>
> >> Diff
I find myself regularly asking people to run 'ifconfig iwm0 debug' to
figure out reasons behind association failures from dmesg output.
I would like to make this information more accessible. Making it part
of regular ifconfig output seems like a reasonable thing to do. This
becomes possible now
On Wed, Aug 28, 2019 at 10:07:32AM +0800, Michael Mikonos wrote:
> On Sun, Aug 25, 2019 at 02:58:47PM +0200, Otto Moerbeek wrote:
> > On Sun, Aug 25, 2019 at 08:32:04PM +0800, Michael Mikonos wrote:
> >
> > > Hello,
> > >
> > > I noticed that flex is too trusting and assumes
> > > calloc/malloc
On 8/28/19 12:26 PM, Gilles Chehade wrote:
> On Wed, Aug 28, 2019 at 10:33:29AM +0200, Martijn van Duren wrote:
>> On 8/28/19 9:23 AM, gil...@poolp.org wrote:
>>> 28 ao??t 2019 09:04 "Martijn van Duren" a
>>> ??crit:
>>>
Currently looking into writing an spf filter based on libopensmtpd.
Martin Pieuchot wrote:
> Is there any value to keep the IFF_DEBUG output if ifconfig(8) already
> report the failures?
Yes. "debug" gives the play-by-play in dmesg, which is very different
from the limited information this new mechanism provides.
> I'd say go for the x* solution,
>
> -Otto
Sure. When I looked at this again there are also realloc() return
value checks missing, so I added xcalloc(), xmalloc() and xrealloc().
An old (unused) function yy_flex_xmalloc() gets removed. When building
this I checked the resulting .o files
On Wed, Aug 28, 2019 at 10:39:24AM -0300, Martin Pieuchot wrote:
> On 28/08/19(Wed) 12:54, Stefan Sperling wrote:
> > +print_assoc_failures(uint32_t assoc_fail, const char *intro, const char
> > *outro)
> > +{
> > + /* Filter out the most obvious failure cases. */
> > + assoc_fail &=
On Wed, Aug 28, 2019 at 04:18:41PM +0200, Stefan Sperling wrote:
> Updated diff below.
And this is another update which changes display of failure codes
from "!(foo.bar)" to "!foo,!bar", as suggested off-list by Theo.
This should make the output easier to parse.
diff refs/heads/master
On Wed, Aug 28, 2019 at 04:52:10PM +0200, Stefan Sperling wrote:
> On Wed, Aug 28, 2019 at 04:18:41PM +0200, Stefan Sperling wrote:
> > Updated diff below.
>
> And this is another update which changes display of failure codes
> from "!(foo.bar)" to "!foo,!bar", as suggested off-list by Theo.
>
>
On 28/08/19(Wed) 12:54, Stefan Sperling wrote:
> I find myself regularly asking people to run 'ifconfig iwm0 debug' to
> figure out reasons behind association failures from dmesg output.
>
> I would like to make this information more accessible. Making it part
> of regular ifconfig output seems
On Sat, Aug 17, 2019 at 12:13:50PM -0300, Rafael Neves wrote:
> Hi,
>
> Submitting to tech@ to broader audience.
>
> When using -P option in mfs with a directory or a block device that
> doen't exist, for example when the device roams, newfs(2) leaves
> leftovers of temporary mount points.
>
ping and traceroute are setuid programs, so increased access-reduction
features are worthwhile.
they can both lock their filesystem visibility to "readonly" very early on.
the attack model being prevented against is very obscure. it imagines a
bug in something between start-of-program and
On Wed, Aug 28, 2019 at 12:03:07PM -0600, Theo de Raadt wrote:
> ping and traceroute are setuid programs, so increased access-reduction
> features are worthwhile.
>
> they can both lock their filesystem visibility to "readonly" very early on.
>
> the attack model being prevented against is very
On Wed, Aug 28, 2019 at 05:07:34PM +0200, Stefan Sperling wrote:
> On Wed, Aug 28, 2019 at 04:52:10PM +0200, Stefan Sperling wrote:
> > On Wed, Aug 28, 2019 at 04:18:41PM +0200, Stefan Sperling wrote:
> > > Updated diff below.
> >
> > And this is another update which changes display of failure
On Wed, Aug 28, 2019 at 06:58:28PM +0200, Alexander Bluhm wrote:
> in rev 1.273 RTM_LOCK has been removed from net/rtsock.c. Since
> then the big switch in rtm_output() has RTM_CHANGE as a single case.
> It does not make sense to check rtm_type again.
OK kn
I also double checked that no
Hi,
in rev 1.273 RTM_LOCK has been removed from net/rtsock.c. Since
then the big switch in rtm_output() has RTM_CHANGE as a single case.
It does not make sense to check rtm_type again.
For easier review I provide the diff -w output. Otherwise you would
mostly see the indent change.
ok?
bluhm
> Or, you could explain this more as an attribute of the filesystem:
>
> FFS filesystems are byte-order dependent, and thus not portable to
> systems with a different endianness.
>
> (two n in endianness)
>
>
what about this text in mount_ffs(8) where it makes more sense?
Index: mount_ffs.8
While testing my assocfail diff I have found a bug. The beacon parsing
code will skip RSN information in beacons unless WPA is active in the
current configuration. The symptom of this was WPA2 APs being flagged
!wpaprotos sometimes. I've even seen scan results in debug output where
every line
Hi,
route(8) should provide the storage for struct sockaddr_dl to the
kernel when creating an IFP address. Instead it uses inet/inet6
autodetection also for the link address type.
Currently nothing bad happens as the kernel uses only the field
sdl_index which is within the size of a
Hello Mark,
below is the patch I'm using for a while now on Pinebook and A64+.
I thought, if it's good enough maybe it could be accepted to the main
tree.
I used it with device tree entries below, apm was able to set lowest
and highest clock, running stable for more than a week.
It's actually
On Wed, Aug 28, 2019 at 07:12:58PM +0200, Stefan Sperling wrote:
> Another (hopefully final) update:
Turns out the previous diffs break the ramdisk kernel build.
Fixed version:
diff refs/heads/master refs/heads/assocfail
blob - 543e09f0d6e6b4e75456a21d4218468729b61a5e
blob +
Hi,
The kernel may crash as there is not enough input validation in
routing messages.
https://syzkaller.appspot.com/bug?id=e2076a6518b49730aefe64acf0a266f8e79685a5
Here the name of a routing label is not NUL terminated, but there
are more things that can go wrong. So I added some checks for
Hi
I am experiencing packet loss and ENOBUFs, I have a program with
with two tap(4) interfaces and i am using kqueue(2) to determine
when and which tap interface to process the packet. I
email bugs@ over a month ago with no reply
https://marc.info/?l=openbsd-bugs=156229879107900=2
so i thought i
Since we don't support any smtp-out events at time of writing, so we
might as well throw an error if people try to register one. This way
people won't be surprised if the registration succeeds, but no event
ever arrives.
OK?
martijn@
Index: lka_report.c
tun_dev_write currently checks if the packet being written into the
kernel is less than the current if_mtu of the interface. we don't really
have a conflation of the mtu with the mru in any other driver, so i'd
like to remove it from tun(4).
we can also avoid a check at runtime about what type of
34 matches
Mail list logo
