[Standards] RFC vs privacy lists
asterix at lagaule.org
Thu Apr 28 07:52:21 UTC 2011
Le 28/04/2011 00:24, Florian Zeitz a écrit :
> Am 27.04.2011 23:43, schrieb Florian Zeitz:
>> Am 27.04.2011 23:28, schrieb Yann Leboulanger:
>>> No, the outgoing iq is not blocked, but the reply is.
>>> So a client sends an iq, but nver get an answer, which is against the
>> As you pointed out yourself, and as Remko has pointed out is defined in
>> XEP-0016 on decent servers the client DOES get a reply. A
>> service-unavailable reply, but still a reply.
>> You are in fact right that privacy lists allow you to shoot yourself in
>> the foot in this regard. If you block all incommig IQs ALL of them are
>> going to be blocked, including the ones from your server. If that's not
>> what you want whitelist the server, I'm not really sure what the problem
> <opens mouth, inserts foot>
> Okay, so I see where you're coming from now. And it is in fact a problem.
> Strictly following XEP-0016 when a client sends a type get/set IQ to
> it's server, the server should send itself an error IQ and the client
> would never see an answer.
> Now, one might argue that expecting an answer from someone you have
> blogged from sending you one is a stupid idea. That's not entirely
> wrong, but still clashes with the RFCs.
And worth: I don't know that it's blocked. If I use tkabber, set their
anti-spam rule, then I use Gajim, it cannot even know that my server
supports privacy rules because it doesn't reply to disco#info.
> The easiest way to fix this (IMHO) is probably to send the user a type
> error IQ whenever he is trying to send a type get/set one to a JID that
> is blocked from answering.
> That does not fix your problem however and I maintain that the solution
> to that is to allow entities that you want to receive IQs from to send
> you IQs :).
That will partialy solve my problem: At least I'll get an iq error and
it'll be ok with RFC.
And then yes, I'll contact tkabber devs to whitelist the server in their
More information about the Standards