Re: Help SMPT Errors

This below is the main reason why.

FAIL Reverse DNS entries for MX records ERROR: The IP of one or more of your
mail server(s) have no reverse DNS (PTR) entries (if you see "Timeout"
below,
it may mean that your DNS servers did not respond fast enough). RFC1912 2.1
says you should have a reverse DNS for all your mail servers. It is
strongly
urged that you have them, as many mailservers will not accept mail from
mailservers with no reverse DNS entry. You can double-check using the
'Reverse DNS Lookup' tool at the DNSstuff site (it contacts your servers in
real time; the reverse DNS lookups in the DNS report use our local caching
DNS server). The problem MX records are:
113.230.141.82.in-addr.arpa [No reverse DNS entry (rcode: 3 ancount: 0)

You need to ask your ISP to add a PTR record for 82.141.230.113 and map it
to mail.disability-federation.ie.

ALSO, it is recommended that your server advertise the correct name (this
was mentioned later as another warning). Go to the Default SMTP Virtual
Server properties, Delivery Tab, Advanced button, and where it shows the
Fully Qualified Domain Name, change that to mail.disability-federation.ie.

Making those 2 changes should get you squared away. The other warnings are
valid warnings, and per the RFC's, they ought to be fixed, but they won't
affect other domains not accepting mail from you.

--
Ben Winzenz
Exchange MVP
MessageOne
Read my blog!
http://winzenz.blogspot.com
http://feeds.feedburner.com/winzenz (RSS Feed)


"Aaron (ireland)" <Aaronireland@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:53D89143-961E-40C0-8E89-2DB2671EEE86@xxxxxxxxxxxxxxxx
Could you please take a look at the results;

DNS Report for disability-federation.ie
Generated by www.DNSreport.com at 11:38:12 GMT on 10 Apr 2006.
Category Status Test Name Information
Parent PASS Missing Direct Parent check OK. Your direct parent zone
exists,
which is good. Some domains (usually third or fourth level domains, such
as
example.co.us) do not have a direct parent zone ('co.us' in this example),
which is legal but can cause confusion.
INFO NS records at parent servers Your NS records at the parent servers
are:

ns2.raqbay.net. [212.147.142.51 (NO GLUE)] [IE]
dub2.raqbay.net. [212.147.142.50 (NO GLUE)] [IE]

[These were obtained from gns2.domainregistry.ie]
PASS Parent nameservers have your nameservers listed OK. When someone uses
DNS to look up your domain, the first step (if it doesn't already know
about
your domain) is to go to the parent servers. If you aren't listed there,
you
can't be found. But you are listed there.
WARN Glue at parent nameservers WARNING. The parent servers (I checked
with
gns2.domainregistry.ie.) are not providing glue for all your nameservers.
This means that they are supplying the NS records (host.example.com), but
not
supplying the A records (192.0.2.53), which can cause slightly slower
connections, and may cause incompatibilities with some non-RFC-compliant
programs. This is perfectly acceptable behavior per the RFCs. This will
usually occur if your DNS servers are not in the same TLD as your domain
(for
example, a DNS server of "ns1.example.org" for the domain "example.com").
In
this case, you can speed up the connections slightly by having NS records
that are in the same TLD as your domain.
PASS DNS servers have A records OK. All your DNS servers either have A
records at the zone parent servers, or do not need them (if the DNS
servers
are on other TLDs). A records are required for your hostnames to ensure
that
other DNS servers can reach your DNS servers. Note that there will be
problems if your DNS servers do not have these same A records.
NS INFO NS records at your nameservers Your NS records at your nameservers
are:

dub2.raqbay.net. [212.147.142.50] [TTL=86400]
ns2.raqbay.net. [212.147.142.51] [TTL=86400]


FAIL Open DNS servers ERROR: One or more of your nameservers reports that
it
is an open DNS server. This usually means that anyone in the world can
query
it for domains it is not authoritative for (it is possible that the DNS
server advertises that it does recursive lookups when it does not, but
that
shouldn't happen). This can cause an excessive load on your DNS server.
Also,
it is strongly discouraged to have a DNS server be both authoritative for
your domain and be recursive (even if it is not open), due to the
potential
for cache poisoning (with no recursion, there is no cache, and it is
impossible to poison it). Also, the bad guys could use your DNS server as
part of an attack, by forging their IP address. Problem record(s) are:
Server 212.147.142.51 reports that it will do recursive lookups. [test]
Server 212.147.142.50 reports that it will do recursive lookups. [test]


See this page for info on closing open DNS servers.

PASS Mismatched glue OK. The DNS report did not detect any discrepancies
between the glue provided by the parent servers and that provided by your
authoritative DNS servers.
PASS No NS A records at nameservers OK. Your nameservers do include
corresponding A records when asked for your NS records. This ensures that
your DNS servers know the A records corresponding to all your NS records.
PASS All nameservers report identical NS records OK. The NS records at all
your nameservers are identical.
PASS All nameservers respond OK. All of your nameservers listed at the
parent nameservers responded.
PASS Nameserver name validity OK. All of the NS records that your
nameservers report seem valid (no IPs or partial domain names).
PASS Number of nameservers OK. You have 2 nameservers. You must have at
least 2 nameservers (RFC2182 section 5 recommends at least 3 nameservers),
and preferably no more than 7.
PASS Lame nameservers OK. All the nameservers listed at the parent servers
answer authoritatively for your domain.
PASS Missing (stealth) nameservers OK. All 2 of your nameservers (as
reported by your nameservers) are also listed at the parent servers.
PASS Missing nameservers 2 OK. All of the nameservers listed at the parent
nameservers are also listed as NS records at your nameservers.
PASS No CNAMEs for domain OK. There are no CNAMEs for
disability-federation.ie. RFC1912 2.4 and RFC2181 10.3 state that there
should be no CNAMEs if an NS (or any other) record is present.
PASS No NSs with CNAMEs OK. There are no CNAMEs for your NS records.
RFC1912
2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any
other) record is present.
WARN Nameservers on separate class C's WARNING: We cannot test to see if
your nameservers are all on the same Class C (technically, /24) range,
because the root servers are not sending glue. We plan to add such a test
later, but today you will have to manually check to make sure that they
are
on separate Class C ranges. Your nameservers should be at geographically
dispersed locations. You should not have all of your nameservers at the
same
location. RFC2182 3.1 goes into more detail about secondary nameserver
location.
PASS All NS IPs public OK. All of your NS records appear to use public
IPs.
If there were any private IPs, they would not be reachable, causing DNS
delays.
PASS TCP Allowed OK. All your DNS servers allow TCP connections. Although
rarely used, TCP connections are occasionally used instead of UDP
connections. When firewalls block the TCP DNS connections, it can cause
hard-to-diagnose problems.
INFO Nameservers versions Your nameservers have the following versions:

212.147.142.51: "100.100.100"
212.147.142.50: "100.100.100"

PASS Stealth NS record leakage Your DNS servers do not leak any stealth NS
records (if any) in non-NS requests.
SOA INFO SOA record Your SOA record [TTL=86400] is:
Primary nameserver: dub2.raqbay.net.
Hostmaster E-mail address: domainhost.activeonline.ie.
Serial #: 1144074070
Refresh: 10800
Retry: 3600
Expire: 604800
Default TTL: 86400

PASS NS agreement on SOA serial # OK. All your nameservers agree that your
SOA serial number is 1144074070. That means that all your nameservers are
using the same data (unless you have different sets of data with the same
serial number, which would be very bad)! Note that the DNS Report only
checks
the NS records listed at the parent servers (not any stealth servers).

PASS SOA MNAME Check OK. Your SOA (Start of Authority) record states that
your master (primary) name server is: dub2.raqbay.net.. That server is
listed
at the parent servers, which is correct.

PASS SOA RNAME Check OK. Your SOA (Start of Authority) record states that
your DNS contact E-mail address is: domainhost@xxxxxxxxxxxxxxxx (techie
note:
we have changed the initial '.' to an '@' for display purposes).
WARN SOA Serial Number WARNING: Your SOA serial number is: 1144074070.
That
is OK, but the recommended format (per RFC1912 2.2) is YYYYMMDDnn, where
'nn'
is the revision. For example, if you are making the 3rd change on 02 May
2000, you would use 2000050203. This number must be incremented every time
you make a DNS change.

Your SOA serial appears to be the number of seconds since midnight 01 Jan
1970 when the last DNS change was made (tinydns format). That works out to
be
Mon Apr 03 10:21:10 2006 EST.
PASS SOA REFRESH value OK. Your SOA REFRESH interval is : 10800 seconds.
This seems normal (about 3600-7200 seconds is good if not using DNS
NOTIFY;
RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes
to
12 hours)). This value determines how often secondary/slave nameservers
check
with the master for updates.
PASS SOA RETRY value OK. Your SOA RETRY interval is : 3600 seconds. This
seems normal (about 120-7200 seconds is good). The retry value is the
amount
of time your secondary/slave nameservers will wait to contact the master
nameserver again if the last attempt failed.
PASS SOA EXPIRE value OK. Your SOA EXPIRE time: 604800 seconds. This seems
normal (about 1209600 to 2419200 seconds (2-4 weeks) is good). RFC1912
suggests 2-4 weeks. This is how long a secondary/slave nameserver will
wait
before considering its DNS data stale if it can't reach the primary
nameserver.
PASS SOA MINIMUM TTL value OK. Your SOA MINIMUM TTL is: 86400 seconds.
This
seems normal (about 3,600 to 86400 seconds or 1-24 hours is good). RFC2308
suggests a value of 1-3 hours. This value used to determine the default
(technically, minimum) TTL (time-to-live) for DNS entries, but now is used
for negative caching.
MX INFO MX Record Your 1 MX record is:
20 mail.disability-federation.ie. [TTL=86400] IP=82.141.230.113
[TTL=86400]
[IE]

