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