SMTP instance fully-qualified domain name does not match DNS resol

We can't send and receive e-mail "out the house"...it only works on the
intranet.
I ran the exchange "troubleshooting assisant", it says:

Server: PRO-SERVER

SMTP instance fully-qualified domain name does not match DNS resolved
server name Server: PRO-SERVER
The fully-qualified domain name of SMTP virtual server 'Default SMTP
Virtual Server' on server pro-server does not match the DNS resolved server
name. This may cause mail routing problems. SMTP virtual server: domaine.dk.
DNS resolved server name: pro-server.domaine.local

What to do?

 

Run an ipconfig /all from this server & post the output. Did you run the
CEICW to configure everything, including your Exchange? Do you have a static
public IP? Registered domain name?

 

That's completely irrelevant, and the two can never possibly match in a
correctly-configured SBS. It has some meaning only when the organisation
handles its own public DNS, which small organisations don't do in-house,
and which SBS isn't intended to do.

Do what Lanwench says, if there's still trouble, post the error messages
or logs, and we stand a chance of guessing what's wrong.

 

Hi
Yes i have run the CEICW.
The server have been running for 1½ year, but we have never used the Exchange.
E-mail is routed via DNS, I have sat the MX record (our ISP allow us to
control the DNS for our domaine)

Ipconfig:
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\Documents and Settings\Administrator>ipconfig -all

Windows IP Configuration

Host Name . . . . . . . . . . . . : pro-server
Primary Dns Suffix . . . . . . . : domaine.local
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : Yes
DNS Suffix Search List. . . . . . : domaine.local

Ethernet adapter Server Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
Physical Address. . . . . . . . . : 00-13-20-D5-53-D8
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 10.111.19.199
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 10.111.19.199
Primary WINS Server . . . . . . . : 10.111.19.200

Ethernet adapter Internet Network Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) PRO/1000 PM Network Connection
Physical Address. . . . . . . . . : 00-13-20-D5-53-D7
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 217.116.239.147
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 217.116.239.254
DNS Servers . . . . . . . . . . . : 217.116.227.8
217.116.227.58
Primary WINS Server . . . . . . . : 10.111.19.200
NetBIOS over Tcpip. . . . . . . . : Disabled

Thanks a lot in advance
Best regards
Henrik

 

There's more than one issue here, but we'll go step by step.

First, no NIC on either workstation or SBS should ever show any DNS
server other than the SBS internal NIC address. Everything has to use
the SBS because external DNS servers are not aware of your network AD
details. When you run the CEICW, the ISP's DNS servers can be (they do
not have to be) entered, and they will appear as forwarders to the SBS.
SBS can run without forwarders, but slightly less efficiently. Both SBS
NICs must show the SBS internal IP address only.

As far as I know, the SBS also has to be the WINS server. This question
doesn't come up often as it's very rare for an SBS network to have
another WINS server.

You have trouble with email in and out. The mechanisms are completely
separate, so it appears there are at least two problems. Is there
anything in any event log about email? Possibly not, as there is
extensive logging of SMTP separately, which is not enabled by default.
In Server Management, Advanced, Exchange, Servers, <your server>,
Protocols, SMTP, Default SMTP Virtual Server, Properties, on the General
tab, tick the Logging box, click Properties, note where the log files
will be, click the Advanced tab and tick everything. You'll need to
delete old log files occasionally, as SBS won't.

For receiving, you need a correct MX record, port 25 access to your SBS,
and for the SBS to have a policy accepting email to your public domain
name, the last two of which the CEICW should have handled. At the
moment, (11:54 UTC, 21/07/07) I can reach your SBS by telnet on port
25, so that part seems OK.

I've sent a brief message to [email protected]<domain returned by Exchange>
which appeared to be received normally, and also a standard email via
my normal mail client and server. The server log did not show any
problem in transmission, so hopefully your alias of postmaster should
now have two rather cryptic emails in his mailbox.

