Re: smtpd "require auth"

Penned by Bob Beck on 20121009 10:05.42, we have: | Gilles, I'm actually wondering - should there even be a difference? | | Every practical implementation of 587 I've ever seen requires auth. Is there | any sane reason to have "enable auth" not actually require it? I.E. wha

IPv6 stable privacy addresses (Fwd: I-D Action: draft-ietf-6man-stable-privacy-addresses-01.txt)

Folks, FYI. This is meant to solve the problem of host tracking and address scanning: Thanks, Fernando Original Message Subject: I-D Action: draft-ietf-6man-stable-privacy-addresses-01.txt Date: Sun, 07

Re: smtpd "require auth"

On 10/09/12 15:24, Alexander Hall wrote: Hi, I suddenly got a flood of incoming spam, and when I could not find any trace of them in the spamdb output, I suspected it was coming in on port 587, which I had configured with tls and "enable auth" For shitz and giggles, I don't believe they spamme

Re: Support power saving with athn(4) in host AP mode

On 22.8.2012 12:52, Marko Saarela wrote: > On 18.8.2012 11:40, Mark Kettenis wrote: >> Further testing would be welcome. Even if you don't use clients with >> power saving enabled. So if you're running an athn(4) based AP, >> please give this a spin. > > Been testing this for two days and everyt

Re: smtpd "require auth"

On Tue, Oct 09, 2012 at 12:02:48PM -0600, Bob Beck wrote: > >> Then what about the opposite ? > >> > >> listen on fxp0 [...] auth # 99% case > >> listen on fxp0 [...] auth-optional # 1% case > > > > > > I'd say this is at least less surprising, and will likely cau

Re: smtpd "require auth"

>> Then what about the opposite ? >> >> listen on fxp0 [...] auth # 99% case >> listen on fxp0 [...] auth-optional # 1% case > > > I'd say this is at least less surprising, and will likely cause less admins > to open a backdoor for locally destinated mail, bypassi

Re: smtpd "require auth"

I also like the last version, makes the default sane. Den 9 okt 2012 19:56 skrev "Bob Beck" : > > Then what about the opposite ? > > > > listen on fxp0 [...] auth # 99% case > > listen on fxp0 [...] auth-optional # 1% case > > > > Better, as long as we're sure th

Re: smtpd "require auth"

On 10/09/12 19:21, Gilles Chehade wrote: On Tue, Oct 09, 2012 at 11:08:17AM -0600, Bob Beck wrote: On Tue, Oct 9, 2012 at 11:04 AM, Bob Beck wrote: I think Bob's point is that then you use 587 (with auth) for yourselves and 25 (without auth) for mail from the rest of the intertubes. Yes, t

Re: smtpd "require auth"

> Then what about the opposite ? > > listen on fxp0 [...] auth # 99% case > listen on fxp0 [...] auth-optional # 1% case > Better, as long as we're sure there's real use for auth-optional

Re: smtpd "require auth"

Bob Beck wrote: On Tue, Oct 9, 2012 at 11:04 AM, Bob Beck wrote: I think Bob's point is that then you use 587 (with auth) for yourselves and 25 (without auth) for mail from the rest of the intertubes. Yes, that's my point :) Along with the fact that this is probably the 99% use case out t

Re: smtpd "require auth"

On Tue, Oct 09, 2012 at 11:08:17AM -0600, Bob Beck wrote: > On Tue, Oct 9, 2012 at 11:04 AM, Bob Beck wrote: > >> > >> I think Bob's point is that then you use 587 (with auth) for yourselves and > >> 25 (without auth) for mail from the rest of the intertubes. > >> > > > > Yes, that's my point :) >

Re: smtpd "require auth"

On Tue, Oct 09, 2012 at 07:05:46PM +0200, Alexander Hall wrote: > >The following diff is what I intend to commit tonight with an ok from > >eric@. It applies on -current, but beware as it kills the "enable" > >keyword: > > > > listen on bnx0 [...] auth # enable auth > > listen

Re: smtpd "require auth"

On Tue, Oct 9, 2012 at 11:04 AM, Bob Beck wrote: >> >> I think Bob's point is that then you use 587 (with auth) for yourselves and >> 25 (without auth) for mail from the rest of the intertubes. >> > > Yes, that's my point :) Along with the fact that this is probably the 99% use case out there. K

Re: smtpd "require auth"

On 10/09/12 17:07, Gilles Chehade wrote: On Tue, Oct 09, 2012 at 03:48:44PM +0200, Gilles Chehade wrote: On Tue, Oct 09, 2012 at 03:43:03PM +0200, Alexander Hall wrote: On 10/09/12 15:33, Gilles Chehade wrote: Argh, you should have talked to me first ... Both require ssl and require auth are

Re: smtpd "require auth"

