[ejabberd] privacy lists in 2.1.6
flatworm at users.sourceforge.net
Sat Mar 26 01:33:08 MSK 2011
On Fri, Mar 25, 2011 at 05:02:49PM +0100, Badlop wrote:
> 2011/3/25 Yann Leboulanger <asterix at lagaule.org>:
> > I'm facing a problem with privacy lists in ejabberd 2.1.6.
> > In ejabberd 2.1.5, it was replying to disco#info.
> This is the relevant change:
> commit 84d4a1619b7625e00788e550bd8e86f872577fc3
> Author: Badlop <badlop at process-one.net>
> AuthorDate: Sat Oct 16 20:31:44 2010 +0200
> Check privacy of incoming IQ stanzas (EJAB-1320)
> > If I setup a rule that deny all that have subscription=none to send me iq,
> > that also prevents ejabberd to reply to my disco#info request for example.
> > And that's not conform with RFC that says that all <iq> MUST have a reply.
> But the same RFC says in
> http://xmpp.org/rfcs/rfc3921.html#rfc.section.10.2 that:
> > Privacy lists MUST be the first delivery rule applied by a server, superseding ...
I think the original poster's thought was more about some mechanism
analogous to "stateful" firewalls for IP networks.
Say, for Linux with its netfiltes/iptables stack, a typical setup
for a LAN border gateway is to:
* Block everything going from the Internet to LAN;
* Block everything going from LAN to the Internet except for what is
* Allow traffic foing from the Internet to LAN which pertains to an
already established LAN->Internet connection as well as traffic which
"is related" to such a connection (like certain ICMP packets).
This thing is naturally implemented using what's called "connection
tracking", so presumably that's what OP was talking about.
For an XMPP server, such tracking could work this way:
* A client sends an IQ request to some other host.
* The client's server adds some kind of record to a special
tracking table, assigning a timestamp to this record.
* When the IQ response arrives, the tracking table is consulted.
If the matching record is there, it is removed and the stanza is
forwarded to the client. Otherwise the active privacy list is
consulted to decide what to do with the stanza.
The tracking table should be periodically scanned to get rid of
Of course, like with IP connection tracking, there is a problem with
resources needed to maintain this solution.
More information about the ejabberd