Subject: Wildcards

From: "Hector Santos" <[email-masked]>
Date: Thu, 17 Jun 2004 12:48:14 -0400

I got an interesting report from a blackberry customer that highlighted a
bug in our MCEP support.

The domain in question was nextel blackberry.net    We support SPF and MCEP.

For SPF, the TXT record returns:

d:\wc5beta>nslookup -query=txt   nextel.blackberry.net

Non-authoritative answer:
nextel.blackberry.net   text =

        "Standard MX Record"

blackberry.net  nameserver = xns01lhr.rim.net
blackberry.net  nameserver = xns01ykf.rim.net
xns01ykf.rim.net        internet address = 206.51.26.10

For a _EP lookup:

d:\wc5beta>nslookup -query=txt   _ep.nextel.blackberry.net

Non-authoritative answer:
_ep.nextel.blackberry.net       text =

        "Wildcard MX Record"

blackberry.net  nameserver = xns01ykf.rim.net
blackberry.net  nameserver = xns01lhr.rim.net
xns01lhr.rim.net        internet address = 193.109.81.21
xns01ykf.rim.net        internet address = 206.51.26.10

The BUG was that we didn't check for a "<ep" initial characters before
running it in the XML processor.  This was fixed, but the fact that there
was a response to a _EP subdomain lookup forced an initial FAIL assumpton
for this domain policy (i.e., corrupted record).

In other words, SPF has no prefix.  So checking for a V=SPF1 directive is
mandatory.

For MCEP, a prefix _ep. was presumed (incorrectly by me) to be unique.

How is MARID going to address issues like this?   Yes, the client will need
to check for correct records,  but is there going to be a exclusive prefix
that suggest a incorrect record means the sender should be rejected or
anything of that nature?

PS:  Apparently,  blackberry is experimenting with something,  any subdomain
lookup will return the "wildcard MX record" response.

d:\wc5beta>nslookup -query=txt   _foobar.nextel.blackberry.net

Non-authoritative answer:
_foobar.nextel.blackberry.net   text =

        "Wildcard MX Record"

blackberry.net  nameserver = xns01lhr.rim.net
blackberry.net  nameserver = xns01ykf.rim.net