[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.
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.
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?
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).
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
