Sendmail STARTTLS error

can your post your sendmail.mc file?

Here you go,

dnl#
include(`../m4/cf.m4')
VERSIONID(`default setup for Slackware Linux')dnl
OSTYPE(`linux')dnl
define('confDOMAIN_NAME', '$w.$m')dnl
dnl#
define(`confCACERT_PATH', `/etc/mail/certs')dnl
define(`confCACERT', `/etc/mail/certs/cacert.pem')dnl
define(`confSERVER_CERT', `/etc/mail/certs/server-cert.pem')dnl
define(`confSERVER_KEY', `/etc/mail/certs/server-key.pem')dnl  
define(`confCLIENT_CERT', `/etc/mail/certs/server-cert.pem')dnl
define(`confCLIENT_KEY', `/etc/mail/certs/server-key.pem')dnl    
dnl# These settings help protect against people verifying email addresses
dnl# at your site in order to send you email that you probably don't want:
define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl
dnl# No timeout for ident:
define(`confTO_IDENT', `0')dnl
dnl# See the README in /usr/share/sendmail/cf for a ton of information on
dnl# how these options work:
FEATURE(`use_cw_file')dnl  
FEATURE(`use_ct_file')dnl
FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl
FEATURE(`access_db', `hash -T<TMPF> /etc/mail/access')dnl
FEATURE(`blacklist_recipients')dnl
FEATURE(`local_procmail',`',`procmail -t -Y -a $h -d $u')dnl
FEATURE(`always_add_domain')dnl
FEATURE(`redirect')dnl
FEATURE(`no_default_msa')dnl
FEATURE(`enhdnsbl', `b.barracudacentral.org', `"550 Rejected: IP in Barracuda RBL"')dnl
FEATURE(`enhdnsbl', `z.mailspike.net', `"550 Rejected: IP found in mailspike RBL"')dnl
FEATURE(`dnsbl', `korea.services.net', `"550 Rejected: Email rejected due to sending server misconfiguration - see http://korea.services.net"')dnl
INPUT_MAIL_FILTER(`clamav', `S=local:/var/run/clamav/clmilter.sock, F=, T=S:4m;R:4m;C:30s;E:10m')dnl
INPUT_MAIL_FILTER(`opendkim',`S=local:/var/run/dkim/dkim.sock')dnl
define(`confINPUT_MAIL_FILTERS', `clamav, opendkim')dnl
dnl# Also accept mail for localhost.localdomain:
LOCAL_DOMAIN(`localhost.localdomain')dnl
MAILER(local)dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
dnl# Allow SASL authentication/relaying:
define(`confAUTH_OPTIONS', `A p y')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN DIGEST-MD5 CRAM-MD5')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
dnl DAEMON_OPTIONS(`Port=587, Name=MSA, M=E')dnl
dnl# Daemon options after M= below that might need to be changed are:
dnl# s (allow SSL, not only TLS)
dnl# a (require authentication)
DAEMON_OPTIONS(`Port=smtps, Name=MSA-SSL, M=Esa')dnl
LOCAL_CONFIG
dnl# Do not allow the weak SSLv2:
O CipherList=ALL:!ADH:!NULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:+SSLv3:+TLSv1:-SSLv2:+EXP:+eNULL

Ken

This looks like it might take a while lol

I'll update once It completes and I rebuild and verify

Ken

It does.  Depending upon the cpu and memory, it may take a very long while.  Don't be concerned.

And if you still can't get that domain to cooperate, you can disable encryption to that domain in /etc/mail/access

Add a line                           Try_TLS:<partial or full destination hostname / mx record>     NO

That will tell sendmail to skip the TLS handshake on that domain.  When I was running sendmail I had a few domains that just wouldn't complete handshake, and sendmail does not fallback to an unencrypted connection.

use of the try_tls in the access depends upon the version of sendmail running.

+SSLv3: indicates that you are allowing SSLv3 but it has been removed from most servers by now.

What the client allows is of little importance as long as the client can negotiate the options available from the server

try the following from the sendmail on which the email lands to reach the remote
openssl s_client -connect server.domain.org -starttls smtp

Look at the protocol, certificate information...

Sorry for the delay, I had to run out for a while.

[ Jan Springer ] -
I've rebuilt my cf file and restarted Sendmail... No change

[ Scott Silva ] -
I've tried the TRY_TLS with no success. It works great for communication issues (TLS client errors) w/ Ironports etc

[ arnold ] -
Great idea, but no luck nothing to connect to except http/https ports which go to an outlook web app.
I do know that mail sent to recipients go to a different address,

To me it looks like there's something wrong with the senders certificate and my server's refusing to accept it.
Am I looking at it wrong?

Is that a self-signed certificate?  If so, are you sure that all of values (i.e., fqdn) were entered correctly?

Ok

I've just pulled logs going back to October 16th, and aside from this one server there are only two other servers that have generated this error.

I am not sure.  Perhaps Arnold or Dave can assist.

Jan,

My certificate is self signed yes... I can't say if the sending server doesn't like it or not, but with the volume of email sent and received through my server I'd hear about delivery issues real fast

I don't disagree.  But I do run into the server now and again that has to be difficult when all others don't have a problem.

I can't speak for the senders certificate other than my server seems to enjoy spitting it out heh

Maybe try MXTool box on the offending site and see what you get... You might have to test the MX record names too...

You're right, it happens.. But to answer your question yes the FQDN matches the mail server's name

Scott,

That's the rub.. the MX record for the domain points to a totally different server and IP.

So you get a fail when they send to you? Use that IP or name for the mxtoolbox tests...  Many companies only receive on their MX boxes and send from another...

blacklists are clean for the domains listed mail server

an smtp test... I think it checks cert validity...

blacklists on "problem server" IP are clean as well

That is correct.. Sending to them is no problem (they receive on a different server) but when they send to my server it results in a failure

no can do, no smtp/smtps ports open... The server does appear to be an Exchange server and the only open ports are http and https
I've loaded the domain in my browser and it turned out to be an "Outlook Web Portal"

:) lol ... I'm liking you Scott you cover bases

Yes "Try_Tls" was used on the "offending" domain name, and not the domain on record.
There's no point in trying it on the other server, it's not in the logs for the sessions in question

The test suggested is to replicate the sendmail connection to the remote system would actually answer many things definitively. If you must, you could use the options to identify yourself using the same certificate your sendmail is configured to use when establishing outgoing STARTTLS connection.
usually, only the remote side needs to have a valid certificate to authenticate who they are, the client does not need an authentication certificate unless that is the agreement between your organization as the sender and the receiving organization as the server through which you will relay.

Try as suggested, disable the SSLv3 as a viable option on your client side and see if that fixes the issue since the error refers to SSLv3.....

If you feel comfortable with any of the experts commenting here, you could provide(message) them the name of the server through which you want to relay, we would be able to check on whether the issue is there....

or with your, the openssl s_client has options that you can force it to attempt connections using SSLV2, SSlv3, tls, etc. and see whether one of those options is what breaks the functionality, i.e. if you follow the advise to disable the SSLv3 cipher, it may fix your outgoing connection, and/or impact your incoming ones forcing some users to update their email clients/systems........

Your error logs is not clear to me (since I am not a sendmail ....) To me it seems as an outgoing connection from your server to ..... where it tries to initiate a TLS session but fails...

I'm betting it's becoming clear why I reached out lol

Arnold,

This isn't an outgoing issue of "mine"...   It's an incoming issue with 1 server out of thousands

Arnold,
Essentially, my server sees an incoming request, but appears to be having an issue with the certificate from the sender
(At least that's how it's looking)

lol

Yea I've pretty much decided that I was going to try to contact them in the morning

Just an update

For grins and giggles SSLV3 was disabled, and a new error failure occured

No SSLv3- "STARTTLS=server, error: accept failed=-1, reason=no shared cipher, SSL_error=1"
w/ SSLv3- "STARTTLS=server, error: accept failed=0, reason=sslv3 alert certificate unknown, SSL_error=1"

I'm now wondering if they're running a cypher that my server isn't configured to use

I'm thinking they are running SSLV3 with a bad certificate... A lot of part time postmasters don't configure TLS right, especially if they are running older software versions or appliances...

Agreed, it's one or the other lol

I'm done caring for the night ;) lol

Thanks everyone, I'll close this tomorrow

Have a great night

Jan and Scott,

I appreciate the effort the two of you made in resolving this issue.
I ended up sending an email the the districts admin who never really replied, but the 40 min retries that have been going on for the past month have ended heh

I'm guessing he dumped the queue, I'll have to wait to see if the issue has been addressed or not :\

Thanks again
Ken