Are there any plans to support <accept/> within the Py transports? As I understand it they all currently can only initiate the connection to the jabberd router.
My issue is that we have a split environment where the jabberd router sits on our corporate intranet, and the external gateways sit on the Internet. The firewall between is severely port-limiting for connections initiated on the Internet to the intranet. In order to have multiple gateways, I would need a separate IP address for each one, assuming I have a single available port to use. Thanks in advance, Brian Safford Electronic Data Systems From [EMAIL PROTECTED] Fri Apr 28 14:08:35 2006 From: [EMAIL PROTECTED] (Norman Rasmussen) Date: Fri Apr 28 14:08:39 2006 Subject: [py-transports] Support for <accept/> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On 4/28/06, Safford, Brian <[EMAIL PROTECTED]> wrote: > My issue is that we have a split environment where the jabberd router > sits on our corporate intranet, and the external gateways sit on the > Internet. The firewall between is severely port-limiting for connections > initiated on the Internet to the intranet. In order to have multiple > gateways, I would need a separate IP address for each one, assuming I > have a single available port to use. You should be able to configure your firewall to only allow the gateway machine to connect to the internal jabber server. Depending on the internal server, you can run all transports on a single machine and connect to a single port internally. An alternative is to set up a second server externally that's only used for transports (doesn't have to have a valid dns entry), and then use s2s to connect between the internal and external servers. (each transport must have a valid dns entry that points to the external server). Basically the external server is doing the 'accept' work for you. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Fri Apr 28 14:13:38 2006 From: [EMAIL PROTECTED] (Safford, Brian) Date: Fri Apr 28 14:14:08 2006 Subject: [py-transports] Support for <accept/> Message-ID: <[EMAIL PROTECTED]> I should have mentioned that we're using Jabber Inc's XCP stuff, and that we cannot make any changes to the firewall. I like the idea of running an external jabber server that handles the gateway traffic. I'll pursue that one. Thanks! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Norman Rasmussen Sent: Friday, April 28, 2006 10:09 AM To: PyAIM-t/PyICQ-t/PyMSN-t Discussion Subject: Re: [py-transports] Support for <accept/> On 4/28/06, Safford, Brian <[EMAIL PROTECTED]> wrote: > My issue is that we have a split environment where the jabberd router > sits on our corporate intranet, and the external gateways sit on the > Internet. The firewall between is severely port-limiting for connections > initiated on the Internet to the intranet. In order to have multiple > gateways, I would need a separate IP address for each one, assuming I > have a single available port to use. You should be able to configure your firewall to only allow the gateway machine to connect to the internal jabber server. Depending on the internal server, you can run all transports on a single machine and connect to a single port internally. An alternative is to set up a second server externally that's only used for transports (doesn't have to have a valid dns entry), and then use s2s to connect between the internal and external servers. (each transport must have a valid dns entry that points to the external server). Basically the external server is doing the 'accept' work for you. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ _______________________________________________ py-transports mailing list [email protected] http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports From [EMAIL PROTECTED] Fri Apr 28 15:02:54 2006 From: [EMAIL PROTECTED] (Matthias Wimmer) Date: Fri Apr 28 15:03:15 2006 Subject: [py-transports] Support for <accept/> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Safford, Brian schrieb: > Are there any plans to support <accept/> within the Py transports? As I > understand it they all currently can only initiate the connection to the > jabberd router. > > My issue is that we have a split environment where the jabberd router > sits on our corporate intranet, and the external gateways sit on the > Internet. The firewall between is severely port-limiting for connections > initiated on the Internet to the intranet. In order to have multiple > gateways, I would need a separate IP address for each one, assuming I > have a single available port to use. > I don't know the configuration of XCP, but you could use jabberd 1.4.x to bridge between the transport and your server. This bridging jabberd14 could be installed outside the firewall on the same host as the transport. The configuration for the bridging jabberd14 would be something like this: <jabber xmlns='http://jabberd.org/ns/configfile'> <service id='linkerXCP'> <uplink/> <accept> <host>192.0.2.1</host> <port>5111</port> <secret>password</secret> </accept> </service> <service id='linkerTransport'> <host>transport.domain</host> <accept> <host>192.0.2.1</host> <port>5112</port> <secret>password</secret> </accept> </service> </jabber> Tot kijk Matthias From [EMAIL PROTECTED] Fri Apr 28 15:06:04 2006 From: [EMAIL PROTECTED] (Matthias Wimmer) Date: Fri Apr 28 15:06:11 2006 Subject: [py-transports] Support for <accept/> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Norman Rasmussen schrieb: > > An alternative is to set up a second server externally that's only > used for transports (doesn't have to have a valid dns entry), and then > use s2s to connect between the internal and external servers. (each > transport must have a valid dns entry that points to the external > server). Basically the external server is doing the 'accept' work for > you. s2s won't work. With s2s the external server needs to be able to connect to the internal server as well. From [EMAIL PROTECTED] Fri Apr 28 17:43:58 2006 From: [EMAIL PROTECTED] (Norman Rasmussen) Date: Fri Apr 28 17:44:31 2006 Subject: [py-transports] Support for <accept/> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On 4/28/06, Matthias Wimmer <[EMAIL PROTECTED]> wrote: > s2s won't work. With s2s the external server needs to be able to connect > to the internal server as well. You could use s2s authenticated via SASL. As far as I know this doesn't required dialback. I also assumed that the firewall might have been opened for all s2s connections (which would make sense). -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Fri Apr 28 18:00:09 2006 From: [EMAIL PROTECTED] (Matthias Wimmer) Date: Fri Apr 28 18:00:17 2006 Subject: [py-transports] Support for <accept/> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Norman Rasmussen schrieb: > On 4/28/06, Matthias Wimmer <[EMAIL PROTECTED]> wrote: >> s2s won't work. With s2s the external server needs to be able to connect >> to the internal server as well. > > You could use s2s authenticated via SASL. As far as I know this > doesn't required dialback. I also assumed that the firewall might > have been opened for all s2s connections (which would make sense). A transport typically needs not only to receive messages, but to also send messages back to the user. As s2s connections are unidirectional, the transport has to connect back even with SASL. From [EMAIL PROTECTED] Fri Apr 28 18:07:46 2006 From: [EMAIL PROTECTED] (Norman Rasmussen) Date: Fri Apr 28 18:07:50 2006 Subject: [py-transports] Support for <accept/> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On 4/28/06, Matthias Wimmer <[EMAIL PROTECTED]> wrote: > Norman Rasmussen schrieb: > > On 4/28/06, Matthias Wimmer <[EMAIL PROTECTED]> wrote: > >> s2s won't work. With s2s the external server needs to be able to connect > >> to the internal server as well. > > > > You could use s2s authenticated via SASL. As far as I know this > > doesn't required dialback. I also assumed that the firewall might > > have been opened for all s2s connections (which would make sense). > > A transport typically needs not only to receive messages, but to also > send messages back to the user. As s2s connections are unidirectional, > the transport has to connect back even with SASL. RFC 3920, Section 8.1: Domains requiring robust security SHOULD use TLS and SASL; see Server-to-Server Communications for details. If SASL is used for server-to-server authentication, dialback SHOULD NOT be used since it is unnecessary. Documentation of dialback is included mainly for the sake of backward-compatibility with existing implementations and deployments. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Fri Apr 28 18:09:55 2006 From: [EMAIL PROTECTED] (Norman Rasmussen) Date: Fri Apr 28 18:09:58 2006 Subject: [py-transports] Support for <accept/> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On 4/28/06, Norman Rasmussen <[EMAIL PROTECTED]> wrote: > On 4/28/06, Matthias Wimmer <[EMAIL PROTECTED]> wrote: > > Norman Rasmussen schrieb: > > > On 4/28/06, Matthias Wimmer <[EMAIL PROTECTED]> wrote: > > >> s2s won't work. With s2s the external server needs to be able to connect > > >> to the internal server as well. > > > > > > You could use s2s authenticated via SASL. As far as I know this > > > doesn't required dialback. I also assumed that the firewall might > > > have been opened for all s2s connections (which would make sense). > > > > A transport typically needs not only to receive messages, but to also > > send messages back to the user. As s2s connections are unidirectional, > > the transport has to connect back even with SASL. > > RFC 3920, Section 8.1: > > Domains requiring robust security SHOULD use TLS and SASL; see > Server-to-Server Communications for details. If SASL is used for > server-to-server authentication, dialback SHOULD NOT be used since it > is unnecessary. Documentation of dialback is included mainly for the > sake of backward-compatibility with existing implementations and > deployments. > Sorry - You're right Section 4.1: The initial stream enables unidirectional communication from the initiating entity to the receiving entity; in order to enable information exchange from the receiving entity to the initiating entity, the receiving entity MUST negotiate a stream in the opposite direction (the "response stream"). That sucks! So run your reverse s2s connection via a reverse ssh tunnel :-P -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Fri Apr 28 18:11:27 2006 From: [EMAIL PROTECTED] (Matthias Wimmer) Date: Fri Apr 28 18:11:35 2006 Subject: [py-transports] Support for <accept/> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Norman Rasmussen schrieb: > RFC 3920, Section 8.1: > > Domains requiring robust security SHOULD use TLS and SASL; see > Server-to-Server Communications for details. If SASL is used for > server-to-server authentication, dialback SHOULD NOT be used since it > is unnecessary. Documentation of dialback is included mainly for the > sake of backward-compatibility with existing implementations and > deployments. I know this. With dialback and a bi-directional connections, four connections would be established: S -> T: stanza stream T -> S: dialback for S->T stanza stream T -> S: stanza stream S -> T: dialback for T->S stanza stream With SASL the 2nd and the 4th connection is not needed (nor done). This is what the cited paragraph mentions. But still you need the 3rd connection which is used to send stanzas from the transport to the server. From [EMAIL PROTECTED] Fri Apr 28 18:27:42 2006 From: [EMAIL PROTECTED] (Matthias Wimmer) Date: Fri Apr 28 18:27:47 2006 Subject: [py-transports] Support for <accept/> In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Matthias Wimmer schrieb: > I know this. With dialback and a bi-directional connections, four > connections would be established: > > S -> T: stanza stream > T -> S: dialback for S->T stanza stream > T -> S: stanza stream > S -> T: dialback for T->S stanza stream > > With SASL the 2nd and the 4th connection is not needed (nor done). > This is what the cited paragraph mentions. But still you need the 3rd > connection which is used to send stanzas from the transport to the > server. One addition: a s2s components can reuse existing connections. Therefore the 2nd connection in this dialback example can used for the 3rd connection. And the 1st connection can be used for the 4th. I just wrote this as completely separate connections to show what is meant by not doing dialback. But in an environment of clustered s2s components you can really get those four independant connections. From [EMAIL PROTECTED] Fri Apr 28 20:11:51 2006 From: [EMAIL PROTECTED] (Lars T. Mikkelsen) Date: Fri Apr 28 20:11:58 2006 Subject: [py-transports] PyMSNt Fullname for MSN nickname In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Hi Maarten, On Thu, Apr 27, 2006 at 08:47:24PM +0200, Maarten Fonville wrote: > I suspect that the problem could be that the nickname field has been > send after the fullname field and so the name will be empty(!) and so > the updateNickName method will use the JID user part for nickname. I checked the vCard sent by the Google Talk server, and it does in fact not contain a <NICKNAME/> element. However, I agree that there might be an issue if the vCard contains an empty <NICKNAME/> after an non-empty <FN/>. I found a bug a couple of lines below the snippet you posted, that prevents the nickname from being set properly in some cases. The attached patch fixes the issue. > James, could you please fix this, I suspect that putting an "not name > and " part before the NICKNAME 'if' will do the trick By doing this we'll lose the priority of <NICKNAME/> over <FN/> if the vCard contains an <FN/> after the <NICKNAME/>. Best regards, Lars -------------- next part -------------- Index: src/session.py =================================================================== --- src/session.py (revision 144) +++ src/session.py (working copy) @@ -133,7 +133,7 @@ self.legacycon.updateAvatar(self.avatar) avatarSet = True if name: - self.updateNickname(e.__str__()) + self.updateNickname(name) if not avatarSet: self.legacycon.updateAvatar() # Default avatar From [EMAIL PROTECTED] Sat Apr 29 11:12:04 2006 From: [EMAIL PROTECTED] (Pedro Melo) Date: Sat Apr 29 11:12:15 2006 Subject: [py-transports] PyMSNt Fullname for MSN nickname In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Hi, JEP-0172, User nickname, is in the Last Call... I suppose that if it gets through thats the one pymsnt and probably all other py* transport will use, right? Best regards, On Apr 28, 2006, at 9:11 PM, Lars T. Mikkelsen wrote: > Hi Maarten, > > On Thu, Apr 27, 2006 at 08:47:24PM +0200, Maarten Fonville wrote: >> I suspect that the problem could be that the nickname field has been >> send after the fullname field and so the name will be empty(!) and so >> the updateNickName method will use the JID user part for nickname. > > I checked the vCard sent by the Google Talk server, and it does in > fact > not contain a <NICKNAME/> element. However, I agree that there > might be > an issue if the vCard contains an empty <NICKNAME/> after an non-empty > <FN/>. > > I found a bug a couple of lines below the snippet you posted, that > prevents the nickname from being set properly in some cases. The > attached patch fixes the issue. > >> James, could you please fix this, I suspect that putting an "not name >> and " part before the NICKNAME 'if' will do the trick > > By doing this we'll lose the priority of <NICKNAME/> over <FN/> if the > vCard contains an <FN/> after the <NICKNAME/>. > > Best regards, > Lars > <update-nickname.patch> > _______________________________________________ > py-transports mailing list > [email protected] > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports -- HIId: Pedro Melo SMTP: [EMAIL PROTECTED] XMPP: [EMAIL PROTECTED]
