-------- Original-Nachricht -------- > Datum: Wed, 22 Aug 2007 14:06:47 +0200 > Von: Elias Oltmanns <[EMAIL PROTECTED]> > An: [email protected] > Betreff: Re: [dspam-users] [RFC] Signature leakage and its consequences
> [EMAIL PROTECTED] wrote: > > -------- 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'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... > > Could you explain more explicitly how you'd suggest to go about it? I'm > particularly interested in this case where Daniel has set up global > aliases for retraining. As far as I can see, only DSPAM can tell who the > retraining request came from by looking up the uid part of the signature > in its database. In order to make sure that the request *really* > originated from the same user DSPAM thinks it did, postfix, or any other > MTA for that matter, would have to perform some sort of authentication > (like SASL) and check afterwards whether the authenticated user is > permitted to retrain the data of the user specified in the uid part of > the signature. This would require postfix to parse the message with a > similar algorithm as DSPAM does and it would also have to have access to > DSPAMs uid mapping table, the latter being not a big deal, admittedly. > There are many ways to implement a global training alias. No one forces you to use UID's in the signature. It can be done without. Anyway... I will try to explain two approaches: I have created 3 transports in Postfix. One for training as spam (lets call it dspam-spam) and one for training as ham (lets call it dspam-ham) and one for retraining (lets call it dspam-retrain). I have set up a restriction class in Postfix to only allow SASL authenticated users to use the global training alias. Not authenticated users are denied access. After that I call the transport either with "FILTER dspam-ham" or with "FILTER dspam-spam" or "FILTER dspam-retrain". The transports are then normal pipe transports calling the DSPAM binary and using the option "--user ${sender}" and other switches (depending on which one is called). Now assume I have an account and you have an account on that server. And now assume I got (how ever) a signature belonging to a mail you have received (for example !DSPAM:4,46cc4dd8264013699821073!). Now if I would send a message to the global training alias and use your signature (with our without the UID) then DSPAM will bark and not retrain your database because DSPAM is forced to use my user name (--user switch) in the training script. This is just one way of doing it. You could do it with user specific alias addresses if you like. For example: dspam-ham-<[EMAIL PROTECTED]>, dspam-spam-<[EMAIL PROTECTED]> and dspam-retrain-<[EMAIL PROTECTED]>. Then the user would just need to send a miss classified mail to [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] Then you do the same stuff as above with the restriction class and then you process everything with a Postfix recipient access map using regex or pcre. For example (with PCRE): /^(dspam\-(ham|spam|retrain))\-(.*)$/ FILTER ${1} This is as well just one way of doing it. I could name at least two other methods of doing it. > Please note that I was originally talking about an ISP which makes a > difference to Daniel's case. > I am an ISP. > It may be company policy to trust its > employees not to mess around with their colleagues training data. > I don't trust anyone not authenticated. > This > cannot be assumed in general. Also, I'm not trying to prove that DSPAM > is flawed by design. All I'm saying is that there is a problem without > an obvious solution---well, not obvious to me anyway. Personally, I > definitely prefer the global alias approach over any other solution > which is, obviously, why I'm so interested in solving this issue. > You mean one global alias for each action for all users (aka: [EMAIL PROTECTED])? Or you mean an alias for each action for each user (aka: [EMAIL PROTECTED])? > I > appreciate that in Tony's experience there are good reasons for > discarding this method altogether but this need not be the case for > every group of users. For webmail users its no big deal to retrain their > spam filter by draging things around in their familiar web interface. > My web mail users would kill me if they would need to drag mails around. In their web interface they have a button for spam and one for ham. The press them and the message gets relearned. And my Domino users would kill me if I would not allow them to retrain directly from their inbox. They select a bunch of messages and then train them in one run. If they would be forced to move messages around into different folders, then I am sure they would stop training. > Those, who generally download their emails -- for various good reasons > like being only intermittently connected to the web, possibly on a low > bandwidth link -- may find it more convenient to forward (at least false > negatives) to an alias. > It would be stupid to only focus on FN's and let FP's out of the game. > In fact, the DSPAM manual implies that this was > "the more common approach to training". > > [...] > >> 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? > > No, you met the point spot on. Whether it really is a storm in the > teacup I'm not quite convinced yet, but it probably isn't exactly one of > the most pressing issues either. Please note, however, that once the > worst case has happened and you have had to restore the db from a > backup, you'd probably be all the more keen to make sure that this sort > of thing won't happen again. > > Regards, > > Elias Kind Regards Steve -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
