Solved

Exchange 2010 Receive Connector, One Server, One NIC, *.local Domain Configuration

Posted on 2012-04-06
7
2,022 Views
Last Modified: 2012-07-18
Hi,

I've have a question about the right way to configure a Receive Connector for a single Exchange 2010 Server without an Edge server.

I have a *.local internal domain name for the Microsoft domain. The default receive connector is Default EX1 and is bound to port 25 and under the "Specify the FQDN this connector will provide in response to HELO or EHLO:" I have the *.local domain. (from what you I know you don't want to mess with this).

Now I need to configure a Receive Connector for the *.com external FQDN domain so that I have a *.com domain under the field for "Specify the FQDN this connector will provide in response to HELO or EHLO:". And it will provide the correct HELO response to external queries for blacklist purposes, etc.

In configuring the second receive connector I had to configure a 2nd IP address on the same one NIC as two receive connectors can't be on the same port (port 25) with the same IP address.

This has been working for the last year in one setup but is it the correct way of doing this?

I seen examples on Microsoft's websites where there's only one receive connector but that's because they used a *.com for an internal domain name, rather than the *.local which is what I've known to use as the recommended practice.

Using a *.com domain name would eliminate the need for the second one as your HELO EHLO response field can just be your external domain name such as mail.domain.com.

I'm about to setup another network with a single Exchange server and am trying to determine if I should make it a *.com local domain or a *.local based on the above.

Thanks a bunch.
0
Comment
Question by:RFVDB
  • 4
  • 3
7 Comments
 
LVL 58

Assisted Solution

by:tigermatt
tigermatt earned 500 total points
Comment Utility
If you speak to a lot of people, they will tell you the best practice is to install an Edge Transport server. Unfortunately, most sites smaller than several thousand users do not often have the resources to run a dedicated edge network just for email delivery, so I expect that option is out for you!

The problem you will face with the "Default <Server Name>" receive connector is in its default Authentication options: Exchange Server authentication is, by default, enabled. This prevents you from changing the FQDN to a value other than the server's internal FQDN/NetBIOS name. As you would expect, Exchange Servers need to be able to communicate with each other on a network, so it is advisable to leave this default configuration enabled. Even if you are a single server setup now, you don't necessarily know when you may require the ability to talk to multiple Exchange Servers on the network.

There's no real "best practice" I'm aware of which describes how best to configure this, except using an Edge Transport server. That said, there's a number of options which I would typically opt for:
In a single-server deployment, disable Exchange Server as an authentication method on the default receive connector. This gives you the freedom to change the FQDN on the connector to a value other than the server's internal FQDN (ServerName.domain.local), but does mean you are meddling with default permissions setups
add an additional IP address and bind a receive connector with anonymous authentication to that IP, as you have done already
or, enable anonymous authentication on the default connector, don't change any other parameters, and the leave the HELO/EHLO response in the default setting (the FQDN of the server)
You may be surprised by the last possibility above, but this is an entirely possible configuration. I know of many servers which employ this set-up and have no problems sending or receiving email.

RFC 5321, at least in my interpretation, is quite loose in the regard of what should be returned in the server's 220 response at the start of the SMTP session. The most I could find is: (section 3.1)
SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems.  Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns.
and section 2.3.5:
Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP.  In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs... are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs
So, based on section 2.3.5, you may be in breach of the SMTP RFCs by not specifying the proper FQDN on your receive connector, but in my experience, this has never posed a problem - and I think the RFC is quite loose in this regard. There's nothing in the RFC (at least, nothing I can find or recall) which explicitly states the nature of the initial 220 response at the beginning of an SMTP session.

Now, all of that is for receiving. What does matter is the HELO/EHLO your server announces when sending email. In Exchange 2007 and 2010, the send and receive connectors are split, as are the FQDNs configured on them. (In Exchange 2003, the name for sending and receiving was the same, and configured on the SMTP Virtual Server). As an anti-spam technique, most anti-spam software will do a Forward-Confirmed reverse DNS (FCrDNS) check on the name you present in your HELO/EHLO announcement when sending email. It is critical, therefore, that this name is a valid, publicly resolvable name. This is what you configure on your send connector.

In all honesty, I have a couple of servers which are still configured with their default property on the receive connector, and have no issues sending and receiving email. Whether I am in breach of the RFCs, I am not completely sure, but I'm fairly convinced based on the above that I am not. What matters is that the outbound HELO/EHLO is correct, and this is set correctly on all those servers I manage.

How you go about this is entirely up to you. Adding the additional IP address is definitely a valid and acceptable method, but also increases complexity with your Exchange deployment. I've also fiddled with authentication parameters to make use of the default connector.

It's entirely up to you, but as I'm sure the above has proven, there's no 100% definite answer!

-Matt
0
 

Author Comment

by:RFVDB
Comment Utility
Hi Tigermatt,

Thanks for the VERY comprehensive answer. I just went on a long vacation as you answered and just came back. Will be reviewing this in the next couple of days and will then get back to you.

Best, Jonathan
0
 
LVL 58

Expert Comment

by:tigermatt
Comment Utility
Jonathan,

More than welcome, and no worries on the delay. Just let me know if you do have any questions and I'll be happy to answer them.

I hope you enjoyed your vacation!

-Matt
0
Don't lose your head updating email signatures!

Do your end users still have the wrong email signature? Do email signature updates bore you or fill you with a sense of dread? You can make this a whole lot easier on yourself by trusting an Exclaimer email signature management solution. Over 50 million users do...so should you!

 

Author Comment

by:RFVDB
Comment Utility
Thanks a lot for the comprehensive answer. I guess my last question revolves around the following:

1) From what I know you need to have a Reverse pointer record pointing to your outgoing SMTP Public IP address otherwise you get blacklisted? But your SMTP outgoing address doesn't have to be the same as your MX record right? Or do external mail/spam servers compare your reverse pointer IP address to the IP address or FQDN of your MX Record?