> I think Bob's point is that then you use 587 (with auth) for yourselves and > 25 (without auth) for mail from the rest of the intertubes. > Yes, that's my point :)

Re: smtpd "require auth"

On Tue, Oct 09, 2012 at 06:49:15PM +0200, Alexander Hall wrote: > > I think Bob's point is that then you use 587 (with auth) for > yourselves and 25 (without auth) for mail from the rest of the > intertubes. > Yes I understand this :-) What I want to highlight is the implication of this change

Re: smtpd "require auth"

On 2012/10/09 18:49, Alexander Hall wrote: > On 10/09/12 17:38, Gilles Chehade wrote: > >On Tue, Oct 09, 2012 at 09:29:25AM -0600, Bob Beck wrote: > >>On Tue, Oct 9, 2012 at 9:25 AM, Gilles Chehade wrote: > >> > >>> > >>>I agree with you that people will probably not want port 587 without auth > >

Re: smtpd "require auth"

On 10/09/12 17:38, Gilles Chehade wrote: On Tue, Oct 09, 2012 at 09:29:25AM -0600, Bob Beck wrote: On Tue, Oct 9, 2012 at 9:25 AM, Gilles Chehade wrote: I agree with you that people will probably not want port 587 without auth turned on so on a practical point of view, we could make it impli

Re: Scheduler improvements, take 1001, Patch 5/5

This patch moves struct schedstate_percpu to kernel land, which I think is cleaner than exposing structures for scheduler state to userland, especially since grepping for 'schedstate' in /usr/src yielded no results outside of /usr/src/sys. I have not seen negative impact from this, but I haven't y

Re: Scheduler improvements, take 1001, Patch 4/5

This patch uses the previous one to take CPU topology into account when calculating the cost of moving a process between CPUs. This is only done on amd64 at the moment, and the cost factors are guesses right now, but it's a start. -- Gregor Best

Re: Scheduler improvements, take 1001, Patch 3/5

This patch simply imports Christiano's code for detecting CPU topology, as posted on tech@ a while (more than two months) ago. I took it verbatim and didn't change anything yet. -- Gregor Best

Re: Scheduler improvements, take 1001, Patch 2/5

This patch simply halves the timeslice processes get until they are preempted. This patch is standalone and the rest of the patches does not depend on it, but I figured I'd throw it in anyway. -- Gregor Best

Re: Scheduler improvements, take 1001, Patch 1/5

As requested, I'll write down a few comments on each patch. So, here goes: This is the initial commit, it replaces the multiple FIFO queues that were used before with one RB-tree per CPU as a runqueue. The RB-tree is used because it offers operations such as min(), insert() and remove() in O(log n

Re: Scheduler improvements, take 1001, Patch 3/5