Your SBS IP address does not appear to have a DNS PTR record at all, not
even a generic-type one, and this may well be why you can't send email.
That needs to be set up by your ISP, which may have given you the means
to do it yourself. Ideally it should be the FQDN you use for the primary
MX record, and the FQDN of the Exchange SMTP virtual server should be
set to match this.

 

Forgot to mention it, but http://www.dnsstuff.com is a useful site
when you have email/DNS trouble.

 

Hi - can't explain how thankful I am.
I will try this when my colleges lock of their computers.

Best regards
henrik

 

Jubii...i changed the the DNS server on the external nic.
And now we can receive e-mail from the outside

I have contacted our ISP to have them set up the PRT - i'm not sure they
can/will do it, - is there a work-around if don't?

About the WINS server, should it have them same IP as the SBS internal - I'm
pretty sure that the IP come from the CEICW - i don't rembember having touch
the WINS at all.

Again, thanks a lot for your help.
(i have recieved the 2 e-mail you sendt to )


Best regards

Henrik

 

Not really, there are 'grades' of problem, and you seem to have
the worst. Many email servers look for a sender's PTR record,
some want them to match the MX record but most are happy to
find anything at all. Some email blacklists check PTR records
for 'proper' names, not just dsl-1-2-3-4.isp.net or similar.
Even with a static IP address, one of these PTRs will get you
on the SORBS blacklist, among others.

Your IP address doesn't have a PTR record at all, and any mail
server which checks PTRs won't like that. There's nothing you
can do apart from sending email via a smarthost, and presumably
if your ISP won't fix the PTR, they must have a SMTP server you
can use.

 

Now I got our ISP to set up PTR:
7.239.116.217.in-addr.arpa mail.domaine.dk

Sorry to bother you again, but I still can't send e-mails

The "MS Exchange Troubleshooting assistant" still says:

The fully-qualified domain name of SMTP virtual server 'Default SMTP Virtual
Server' on server pro-server does not match the DNS resolved server name.
This may cause mail routing problems. SMTP virtual server: domaine.dk. DNS
resolved server name: pro-server.domaine.local

Best regards
Henrik

 

As I said to start with, that is not relevant. The actual name of the
machine running Exchange, the 'DNS resolved server name', has absolutely
nothing to do with external email. This troubleshooting assistant is
extremely simplistic, and clearly intended for use in a large standard
Windows Server installation which operates its own public DNS server. It
doesn't seem to be appropriate for SBS.

Sorry, this has to be done the hard way. Before we know if there's a
routing problem, we have to know if email is getting out at all. The
first stage is the Message Tracking centre in Exchange Management,
Tools. This will show what Exchange thinks it is doing with the message.
Near the bottom of the list of events for a particular message will be:

01/02/03 01:02 SMTP: Started Outbound Transfer of Message
01/02/03 01:02 Message transferred to <receiving server> by SMTP

If these lines are not present, we might hope that an error message is
there instead.

If all looks good here, then it gets more difficult. I'll cut and paste
from a previous message:

'In Server Management, Advanced, Exchange, Servers, <your server>,
Protocols, SMTP, Default SMTP Virtual Server, Properties, on the General
tab, tick the Logging box, click Properties, note where the log files
will be, click the Advanced tab and tick everything. You'll need to
delete old log files occasionally, as SBS won't.'

These logs aren't the easiest thing in the world to decipher, and
incoming and outgoing entries are mixed. Still, at the moment there
shouldn't be much incoming, should there?

