Adrian Ulrich wrote:
Google doesn't send vcards to unauthorized users:
<vCard xmlns="vcard-temp" prodid="-//HandGen//NONSGML vGen v1.0//EN" version="2.0"
/>
<error type="cancel" code="503" >
<service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</error>
It seems to me that Google's service returns this error for just about
anything that isn't a presence subscription request. Google's general
approach to everything seems to be "friends only".
Well.. IMO djabberd would just need a simple configuration option such as
'SendVcardsToAnyone false'
I'm always reluctant to add new boolean options without considering
first whether they're solving the right problem, or else you get stuck
with a sea of conflicting/confusing options that all solve a problem one
person had once.
For example, you could easily come up with some additional "modes":
* Send vCards only to people in the same domain as the requestee
* Serve a different, limited vCard to unrecognized folks
* Allow each user to configure whether to make their vCard public.
* Only allow presence requests from JIDs that aren't in the
recipient's roster. (That is, extend the "in roster only" rule to apply
to many more sorts of stanzas, as Google Talk does.)
What you're describing is certainly going to be a common case, but I
think we should find an approach that isn't going to get confusing if
and when the above cases are also added.
What about something like this?
<Plugin DJabberd::Plugin::RestrictStanzaTypes>
Messages roster same-domain
VCards none
Presence all
</Plugin>
Generally this is:
SomePredefinedMessageType <all|roster|same-domain|none>
This plugin would be loaded before all of the other plugins and would
respond like your Google Talk example above when the stanza is unacceptable.
I'm not 100% wild on hard-coding "Messages", "VCards" and "Presence"
over some more general solution, but short of going crazy and allowing
netfilter-style rule chains I can't think of a good way to generalize
this in a way that doesn't make it awkward to configure the common cases.
(Of course, someone could also write something that implements
netfilter-style rule chains for the awkward cases!)