diff --git a/arch/amd64/amd64/identcpu.c b/arch/amd64/amd64/identcpu.c index c597bb0..982c2bb 100644 --- a/arch/amd64/amd64/identcpu.c +++ b/arch/amd64/amd64/identcpu.c @@ -210,6 +210,8 @@ void (*setperf_setup)(struct cpu_info *); void via_nano_setup(struct cpu_info *ci); +void cpu_topology(st

Re: Scheduler improvements, take 1001, Patch 4/5

diff --git a/arch/amd64/include/cpu.h b/arch/amd64/include/cpu.h index 12e48d6..99501a1 100644 --- a/arch/amd64/include/cpu.h +++ b/arch/amd64/include/cpu.h @@ -102,9 +102,11 @@ struct cpu_info { u_int32_t ci_cflushsz; u_int64_t ci_tsc_freq; +#define ARCH_HAVE_CPU_TOPO

Re: Scheduler improvements, take 1001, Patch 5/5

diff --git a/sys/sched.h b/sys/sched.h index fb01f21..1784ee2 100644 --- a/sys/sched.h +++ b/sys/sched.h @@ -69,8 +69,10 @@ #ifndef_SYS_SCHED_H_ #define_SYS_SCHED_H_ +#ifdef _KERNEL #include #include +#endif /* * Posix defines a which may want to include @@ -88,11 +90

Re: Scheduler improvements, take 1001, Patch 1/5

diff --git a/kern/kern_clock.c b/kern/kern_clock.c index 843965b..f598afc 100644 --- a/kern/kern_clock.c +++ b/kern/kern_clock.c @@ -233,7 +233,7 @@ hardclock(struct clockframe *frame) if (stathz == 0) statclock(frame); - if (--ci->ci_schedstate.spc_rrticks <= 0) +

Re: Scheduler improvements, take 1001, Patch 1/5

diff --git a/kern/sched_bsd.c b/kern/sched_bsd.c index 172bb8f..c7121dc 100644 --- a/kern/sched_bsd.c +++ b/kern/sched_bsd.c @@ -77,12 +77,12 @@ scheduler_start(void) timeout_set(&schedcpu_to, schedcpu, &schedcpu_to); - rrticks_init = hz / 10; + rrticks_init = hz / 20;

Scheduler improvements, take 1001

(By popular request as a new thread). Hi people, I've tried splitting my scheduler patch into smaller fragments, and here's the result. I changed a few things people mentioned over the last few days, such as the following: 1) sys/proc.h now includes sys/tree.h, which should make libc builds

Re: smtpd "require auth"

On Tue, Oct 09, 2012 at 09:29:25AM -0600, Bob Beck wrote: > On Tue, Oct 9, 2012 at 9:25 AM, Gilles Chehade wrote: > > > > > I agree with you that people will probably not want port 587 without auth > > turned on so on a practical point of view, we could make it implicit. > > > > There's a syntax

Re: smtpd "require auth"

On Tue, Oct 9, 2012 at 9:25 AM, Gilles Chehade wrote: > > I agree with you that people will probably not want port 587 without auth > turned on so on a practical point of view, we could make it implicit. > > There's a syntax issue though because, users will likely be less surprised by: > > li

Re: smtpd "require auth"

On Tue, Oct 09, 2012 at 09:05:42AM -0600, Bob Beck wrote: > Gilles, I'm actually wondering - should there even be a difference? > > Every practical implementation of 587 I've ever seen requires auth. Is there > any sane reason to have "enable auth" not actually require it? I.E. what > I'm asking

Re: smtpd "require auth"

On Tue, Oct 09, 2012 at 03:48:44PM +0200, Gilles Chehade wrote: > On Tue, Oct 09, 2012 at 03:43:03PM +0200, Alexander Hall wrote: > > On 10/09/12 15:33, Gilles Chehade wrote: > > >Argh, you should have talked to me first ... > > > > > >Both require ssl and require auth are implemented already ... I

Re: smtpd "require auth"

Gilles, I'm actually wondering - should there even be a difference? Every practical implementation of 587 I've ever seen requires auth. Is there any sane reason to have "enable auth" not actually require it? I.E. what I'm asking is is "enable" (without require) simply a silly knob that we're putt

Re: smtpd "require auth"

On Tue, Oct 09, 2012 at 03:43:03PM +0200, Alexander Hall wrote: > On 10/09/12 15:33, Gilles Chehade wrote: > >Argh, you should have talked to me first ... > > > >Both require ssl and require auth are implemented already ... I did > >not commit yet because we stabilized a release and decided to not

Re: smtpd "require auth"

On 10/09/12 15:38, Gilles Chehade wrote: ok, discussed with eric, not critical but still very annoying so we'll commit the feature tonight. Ah, so something good came out of my diff anyway! :-) I was actually unsure whether this would get an OK or be postponed, so that could indeed have hinte

Re: smtpd "require auth"

On 10/09/12 15:33, Gilles Chehade wrote: Argh, you should have talked to me first ... Both require ssl and require auth are implemented already ... I did not commit yet because we stabilized a release and decided to not add new features to it unless they are critical. This feature should be com

Re: smtpd "require auth"

ok, discussed with eric, not critical but still very annoying so we'll commit the feature tonight. On Tue, Oct 09, 2012 at 03:33:03PM +0200, Gilles Chehade wrote: > Argh, you should have talked to me first ... > > Both require ssl and require auth are implemented already ... I did > not commit ye

Re: smtpd "require auth"

Argh, you should have talked to me first ... Both require ssl and require auth are implemented already ... I did not commit yet because we stabilized a release and decided to not add new features to it unless they are critical. This feature should be committed in a few days Gilles On Tue, Oct

smtpd "require auth"

Hi, I suddenly got a flood of incoming spam, and when I could not find any trace of them in the spamdb output, I suspected it was coming in on port 587, which I had configured with tls and "enable auth" I did not realize that that would allow anyone to send locally addressed mail to me that way,

Re: acpiec madness (HP laptop people pay attention to this one) - tested on some HP Compaq platforms

Theo, Thank you for comprehensive answer. It can be wrong and I don't know on how to do acpi things right, but three years ago I wrote about HP-Compaq acpiec specific errors to tech@. I'm not a guru in programming, but it is very sorrowfully having the same acpiec errors from version to version f

Re: Fix iked's auto-srcid based on the local hostname

On Tue, Oct 9, 2012 at 1:23 PM, Reyk Floeter wrote: > Hi, > > the iked.conf(5) manpage says: "If srcid is omitted, the default is to > use the hostname of the local machine, see hostname(1) to set or print > the hostname." This was true but I broke it with a commit about two > years ago :( > > The

Fix iked's auto-srcid based on the local hostname

Hi, the iked.conf(5) manpage says: "If srcid is omitted, the default is to use the hostname of the local machine, see hostname(1) to set or print the hostname." This was true but I broke it with a commit about two years ago :( The following diff tells ikev2_policy2id() in ca_setreq() that it's de