EXCHANGE 2003 gives this error: 421 SMTP service not available, closing transmission channel

Hi compinfo,

It could be one of several things.  First think you need to do is telnet to port 25 of your Exchange server from INSIDE the network.  That is, a PC on the same LAN as the Exchange server.
Details on how to do this can be found at : http://support.microsoft.com/default.aspx?kbid=153119&product=exch2k

If that works, you then need to do the same telnet test from your Linux box.

I'd guess that you'll get the above error.  If so, I'm guessing that it's a problem with the firewall and not Exchange.

The reason for this is your Exchange server would reply with something like:
421-Microsoft ESMTP MAIL Service, Version: 5.0.2195.6713 ready at Service not available, closing transmission channel

Note that it mentions that it's an MS server, and loads of other stuff?

I think that your WatchGuard is acting as an SMTP proxy server itself, and not just passing the port through.
Test reconfiguring this for simple port forwarding and see what happens then.

Let us know what happens :-)

Results:

Telnet from within the same network as the exchange server, using this command (telnet mail.mywebsite.com 25):  

"421 SMTP service not available, closing transmission channel"

Telnet from within the same network as the exchange server, using this command (telnet 192.168.16.3 25):

220 mywebsite.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.0 ready at Mon, 20 Sep 2004 14:00 -0400
(Hey, why isn't it saying 'mail.mywebsite.com' instead?)


Telnet from linux box to the exchange box, using this command (telnet 192.168.16.3 25):

Trying 192.168.16.3...
Connected to mail (192.168.16.3).
Escape character is.
220 mywebsite.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.0 ready at Mon, 20 Sep 2004 14:10 -0400

Telnet from linux box to the exchange box, using this command (telnet mail.mywebsite.com 25):

(Same as above)

________________________

What specifically should I look for on the exchange 2003 server??  Thanks!

From what you've posted, I don't think that "mail.mywebsite.com" resolves to 192.168.16.3 inside your network.
To check this, do the following (from one of the machines you tested on):
nslookup mail.mywebsite.com

That'll give you the IP address.  I'm guessing from the above that it'll return the External not Internal IP address.
This means that the telnet session will be routed through your FireBox when you use "mail.mywebsite.com".  When you use the Internal IP you'll be talking directly to the server.

Looking at this, the problem is with the configuration on your FireBox.  It's not doing the SMTP port forwarding properly.  I'm guessing that you have SMTP proxy turned on, and that's not configured correctly.  This is what you need to check.

As for why your Exchange server isn't returning "mail.mywebsite.com", you can change this:
ESM, Admin Groups, <your admin group>, Server, <your server>, Protocols, SMTP.
Right click in Default SMTP server and choose Properties. Click on the Connection tab and then Advanced. In the box "FQDN" enter "mail.mywebsite.com"

Exchange info from https://www.experts-exchange.com/questions/21130164/How-do-I-get-proper-DNS-name-response-from-Exchange-2000.html

Very interesting results:

nslookup from within the same network as the exchange server, using this command (nslookup mail.mywebsite.com):  

C:\Documents and Settings\me.domain>nslookup mail.mywebsite.com
*** Can't find server name for address 192.168.16.3: Non-existent domain
*** Default servers are not available
Server:  UnKnown
Address:  192.168.16.3

Non-authoritative answer:
Name:    mail.mywebsite.com
Address:  55.55.55.3

nslookup from linux box to the exchange box, using this command (nslookup mail.mywebsite.com):

[root@www root]# nslookup mail.mywebsite.com
Server:         66.66.66.66 (<-- actually this is my ISP's DNS primary server)
Address:        66.66.66.67#53 (<-- this is my ISP's DNS secondary server)

Non-authoritative answer:
Name:   mail.mywebsite.com
Address: 55.55.55.3
___________________

I went ahead and changed the SMTP properties on the exchange server too.

OK - I think that proves my theory about it being the WatchGuard.

Is 192.168.16.3 your domain controller/DNS?  It doesn't seem to have a reverse DNS zone set up for your internal network.

Anyway - from the above.
When you did the telnet to 192.168.16.3, you were connecting directly to the Exchange server and getting "220 mywebsite.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.0 ready at Mon, 20 Sep 2004 14:10 -0400".  This is correct

When you did the telnet to mail.mywebsite.com it was actually connecting you to 55.55.55.3.
You were then getting "421 SMTP service not available, closing transmission channel" as a response.

This presumably is the external IP of your Exchange server, which is forwarded on to the server by your Firebox?
I think that the Firebox is returning the 421 error.  This is probably a configuration issue on the Firebox itself.

Can you please confirm that 55.55.55.3 is the external address for inbound mail delivery and should be NATed to 192.168.16.3?

I'll then know if I'm barking up the wrong tree or not.

Check the config on the Firebox.  Do you have SMTP proxy enabled?

192.168.16.3 is the one and only windows SBS 2003 with exchange on it (of course).  All clients on the windows network have static IP addresses.  

55.55.55.3 is programmed in the firebox under the 'firebox interaces' aliases button.  On my exchange server, I don't believe 55.55.55.3 is programmed anywhere, it's only the private IP address.

The watchguard tech support gave me this reply:

"You cannot access mail.flyavl.com by url from the trusted (remember double NAT). You have to access it from the trusted by the Private IP address." (Because it is in DROP-IN mode as opposed to ROUTED mode on the firebox)

I have 2 SMTP 'services' enabled on the firebox, one for SMTP for the SBS 2003 and one for SMTP on the Optional (DMZ) network.  The way it reads, it should work, however, because of the statement from the watchguard tech support, they are saying that it won't work.  Here's what else watchguard is saying:

"Ok, I looked through those logs and found TCP port 25 traffic going from 192.168.16.4 to 55.55.55.3. This is correct. But following the TCP stream, I see that the error is "421 SMTP service not available, closing transmission channel".

That is the mail server shutting down that session."

What's driving me nuts is the fact that at one time, this all worked fine!  

compinfo,

I'm not greatly familiar with Watchguard configs, but will hazard a guess :-)

> "You cannot access mail.flyavl.com by url from the trusted (remember
> double NAT). You have to access it from the trusted by the Private IP
> address." (Because it is in DROP-IN mode as opposed to ROUTED mode on
> the firebox)