PASS Low port test OK. Our local DNS server that uses a low port number
can
get your MX record. Some DNS servers are behind firewalls that block low
port
numbers. This does not guarantee that your DNS server does not block low
ports, but is a good indication that it does not.
PASS Invalid characters OK. All of your MX records appear to use valid
hostnames, without any invalid characters.
PASS All MX IPs public OK. All of your MX records appear to use public
IPs.
If there were any private IPs, they would not be reachable, causing slight
mail delays, extra resource usage, and possibly bounced mail.
PASS MX records are not CNAMEs OK. Looking up your MX record did not just
return a CNAME. If an MX record query returns a CNAME, extra processing is
required, and some mail servers may not be able to handle it.
PASS MX A lookups have no CNAMEs OK. There appear to be no CNAMEs returned
for A records lookups from your MX records (CNAMEs are prohibited in MX
records, according to RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181
10.3).
PASS MX is host name, not IP OK. All of your MX records are host names (as
opposed to IP addresses, which are not allowed in MX records).
INFO Multiple MX records NOTE: You only have 1 MX record. If your primary
mail server is down or unreachable, there is a chance that mail may have
troubles reaching you. In the past, mailservers would usually re-try
E-mail
for up to 48 hours. But many now only re-try for a couple of hours. If
your
primary mailserver is very reliable (or can be fixed quickly if it goes
down), having just one mailserver may be acceptable.
PASS Differing MX-A records OK. I did not detect differing IPs for your MX
records (this would happen if your DNS servers return different IPs than
the
DNS servers that are authoritative for the hostname in your MX records).
PASS Duplicate MX records OK. You do not have any duplicate MX records
(pointing to the same IP). Although technically valid, duplicate MX
records
can cause a lot of confusion, and waste resources.
FAIL Reverse DNS entries for MX records ERROR: The IP of one or more of
your
mail server(s) have no reverse DNS (PTR) entries (if you see "Timeout"
below,
it may mean that your DNS servers did not respond fast enough). RFC1912
2.1
says you should have a reverse DNS for all your mail servers. It is
strongly
urged that you have them, as many mailservers will not accept mail from
mailservers with no reverse DNS entry. You can double-check using the
'Reverse DNS Lookup' tool at the DNSstuff site (it contacts your servers
in
real time; the reverse DNS lookups in the DNS report use our local caching
DNS server). The problem MX records are:
113.230.141.82.in-addr.arpa [No reverse DNS entry (rcode: 3 ancount: 0)
(check it)]