Or do they compare the header information (where it says the FQDN server info, etc.) in the email to the Reverse PTR Record?

2) Is the HELO/EHLO response on your MX record actually tested by external mail/spam servers for the correct DNS name matching your MX record - for spam reasons? Or does it not matter if it says mail.domain.local or mail.domain.com?

Thank again

Jonathan
0
 
LVL 58

Assisted Solution

by:tigermatt
tigermatt earned 500 total points
Comment Utility
Hi Jonathan,

...need to have a Reverse pointer record pointing to your outgoing SMTP Public IP address otherwise you get blacklisted?

Yes, you need to have what is known as forward-confirmed reverse DNS resolution on any public IP addresses which you issue mail to the Internet from. This means that a PTR lookup on the address should return some hostname, say outbound.domain.com. If a forward DNS lookup is then performed using that hostname, the outbound IP address should be returned again - i.e. you should be able to go full circle by looking up the PTR record and then using that result in a further A record lookup.

You do have to be careful with this though. Many ISPs will create default PTR records for IP addresses in the in-addr.arpa zone; these are often rejected by spam filtering services, even if they would otherwise satisfy the requirement above, so I would not advise keeping the in-addr.arpa PTR record if at all possible. Your ISP will be able to change it.

I was wrong on my original comment above - I said the FCrDNS needed to be on the EHLO/HELO announcement as set in your send connector, but that's incorrect! My fault. The FCrDNS is literally just using the physical IP address your server is appearing to the Internet as and performing the two DNS lookups I outlined above.

Further, while the EHLO/HELO response in your send connector does need to be a valid domain name, it is not permitted for a mail transfer agent to reject mail on the basis of a faulty EHLO/HELO header:

An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis
-- RFC 5321 (Section 4.1.4)

Of course, whether every MTA out there heeds that section of the RFC, I cannot comment. It is definitely advisable to use a valid, publicly routable domain name for your outbound HELO, which means you also satisfy the next requirement:

The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal...
-- RFC 5321

But your SMTP outgoing address doesn't have to be the same as your MX record right?

