-------- Original-Nachricht --------
> Datum: Wed, 22 Aug 2007 15:52:29 +1000
> Von: Daniel Rose <[EMAIL PROTECTED]>
> An: [EMAIL PROTECTED]
> CC: [email protected]
> Betreff: Re: [dspam-users] [RFC] Signature leakage and its consequences

> >>
> > I sent a message there. Can you check?
> 
> Yep; it retrained.
> 
Not good.


> 
> >> It's not a simulated environment here, just a pilot project, and I'm
> not
> >> usually careless, but I have clearly overlooked this problem so maybe I
> am.
> >>
> > If you have, then send more info:
> > - What MTA
> > - What version of DSPAM
> > - etc...
> 
> 
> There's a production mail feed gateway -> crap filter -> exchange
> 
> 
> I've done redirects for a pilot group of users
> 
> gateway -----------> crap filter ------> exchange
>          |                                  ^
>          ---> postfix -> dspam -> postfix---|
> 
> 
Postfix? Great! Then I can help. What version of Postfix? What version of DSPAM?



> I'll skip the extra details because it's not up to me to give them out;
> and more importantly, I don't need that level of help, I was just struck that
> the problem which was dismissed by you and Tony as being an edge case is
> probably very common.
> 
> Essentially I need to make sure that external people can't send to the
> training addresses, which is easy enough to do.
> 
> It's not so easy to stop staff from poisoning each other's spam databases,
> but I really don't think it'll be a problem.
> 
You can prevent that as well...


> 
> >> I suppose the neatest solution for my particular problem is to strip
> any
> >> line with !DSPAM:[0-9]*,.{22,22}! (or whatever...) on the way in or out
> of
> >> the building, but that doesn't stop users from messing with it
> internally
> >> (internal mail is all within exchange and I can't touch it).
> >>
> > This would be security through obscurity and this mostly does not work.
> Better would be to make a profound and solid setup.
> 
> I take it from this you mean that the signature data is obscured; in which
> case I agree.
> 
> 
> Perhaps however it's a storm in a teacup.  The worst case scenario is that
> we either restore the db from a backup or just reset the training and
> start again.  This doesn't seem too serious really; have I missed the
> point?
> 
> 
> -- 
> Daniel Rose
> National Library of Australia

Steve
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Reply via email to