-------- Original-Nachricht -------- > Datum: Thu, 23 Aug 2007 12:40:16 +0200 > Von: Elias Oltmanns <[EMAIL PROTECTED]> > An: [EMAIL PROTECTED] > CC: [email protected] > Betreff: Re: [dspam-users] [RFC] Signature leakage and its consequences
> [EMAIL PROTECTED] wrote: > > -------- 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 > [...] > >> 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. > > This is rather an important point. Perhaps it would be good advice to > say it *should* be done without, see below. > It depends on your needs or your setup. > > 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'm confused. Whats this dspam-retrain transport for? Is it a new > feature in 3.8.0? > No. It is just a transport I created in Postfix and this transport calls an self made script to parse the message for the DSPAM header and switch the class for the message from spam to ham or from ham to spam. But this only works if the training message has the original DSPAM header. Without it I can not use the retraining transport. > > 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. > > That's not quite true, I'm sorry to say. If there is a uid embedded in > the signature, DSPAM will use that uid totally disregarding the --user > option on your command line. If there is no uid in the signature, you > are right, of course. > Yes. You are right. When the UID is embedded in the signature then the --user switch is not consulted. Sorry. My bad. > > > > This is just one way of doing it. > > And its rather an obvious way too, I have to admit (with the > restriction mentioned above). Tahnks for the hint. > No problem. The list is here to help each other. > > 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. > > Right, so here is another challange: Everything you described so far > actually entrusted the MTA with the decision which user's dataset > should be queried for the presented signature and, if found, retrained > accordingly. Earlier I have pointed out that it is actually dangerous to > embed the uid in the signature in the first place, because DSPAM will > switch to that uid on retraining whatever might be specified as the > --user option on the command line. So, unless someone can come up with > another example configuration, the following excerpt from the DSPAM > README should be considered misleading, to say the least, as far as > signatures with embedded uids are concerned: > > --8<---------------cut here---------------start------------->8--- > Note About Security: > > You might be wondering if a user can forward a spam to another user's > address, or whether a spammer can forward a spam to another user's > notspam address. The answer is "no". The key to all mail-based > retraining > is the signature embedded in each email. The signature is stored with > each user's own user id, and so not only does the incoming message > have > to bear a valid signature, but it also has to be stored on the system > with > the correct user id. This prevents any kind of alias abuse. > --8<---------------cut here---------------end--------------->8--- > The text above just says that [EMAIL PROTECTED] could not send a mail to a training alias and force DSPAM to learn spam/ham. It mentions that the UID and the SIGNATURE is needed. But it fails to tell the whole story about signatures in outgoing mails. However... assuming an attacker captures a mail with a signature and a UID then the attacker still needs to guess the alias. I know that this is not a real protection but still... > Am I wrong in thinking that setting > > UIDInSignature on > > is dangerous in spam filter contexts? It may be useful for other > classification purposes but I don't see how I can safely use it for spam > filtering. > It is dangerous if the other site (DSPAM) does not authenticate. > [...] > >> 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])? > > Yes. > > > Or you mean an alias for each action for each user (aka: > > [EMAIL PROTECTED])? > > No. > DSPAM offers another method to implement aliases: ParseToHeaders ChangeModeOnParse ChangeUserOnParse But this one can as well be exploited if set up the wrong way. > [...] > >> 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. > > > > That's not what I meant to imply. Personally, I only download my *real* > emails meaning those that have been classified as innocent. The rest is > sent to a junk folder by a filtering rule. So, I need an alias for > retraining false negatives, because those emails aren't on the server > anymore by the time I check them. Since I have to check my junk folder > on the server anyway, I wouldn't strictly need an alias for false > positives but could use a web interface or a reclassification folder > instead. > But since you check your spam folder on the server then why not using the web ui for doing the training? > Regards, > > Elias // SteveB -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
