-------- Original-Nachricht -------- > Datum: Thu, 23 Aug 2007 14:55:50 +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: 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 > > > [...] > >> 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... > > > > This is virtually no protection at all. > I know. > Firstly, *all* your customers no > at least the aliases of your setup so once they've got hold of somebody > else's signature, they will know what to do. Secondly, some testing has > shown that guessing the aliases is particularly easy if people have > emebedded uids in their signatures. In these cases [EMAIL PROTECTED] > seems almost a safe bet and [EMAIL PROTECTED] seems rather common too. > Also, there are even prominent members of this list whose accept > [EMAIL PROTECTED] accepted at least an RCPT command which shows that they > don't athenticate the sender---not at that stage, at least. This is > safe, as I said before, only as long as they keep their signatures to > themselves. Of course, I don't actually have proof that I haven't been > trapped by a honeypot whenever I thought I had guessed a spam or notspam > alias. > > > > >> 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. > > > > The embedded uid *is* DSPAM's way of authenticating users. If you > present a signature with an embedded uid and that combination is present > in the database, DSPAM will happily believe you are *the right person*. > I know. > Moreover, it is safe to assume that most (if not all) sites that use the > option UIDInSignature will also use one single alias per action for all > users, e.g. [EMAIL PROTECTED], because this option is introduced in the > README for this particular setup. You have to authorise all your > customers to send emails to those global aliases but the MTA does not > know about signatures, let alone embedded uids, unless you do some > scripting. Thats my point: If all users send their spam > The users are sending their signatures but not content. > to the same > address, e.g. [EMAIL PROTECTED], but the system maintains seperate > dictionaries for those users (or at least some groups), you either have > to make sure that the uid in the signature matches the credentials > supplied to tha MTA, or DSPAM has to disregard the uid -- which is only > possible by turning UIDInSignature off. Perhaps I'm paranoid in thinking > that the implications of UIDInSignature should be stated more clearly in > the README because otherwise the note on security quoted above may very > likely lead to false assumptions. > Right. > > > >> [...] > >> >> 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 > > > > I told you, I don't want per user aliases, so this option is not > applicable. > No problem. > More importantly, *you* told me how to achieve my goal the > safe way, namely by turning UIDInSignature off and relying on the MTA to > specify the right --user option, whereas the README tells me to it > exactly the other way round without mentioning the potential security > risks. On the contrary, the statement quoted above suggested to me, as > it apparently did to others, that it was perfectly safe to leave the > global aliases unprotected because DSPAM could tell users apart and > verify whether the retraining request was legitimate. > Well... the README is wrong. Unfortunately. And I don't think that Jonathan will do much about it. > Finally, I give you an example why I was rather intrigued by this > suggestion, i.e., the possibility to retrain by forwarding without the > requirement for further authentication by the MTA. Consider the > situation that someone has an account at ISP A protected facilitating > DSPAM. However, all email (well, at least all innocnt email) to that > account is forwarded to an account at ISP B. Moreover, ISP B is actually > the internet access provider for that user and blocks all outbound > connections to port 25. Now the user can only relay through the server > at ISP B because smtp connections to A are blocked. I've encountered > that kind of restrictions several times and have been subject to them > myself for almost four years (at two different institutions). Now, if > the retraining aliases at ISP B are not protected by smtp auth, the user > can simply relay messages to those aliases through the smtp server of > ISP A. This approach would be reasonably safe, in my opinion, if the > user only forwarded any signatures to those training aliases and nowhere > else -- assuming, of course, that ISP A can be trusted. However, ISP B > can not even be sure that the user is aware of the problem of leaking > signatures and cannot possibly check whether they have been revealed by > forwarding an email somewhere through ISP A. > > [...] > >> 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? > > > > Because I find it more convenient to log onto my server using IMAP to > forward all false positives to an alias. This way I have a common > interface to all my emails regardless whether they are stored locally or > on the server. > I understand. > Regards, > > Elias > Steve -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