Right, trying to translate that into English - they're saying that you can't route from inside the network, via the Firebox, back into the network.  That makes sense.

So:
Your Internal IP for your Exchange server is 192.168.16.3
Your External (web-facing) IP for your Exchange server is 55.55.55.3
What is the IP of your webserver in the DMZ?

Also, I don't think we mentioned, I take it that inbound External SMTP email is arriving OK?  As in, email from the WAN connection of the firewall?

Ok -

IP address of the webserver in the DMZ is: 55.55.55.2.

I'm not sure I understand the 'email from the WAN connection of the firewall'?  On the firebox, I have 3 connections, 1. External - connects to the router that connects to the T-1 line, 2.  Trusted - goes to the internal 192.168.16.X network, and 3.  Optional (DMZ) - Only has the linux webserver on it.

Email is relaying fine to and from the exchange server, with the exception of email coming from the linux webserver to the exchange server.

Hope this is clear! :)

Sorry, by WAN I meant "External".  Different firewalls have different names :-)

Here's something to try.  Try setting the webserver to send emails to 192.168.16.3.  What happens?

I think you need to configure the firewall to route traffic on port 25 from the DMZ to the Trusted interface.
I can't tell you how to do that though, so you'll need to speak to Watchguard again I'm afraid.

I added this entry in the /etc/hosts file on the linux webserver:

192.168.16.3     mail.mywebsite.com

***********************

That doesn't work either...

compinfo,
> That doesn't work either...

I didn't really think it would - but thought it was worth a try.

I'm afraid you're going to have to speak to the WatchGuard people again.
What you're trying to do *ought* to work, but I've never set it up that way myself.

In this environment, I've always had the webserver sending emails through an External SMTP gateway (the ISPs smarthost).  That way I don't really need to worry about all this stuff, and if anything nasty happened to the webserver it's got no way of talking to my real network :-)

