DNS report on my exchange server?

After screwing up a few minor settings recently I'm checking out my
exchange 2000 server installation. Its been stable for several years and
had its first reboot in 18 months yesterday. I've found nothing further
amiss apart from some results from DNSreport.com? When sbs was installed
I ran some dnsreports test and these 'errors' did not occur. Since then
I've changed ISP.

errors are;

1/ mailserver appearing to be xxx.domainname.local and not .com?
2/ mail in domain literal form not accepted?
3/ no spf record?

So, .local instead of .com? I remember some ambiguity on how that should
be set up and its working now. Should I try to change it?

Domain literal isn't used by anyone I know sending mail to us so should I
ignore it..

SPF? huh. factor 30 or what?.. I see this was targeted for onctober 1. It
might explain why a couple of my mails recently to a large organisation
seemed to not make it although a delivery receipt was received. What's
everyone else doing with SPF? The 'install' procedure seems a bit of a
hack and the SPF wizard won't produce a record for my domain...

Comments appreciated..




Specific message texts;

1/

'WARNING: One or more of your mailservers may be 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). This probably won't
cause any harm, but may be a technical violation of RFC821 4.3 (and
RFC2821 4.3.1).

xxx.domainname.com claims to be host xxx.domainname.local'


and 2/

'WARN: 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.

xxx.domainname.com's postmaster@[66.14.182.253] response:
>>> RCPT TO:<postmaster@[66.14.182.253]>
<<< 550 5.7.1 Unable to relay for postmaster@[66.14.182.253]'


and finally 3/

'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).'

Javier
Thu Oct 14 10:16:43 CDT 2004

Hi Jeff!

First of all-> 18 months without a reboot???? I think you must not be
patching your box.

> So, .local instead of .com? I remember some ambiguity on how that should
> be set up and its working now. Should I try to change it?

This is something that the SBS2k wizards didn't do well... but it is easy to
fix. The problem is that the EHLO greeting of your Exchange box is using its
internal dns name. You can fix this by going to Exchange system manager->
Servers-> %servername%-> Protocols-> SMTP-> Default Virtual SMTP Server->
Properties-> Delivery tab-> Advanced-> Fully Qualified Domain name: change
it to the exact name that appears in your MX records (i.e.
mail.yourdomain.com).

This is more critical if you are using DNS than with smarthost.

> Domain literal isn't used by anyone I know sending mail to us so should I
> ignore it..

Ignore it.

> SPF? huh. factor 30 or what?.. I see this was targeted for onctober 1. It
> might explain why a couple of my mails recently to a large organisation
> seemed to not make it although a delivery receipt was received. What's
> everyone else doing with SPF? The 'install' procedure seems a bit of a
> hack and the SPF wizard won't produce a record for my domain...

Just because dnsreports.com added the SPF check it doesn't mean that it
implemented. I have been researching this for a while and this is what I
came up with:

SPF is not totally implemented by anyone right now... that means that if you
do not have the record nobody is going to block mail because of that.
However, some ISPs (a small group) are doing SPF checks... so if you *do
have* SPF records they must be correct otherwise you could loose mail.

Frankly, I wouldn't worry about SPF records at the moment (it will take at
the very least a year to get this working). However, if you do want to add
them it is pretty easy (if you can add TXT records to your public DNS)... we
can help you do this if you are interested, but we would need more info
about your setup.

--
Javier [SBS MVP]

<< SBS ROCKS!!! >>

Lanwench
Fri Oct 15 09:57:38 CDT 2004

Javier Gomez [SBS MVP] wrote:
> Hi Jeff!
>
> First of all-> 18 months without a reboot???? I think you must not be
> patching your box.

Ayuh!
>
>> So, .local instead of .com? I remember some ambiguity on how that
>> should be set up and its working now. Should I try to change it?
>
> This is something that the SBS2k wizards didn't do well... but it is
> easy to fix. The problem is that the EHLO greeting of your Exchange
> box is using its internal dns name. You can fix this by going to
> Exchange system manager-> Servers-> %servername%-> Protocols-> SMTP->
> Default Virtual SMTP Server-> Properties-> Delivery tab-> Advanced->
> Fully Qualified Domain name: change it to the exact name that appears
> in your MX records (i.e. mail.yourdomain.com).
>
> This is more critical if you are using DNS than with smarthost.

Yes, but this is not mandatory at all - I have never had a need to change
the masquerade name.
>
>> Domain literal isn't used by anyone I know sending mail to us so
>> should I ignore it..
>
> Ignore it.
>
>> SPF? huh. factor 30 or what?.. I see this was targeted for onctober
>> 1. It might explain why a couple of my mails recently to a large
>> organisation seemed to not make it although a delivery receipt was
>> received. What's everyone else doing with SPF? The 'install'
>> procedure seems a bit of a hack and the SPF wizard won't produce a
>> record for my domain...
>
> Just because dnsreports.com added the SPF check it doesn't mean that
> it implemented. I have been researching this for a while and this is
> what I came up with:
>
> SPF is not totally implemented by anyone right now... that means that
> if you do not have the record nobody is going to block mail because
> of that. However, some ISPs (a small group) are doing SPF checks...
> so if you *do have* SPF records they must be correct otherwise you
> could loose mail.
>
> Frankly, I wouldn't worry about SPF records at the moment (it will
> take at the very least a year to get this working). However, if you
> do want to add them it is pretty easy (if you can add TXT records to
> your public DNS)... we can help you do this if you are interested,
> but we would need more info about your setup.

Jeff
Tue Oct 19 09:33:49 CDT 2004

Thank you to all who replied. I've decided to leave the EHLO greeting
because it's not causeing any problems other than from dnsreports.. Ditto
with the domain literals.

This SPF thing is another matter though. I've a couple of correspondants
who are in large organisations who appear to have put spf in place. One
here in the US and one located in the UK but US owned. Mail to them get's
'lost'. Receive receipt indicated the mailserver received the mail. but no
read reciept and the mail account doesn't get the mail - until I put in the
spf record and then all's well? Doesn't seem quite right but now all mails
being received..

And to javier - yup, to my shame It didn't get rebooted until I had a
problem and then a whole boat load of fixes went on so its all up to date
now.