Packet Relay? No, thanks

During my development of a multicast service for ejabberd that implements XEP33: Extended Stanza Addressing, I found a phrase that catch my attention:

The server MAY choose to limit whether non-local servers can send address headers that require the local server to send to third parties (relaying).

Packet relay: server A wants to send a packet to server B. Instead of simply doing that, he sends a packet to server C requesting him to resend it (relay it) to server B.

Why should a public Jabber server accept orders from another Jabber server to send packets to a third Jabber server?

This feature may or may not be useful on open networks (like the XMPP Federation), and may or may not on private networks. But I think that packet relay does not solve any critical problem right now, and instead it brings many new undesired problems.

Just to name one problem related to packet relay: abuse to send spam. You just need to see what happened to email relay.

I've removed all support for packet relay on my implementation for ejabberd. I proposed to describe packet relay support as an optional feature on XEP33, and discourage its usage on open networks.

If a server developer wants to implement it, ok, implement it. If a Jabber server admin needs that feature for some reason on his private network, ok, enable it. But I think there are more important features that I must implement during this GSoC project than packet relay.

Please post a comment if you would like to have packet relay support on ejabberd's multicast service. If so, explain why you find that feature useful.

Related links: MUC logs.