Mail PASS Connect to mail servers OK: I was able to connect to all of your
mailservers.
WARN Mail server host name in greeting WARNING: One or more of your
mailservers is claiming to be a host other than what it really is (the
SMTP
greeting should be a 3-digit code, followed by a space or a dash, then the
host name). If your mailserver sends out E-mail using this domain in its
EHLO
or HELO, your E-mail might get blocked by anti-spam software. This is also
a
technical violation of RFC821 4.3 (and RFC2821 4.3.1). Note that the
hostname
given in the SMTP greeting should have an A record pointing back to the
same
server.

mail.disability-federation.ie claims to be non-existent host
dfisbs-pdc03.DFISBS03PDC.local:
220 dfisbs-pdc03.DFISBS03PDC.local Microsoft ESMTP MAIL Service, Version:
6.0.3790.1830 ready at Mon, 10 Apr 2006 12:37:48 +0100

PASS Acceptance of NULL <> sender OK: All of your mailservers accept mail
from "<>". You are required (RFC1123 5.2.9) to receive this type of mail
(which includes reject/bounce messages and return receipts).
FAIL Acceptance of postmaster address ERROR: One or more of your
mailservers
does not accept mail to postmaster@xxxxxxxxxxxxxxxxxxxxxxxxx Mailservers
are
required (RFC822 6.3, RFC1123 5.2.7, and RFC2821 4.5.1) to accept mail to
postmaster.
mail.disability-federation.ie's postmaster response: >>> RCPT
TO:<postmaster@xxxxxxxxxxxxxxxxxxxxxxxx> <<< 550 5.1.1 User unknown
WARN Acceptance of abuse address WARNING: One or more of your mailservers
does not accept mail to abuse@xxxxxxxxxxxxxxxxxxxxxxxxx Mailservers are
expected by RFC2142 to accept mail to abuse.

