This problem only seems to be to outside connections utilizing ESMTP and trying to establish a TLS connection.  Of course we will not be able to establish a TLS connection to outside SMTP servers since we will not have each others Certificates.  But during the connection the outside SMTP server states to start sending data but the data will not be transferred.  Now, I had about 6 messages this morning in the queue that were stuck in there.  I flushed them out in the afternoon and they all got delivered.  Any ideas as to why this connection is having diffuculties is it on my end?  Is there a way to have sendmail not to establish a TTL connection?  I see that there are available entries that are commented our in the sendmail.cf about TTL, if they are commented out that should mean that my mail server will not use TTL.  Can this even be the problem?  This is the only common variable of the messages getting stuck in my queue.  These are some SMTP's that I have some diffuculties with: UCSD.EDU;TMAIL.COM;IRONMOUNTAIN.COM;HANGER.COM.

I have not been able to resolve this issue.  We send mail to Hanger.com frequently and this is now begining to affect work flow.  I do not beleive it is a network problem since we recieve from this SMTP's just fine.  It is sending out to them that is the problem.  Here is my Sendmail.cf:

divert(-1)
dnl This is the sendmail macro config file. If you make changes to this file,
dnl you need the sendmail-cf rpm installed and then have to generate a
dnl new /etc/mail/sendmail.cf by running the following command:
dnl
dnl        m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
dnl
include(`/usr/share/sendmail-cf/m4/cf.m4')
VERSIONID(`linux setup for Red Hat Linux')dnl
OSTYPE(`linux')
dnl Uncomment and edit the following line if your mail needs to be sent out
dnl through an external mail server:
dnl define(`SMART_HOST',`smtp.your.provider')
define(`confDEF_USER_ID',``8:12'')dnl
undefine(`UUCP_RELAY')dnl
undefine(`BITNET_RELAY')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
dnl define(`STATUS_FILE', `/etc/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 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 define(`confCACERT_PATH',`/usr/share/ssl/certs')
dnl define(`confCACERT',`/usr/share/ssl/certs/ca-bundle.crt')
dnl define(`confSERVER_CERT',`/usr/share/ssl/certs/sendmail.pem')
dnl define(`confSERVER_KEY',`/usr/share/ssl/certs/sendmail.pem')
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 The '-t' option will retry delivery if e.g. the user runs over his quota.
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 This changes sendmail to only listen on the loopback device 127.0.0.1
dnl and not on any other network devices. Comment this out if you want
dnl to accept email over the network.
dnl DAEMON_OPTIONS(`Port=smtp,Addr=192.168.0.6, Name=MTA')
dnl NOTE: binding both IPv4 and IPv6 daemon to the same port requires
dnl       a kernel patch
dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')
dnl We strongly recommend to comment this one out if you want to protect
dnl yourself from spam. However, the laptop and users on computers that do
dnl not have 24x7 DNS do need this.
dnl FEATURE(`accept_unresolvable_domains')dnl
dnl FEATURE(`relay_based_on_MX')dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
Cwlocalhost.localdomain


I am not too strong in Linux.  So I really need some help on this one!  I am not even sure if I am troubleshooting the right thing here.  Is it the fact that my server is trying to establish a TLS connection or is it totally something else?

Also when reconciling the maillog I see the TLS connection, but with "verify=FAIL"

Well I have made one determining factor after troubleshooting all last night.  That these emails are not transferring because they have attachments.  Now, I can send a regular email with no attachment, and to throw another twist I can send an email with a 5KB attachment with no problem.  But I tried a 17KB attachment and it received the deferred connection in the mqueue.  I have sendmail configured to maximum mail size to 10MB.  I really don't understand this problem.  I am now seeing more smtp having issues: UPS.com and ADP.com.  This is really going to hurt us if I cannot resolve this problem.  Before I rebuild the mail server I had in place a Microsoft Windows 2003 SMTP server for temporary and I had no issues with that.  According to sendmail.org there are two issues that maybe causing these types of problems:

Q3.10 -- How do I solve "collect: I/O error on connection" or "reply: read error from host.name" errors?
Date: April 8, 1997
Updated: May 9, 2000
Updated: June 8, 2002
Updated: March 2, 2003

If you are just getting occasional such messages, they're probably due to a temporary network problem, or the remote host crashing or otherwise abruptly terminating the connection. If you are getting a lot of these from a single host, there is probably some incompatibility between 8.x and that host (see Q3.12 and Q3.20). If you get a lot of them in general, you may have network problems that are causing connections to get reset.

Note that this problem is sometimes caused by incompatible values of the MTU (Maximum Transmission Unit) size on a SLIP or PPP connection. Be sure that your MTU size is configured to be the same value as what your ISP has configured for your connection. If you are still having problems, then have your ISP configure your MTU size for 1500 (the maximum value), and you configure your MTU size similarly.

Another possibility is that you have a router/firewall filtering out all incoming ICMP messages, while your OS is doing "Path MTU discovery" (e.g. modern TCP/IP stacks do this by default). Path MTU discovery relies on certain ICMP messages being allowed through back to the host originating the traffic - see our tip on Path MTU Discovery and RFC 1191 for the details.

I have looked at my MTU on my external router and it is set to 1500 just as my sendmail server is too!  I really need some help here it is causing some work stoppage at points.

Dennis

I tried a temporary install of sendmail on another box and I get the same result.  Now I am just thinking that either I am not configuring sendmail correctly or I have bad installation disk.

Here is more to add to my problem.  An smtp that I was having trouble with @hanger.com is now OK.  I have just sent two e-mails with large attachments and they were received.  But now I am getting more smtps stuck in the queue.  I have now been tasked to look at MS exchange and offsite mail hosting I have posted a request for recommendations on offsite hosting  here in EE: http://www.experts-exchange.com/Networking/Email_Groupware/Q_21889657.html .  I come from an Exchange background and that is what I prefer.  But in the mean time before we get this new service or server, I need to have functional email and I am downloading 9.0 as we speak and see if this helps me some.  No one has commented am not sure if I am being over looked or if no one has any answers, at this time I am beginning to get desperate here!

The problem was resolved when we updated our Firewall to the latest build.