locked
FQDN in the Default SMTP Virtual Server Properties of Exchange 2003 RRS feed

  • Question

  • Chaps,

    I have a problem.  I have a server called bing.ling.local hence my machine is called bing.

    I use two ISPs to send email, Demon UK and EasyNet. 

    What has happened recently is that I could not send emails to a particular domain (I cannot disclose this domain), since the message it came up with was:

     

    You do not have permission to send to this recipient.  For assistance, contact your system administrator.

    <bing.ling.local #5.7.1 smtp;554 5.7.1 <bing.ling.local>: Helo command rejected: Host not found>

     

    The strange issue is that the above message would come back to the sender intermittently.

     

    The FQDN in Exchange 2003's SMTP Virtual Server was set to:  bing.ling.local.  It has been since 2006, and we have not had a single problem with any other recipient.  The recipients we deal with are large PLCs in the UK.

     

    Anyway, to cut a long story short, someone suggested that we should change the FQDN to mailserver.<domainname> so if our domain name was bloggs.com then the suggestion was mailserver.bloggs.com.

     

    The setting in the FQDN has been changed to mailserver.bloggs.com and we do not have the issue at all.

     

    Can someone now tell me what the Exchange Server best practices are for settting this value?

     

    Someone suggested that the rDNS on our ISP is set to something completely different, i.e. <accountname>.adsl.demon.co.uk so this should be used in the FQDN, even though it does not check correctly when I press the check button.

     

    Can someone please help as this remains a big mystery and I am tearing my hair out.

     

    Personally I think that the recipient who had the problem changed their anti-spam device and blamed the FQDN on our Exchange Server, but that is just me....I am open to an expert opinion.

     

    Thanks,

     

    SC

    Thursday, November 13, 2008 5:33 PM

Answers

  • Hi,

     

    Maybe you are not fully understand the processing of transport in Exchange 2003. In fact, the connector is not necessary. It is just the tool to be used for doing some restrictions. The final delivery is via SMTP Virtual Server because the connector has to be associated with Bridgehead that is SMTP Virtual Server.

     

    To better understand that, please view the document as below link:

    http://technet.microsoft.com/en-us/library/aa997477.aspx

     

    Thanks

     

    Allen

    Wednesday, November 19, 2008 9:06 AM

All replies

  • Hi,

     

    This issue may occur if the remote server have enabled "Reverse DNS" feature on the anti-spam device or email server.

     

    Please understand that when we sending the email, the FQDN of the SMTP Virtual Server will be added into message header which represents the source of the email come from.

     

    If the "Reverse DNS" has been enabled, the remote server first use the IP address of the message header to query the PTR record of your email server in the DNS, then compare it to the FQDN in the message header, verify whether the two records are matching. If not same, it will recogize the email is spam email and reject it.

     

    Because the original FQDN of the SMTP virtual server was bing.ling.local, that is internal name not the public name which registered in DNS. So, that causes the remote server which enabled "reverse DNS" failed to resolve your exchange server.

     

    Thus, we must use the public name which registered in DNS and had PTR record.

     

    Thanks

     

    Allen

    Monday, November 17, 2008 7:15 AM
  • I think that this is wrong.

     

    The Default SMTP Virtual Server is to handle internal mail and the usual free/busy in Exchange.  There is a TechNet article which explicitly says that a connector needs to be created so that you separate the outbound external email traffic away from the SMTP virtual server.

     

    The sender got a message back:  Helo command rejected.  Host not found.

     

    This could be because of two things:

     

    1) the recipient's mailserver does not accept HELO, but EHLO which the connector does by default, is this correct?

    2) the recipient's mailserver may be temporarily offline if the server's MX records which are pointing at the server itself has a comms issue, correct?

     

    Only Exchange can send back to the sender this NDR with the info, so when the recipient says that the mail has never hit their exchange server they will need to analyse their logs, especially their NetMon.

     

    Please can you confirm the above is correct.

     

    S

     

    Tuesday, November 18, 2008 2:31 PM
  • Hi,

     

    Maybe you are not fully understand the processing of transport in Exchange 2003. In fact, the connector is not necessary. It is just the tool to be used for doing some restrictions. The final delivery is via SMTP Virtual Server because the connector has to be associated with Bridgehead that is SMTP Virtual Server.

     

    To better understand that, please view the document as below link:

    http://technet.microsoft.com/en-us/library/aa997477.aspx

     

    Thanks

     

    Allen

    Wednesday, November 19, 2008 9:06 AM