Re: smtpd handling of \r in DATA part

September 19, 2019 7:26 PM, "Eric Faurot" wrote: > On Thu, Sep 19, 2019 at 05:46:47PM +0200, Gilles Chehade wrote: > >> Hello, >> >> The RFC for SMTP states the following (section 2.3.8): >> >> In addition, the appearance of "bare" "CR" or "LF" characters in text >> (i.e., either without the o

Re: smtpd handling of \r in DATA part

On Thu, Sep 19, 2019 at 05:46:47PM +0200, Gilles Chehade wrote: > Hello, > > The RFC for SMTP states the following (section 2.3.8): > > In addition, the appearance of "bare" "CR" or "LF" characters in text > (i.e., either without the other) has a long history of causing > problems in

PATCH: ldpd: adjacency processing fix

If remote peer changes LSR ID, ldpd will not update adjacency. Because ldpd looks up the adjacency only by source IP address and does not consider LSR ID. You can see it in 'ldpctl show discovery'. This patch fixes it. diff --git usr.sbin/ldpd/adjacency.c usr.sbin/ldpd/adjacency.c index a40027225e

EFI frame buffer > 4GB

Hi, I recently got a VAIO Pro PK. The diff below is required to boot. Without the diff, it freezes during boot. Its EFI framebuffer is located 0x40 (9 zeros). This is > 4GB and higher than highest available memory of the machine. These configuraions seem to cause the problem. * * *

smtpd handling of \r in DATA part

Hello, The RFC for SMTP states the following (section 2.3.8): In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool.

Re: New driver for AMD CPU temperature sensor over SMN

On Tue, Sep 17, 2019 at 12:41:11PM -0400, Bryan Steele wrote: > Unlike with previous generations of AMD processors, the on-die > temperature sensor is only available from reading from the SMU > co-processor over an internal network (SMN), this includes all > Ryzen CPUs and some later Family 15h mod

Re: bpf_mtap_hdr copy function is redundant

On Thu, Sep 19, 2019 at 09:02:09AM +0200, Klemens Nanni wrote: > On Thu, Sep 19, 2019 at 01:04:03PM +1000, David Gwynne wrote: > > this removes the cpfn argument from bpf_mtap_hdr since nothing uses it > > anymore. > OK kn if you update pbf_mtap(9) as well. Same here. OK claudio and please update

Re: bpf_mtap_hdr copy function is redundant

On Thu, Sep 19, 2019 at 01:04:03PM +1000, David Gwynne wrote: > this removes the cpfn argument from bpf_mtap_hdr since nothing uses it > anymore. OK kn if you update pbf_mtap(9) as well.