[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. Please note that I was originally talking about an ISP which makes a difference to Daniel's case. It may be company policy to trust its employees not to mess around with their colleagues training data. 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. 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. 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. 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
