[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. 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*. 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 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. > >> [...] >> >> 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. 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. 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. Regards, Elias
