Re: How to communicate between Receiving and Authoritative server

On 11 February 2015 at 13:27, <[email protected]> wrote:

> Hi, I am new and I hope that is the right mailing list for questions like
> this.
>
> According to XEP-0220 the Authoritative-Server receives via a new
> connection `db:verify` and sends a go or no-go back to the Receiving-Server.
>
> How can he send the `db:verify` to an other server without having a
> established connection?
>
>
Short version:

The authentication only affects "stanzas" - the routable elements,
<message/>, <presence/>, and <iq/>, so dialback elements aren't affected by
this and can be sent even if the session isn't authenticated.

Longer version:

When the Receiving server sends the Authoritative server a <db:verify/>, it
is actually making the assertion that it has authenticated the
Authoritative server to be the authority for a particular domain, and as
such is giving the Authoritative server permission to send <db:verify/>
responses for that domain. So you can't send a <db:verify/> result unless
you've received that permission.

In principle, an Authoritative server could reasonably just send any old
stanzas once it's received a <db:verify/>, since after all if it's the
authority it may as well - but this isn't done (and will break/confuse
servers by sending stanzas in the "wrong" direction anyway). All this is
mostly because dialback wasn't really treated as a "proper" authentication
method, and wasn't really analysed, and despite it working really well for
years, the community just didn't understand it - as such, there's a lot of
weird choices in the system. The one-way directionality of S2S is just one
case of this.

As such, if you're looking at all this with a fresh pair of eyes and
thinking it doesn't make sense, you're right - and between XEP-0288 and
XEP-0344, you might find some attempts to clean this up a bit. More input
is always welcome, on standards@

Dave.

_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________