Op zaterdag 27 augustus 2005 18:43, schreef Bart van Bragt: > Sander Devrieze wrote: > >> A spimmer would probably do the same as most spammers these days. Not > >> set up their own server but use compromised computers all over the > >> internet. These could either act as as mini servers > > > > This will cost money/time and make it not profitable. > > Is that so? Then why are there lots and lots of worms/viruses/trojans > out there that turn PCs into zombie machines? Why wouldn't they use that > to fetch the JID+password of this user and use that to send loads of SPIM?
He was talking about mini-servers. So semi-servers that send spam directly via s2s. A worm/virus/trojan that gets the JID+password (Remark that there are many different client that store passwords on different ways, even some encrypt them! This makes it a lot harder (and so more expensive!) for the spimmer to find this information on many computer.). Remark that the spimmer also has not an unlimited set of Jabber IDs. Due to limits of the number of messages the spimmer can send on the server, and the fact that it will be very easy (and profitable, as his server might be blocked if he don't solve this problem soon) for the server admin to disable that account and contact the real account member why his account was disabled. > > It would result that if spimmers discover the open registration, many > > servers might be blocked for some time. But afterwards we will have at > > least a better set of public servers left, and maybe a new version of the > > registration JEP that blocks spimmers. > > If you ask me in-band registration should be disabled on public servers > and it should be replaced by some kind of bot proof web page. This way > it's also easier to get a (valid) email address of the user in case they > forget their password etc. In-band registration is spimmers heaven... In-band registration is quite useful: * in private networks, * as long as it is not yet abused. Plus that it now might be possible to abuse in-band registration, does not mean we need to throw the baby out with the badwater. No one said it is not allowed the JEP to: * use Data Forms to ask additional information including an email address, * use xml:lang to internationalize the Data Forms, * add some random question that only humans can answer, * add other technologies so that a Jabber server implementation can be secure out-of-the-box (the problem with the web registration, is that it is up to the admin to implement a web registration form with good or bad protection against bots...especially the lazy ones, as they will choose the web form software that is the easiest to setup). > IMO blocking people that are not on your roster is a very important way > to combat SPIM, IMO I don't think that is a good approach. :-s <snip> > Having: > - Dialback and related mechanisms (ability to hunt the SPIMmer) > - Karma limits on the server (important to keep zombie PCs relatively > quiet) ...and so more expensive. > Adding whitelists to that sounds like a (very) bad > idea, it will reduce the openness of the Jabber network quite a bit. Whitelisted server == Any server with a *free* or commercial certificate issued by one of the authorities voted by e.g. the JSF Members (Allow server?-->yes/no vote). This certificate is *not* the same as the one used for TLS and SASL between servers. Instead it is an additional certificate especially for the whitlisting (or you can call it "opt-in"). A server also can have more signatures (see blacklisted server)! All certificates used for whitelisting/blacklisting can be retrieved by other servers over XMPP: they are stored on the server from which the certificates are. Blacklisted server == Any server with a *free* or commercial certificate issued by one of the authorities that *was* approved by the JSF but not anymore because of *permanent* and *important* problems with spimming. Or a certificate that is signed by an authority that was never approved by the JSF. Remark that all certificates issued by this authority will become blacklisted as it might be possible that the authority was not suspicious enough with other servers too (and might gave certificates to other spimmers or servers that can not offer a good enough protection against spimming). To protect you against this, you can opt to have a few more certificates to make it redundant: if one certificate is not good anymore, the others still are ok, and the outgoing connections will still be possible (though it will be a good idea for this admin to replace that certificate with another one to stay redundant). <snip> -- Mvg, Sander Devrieze. xmpp:[EMAIL PROTECTED] ejabberd, the expandable Jabber daemon. -- http://ejabberd.jabber.ru/ _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