mail.disability-federation.ie's abuse response:
>>> RCPT TO:<abuse@xxxxxxxxxxxxxxxxxxxxxxxx>
<<< 550 5.1.1 User unknown


INFO Acceptance of domain literals WARNING: One or more of your
mailservers
does not accept mail in the domain literal format (user@[0.0.0.0]).
Mailservers are technically required RFC1123 5.2.17 to accept mail to
domain
literals for any of its IP addresses. Not accepting domain literals can
make
it more difficult to test your mailserver, and can prevent you from
receiving
E-mail from people reporting problems with your mailserver. However, it is
unlikely that any problems will occur if the domain literals are not
accepted
(mailservers at many common large domains have this problem).

mail.disability-federation.ie's postmaster@[82.141.230.113] response:
>>> RCPT TO:<postmaster@[82.141.230.113]>
<<< 550 5.7.1 Unable to relay for postmaster@[82.141.230.113]


PASS Open relay test OK: All of your mailservers appear to be closed to
relaying. This is not a thorough check, you can get a thorough one here.
mail.disability-federation.ie OK: 550 5.7.1 Unable to relay for
Not.abuse.see.www.DNSreport.com.from.IP.82.141.230.113@xxxxxxxxxxxxx

WARN SPF record Your domain does not have an SPF record. This means that
spammers can easily send out E-mail that looks like it came from your
domain,
which can make your domain look bad (if the recipient thinks you really
sent
it), and can cost you money (when people complain to you, rather than the
spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the
target date for domains to have SPF records in place (Hotmail, for
example,
started checking SPF records on 01 Oct 2004).
WWW
INFO WWW Record Your www.disability-federation.ie A record is:

www.disability-federation.ie. A 212.147.142.52 [TTL=86400] [IE]


PASS All WWW IPs public OK. All of your WWW IPs appear to be public IPs.
If
there were any private IPs, they would not be reachable, causing problems
reaching your web site.
PASS CNAME Lookup OK. Some domains have a CNAME record for their WWW
server
that requires an extra DNS lookup, which slightly delays the initial
access
to the website and use extra bandwidth. There are no CNAMEs for
www.disability-federation.ie, which is good.



"Ben Winzenz [Exchange MVP]" wrote:

Sounds like the domain you are sending to is performing reverse dns
lookups
and can't match the IP you are connecting with back to a valid hostname.

Do you have a valid PTR record that maps back to the A record of your
mail
server?

Run a report over at http://www.dnsreport.com and see what it says. If
there are any dns problems, it will tell you what they are.

--
Ben Winzenz
Exchange MVP
MessageOne
Read my blog!
http://winzenz.blogspot.com
http://feeds.feedburner.com/winzenz (RSS Feed)


"Aaron (ireland)" <Aaronireland@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:D84E9D0F-FF49-4502-94DC-5740C3C7C0E5@xxxxxxxxxxxxxxxx
Hi all,

Dell 1420SC>SBS2003>Exchange 2003

Can someone please explain the below error;

This is an SMTP protocol warning log for virtual server ID 1,
connection
#1545. The remote host "unknown remote ip", responded to the SMTP
command
"rcpt" with "450 Client host rejected: cannot find your hostname, [Our
public
ip of mail server". The full command sent was "RCPT
TO:<email@xxxxxxxxxx>
".
This may cause the connection to fail.

I did not include the ip and email information. Unknown host as above
was
an
ip of a system in another country and the email@doamin was connected to
that
ip when i pinged mail@xxxxxxxxxxx Finally as above our public ip was
refered
to!

Thank you.





.

Loading