|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: Help with header_checks
From: Noel Jones (njones
megan.vbhcs.org)
Date: Mon May 03 2004 - 22:00:43 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, May 03, 2004 at 07:59:47PM -0400, Greg A. Woods wrote:
> > To have /m turned off by default, *as used
> > everywhere else* would require that EVERY (mime_)header_check rule
> > have the /m flag added to it.
>
> _IFF_ that's what the RE author intends, of course.
>
> Consider the possibility that the user only wants to match the first
> line of a multi-line header....
>
Why would someone do that??? I mean really? When is this useful?
Of course the flag is available if you find something useful besides
checking for the old outlook "blank folding" vulnerability.
>
> > This would undoubtedly cause far more
> > problems for the masses than the few cases where someone who knows
> > regexp and doesn't read the postfix docs does what they think is the
> > right thing.
>
> It is undoubtable that you are mistaken.
>
Have you already forgetton how many questions there used to be about
pcre checks when the /s flag wasn't on by default? Yes, we still have
the occasional question about the /i flag, but the noise has been
greatly reduced.
> Inconsistency of otherwise universally accepted de facto standards and
> documented features is _never_ a good thing in this sort of scenario.
>
and software that is much harder for most to use because it
adhers to de facto standards is doomed to be used only by those who
cling to the old de facto standards.
Software with sane default settings that can be changed benfits
everyone.
While I appreciate your opinion on this (and everything else!), and
can see your point, I am certain that postfix would _not_ be a better
product if all those handy flags were left off by default. And that's
my final answer.
--
Noel Jones
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]