Correct. Many, many people claim that these records need to match, but there is absolutely no requirement for that to be the case. If it were, all the third-party cloud-based spam filtering services would run into problems! With those services, the customer typically routes their inbound MX to the cloud-based service, but they issue email to the Internet directly (not via the cloud service). In that case, the records would not match and so there would be all sorts of issues to contend with! In reality, this works just fine across the Internet, so this claim is supported!

Is the HELO/EHLO response on your MX record actually tested by external mail/spam servers for the correct DNS name matching your MX record - for spam reasons?

There is a system called callback verification in which a receiving server opens an SMTP session back to one of the MX records listed on the sender's email address domain, and then mimics an SMTP session to try to decipher whether the address is valid or not. However, this is a technique which I have not seen commonly used, simply due to the significant overhead it would involve on large systems - and it also has the propensity to make the checking server (which is legitimate) look like a spammer performing a dictionary harvest.

I'm not aware of any widespread use of going to the lengths of connecting back to the server listed in the sender's MX record and then explicitly checking the EHLO/HELO response sent back for validity. As per the above RFC outtakes, technically that does need to be a valid domain, but nothing can be inferred or blocked based on EHLO/HELO responses, and it would be a massive performance hit to be connecting back to sending servers all the time.

does it not matter if it says mail.domain.local or mail.domain.com?

On the inbound, my professional opinion is that it does not matter. From a strictly technical perspective, you are probably in breach of the RFC section I quoted above (domain names, where used, must be fully qualified and resolvable) but I have seen plenty of MTAs configured (even one such example which dealt with tens of thousands of messages for thousands of users on a daily basis) with their default server.domain.local on the inbound receive connector and have never had a problem.

So, strictly, it should be mail.domain.com on the inbound receive connector, but in reality, it does not cause an issue. Your outbound configuration, DNS wise, is much more critical.

I thought you might appreciate the following two screenshots which I have taken from the administrative console of my favourite anti-spam product, Vamsoft ORF. This is a product I have been using for years with massive success. There are also cloud services, including one from Microsoft, which also work really well.

The part I like about Vamsoft is that there is no "content scanning" (bayesian filters and such) - everything it uses to filter spam is based on very rigid interpretation of the RFCs. I tend to trust that the software has interpreted the RFCs correctly! Here are two outtakes from the "HELO Blacklist" and "Reverse DNS" filters:

Reverse DNS filterHELO/EHLO filter
-Matt
0
 

Author Comment

by:RFVDB
Comment Utility
Hi Matt,

Wow, thanks for the comprehensive answer. I wish I could give more than 500 points for your answers!

So basically in its most simplest form, this is what I get from the above that I would need to have in place:
1) The sending domain needs to have an MX record, whatever WAN IP that points to, we don't care - they don't do EHLO/HELO checks on the MX record.
2) The send connector's External IP however that its coming from needs to have an A record in place so that you get FCrDNS - it DOES NOT NEED TO MATCH AN MX RECORD, JUST AN A RECORD.
3) The send connector EHLO/HELO response doesn't need to match the FCrDNS, but for the sake of those off-RFC spam filters out there, why not match it. :)

Thanks a bunch!

Best, Jonathan
0
 
LVL 58

Accepted Solution

by:
tigermatt earned 500 total points
Comment Utility
Yes, that looks exactly right to me. Well done for distilling that from my verbose answers above (you've probably noticed I like to answer with lots of detail!).

Best of luck with it all and let me know if I can be of any additional assistance,

-Matt
0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

Learn to move / copy / export exchange contacts to iPhone without using any software. Also see the issues in configuration of exchange with iPhone to migrate contacts.
Scam emails are a huge burden for many businesses. Spotting one is not always easy. Follow our tips to identify if an email you receive is a scam.
This tutorial will walk an individual through the steps necessary to configure their installation of BackupExec 2012 to use network shared disk space. Verify that the path to the shared storage is valid and that data can be written to that location:…
To efficiently enable the rotation of USB drives for backups, storage pools need to be created. This way no matter which USB drive is installed, the backups will successfully write without any administrative intervention. Multiple USB devices need t…

728 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

9 Experts available now in Live!

Get 1:1 Help Now