Daniel,
Would it be possible/difficult to filter traffic so that users on the same server could not talk to each other over the gateways?
i.e. if usera and userb are logged into MSN using XMPP/gateway and attempt to talk to each other over MSN/whatever then the gateway refuses and tells them to talk internally instead?
We’re attempting to train people to talk to each other without using the public networks if possible, and a technological enforcer would be the easiest way (for us, not you )
thanks,
DJ
Disagree with it in principle? Some people
In our corporate environment, where sensitive information is exchanged, it’s just trying to ensure that everything that can be kept off public networks, is. The only complication is that it’d have to check both that the user is currently logged in locally (and through the gateway) so not to restrict communication if an internal person logs in using the native client elsewhere.
Thanks again for this…
D
laugh I was wondering if you’d pick up on that. My “disagreement” is just that I think if someone chooses to talk to someone else through MSN, then that’s their choice and they should be allowed to. That said, I work with open non-corporate environments and I certainly see your point.
BTW, one thing I wanted to ask you … which is preferrable:
- “hey, talk to this person through XMPP”
or
- just redirect the message silently behind the scenes
the latter doesn’t “teach” them anything.
My problem is that I also work with a load of engineers who will undoubtably have the same view as you.
So, I’d prefer it tell them to use XMPP personally (to educate them). However, what will probably happen is that they’ll complain about that so then I’d wished I’d asked for the automatic redirect.
Would asking for a configurable option for both be too much to ask? Failing that, I suspect an auto-redirect will result in the fewest support calls!
Jadestorm,
I wonder if this is something that could be done using the Packet Filter plugin. I haven’t looked into exactly how the transports work (I should ) put as long as there is a reliable source and destination JID then the traffic could probably be blocked/rejected. Thoughts?
Hi Nate! I watched your podcast, excellent! =) I’m not sure if the Packet Filter plugin would work in this instance because it would need to have some knowledge of the internals of the IM Gateway plugin. If XMPP user A sends a message to MSN user XYZ who happens to also be XMPP user B, the packet goes into the gateway plugin, and out through MSN. Then MSN sends it to XMPP user B back through their own MSN session. There’s no external idea of how XMPP user A and B map together. The IM gateway plugin can make that mapping by looking in it’s own registration tables.
One possibility might be if the IM Gateway plugin could “tell the packet filter” plugin what to do. In other words… XMPP user A logs in. I’m going to shorten my plugin to IMG and yours to PF because I’m tired of typing. lol XMPP user A logs in and IMG tells PF “hey, map all internal messages to account@msn.myserver.org, account2@aim.myserver.org, account3@icq.myserver.org to XMPP user A”. That way it could go ahead and set up the relationship and intercept things on the fly. That’s kinda an interesting concept. I haven’t looked at PF enough yet to know if that would be possible. Thoughts?
(that still would dodge by the possible request to have the messages flat out denied and the end user told to use XMPP, but it would be a way to handle the other scenario in a nice clean fashion that doesn’t involve me writing a lot of extra support ;D )
I think we could do something neat. I’m headed off to Europe in a couple days. Cool if I ping you when I get back and we can talk about possible integration points?