3

I read with interest from sendmail guide that it is possible to disable TLS. I tried doing so for internal mails by adding the following lines in /etc/mail/access:

Try_TLS:my.server           NO
Try_TLS:localhost6.localdomain6         NO
Try_TLS:localhost.localdomain           NO
Try_TLS:localhost           NO
Try_TLS:127.0.0.1           NO

However, it doesn't seem to work and I am still seeing the following:

Received: from my.server (localhost6.localdomain6 [127.0.0.1])
    by my.server (8.14.8/8.14.8) with ESMTP id s6H2Wanf004005
    (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO)
    for <[email protected]>; Tue, 15 Jul 2014 10:32:36 +0000
Received: (from user@localhost)
    by my.server (8.14.8/8.14.8/client) id s6H2WZfQ004004
    for user; Tue, 15 Jul 2014 10:32:35 +0000

Any idea?

Question Overflow
  • 4,568
  • 19
  • 57
  • 84

1 Answers1

5

There are several TLS related settings you can use in the access map:

  • try_tls is used when sendmail is a client (i.e. sending email)
  • tls_srv applies to servers, when sendmail is a client (i.e. sending email)
  • tls_clt applies to clients, when sendmail is a server (i.e. accepting email)
  • srv_features is used when sendmail is a server (i.e. accepting email), and determines features to offer

srv_features determines what features to offer (at the EHLO stage), this includes STARTTLS, and other protocol options like PIPELINING, VERBose and AUTHenticate. See §5.1.4.15 of the current Sendmail Installation and Operation Guide(PDF) for details.

tls_clt are the TLS-related settings for particular sending systems, this is used to make sure that a minimum level of encryption and/or identity (client cert) are in place by the time an email is being submitted.

(There's also tls_rcpt to configure based on recipient, it's usually used to enforce encryption, and not so useful here.)

You seem to have edited your headers, but I assume only the hostnames, and you are sending via sendmail on localhost. In this set up the client (MSP), a sendmail running as a mail submission program, uses submit.cf and by default that has no support for any access map enabled.

The flow (excuse the ASCII art):

           (submit.cf)               (sendmail.cf)
 email →   sendmail-MSP →[127.0.0.1]→ sendmail    
                      ↗                ↕
          queue runner               access.db
           (submit.cf)

So, you should use instead in the access map:

srv_features:127.0.0.1        S

The "S" in srv_features means "don't offer STARTTLS" (there are some other flags too, regarding authentication and client certs and more), then rebuild access.db with makemap.

This will only be used by the daemon sendmail server (not the submission part, or its queue runner).

You could add FEATURE(access_db) to your submit.mc, but that's not something to undertake lightly. See http://www.sendmail.com/sm/open_source/docs/m4/msp.html .

mr.spuratic
  • 9,721
  • 26
  • 41
  • Awesome! It works perfectly. Sorry, I am a bit lost on the four bullet points. Can you clarify the difference between `tls_clt` and `srv_features`? Thanks. – Question Overflow Jul 17 '14 at 11:06
  • @QuestionOverflow it is my understanding that `srv_features` is before TLS is established, whereas the rest of the settings to enforce various levels of encryption afterwards. – cnst Feb 27 '19 at 23:52
  • @cnst this was addressed in an edit and not noted in comments, but that's more or less it. The underlying issue was sendmail's "opportunistic" use of TLS, so arranging for the server not to offer STARTTLS at all is the workaround. – mr.spuratic Feb 28 '19 at 19:06