-------- 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. > > > > 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. > Same here. To retrain the DSPAM setup my users either need to be SASL authenticated (for retraining with email) or they need to authenticate (with the email login information) against HTTPS secured web server running the DSPAM web-ui. > > 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. > I use one merged group (which I trained first with TEFT and then switched to TOE) for all accounts. The user data is TOE. If they don't retrain then at least the data does not get polluted. I don't force them to retrain. It is their account. If THEY don't do anything then nothing will change FOR THEM. So it is in their own interest to be active. > 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. > Best, > > --Tonni > Steve > -- > Tony Earnshaw > Email: tonni at hetnet dot nl -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
