stpeter at stpeter.im
Thu Nov 19 13:57:53 CST 2009
Hi Evgeniy, thanks for your answers.
On 11/18/09 9:59 PM, Evgeniy Khramtsov wrote:
> Peter Saint-Andre wrote:
>> How is your DNSBL built?
> Currently it is build manually, no reporting yet.
OK. My question really was: what are the criteria for adding a domain to
the blacklist? See a list of possible criteria at the end of this message.
> It is located on
> dnsbl.jabber.ru and is maintaining according to DNSxL I-D.
I assume you mean this:
And not this:
>> What are the inputs?
> The input currently is server DNS names (i.e. only s2s so far). The
> format is described in the DNSxL I-D:
>> How does the operator of an XMPP service find out if their domain or
>> IP address is listed? Do you return a particular stream error to
>> entities that are on the DNSBL?
> Those are not yet implemented. It's on my TODO list.
>> How does a service remove itself from the list? Where is the list
>> maintained and by whom?
> There is no such functionality yet. Please understand, we ran it as a
> testing service only for our purposes. However, everyone is able to
> maintain his own list. There are also software available for that
> purpose (rbldnsd for example). By the way, there is I-D available which
> discusses guidelines for the management of public DNSBLs by their
> operators - http://tools.ietf.org/html/draft-irtf-asrg-bcp-blacklists-05
Thanks for the links.
>> How does someone access the list?
> Everybody can access it via DNS client ;)
OK. How do they discover its address? I don't see an SRV record defined
for DNSBLs. Do people simply need to know that the address is
>> What if the machine on which the DNSBL is located gets hacked? Does
>> this introduce a single point of failure or attack for the XMPP network?
> If you have only one DNSBL configured in your service then, yes, you are
> in troubles. However typically, you should have multiple DNSBLs
> configured (and even weighted and ranged) to get rid of that kind of
>> Personally I would prefer a decentralized technology like XEP-0268 to a
>> centralized DNSBL.
> I read the XEP and didn't find where it is more decentralized than
In my experience with email, DNSBLs tend to become centralized (people
trust only one or two). If we can avoid that in XMPP, I would be
happier. I am especially concerned about the "arbitrary operational
decisions by blacklist operators" mentioned in
draft-church-dnsbl-harmful-01 because I have run into those for email.
> Also, as I understand the XEP only describes reporting technics.
You're right. What a service does based on reports is a matter of local
service policy. Reports could even be used as input to DNSBLs.
In general, I think we need to carefully consider whether we think
DNSBLs are helpful. Typically, blacklists work only if you have a
somewhat strong sense of identity. This is not generally the case for
email (which is why whitelists work better there), but I think that we
might be able to make DNSBLs work on the XMPP network. However, if we do
so, let's at least try to do it intelligently. I suggest that we read
draft-church-dnsbl-harmful-01 and other relevant information to arrive
at some reasonable policies and procedures.
I'd also like some feedback on my proposal for server reputations. A
server is not boolean "good" or "bad", but probably some shade of grey.
I think that a new server on the network would start with a score of
zero. Its score would go up for:
1. CA-issued certificate
2. CAPTCHA or other hurdle required for account registration
3. Support for incident reporting (XEP-0268)
4. TLS succeeds (with SASL EXTERNAL or Dialback)
5. Longevity (e.g., 1 point for each year on the network)
6. Admins answer mail sent to xmpp at domain.tld
7. Proper DNS SRV records
8. Website with contact addresses
9. Other good things (let's define these)
Its score would go down (negative) for:
1. Actively sends spam
2. Generates denial of service attacks
3. Other abusive activities (let's define these)
My main concern here is that we have objective criteria for scoring
servers, not arbitrary decisions by DNSBL operators.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Operators