Yeah, the problem is that this is a small business server 2003 box, so we use it for file/print sharing as well as exchange, so I need to keep it 'buffered' from the outside world as much as possible.

Sorry, that's not quite what I meant.
I was suggesting configuring your Linux-based webserver to send emails directly to your ISPs smarthost.

That way it doesn't need to contact your SBS server at all.

Oh! Sorry! *blush*

I did not know that type of option was available from my ISP.  In this case, how would I go about doing it?  Since my ISP routes the 55.55.55.3 ip directly to mail.mywebsite.com through their DNS servers, I'm not sure they have smarthost's.  How would I know exactly what to ask them?  Thanks!

compinfo,
Almost all ISPs have a smarthost.  Most users use their ISPs smarthost to relay their emails.

Often they'll have this information on their web page or support pages.  If you let me know who your ISP is, I'll take a look for you.

Alternatively, contact them and ask if they've got an email smarthost.  If they don't know what you're talking about, start looking for another ISP! :)

I'm not sure I understand how getting my ISP to do a smarthost would help, if you don't mind explaining it a bit further?

Between the ISP and the Firewall, I do have a cisco 2600 router.  All traffic from the 55.55.55.x/29 is routed to the cisco router at 55.55.54.142.  At this point, I'm pretty sure that the router is just passing traffic through to the firewall.

compinfo,
> I'm not sure I understand how getting my ISP to do a smarthost would
> help, if you don't mind explaining it a bit further?

I thought that you needed to be able to send emails from your webserver in the DMZ?
What you're trying to configure is for the webserver to send it's email in to your Exchange server in the trusted network.

What I was suggesting was configuring the webserver to send the email directly to your ISPs smarthost - which then doesn't require the Watchguard to route the data from your DMZ to your Trusted network.

I'd imagine that you're right about what the routers doing.  I'm conviced that the problem you're encountering is to do with the Firewall.
The firewall seems to be doing an SMTP-proxy on data between the DMZ and the Trusted network.

Unforunately I don't know enought about the Watchguards to be able to tell you how to turn that off :-(

Hmm... I see what you're saying.  I am not up to date on what a 'smarthost' is, exactly.  Is it a program that runs on either windows or linux that 'forwards' email to the correct route?  If so, what form would it be in (from my ISP)?  Would it be an IP address that I would put in my etc/hosts file, like:

<ISP.IP.X.X>    mail.mywebsite.com

And would I add the entry to my sendmail.cf file too?

Thanks!

Another thought:

Along the same lines as above, if I did do this smarthost solution, how does that work with the webserver knowning the DNS server IPs and the way DNS will route??  Just Curious!

compinfo,
A smarthost is a mail server that will accept mail from your domain and deliver it for you.
The idea of a smarthost is that you can send all of your oubound emails to it, and it'll deal with the job of getting it there.
Almost all ISPs have a smarthost (mail server) as part of their normal service.

As for delivering mails to you, it would work in exactly the same way that other external Internet emails get to you.
For example, if I send an email to you@yourdomain.com, the various mail servers along the way will know how to get it to you.
Your webserver would be doing the same thing.  Simply sending all of it's mails to your ISPs mail server, and trusting it to get the mails to you.

Does that make sense?

