Thread: [pgsql-www] Please remove onerous /^\s*config\b/i body filter.

[pgsql-www] Please remove onerous /^\s*config\b/i body filter.

From
Andres Freund
Date:
Hi,

It triggers on all git generated patches for files config/ (due to
automatically included diffstat).  And it's hardly an uncommon thing to
start a line with in general, newline wrapped emails being what they
are.  I plan to send a fair number of patches for things in these
directories, and I'd like to avoid getting continually trapped in the
filter and/or actively munging content to not trigger the system.

Greetings,

Andres Freund



Re: [pgsql-www] Please remove onerous /^\s*config\b/i body filter.

From
Stephen Frost
Date:
* Andres Freund (andres@anarazel.de) wrote:
> It triggers on all git generated patches for files config/ (due to
> automatically included diffstat).  And it's hardly an uncommon thing to
> start a line with in general, newline wrapped emails being what they
> are.  I plan to send a fair number of patches for things in these
> directories, and I'd like to avoid getting continually trapped in the
> filter and/or actively munging content to not trigger the system.

+1, I'd rather not have to approve all of those..  I don't recall the
last time I saw an actual spam or garbage email caught by that filter
either.

I'm not terribly interested in trying to fight with MJ2, but hopefully
Alvaro can remove that filter without too much trouble...

Thanks!

Stephen

Re: [pgsql-www] Please remove onerous /^\s*config\b/i body filter.

From
Tom Lane
Date:
Stephen Frost <sfrost@snowman.net> writes:
> * Andres Freund (andres@anarazel.de) wrote:
>> It triggers on all git generated patches for files config/ (due to
>> automatically included diffstat).  And it's hardly an uncommon thing to
>> start a line with in general, newline wrapped emails being what they
>> are.  I plan to send a fair number of patches for things in these
>> directories, and I'd like to avoid getting continually trapped in the
>> filter and/or actively munging content to not trigger the system.

> +1, I'd rather not have to approve all of those..  I don't recall the
> last time I saw an actual spam or garbage email caught by that filter
> either.

The one that bites me from time to time is the one for '^\s*sub'.
I assume that's meant to reject misdirected "subscribe" requests,
but (1) it catches way too many other words, and (2) when was the
last time anybody really tried to subscribe that way?
        regards, tom lane