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.
Consider this situation: An ISP is running DSPAM on its mail system.
Customer C has received an email on his DSPAM protected account and, for
some sensible reason, feels like forwarding that email to recipient R.
Assuming that R is actually a mailing list possibly archived on the web,
many people have access to that forwarded email which, unless somebody
has deliberately taken precautionary steps against it, will still
contain the DSPAM signature. Depending on the nature of the mailing list
C might even feel inclined to forward several emails to R so a
sufficiently eager person of bad humor or intentions might collect a
certain amount of signature data and use it to mess up C's DSPAM
database. The situation might get even worse if the ISP has actually set
up group training and several of its customers are unwittingly spreading
their signatures in public places. Especially when the uid is stored in
those signatures and the ISP has set up global addresses for retraining,
perhaps even systems like spamcop could be abused by someone to gather
signature data and launch an attack against that ISP.
IMHO there's no way a user C without *signature* access to R's data will
ever get this to work. Many have tried, many have failed; whatever yo
say about him, Jonz is no slouch.
In a perfect world, I'm sure, the users MUA would take care of whether
to remove the signature before forwarding or not; but then, there would
hardly be any spam in a perfect world, I suppose. Anyway, the question I
have in mind is: can the ISP do anything about it apart from asking all
customers to do some potentially tricky configuration or even switch to
"a better" MUA? I can think of two possibilities:
1. The ISP runs some daemon that searches for DSPAM signatures in
outgoing emails and obscures them in some way.
2. The ISP runs a similar daemon as above but instead of changing the
content of the outgoing message, further retraining using any
signature found in the message is disabled.
The first approach is technically difficult, in case of digitally signed
messages impractical and at least in some countries generally illegal.
The second approach looks more appealing, I think. Even if customer C
forwards a message somewhere and decides afterwords that she wants to
retrain that message, the ISP might still offer a web interface or
another authentication mechanism to retrain a message based on a
disabled (not erased from the database) signature. Still, all this
requires yet another daemon (or mode of the DSPAM daemon) to process all
emails entering the system on an authenticated channel, i.e., sent by
customers' MUAs.
I'm not quite sure whether this scenario should be considered a bit far
fetched and not worth the effort of implementing the proposed solution.
That's why I'm asking you to share your opinion on the matter. Perhaps
there is a flaw in my reasoning after all.
Most people with an IQ over 100 more intellectually gifted than me. I'm
an empirical man myself. I discarded the idea of quarantining or
retraining with aliases at a *very* early stage of using dspam,
basically because my users are both ignorant, lazy, and stupid, and
morons. I now request them, via a nagging cron script, to actually
drag/move incorrectly judged spam to a folder on which a cron script
runs reclassification at given intervals. If they don't, they get nagged
and nagged again, until a: they don't use my email service any more, or
b: they subside and do what I want. I'm Norwegian, my users are Dutch, I
speak their language, *they* are going to subside rather than me.
There was never any question in the first place that users could poison
others' dspam DBs; this I tried and ruled it out. You have submitted a
hypothesis; now either provide proof, or produce a proof of concept.
Best,
--Tonni
--
Tony Earnshaw
Email: tonni at hetnet dot nl