So, in other words, since I have control of my IP block DNS entries at networksolutions advanced DNS management, I would enter mx.myISP.com 10, instead of mail.mywebsite.com 10 (so that everyone knows where to route before getting to my actual mail server), then having their (ISP's) mail server route correctly to my mail.mywebsite.com mail server?

Would a smarthost work with an exchange server??

I just talked with my ISP, they don't know!  800-600-5050 (Newsouth or NuVox Communications), if you want to give it a shot!  :)

compinfo,
> So, in other words, since I have control of my IP block DNS entries at
> networksolutions advanced DNS management, I would enter mx.myISP.com
> 10, instead of mail.mywebsite.com 10 (so that everyone knows where to
> route before getting to my actual mail server), then having their
> (ISP's) mail server route correctly to my mail.mywebsite.com mail server?

No - you don't have to change anything to do with your DNS or where mail is delivered to.

Normal Internet mail works OK, yes?

All you'd be doing is sending your outbound email from your webserver to your ISP's mailserver.
Looking at your ISPs website, this would be smtp.nuvox.net

It would then deliver the mail to you, in exactly the same way as other mail servers on the Internet do.

You don't have to change anything about MX records or where mail is being delivered.
The only thing you'd need to change is how your Linux webserver is sending the mail.

What MTA (email program) do you have on this machine?  Exim, sendmail, postfix, mmdf ?

Sorry for the delay, the answer is SENDMAIL!!  

OK - how did you configure Sendmail?
Did you create an M4 (.mc) file and then use that to compile it into the /etc/sendmail.cf file?

.. or did you use some sort of utility to configure sendmail?

If you used the m4 method, can you please post a copy of the file and I'll tell you what to put in.

Alternatively, you can edit the /etc/sendmail.cf file directly.  This isn't generally a good plan as it's complicated and can be overwritten.

Anyway, to do this:
Open /etc/sendmail.cf in your favourite editor :-)

Look for a line that starts simply "DS".  Note that this stuff is case sensitive.
If it's there and has something after it, let me know what it says.

If it's not there at all, add the line:
DSsmtp.nuvox.net.

If it is there, but just says "DS", replace it with:
DSsmtp.nuvox.net.

Restart sendmail.

Now all emails from your Linux box sill be sent to your ISPs mail server and then forwarded on to you.
You need to ensure that your fiewall is configured to allow this :-)

I configure sendmail on this redhat linux enterprise server 3.0 by editing the sendmail.mc then doing a Make -C /etc/mail (where sendmail.mc, .sf, etc. files are located), then restarting the sendmail service with: service sendmail restart.

I'll try your 'DSsmtp.nuvox.net' solution above, using the process I just described...

The watchguard tech support said I have to add an LMHOST or HOSTS file on the mail server to make this work.  Here's the quote:

1. YOU would need to setup a DNS server on YOUR network. Using an outside DNS server like your doing it the problem. If you do not want to or cannot setup a DNS on your network then you.....

2. ....would have to us a LMHOST/HOST file or the Linux equivialant on the Mail server.

Trusted to trust or optional to trusted. Same thing. It's still a double NAT issue.
 

--  

I found the HOSTS file on the windows server at:  c:\windows\system32\drivers\etc.  I added:

55.55.55.3     www

*****

That didn't work.  At the same time, I also added the DS entry you mentioned above.  Still no go.

On the mail server's hosts file, I also tried the following:

55.55.55.3     www.mywebsite.com
55.55.55.2     mail.mywebsite.com

Still no go...

Ok - I just got this reply from the watchguard tech after sending him a drawing of what is going wrong.  Thoughts??

****
The reason the HOST file was not working ( I just found out after much googling and researching this for you) is that HOST files only work for A records. The do not work for MX records.

So what that means is you will need to write a script on that Linux box so that it sends mail to 192.168.16.3 and not mail.mywebsite.com or 55.55.55.3. This will force that mail to go directly to the trusted interface from the optional, and not out to the external and back in. This will not work.

****

Sendmail.mc:

