Re: [ANNOUNCE] experimental spam filtering

2016-09-23 Thread Jeff Palmer 
Willy,


Thanks for your effort in this.I know its a pain to keep fighting
spam,  but it sounds like you did it the right way.

I for one appreciate your efforts, and those of your team.



On Fri, Sep 23, 2016 at 6:08 PM, Willy Tarreau  wrote:
> Hi Aleks,
>
> On Thu, Sep 22, 2016 at 09:35:39PM +0200, Willy Tarreau wrote:
>> Hi Aleks,
>>
>> On Thu, Sep 22, 2016 at 09:23:45PM +0200, Aleksandar Lazic wrote:
>> > > For now it only adds the "x-bogosity" header to the e-mail and still
>> > > delivers it so that I can monitor the activity, but the purpose is to
>> > > very quickly switch to dropping those marked as spam (which are the
>> > > majority of those people complain about).
>> > >
>> > > I did a few configuration changes for this in the delivery path but
>> > > nothing that should be visible except this new header. I'm just seeing
>> > > the last spam marked as such, after a few other ones I'll configure it
>> > > to block. If you notice that an e-mail from you seems to get blocked
>> > > or to be bouncing, please do report it to me directly so that I can
>> > > check what is happening.
>> >
>> > The mail from "ad3 " was tagged like this.
>> >
>> > X-Bogosity: Unsure, tests=bogofilter, spamicity=0.972880, version=1.2.4
>> >
>> > Does this mean that this mail is not tagged as spam, right?
>>
>> Yep exactly. If at least we get rid of all the readable ads which
>> require us to actually read the subjects before deleting them,
>> that will be a nice improvement already.
>
> By the way I found why it was tagged as "unsure" instead of "spam". I
> didn't specify "-M" in the script so it didn't consider the input file
> was an mbox, hence it probably used to consider the headers in the
> evaluation, leading to a confusing result. With "-M" it clearly states
> it's a spam.
>
> I've now updated the script to locally archive these e-mails instead
> of delivering them. I'll keep an eye on the for some time and will
> deliver them manually if I see some wrong blocking.
>
> Cheers,
> Willy
>



-- 
Jeff Palmer
https://PalmerIT.net

Re: [ANNOUNCE] experimental spam filtering

2016-09-23 Thread Willy Tarreau 
Hi Aleks,

On Thu, Sep 22, 2016 at 09:35:39PM +0200, Willy Tarreau wrote:
> Hi Aleks,
> 
> On Thu, Sep 22, 2016 at 09:23:45PM +0200, Aleksandar Lazic wrote:
> > > For now it only adds the "x-bogosity" header to the e-mail and still
> > > delivers it so that I can monitor the activity, but the purpose is to
> > > very quickly switch to dropping those marked as spam (which are the
> > > majority of those people complain about).
> > > 
> > > I did a few configuration changes for this in the delivery path but
> > > nothing that should be visible except this new header. I'm just seeing
> > > the last spam marked as such, after a few other ones I'll configure it
> > > to block. If you notice that an e-mail from you seems to get blocked
> > > or to be bouncing, please do report it to me directly so that I can
> > > check what is happening.
> > 
> > The mail from "ad3 " was tagged like this.
> > 
> > X-Bogosity: Unsure, tests=bogofilter, spamicity=0.972880, version=1.2.4
> > 
> > Does this mean that this mail is not tagged as spam, right?
> 
> Yep exactly. If at least we get rid of all the readable ads which
> require us to actually read the subjects before deleting them,
> that will be a nice improvement already.

By the way I found why it was tagged as "unsure" instead of "spam". I
didn't specify "-M" in the script so it didn't consider the input file
was an mbox, hence it probably used to consider the headers in the
evaluation, leading to a confusing result. With "-M" it clearly states
it's a spam.

I've now updated the script to locally archive these e-mails instead
of delivering them. I'll keep an eye on the for some time and will
deliver them manually if I see some wrong blocking.

Cheers,
Willy

Re: [DEV] ssl bind_conf per certificat

2016-09-23 Thread Lukas Tribus 

Hi Manu,


Am 23.09.2016 um 16:31 schrieb Emmanuel Hocdet:

Hi all,

I propose to discuss an option to declare ssl options per 
certificat/SNI (instead of global one on bind directive).

use cases will be to set alpn/verify/ per SNI.


I think this would be useful and could simplify some configurations a 
lot, but are you sure we can do this with the OpenSSL API?




Lukas

[DEV] ssl bind_conf per certificat

2016-09-23 Thread Emmanuel Hocdet 
Hi all,

I propose to discuss an option to declare ssl options per certificat/SNI 
(instead of global one on bind directive).
use cases will be to set alpn/verify/ per SNI.

The first idea would be to use a crt-list like directive to express this.
I call it crt-bind for the moment.

in crt-list args is an optional SNI filter.
in crt-bind args is ssl options and SNI filter is after a ‘if’ directive to 
mimic haproxy configuration.

haproxy.cfg:
bind :443 ssl strict-sni crt-bind /etc/haproxy/crtbind.cfg

crtbind.cfg:
mycert.pem  alpn h2,http/1.1  if h2.mydom.net
mycert.pem  verify ca-file ca-admin.pem  if admin.mydom. 
net
mycert.pem # legacy ssl for all others SNI find in CN/SAN in mycert.pem
othercert.pem   alpn http/1.1
…

This will greatly simplify the SSL configuration in a non-homogenous 
environment (for my use case, it would be).
What do you think?
And: what are the useful (and eligible) SSL options for this configuration per 
certificate/SNI.

Manu

Re: [PATCH] MAJOR: filters: Add filters support

2016-09-23 Thread Willy Tarreau 
On Fri, Sep 23, 2016 at 12:53:21AM +0100, Bertrand Jacquin wrote:
> > Thanks for all these information. It helps me to find the bug. I
> > attached a patch. Could you check if it fixes your bug ?
> 
> Thanks a lot for this, I confirm this patch this the issue I was observing.

Great, thanks guys, I've now merged it.

Willy