Exhange 2007 - FQDN not correct in SMTP greeting, does not match reverse DNS (PTR) record

Windows Server 2008
Exchange 2007, SP3
Server Name = Exchange

I have an ISP suddenly rejecting our email.  They have said we are not sending the correct response in our SMTP greeting.  We've had no other large or small ISP's block our email.

We are replying to HELO with the name "exchange.domain.local".  Our MX record points to mail.domain.com

It seems I need to modify a Hub Transport setting to show the <.com> not <.local> FQDN.

I'm wondering about the details and what's the better approach.

- Is it best to not offer any details in an SMTP greeting.
- Where does the change need to be made?  I tested making some changes, but nothing worked.  

I have one Exchange 2007 server with Mailbox, Client Access and Hub Transport roles.

Adding a wrinkle is - we use Google Postini for inbound email filtering inbound, but we send directly outbound.

Using DNSStuff.com for testing.
----------
Internally, I telnet to the Exchange server, port 25.

HELO
250    exchange.domain.local     HELLO   [10.#.#.#]
-----------
external telnet is blocked by firewall rules
Ping mail.domain.com replies with the correct IP 209.#.#.#
-----------
from MX Toolbox

SMTP Reverse DNS Mismatch       Warning - Reverse DNS does not match SMTP Banner
-----------
DNSStuff - SMTP Greeting test, for my-address@domain.com,

Test Status:  WARNING: The hostname in the SMTP greeting does not match the reverse DNS (PTR) record for your mail server. This probably won't cause any harm, but may be a technical violation of RFC5321
----------
In Exchange
- Organizational Config - Hub Transport - Send Connectors - Exchange Internet (enabled)
     "Specify the FQDN..." is blank
- Server Config - Hub Transport
     - Client Exchange
     - Default Exchange
Both show "Specify FQDN..." as exchange.domain.local

What I tested:
- I first changed the send connector, adding mail.domain.com and restarted the MS Exchange Transport server
- Tested from DNSStuff site, got same .local result
- Second, reset send connector to null, set Client Exchange FQDN to mail.domain.com, restart transport service, tested, still get warning

Do I need to wait for my local change to update externally?  I didn't want to leave a potentially incorrect setting, then leave it overnight if it broke email processing.

I looked at MS help in Exchange and it said to NOT change the default server FQDN or I'd screw up internal email.

Any help or advise is much appreciated

Thanks - Dale