divert(-1)dnl
dnl #
dnl # This is the sendmail macro config file for m4. If you make changes to
dnl # /etc/mail/sendmail.mc, you will need to regenerate the
dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package is
dnl # installed and then performing a
dnl #
dnl #     make -C /etc/mail
dnl #
include(`/usr/share/sendmail-cf/m4/cf.m4')dnl
VERSIONID(`setup for Red Hat Linux')dnl
OSTYPE(`linux')dnl
dnl #
dnl # default logging level is 9, you might want to set it higher to
dnl # debug the configuration
dnl #
dnl define(`confLOG_LEVEL', `9')dnl
dnl #
dnl # Uncomment and edit the following line if your outgoing mail needs to
dnl # be sent out through an external mail server:
dnl #
define(`SMART_HOST',`mail.mywebsite.com.')
dnl #
define(`confDEF_USER_ID',``8:12'')dnl
dnl define(`confAUTO_REBUILD')dnl
define(`confTO_CONNECT', `1m')dnl
define(`confTRY_NULL_MX_LIST',true)dnl
define(`confDONT_PROBE_INTERFACES',true)dnl
define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl
define(`ALIAS_FILE', `/etc/aliases')dnl
define(`STATUS_FILE', `/var/log/mail/statistics')dnl
define(`UUCP_MAILER_MAX', `2000000')dnl
define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
define(`confAUTH_OPTIONS', `A')dnl
dnl #
dnl # The following allows relaying if the user authenticates, and disallows
dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links
dnl #
dnl define(`confAUTH_OPTIONS', `A p')dnl
dnl #
dnl # PLAIN is the preferred plaintext authentication method and used by
dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do
dnl # use LOGIN. Other mechanisms should be used if the connection is not
dnl # guaranteed secure.
dnl # Please remember that saslauthd needs to be running for AUTH.
dnl #
dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
dnl #
dnl # Rudimentary information on creating certificates for sendmail TLS:
dnl #     make -C /usr/share/ssl/certs usage
dnl # or use the included makecert.sh script
dnl #
define(`CERT_DIR',`/etc/mail/certs')
define(`confCACERT_PATH',`CERT_DIR')
define(`confCACERT',`CERT_DIR/cacert.pem')
define(`confSERVER_CERT',`CERT_DIR/cert.pem')
define(`confSERVER_KEY',`CERT_DIR/key.pem')
define(`confCLIENT_CERT',`CERT_DIR/cert.pem')
define(`confCLIENT_KEY',`CERT_DIR/key.pem')
dnl #
dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's
dnl # slapd, which requires the file to be readble by group ldap
dnl #
dnl define(`confDONT_BLAME_SENDMAIL',`groupreadablekeyfile')dnl
dnl #
dnl define(`confTO_QUEUEWARN', `4h')dnl
dnl define(`confTO_QUEUERETURN', `5d')dnl
dnl define(`confQUEUE_LA', `12')dnl
dnl define(`confREFUSE_LA', `18')dnl
define(`confTO_IDENT', `0')dnl
dnl FEATURE(delay_checks)dnl
FEATURE(`no_default_msa',`dnl')dnl
FEATURE(`smrsh',`/usr/sbin/smrsh')dnl
FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(redirect)dnl
FEATURE(always_add_domain)dnl
FEATURE(use_cw_file)dnl
FEATURE(use_ct_file)dnl
dnl #
dnl # The -t option will retry delivery if e.g. the user runs over his quota.
dnl #
FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl
FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl
FEATURE(`blacklist_recipients')dnl
EXPOSED_USER(`root')dnl
dnl #
dnl # The following causes sendmail to only listen on the IPv4 loopback address
dnl # 127.0.0.1 and not on any other network devices. Remove the loopback
dnl # address restriction to accept email from the internet or intranet.
dnl #
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 587 for
dnl # mail from MUAs that authenticate. Roaming users who can't reach their
dnl # preferred sendmail daemon due to port 25 being blocked or redirected find
dnl # this useful.
dnl #
dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl
dnl #
dnl # The following causes sendmail to additionally listen to port 465, but
dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed
dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't
dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS
dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps
dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.
dnl #
dnl # For this to work your OpenSSL certificates must be configured.
dnl #
dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
dnl #
dnl # The following causes sendmail to additionally listen on the IPv6 loopback
dnl # device. Remove the loopback address restriction listen to the network.
dnl #
dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl
dnl #
dnl # enable both ipv6 and ipv4 in sendmail:
dnl #
dnl DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6')
dnl #
dnl # We strongly recommend not accepting unresolvable domains if you want to
dnl # protect yourself from spam. However, the laptop and users on computers
dnl # that do not have 24x7 DNS do need this.
dnl #
FEATURE(`accept_unresolvable_domains')dnl
dnl #
dnl FEATURE(`relay_based_on_MX')dnl
dnl #
dnl # Also accept email sent to "localhost.localdomain" as local email.
dnl #
LOCAL_DOMAIN(`localhost.localdomain')dnl
dnl #
dnl # The following example makes mail from this host and any additional
dnl # specified domains appear to be sent from mydomain.com
dnl #
dnl MASQUERADE_AS(`mydomain.com')dnl
dnl #
dnl # masquerade not just the headers, but the envelope as well
dnl #
dnl FEATURE(masquerade_envelope)dnl
dnl #
dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well
dnl #
dnl FEATURE(masquerade_entire_domain)dnl
dnl #
dnl MASQUERADE_DOMAIN(localhost)dnl
dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl
dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl
dnl MASQUERADE_DOMAIN(mydomain.lan)dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
#define('LUSER_RELAY', 'mail.mywebsite.com.')dnl
DSsmtp.nuvox.net

compinfo:
> The reason the HOST file was not working ( I just found out after much
> googling and researching this for you) is that HOST files only work
> for A records. The do not work for MX records
This is absolutely correct.  You need to tell Sendmail where to deliver it to, and by default it won't try using an "A" record.

OK - from what the tech guy said, you need to modify your sendmail.mc file as follows:
Replace:        define(`SMART_HOST',`mail.mywebsite.com.')
With:               define(`SMART_HOST',`192.168.16.3')

Then use m4 to recreate the sendmail.cf file and restart Sendmail.
That'll do what the tech guy said.

If you still can't send emails from the Linux box, try doing a telnet SMTP test.
Follow the instructions at http://support.microsoft.com/default.aspx?kbid=153119
Where you have to specify the server name - put in 192.168.16.3
That is:
telnet 192.168.16.3 25


.. and see how you get on.
If that still doesn't work, then I suggest you go back to the Watchguard tech guy and tell them that you've followed the instructions and it's still broken.

Ok, a few questions:

1.  the m4 technic?  Is this the same as the 'make -C /etc/mail' that Red Hat has me do after I make changes to the sendmail.mc file (so that it will compile the sendmail.cf file with the updates)?  Do I have to use m4 instead?  

2.  Do I nix the 'DSsmtp.nuvox.net.' from the sendmail.mc file now too?

compinfo,
1 - Yup.  The Make will actually be running m4.
2 - Yup.  Actually, when you do the make it'll re-write the /etc/sendmail.cf

Well, no luck on the change.  I do notice that when I watch the rolling logs on the firewall and I fill out the online form that sends out the email that the linux box does send 6 IP packets to my ISP's DNS server IP, but it doesn't show the linux box sending any IP packets to the mail server.  Interesting...  I am awaiting a reply from Red Hat on this matter too and will let you know what happens...

That does seem very odd behaviour.

Did you try the "telnet 192.168.16.3 25" test from the linux box?

Yes, the telnet from the linux box works fine, I get a reply message back and am able to perform EHLO and other commands.

compinfo:
> Yes, the telnet from the linux box works fine, I get a reply message
> back and am able to perform EHLO and other commands.

Aha!  I think we're getting there!

Right, now we just need to work out why the sendmail config isn't sending your emails to your 192.168.16.3 address.
Can you please post the results of these commands?
grep "^DS" /etc/sendmail
cat /etc/hosts
cat /etc/resolv.conf

Ok, I'll send that info.  Here's what the Red Hat Techs are saying now:

"The reason you are not forwarding any email to the inside network is because you
do not have an ethernet device that has an IP address on your internal network.
Your eth1 has an IP address for the external stuff, but your eth0 does not have
an IP address, in fact it is disabled. Is eth0 the network card you wish to
connect to your internal network? If so, do you wish it to have a static IP
address or do you wish it to use DHCP? Thank you. "

Results:

1.  grep "^DS" /etc/mail/sendmail.cf (as all my sendmail stuff is in /etc/mail)

DS192.168.16.3

2.  cat /etc/hosts

127.0.0.1       localhost.localdomain   localhost
#55.55.55.2  mywebsite.com
#55.55.55.2  www.mywebsite.com
#192.168.16.3   mail.mywebsite.com
#55.55.55.3  mail.mywebsite.com


3.  cat /etc/resolv.conf

nameserver 64.1.1.22
nameserver 64.1.1.14

The Redhat comment doesn't make much sense, but if you could post the results of the following commands I should be able to understand what the mean:
ifconfig
netstat -rn

The output from the other commands looks OK to me.