[jdev] [ANN] Google Talk engineering manager live chat
richard at dobson-i.net
Sat Sep 24 16:05:42 CDT 2005
> > Not really, if you use the example of SMTP you cant run two
> > entirely different email services on the same domain.
> Just because a lot of server developers think of MUC and standard c2s as
> two different components doesn't mean that users do. In fact, it's
> exactly the opposite. Here's an example from the email world -- a few
> organizations setup pop.example.com and smtp.example.com so that they
> have more flexibility about where different parts of email traffic go.
Sorry but that is a bit of an erroneous comparison, in the cases where orgs
setup pop.example.com smtp.example.com etc they are not providing extra
email addresses of user at pop.example.com and user at smtp.example.com they are
just pointing to the same server that is providing emails for
user at example.com, in the case of XMPP where you have a MUC component
connected to a host XMPP server the MUC component in current implementations
has its own domain separate from any other domains the server hosts.
> However, the vast, vast majority of companies will just install a single
> email server at one domain that does both sending and receiving of
> email. That's because users and admins think of "email" as a unified
> service for sending and receiving messages. It's the same thing for
> services like MUC. Admins want to setup an "IM system" and shouldn't
> have to care about all the different services and the required DNS
If you want to run a MUC service on its own domain then you have to setup
the DNS entries, if you dont want to have to setup those entries then follow
my suggestion and run all your XMPP services on the same domain rather than
separate ones, other than the possible overlaps it should be fine (although
they can be solved by just using something like prefixing).
> So, let's say you have the choice between two IM systems. One you can
> double click an exe, wait 5 minutes and then it all "just works".
What IM system would this be?, I find it hard to believe any IM system is
going to be externally connectable without some kind of DNS entries being
> other IM system has 5 different sub-components. You'll have to fill out
> paperwork for each one because they require a new subdomain and new
> subdomains are handled by the IT department at your org and will take
> two weeks to setup. Which IM system do you go with? :) For you, a
> subdomain is "no problem", but this is honestly not the situation at a
> lot of orgs.
Then follow the suggestion of implementing all the server component under a
single domain if thats what they want, rather than individual sub domains,
simple and doesnt require any non standard hacks, as it has been said if
there are any problems with this approach its better to perfect the single
domain approach than perpetuate a "hack" that has some potential security
> Yep, you've pointed out exactly why subdomains are required. Quite
> simply, this is a design flaw of the XMPP protocol.
Not really, its just the recommended way to set it up (avoids any namespace
overlaps, i.e. a room overlapping a user with the same name), as far as I
can see it you should be able to run a conference server under the same
domain as c2s, you should easily be able to run stuff like pubsub under it
> I still haven't heard a lot input about why the logic we've implemented
> in Jive Messenger is a bad thing other than "it's not normal". The only
> argument so far is that if you are on "blah.foo.com", your server goes
> down, and there's an evil server on "foo.com" that wants to
> transparently take your IM traffic then you'd be in trouble. This is a
> logically true argument, but I think the enhanced ease of use of
> outweighs this practically non-existant security concern.
Its not non existant at all, at the very least it provides a way for an
attacker to compromise your entire XMPP setup by highjacking a single point
of your DNS setup, at worse they can compromise an organisation unrelated to
your own and highjack your traffic, thats hardly a non-existant security
concern, IMO we shouldnt be working to introduce any security concerns
wether they are serious or not anyway, if anything we should do everything
we can do to make it more secure, not less.
But anyway I doubt you will change your view on this subject, I just hope
you will provide your users with a way to turn off this "feature" just
incase they arnt happy with the security concerns it introduces.
More information about the JDev