Why strip headers?

[Ben Finney]

On 08-May-2005, Tom Anderson wrote:
> On Sat, 2005-05-07 at 23:22, Ben Finney wrote:
> >   - discard some specific X-Foo and permit the rest
> 
> This seems dangerous from a security perspective.  You always want
> to define permissible fields and deny the rest, as you can never
> guess the full range of user input.

This assumes that the input will be executable in some form. In the
case of bogofilter, we *want* unknown input (including unknown
non-standard header fields) to be processed -- that's how we build up
statistics about them.

> I see no value in defining the set of discard fields.

For the reason you stated: some fields might *never* be useful, and
only confusing for bogofilter.

I can understand your viewpoint -- you want to specify what bogofilter
processes and deny the rest. I want the opposite -- specify what
bogofilter denies and process the rest.

I see value in both approaches; that's why I proposed both methods.

> >   - permit some specific X-Foo and discard the rest
> 
> Proposed function: pass in list of allowable header fields in
> addition to standard RFC fields, discarding anything not in either
> of these sets

Yes.  My intention with the above proposals was only to apply to
X-Foo, not the standard RFC-defined header fields; clearley those
should always be permitted unless there's a specific reason.

> This is not particularly difficult to implement.  In fact, let me do
> so quickly now... http://orderamidchaos.com/bogofilter/spamitarium.
> Try it out.

Thanks.

-- 
 \           "Professionalism has no place in art, and hacking is art. |
  `\      Software Engineering might be science; but that's not what I |
_o__)        do. I'm a hacker, not an engineer."  -- Jamie W. Zawinski |
Ben Finney <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.bogofilter.org/pipermail/bogofilter/attachments/20050509/962e3859/attachment.sig>