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

> [EMAIL PROTECTED] wrote:
> > -------- Original-Nachricht --------
> >> Datum: Tue, 21 Aug 2007 18:09:03 +0200
> >> Von: Tony Earnshaw <[EMAIL PROTECTED]>
> >> An: [email protected]
> >> Betreff: Re: [dspam-users] [RFC] Signature leakage and its consequences
> > 
> >> Elias Oltmanns skrev, on 21-08-2007 16:33:
> 
> >>> it seems to me that the signature based approach towards retraining,
> as 
> >>> it is implemented in DSPAM, might be vulnerable to a certain kind of 
> >>> attack described below and I'd like to discuss with you whether this 
> >>> actually poses a problem in reality and whether any thing should or, 
> >>> indeed, can be done about it.
> 
> 
> <SNIP>
> 
> > 
> > 
> >> You have submitted a 
> >> hypothesis; now either provide proof, or produce a proof of concept.
> >>
> I think that his hypothesis can be proven. But only in a simulated
> scenario/environment. No one running a mail server with DSPAM on it and many 
> users
> would be so careless to allow a untrusted user to retrain other users
> DSPAM. And we all know that the chaos exists out there. There are probably
> setups where the installer of the setup has made mistakes and has not properly
> secured the setup. It is like installing a mail server and having a open
> mail relay afterwards (by accident, by not knowing how to, by mistake, etc).
> DSPAM is nothing magic. It is a software which can be wrongly configured.
> DSPAM does not save you from doing stupid mistakes. But DSPAM is not out of
> the box open to such things. It is not flawed by design.
> 
> If a message is sent to [EMAIL PROTECTED] by any of you guys with this in
> it:
> 
> !DSPAM:21,46cb247e46391144716239!
> 
> my dspam will mark ste*ve*'s message as spam. Try it and tell me and I'll
> let you know if it worked; it did for me.
> 
I sent a message there. Can you check?


> 
> It doesn't pop up in this reply to you because ste*ve* 's email has a --\n
> and the !DSPAM: is below that, so it's stripped by thunderbird.  Hardly a
> reliable method.
> 
> 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...


> So... what can I do?  I really like the idea that the users can just send
> to [EMAIL PROTECTED] because otherwise every user needs an alias on the 
> exchange
> server to forward [EMAIL PROTECTED] to [EMAIL PROTECTED]
> 
> Currently I just use two aliases, spam and notspam which is great.
> 
> Now Tony said:
> 
> "IMHO there's no way a user C without *signature* access to R's data will
> ever get this to work."
> 
> but the scenario is that typically, a forwarded message keeps the
> *signature* in it; and Tony also didn't explain why it wouldn't work.  It 
> works for
> me, with other users and with members of the public.
> 
> I can't follow Tony's folder dragging cron job system because I can't do
> much with the exchange server; certainly nothing as involved as that.  If I
> was going down that path then every user could have the spambayes outlook
> plugin and I'd be finished. I'm hoping that dspam can reduce the flow to the
> inbox in the first place; cluesers train things themselves, and all the
> lusers benefit from the merged group.
> 
> ste*ve* uses SASL authentication for email, which I assume implies that
> there exists a mechanism whereby [EMAIL PROTECTED] will only accept email
> sent from [EMAIL PROTECTED]  Is this correct?
> 
Yes. This is correct.


> Both these seem a little heavy.  I agree that this 'problem' is not a flaw
> in dspam as such, but it seems to be a significant consideration that many
> people would miss.  The challenge is to limit who can send email to a
> particular address, which is not the way most email systems work at the 
> moment.
> 
> 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.


> 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

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

Reply via email to