<div>
<br />
Hey,<br />
<br />
It sounds like you've made the change on the Receive Connector? That's the one you'll see if you telnet into the machine on port 25.<br />
<br />
However, in Exchange 2007 the FQDN for the Receive Connector can be different from the FQDN for the Send Connector. Check the values for the Send Connector, that's the important one in this case.<br />
<br />
Chris<br />

</div>


<div>
We were able to successfully telnet into mail.snsautomation.com<br />
<br />
I'm contacting our ISP to make sure our reverse DNS is pointing to the right place. &nbsp;Hopefully that will be the solution we're looking for.
</div>


<div>
<br />
Telnet will work regardless, when you do that you're connecting to the Receive Connector.<br />
<br />
The difference is extremely important.<br />
<br />
The Send Connector, under Organisation Configuration / Hub Transport (or Edge Transport) will also have a name. That name does not have to be the same name as the Receive Connector.<br />
<br />
If you expect the server to create outbound connections using the correct name you must also configure the Send Connector name.<br />
<br />
Chris<br />

</div>


<div>
<br />
You can also see the FQDN used by the Send Connector with the following command in Exchange Management Shell:<br />
<br />
(Get-SendConnector).FQDN<br />
<br />
Chris<br />

</div>


<div>
The Send Connector FQDN has been set to mail.snsautomation.com as well. &nbsp;<br />
Our internal IPs all resolve to correct naming, and we are able to send and receive mail with no problems. &nbsp;This seems to be strictly a spam flagging issue and it's very possible our ISP has something configured wrong. &nbsp;Very, very possible.
</div>


<div>
<br />
Run nslookup on your public IP Address, e.g.:<br />
<br />
nslookup 123.124.125.126<br />
<br />
If the mail server listed in your MX record is also the outbound server then the PTR (Reverse Lookup) record is fine. <br />
<br />
You don't relay out via another server? Yours sends directly?<br />
<br />
Have you looked at the header from a message sent out from your organisation to see which mail servers are listing there?<br />
<br />
Chris<br />

</div>


<div>
The nslookup resolves correctly on the public address.<br />
<br />
Yes, we send directly. &nbsp;No relaying. &nbsp;We did have some extensive hops and jumps but switched everything to direct yesterday. &nbsp;Thought the spam issue might resolve itself once the routing wasn't so complicated.<br />
<br />
I ran a DNS test and it is still coming up as an SPF record warning, even though I added &quot;v=spf1 mx ~all&quot; to our DNS table.<br />
<br />
Here is the mail header I am receiving back:<br />
<br />
ESMTP #554 Transaction Failed Spam Message not queued. ##<br />
<br />
Original message headers:<br />
<br />
Received: from mercury.sns-net.ca ([192.168.10.6]) by mercury ([192.168.10.6])<br />
&nbsp;with mapi; Wed, 16 Jul 2008 12:38:45 -0400<br />
From: xxxx@xxxx.com&gt;<br />
To: &quot;xxxxx@xxxxx.com&gt;<br />
Date: Wed, 16 Jul 2008 12:42:31 -0400<br />
Subject: Testing<br />
Thread-Topic: Testing<br />
Thread-Index: AcjnYvEm4ClxNOKzQSW6SgJW4W<wbr />XsKA==<br />
Message-ID: <br />
Accept-Language: en-US<br />
Content-Language: en-US<br />
X-MS-Has-Attach:<br />
X-MS-TNEF-Correlator:<br />
acceptlanguage: en-US<br />
Content-Type: multipart/alternative;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;boundary=&quot;_000_D471E6C02EB<wbr />42F4395F2A<wbr />C3884B6E1B<wbr />6032E9D648<wbr />3mercury_&quot;<wbr /><br />
MIME-Version: 1.0<br />

</div>


<div>
<br />
The first bit is MAPI, so not so concerning. mercury.sns-net.ca is your internal name for the server I assume?<br />
<br />
Can you get one to send out somewhere successfully then take a look at the header? We need to see your mail server in there as it's seen by others. If you don't have anywhere feel free to drop one to me, my address is in my profile, and I'll take a look at the header in that.<br />
<br />
Chris<br />

</div>


<div>
Yes, &nbsp;mercury.sns-net.ca is our internal name.<br />
<br />
I've sent you off a quick email to see if you can make any sense of the header. &nbsp;We are only getting a few of these bounce backs, so the spam filtering isn't across the board.
</div>


<div>
<div class="content wysiwyg-content">
Good morning Experts!<br />
<br />
We have a very frustrating and puzzling error occuring with our newly live Exchange 2007 server.<br />
For the past week we've been receiving SPAM flagged bounce backs accompanied by the following DNS error:<br />
<br />
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. Note that this one test may use a cached DNS record.<br />
<br />
mail.snsautomation.com claims to be invalid hostname 'mercury'<br />
<br />
In our Exchange setup, we have successfully set the Client MERCURY and Default MERCURY FQDN to mail.snsautomation.com. &nbsp;Our pings have resolved to the correct IP address. &nbsp;<br />
<br />
What setting are we missing here? &nbsp;It seems like a needle in a haystack. &nbsp;If anyone could point us in the right direction, that would be great.<br />
Thanks so much!
</div>
</div>


Good morning Experts!

We have a very frustrating and puzzling error occuring with our newly live Exchange 2007 server.
For the past week we've been receiving SPAM flagged bounce backs accompanied by the following DNS error:

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. Note that this one test may use a cached DNS record.

mail.snsautomation.com claims to be invalid hostname 'mercury'

In our Exchange setup, we have successfully set the Client MERCURY and Default MERCURY FQDN to mail.snsautomation.com.  Our pings have resolved to the correct IP address.  

What setting are we missing here?  It seems like a needle in a haystack.  If anyone could point us in the right direction, that would be great.
Thanks so much!

EHLO HELO FQDN DNS Spam Question?

Various techniques are used to prevent email spam (unsolicited bulk email). No technique is a complete solution to the spam problem, and each has trade-offs between incorrectly rejecting legitimate email (false positives) vs. not rejecting all spam (false negatives) - and the associated costs in time and effort. Anti-spam techniques can be broken into four broad categories: those that require actions by individuals, those that can be automated by email administrators, those that can be automated by email senders and those employed by researchers and law enforcement officials.

AntiSpam

The Domain Name System (DNS) is a hierarchical, globally distributed system responsible for associating the name of a computer, service or other resource into an IP address for connecting to the Internet or a private network. Most prominently, it translates domain names to the numerical IP addresses needed for the purpose of computer services and devices worldwide.

Exchange is the server side of a collaborative application product that is part of the Microsoft Server infrastructure. Exchange's major features include email, calendaring, contacts and tasks, support for mobile and web-based access to information, and support for data storage.