[standards-jig] JEP:0015 Account Transfer
debug at nafai.dyndns.org
Thu Jan 24 20:14:45 UTC 2002
On Thu, 2002-01-24 at 15:13, Iain Shigeoka wrote:
> Sort of. I'm probably not being clear. :)
> The tertserver and old server are completely virtual. A hoax played by the
> rogue spammer's script. So there is no need to verify the ability to
> transfer accounts because there are no accounts to verify. It's all a
> figment of the scripts imagination...
> Hmm. I think I see the disconnect. The spammer is CREATING fake accounts
> on a legitimate server. Say I wanted to create 10,000 jabber.org accounts
> to spam from. I could have my script act like "fakeserver.com" and transfer
> 10,000 non-existant accounts from fakeserver.com to jabber.org. I'm sort of
> hijacking jabber.org's server (or at least its resources and reputation).
> Alternatively, I could use this as a DOS (denial of service) attack by
> chewing up all of jabber.org's resources trying to deal with the mass
> account transfer (and all the data storage that it implies).
> Once again, you can do this through the register protocol as a client but
> account transfer makes it easier to do, and harder to block while still
> supporting the protocol...
> Am I making sense or am I missing it?
Yes; because you need to have an account on newserver before you can
transfer the account. Both the oldaccount and newaccount must pre-exist
before transferring. The account transfer does not create new accounts.
Therefore the DOS is really in allowing new accounts to be created on
the fly. Of course, you could always DOS a server by just sending a
bunch of rouge <message> or <presence> packets to it that it has to
handle/discard. Adding a new account transfer packet doesn't make that
situation any better or any worse. Does this help explain my
Perhaps we could take this to general IM and I pull together the
resulting log and post it here for others' benefit? If this sounds
reasonable to you jab me at airog at floobin.cx
More information about the Standards