<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 11 February 2015 at 13:27,  <span dir="ltr"><<a href="mailto:lukas@zauberstuhl.de" target="_blank">lukas@zauberstuhl.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, I am new and I hope that is the right mailing list for questions like this.<br>
<br>
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.<br>
<br>
How can he send the `db:verify` to an other server without having a established connection?<br>
<br></blockquote><div><br></div><div>Short version:</div><div><br></div><div>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.</div><div><br></div><div>Longer version:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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@</div><div><br></div><div>Dave.</div></div></div></div>