Re: TCPIP Services SMTP, RBLs blocking all inbound email
- From: david20@xxxxxxxxxxxxxxxx
- Date: Fri, 25 May 2007 12:35:09 +0000 (UTC)
In article <1180025236.288730.273060@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Rich Jordan <jordan@xxxxxxxxxxx> writes:
On May 24, 10:54 am, Sam Hoblit <shob...@xxxxxxxxx> wrote:It probably just indicates that it was unable to find
There was NO notification of this (the customer service rep confirmed
that). She did provide a workaround... set a *.mydomain.com CNAME
pointing to 'anything' (we pointed it to the website address). Have
to wait to see if it works. And then decide if its time to change
registrars and service providers again.
Thanks for digging into this. I looked at it briefly, but didn't find
anything and just gave up. Luckily, spam isn't a real problem for us,
so I just turned off RBLs. If your workaround works, please let us
know.
Workaround stops having random subdomain.mydomain.com from pointing to
their ad site; any undefined subdomain now resolves to the domain
website, which is acceptable (we can still define any particular
subdomain, like ftp or whatever, to point where we want).
The problem with RBLs is not fixed.
Perhaps this is a different problem. I've got three sites I'm testing
right now.
First is on megapath using domains registered at domaindiscover.com.
One Alpha running email, a second doing website, DNS resolution
provided by megapath servers, with domain DNS provided by
domaindiscover. TCPIP V5.5 eco 1, VMS V8.2
Second is on Cimco, registered with Dotster. One Alpha running web/
email, several PCs doing other stuff. DNS resolution provided by
Cimco servers, with domain DNS provided by dotster. TCPIP V5.4 eco 6,
VMS V7.3-2
Third is on Cbeyond circuit, registered with Dotster. One Alpha with
email, one VAX (Process Software TCPWare V5.6-2) with email, PCs doing
other stuff. DNS resolution provided by CBeyond servers, domain DNS
provided by dotster. TCPIP V5.4 eco 6, VMS V7.3-2
Sample lookups below (##.##.##.##.zen.spamhaus.org or sbl or xbl) do
have the octets in reverse order per JF's example.
On site 2 and 3, if I do an NSLOOKUP on spamhaus
##.##.##.##.zen.spamhaus.org the response comes back positive for
##.##.##.##.zen.spamhaus.org.mydomain.com pointing to the wildcard
CNAME address (the website). I do NOT know why the .mydomain.com is
being appended; that was not happening last week.
##.##.##.##.zen.spamhaus.org and the resolver then tried it as a short-form
name and therefore tried adding on your domain.
Without the wildcard for your domain that lookup would also have failed.
However now it will return the wildcard.
For nslookup you should be able to just overcome the problem by putting a dot
at the end ie
##.##.##.##.zen.spamhaus.org.
Putting a dot at the end should stop the resolver from attempting to fix-up the
problem with search-list entries etc
Hopefully you should be able to do the same in the configuration file for the
RBL lookups.
ie instead of specifying
zen.spamhaus.org
specify
zen.spamhaus.org.
David Webb
Security team leader
CCSS
Middlesex University
I can do the NSLOOKUP on site 3 from either the VAX or the Alpha.
(different stacks) and get the same result, which really makes me
believe that it cannot be the NSLOOKUP utility that is erroneously
appending the 'ccs4vms.com' to the lookup request. Ditto with a PC,
if it is set to use external DNS servers for resolution; all spamhaus
lookups come back positive with an address pointing to the domain
website (the wildcard alias).
A couple of other sites running Dotster domains and their DNS domain
service exhibit similar behavior.
On site 1, I can do the same NSLOOKUP and get the expected nonexistent
host/domain message. If I re-aim a PC at the external DNS servers at
location 2 or 3 I get the exact same response to the spamhaus request.
The basic configuration of TCPIP on all Alpha systems is identical
except for the domain name, DNS resolution servers, and default route
gateway.
I'm back to calling Dotster; its the one point of commonality, and
their workaround, while it definitely helped by getting rid of the ad-
site linkpages still isn't allowing the RBL lookups to work (though I
still don't see how their DNS servers being set up that way prevents
us from doing the lookups...)
- References:
- Re: TCPIP Services SMTP, RBLs blocking all inbound email
- From: JF Mezei
- Re: TCPIP Services SMTP, RBLs blocking all inbound email
- From: Rich Jordan
- Re: TCPIP Services SMTP, RBLs blocking all inbound email
- From: Sam Hoblit
- Re: TCPIP Services SMTP, RBLs blocking all inbound email
- From: Rich Jordan
- Re: TCPIP Services SMTP, RBLs blocking all inbound email
- Prev by Date: [TCPIP] SET HOST/TELNET
- Next by Date: Re: recognizing newly created device on HSG80
- Previous by thread: Re: TCPIP Services SMTP, RBLs blocking all inbound email
- Next by thread: OpenVMS 2007 Bootcamp
- Index(es):
Relevant Pages
|