Here's a typical outgoing transaction with all log fields enabled
(both IP addresses are private as this is journalled email to another
in-house mail server). The initial connection to port 25 of the
receiving server is not logged. Some handshake commands and responses
may vary, depending on the capabilities of the two servers.

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionResponse SMTPSVC1
NEWSERVER - 25 - -
220+debian.domain.com+ESMTP+Exim+4.50+Thu,+26+Jul+2007+01:02:18++0100 0
0 76 0 110 SMTP - - - -
(receiving server identifies itself)

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionCommand SMTPSVC1
NEWSERVER - 25 EHLO - domain.com 0 0 4 0 110 SMTP - - - -
(sending server identifies itself: really, the EHLO string should match
the MX and PTR records rather than just be the domain name, but this SBS
sends via smarthost and it doesn't matter too much. You may want to
alter the Exchange FQDN string to match the MX anyway, but I'd have
thought that at least some servers wouldn't be too fussy if they see the
right domain name here, as you have)

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionResponse SMTPSVC1
NEWSERVER - 25 - - 250-debian.domain.com+Hello+newserver+[192.168.1.2] 0
0 58 0 110 SMTP - - - -
(receiving server accepts connection, notes IP address of sender)

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionCommand SMTPSVC1
NEWSERVER - 25 MAIL - FROM:<>+SIZE=1077 0 0 4 0 110 SMTP - - - -
(size of message: not mandatory, but polite)

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionResponse SMTPSVC1
NEWSERVER - 25 - - 250+OK 0 0 6 0 110 SMTP - - - -
(OK, we'll accept one that big)

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionCommand SMTPSVC1
NEWSERVER - 25 RCPT - TO:<> 0 0 4 0 110 SMTP -
- - -
(recipient email address)

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionResponse SMTPSVC1
NEWSERVER - 25 - - 250+Accepted 0 0 12 0 110 SMTP - - - -
(OK, we'll accept mail for them: either they have a mailbox here or we
agree to relay for them)

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionCommand SMTPSVC1
NEWSERVER - 25 DATA - - 0 0 4 0 110 SMTP - - - -
(ready to send, are you ready to receive?)

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionResponse SMTPSVC1
NEWSERVER - 25 - -
354+Enter+message,+ending+with+"."+on+a+line+by+itself 0 0 54 0 110 SMTP
- - - -
(go ahead)

[data is now sent with the trailing empty line and .]

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionResponse SMTPSVC1
NEWSERVER - 25 - - 250+OK+id=1IDqo6-0006Lh-Ns 0 0 26 0 125 SMTP - - - -
(OK, we got it: here's a message ID to quote if there's trouble)

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionCommand SMTPSVC1
NEWSERVER - 25 QUIT - - 0 0 4 0 141 SMTP - - - -
(that's all for now)

2007-07-26 00:02:18 192.168.1.252 OutboundConnectionResponse SMTPSVC1
NEWSERVER - 25 - - 221+debian.domain.com+closing+connection 0 0 47 0 141
SMTP - - - -
(OK, bye for now)

The exact messages vary as they are configurable in each mail server,
but you can tell a good response from an error message very easily.

Then some detective work. If the receiving server refuses the message
for any reason, there will be a brief explanation here, and you can
contact the server's admin (worth trying [email protected], they are
supposed to monitor that address) for the exact reason for refusal.
If [email protected] doesn't work, you'll need to track down their domain
administration using the appropriate whois service. Use any of them,
if you get the wrong one it will tell you the correct one. The European
one is at http://www.ripe.net/whois. If the transaction didn't even get
as far as telling you the receiving server's IP address, you will need
to look this up via their MX record.

But if nobody is accepting your mail, the reason ought to be obvious
from several SMTP transaction logs. My guess would be that your mail
isn't even leaving your network for some fairly basic reason.

 

Hi again
The outgoing e-mails are queued.
I can see them in: Server Management/domaine
(exchange)/server/servername/Queues

I send a e-mail from to my hotmail acount
()

The Message Tracking centre says:
29-07-2007 14:15 SMTP Store Driver: Message Submitted from Store
29-07-2007 14:15 SMTP: Message Submitted to Avanced Queuing
29-07-2007 14:15 SMTP: Message Submittion to Avanced Queue
29-07-2007 14:15 SMTP: Message Submitted to Categorizer
29-07-2007 14:15 SMTP: Message Categorized and Queued for Routing
29-07-2007 14:15 SMTP: Message Routed ans Queued for remorte Delivery
29-07-2007 14:51 SMTP: Message Submitted to Avanced Queuing
29-07-2007 14:51 SMTP: Started Message Submission to Avanced Queue
29-07-2007 14:51 SMTP: Message Submitted to Categorizer
29-07-2007 14:51 SMTP: Message Categorized and Queued for Routing
29-07-2007 14:51 SMTP: Message Routed ans Queued for remorte Delivery


I have enablet the SMTP logging, but I think my log looks diffrent than the
one you paisted in your last answear - mine looks like this:

# Message Tracking Log File
# Exchange System Attendant Version 6.5.7226.0
#
Date Time client-ip Client-hostname Partner-Name Server-hostname server-IP Recipient-Address Event-ID MSGID Priority Recipient-Report-Status total-bytes Number-Recipients Origination-Time Encryption service-Version Linked-MSGID Message-Subject Sender-Address


2007-7-29 4:0:21
GMT 127.0.0.1 proakra.dk - PRO-SERVER 127.0.0.1 1019 000001c7d194$fc0799b0$ 0 0 56284 1 - 0 Version:
6.0.3790.1830 - - -

2007-7-29 4:0:21
GMT 127.0.0.1 proakra.dk - PRO-SERVER 127.0.0.1 1025 000001c7d194$fc0799b0$ 0 0 56284 1 - 0 Version:
6.0.3790.1830 - - -

2007-7-29 4:0:22
GMT 127.0.0.1 proakra.dk - PRO-SERVER 127.0.0.1 1024 000001c7d194$fc0799b0$ 0 0 56284 1 - 0 Version:
6.0.3790.1830 - - -

2007-7-29 4:0:22
GMT 127.0.0.1 proakra.dk - PRO-SERVER 127.0.0.1 1033 000001c7d194$fc0799b0$ 0 0 56284 1 - 0 Version:
6.0.3790.1830 - - -

2007-7-29 4:0:22
GMT 127.0.0.1 proakra.dk - PRO-SERVER 127.0.0.1 1036 000001c7d194$fc0799b0$ 0 0 56284 1 - 0 Version:
6.0.3790.1830 - - -

2007-7-29 4:0:22
GMT 127.0.0.1 proakra.dk - PRO-SERVER 127.0.0.1 1023 000001c7d194$fc0799b0$ 0 0 56284 1 - 0 Version:
6.0.3790.1830 - - -

2007-7-29 4:0:22
GMT - - - PRO-SERVER - 1028 000001c7d194$fc0799b0$ 0 0 56284 1 - 0 - - - -

2007-7-29 12:15:19
GMT - - - PRO-SERVER - 1027 0 0 493 1 2007-7-29
12:15:19 GMT 0 - c=DK;a=
;p=PROAKRA;l=PRO-SERVER-070729121519Z-20 - EX:/O=PROAKRA/OU=FIRST
ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=ADMINISTRATOR -

2007-7-29 12:15:19
GMT - - - PRO-SERVER - 1019 0 0 493 1 2007-7-29
12:15:19 GMT 0 - - - - -

2007-7-29 12:15:19
GMT - - - PRO-SERVER - 1025 0 0 493 1 2007-7-29
12:15:19 GMT 0 - - - - -

2007-7-29 12:15:19
GMT - - - PRO-SERVER - 1024 0 0 493 1 2007-7-29
12:15:19 GMT 0 - - - - -

2007-7-29 12:15:19
GMT - - - PRO-SERVER - 1033 0 0 493 1 2007-7-29
12:15:19 GMT 0 - - - -

2007-7-29 12:15:19
GMT - - - PRO-SERVER - 1034 0 0 493 1 2007-7-29
12:15:19 GMT 0 - - - -

2007-7-29 12:19:39
GMT - - - PRO-SERVER - 1027 0 0 485 1 2007-7-29
12:19:39 GMT 0 - c=DK;a=
;p=PROAKRA;l=PRO-SERVER-070729121938Z-21 - EX:/O=PROAKRA/OU=FIRST
ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=ADMINISTRATOR -

2007-7-29 12:19:39
GMT - - - PRO-SERVER - 1019 0 0 485 1 2007-7-29
12:19:39 GMT 0 - - - - -

2007-7-29 12:19:39
GMT - - - PRO-SERVER - 1025 0 0 485 1 2007-7-29
12:19:39 GMT 0 - - - - -

2007-7-29 12:19:39
GMT - - - PRO-SERVER - 1024 0 0 485 1 2007-7-29
12:19:39 GMT 0 - - - - -

2007-7-29 12:19:39
GMT - - - PRO-SERVER - 1033 0 0 485 1 2007-7-29
12:19:39 GMT 0 - - - -

2007-7-29 12:19:39
GMT - - - PRO-SERVER - 1034 0 0 485 1 2007-7-29
12:19:39 GMT 0 - - - -

2007-7-29 12:51:9
GMT - - - PRO-SERVER - 1019 0 0 485 1 2007-7-29
12:19:39 GMT 0 - - - -

2007-7-29 12:51:9
GMT - - - PRO-SERVER - 1019 0 0 493 1 2007-7-29
12:15:19 GMT 0 - - - -

2007-7-29 12:51:9
GMT - - - PRO-SERVER - 1025 0 0 485 1 2007-7-29
12:19:39 GMT 0 - - - -

2007-7-29 12:51:9
GMT - - - PRO-SERVER - 1024 0 0 485 1 2007-7-29
12:19:39 GMT 0 - - - -

2007-7-29 12:51:9
GMT - - - PRO-SERVER - 1033 0 0 485 1 2007-7-29
12:19:39 GMT 0 - - - -

2007-7-29 12:51:9
GMT - - - PRO-SERVER - 1034 0 0 485 1 2007-7-29
12:19:39 GMT 0 - - - -

2007-7-29 12:51:9
GMT - - - PRO-SERVER - 1025 0 0 493 1 2007-7-29
12:15:19 GMT 0 - - - -

2007-7-29 12:51:9
GMT - - - PRO-SERVER - 1024 0 0 493 1 2007-7-29
12:15:19 GMT 0 - - - -

2007-7-29 12:51:9
GMT - - - PRO-SERVER - 1033 0 0 493 1 2007-7-29
12:15:19 GMT 0 - - - -

2007-7-29 12:51:9
GMT - - - PRO-SERVER - 1034 0 0 493 1 2007-7-29
12:15:19 GMT 0 - - - -

2007-7-29 12:52:12
GMT - - - PRO-SERVER - 1027 0 0 493 1 2007-7-29
12:52:12 GMT 0 - c=DK;a=
;p=PROAKRA;l=PRO-SERVER-070729125212Z-22 - EX:/O=PROAKRA/OU=FIRST
ADMINISTRATIVE GROUP/CN=RECIPIENTS/CN=ADMINISTRATOR -

2007-7-29 12:52:12
GMT - - - PRO-SERVER - 1019 0 0 493 1 2007-7-29
12:52:12 GMT 0 - - - - -

2007-7-29 12:52:12
GMT - - - PRO-SERVER - 1025 0 0 493 1 2007-7-29
12:52:12 GMT 0 - - - - -

2007-7-29 12:52:12
GMT - - - PRO-SERVER - 1024 0 0 493 1 2007-7-29
12:52:12 GMT 0 - - - - -

2007-7-29 12:52:12
GMT - - - PRO-SERVER - 1033 0 0 493 1 2007-7-29
12:52:12 GMT 0 - - - -

2007-7-29 12:52:12
GMT - - - PRO-SERVER - 1034 0 0 493 1 2007-7-29
12:52:12 GMT 0 - - - -

2007-7-29 12:52:52
GMT 65.54.246.93 bay0-omc1-s21.bay0.hotmail.com - PRO-SERVER 217.116.239.147 1019 0 0 1990 1 2007-7-29
12:52:52 GMT 0 Version: 6.0.3790.1830 - - -

2007-7-29 12:52:52
GMT 65.54.246.93 bay0-omc1-s21.bay0.hotmail.com - PRO-SERVER 217.116.239.147 1025 0 0 1990 1 2007-7-29
12:52:52 GMT 0 Version: 6.0.3790.1830 - - -

2007-7-29 12:52:52
GMT 65.54.246.93 bay0-omc1-s21.bay0.hotmail.com - PRO-SERVER 217.116.239.147 1024 0 0 1990 1 2007-7-29
12:52:52 GMT 0 Version: 6.0.3790.1830 - - -

2007-7-29 12:52:52
GMT 65.54.246.93 bay0-omc1-s21.bay0.hotmail.com - PRO-SERVER 217.116.239.147 1033 0 0 1990 1 2007-7-29
12:52:52 GMT 0 Version: 6.0.3790.1830 - - -

2007-7-29 12:52:52
GMT 65.54.246.93 bay0-omc1-s21.bay0.hotmail.com - PRO-SERVER 217.116.239.147 1036 0 0 1990 1 2007-7-29
12:52:52 GMT 0 Version: 6.0.3790.1830 - - -

2007-7-29 12:52:52
GMT 65.54.246.93 bay0-omc1-s21.bay0.hotmail.com - PRO-SERVER 217.116.239.147 1023 0 0 1990 1 2007-7-29
12:52:52 GMT 0 Version: 6.0.3790.1830 - - -

2007-7-29 12:52:53
GMT - - - PRO-SERVER - 1028 0 0 1990 1 2007-7-29
12:52:52 GMT 0 - - - -


I can't figuring out what it means?

best regards
Henrik

 

I found this in the SMTP log - i have never heard about these e-mail adresses:



should I be nervous?

regards
Henrik

#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2007-07-29 22:53:11
#Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port
cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes
cs-bytes time-taken cs-version cs-host cs(User-Agent) cs(Cookie) cs(Referer)
2007-07-29 22:53:11 220.132.164.157 217.116.239.147 SMTPSVC1 PRO-SERVER
217.116.239.147 0 HELO - +217.116.239.147 250 0 40 20 0 SMTP - - - -
2007-07-29 22:53:14 220.132.164.157 217.116.239.147 SMTPSVC1 PRO-SERVER
217.116.239.147 0 MAIL - +FROM:+<> 250 0 51 39 0
SMTP - - - -
2007-07-29 22:53:19 220.132.164.157 217.116.239.147 SMTPSVC1 PRO-SERVER
217.116.239.147 0 RCPT - +TO:+<> 550 0 0 37 5000
SMTP - - - -
2007-07-29 22:53:19 220.132.164.157 217.116.239.147 SMTPSVC1 PRO-SERVER
217.116.239.147 0 QUIT - 217.116.239.147 240 9141 58 37 5328 SMTP

 

If this is all there is, not unduly. Hinet is a fairly well-known
domain for producing spam, and this would be an attempt at relaying.
If you see another entry following this, with an outgoing message to
the RCPT address here, then worry a bit, but it's not hard to fix. It
would be ironic if a spammer was able to use your email server while
you could not.

So you've got the right log, but Exchange seems only to be queuing
email. Are there no log entries when you try to send, and an item
is added to the queue? If not, presumably something is missing in
the Exchange setup. It might be worth trying the CEICW again, and if
there is still no effect, to have a look around the Virtual SMTP
Server settings to see if anything obvious is missing. Unfortunately
there is a lot to do in Exchange, and we rely on the CEICW to do it
all. I can't give you an item-by-item list of things to look for.

 

Okay, Thanks a lot., Joe.

I have run the CEICW again, and it did not solve the problem - i will look
closer at the Virtuel SMTP server.

Best Regards
Henrik