2

I'm running SendMail 8.14 and have some custom static routes for sending to certain domains. These domains are "internal" but not managed directly by me.

Here's an example of /etc/mail/mailertable: 

fooexample.com          esmtp:[1.1.1.1]:[2.2.2.2]

The idea here being that I always want to try sending to 1.1.1.1 first and only send do 2.2.2.2 if the primary is unavailable.

This works great. It even uses opportunistic TLS. Woohoo.

I now want to enforce/require STARTTLS encryption when sending to this domain. That way, if I'm sending to 1.1.1.1 and they somehow don't have TLS, I won't let the message through.

I've implemented this policy for external domains in the past and historically have just added this to /etc/mail/access:

TLS_Clt:exampledomainname.com ENCR:112

(where examplehostname.com is a part of the MX/A record hostname for a system -- not necessarily the email domain... since email can be handled by cloud services these days).

Annnnnyway, I'm not sure if this will work for my new scenario because I'm using a static route and not resolving MX/A records (which is what I thought TLS_Clt was ultimately looking at.)

So my questions are:

1) What exactly is TLS_Clt looking for in the matching pattern and how does it verify this if I'm specifying a static route?

2) Can I simply add TLS_Clt:fooexample.com ENCR:112? Or should it be something like 

TLS_Clt:1.1.1.1 ENCR:112
TLS_Clt:2.2.2.2 ENCR:112

Thanks.

AnFi
  • 5,883
  • 1
  • 12
  • 26
Mike B
  • 11,570
  • 42
  • 106
  • 165

1 Answers1

3

Short version:

Use TLS_Rcpt access table entries. to specify per recipient's domain requirements.

TLS_Rcpt:fooexample.com ENCR:112`

Full version:

0) TLS_Clt is for incoming connections. Use TLS_Srv for outgoing connections
1) Sendmail looks for TLS_Srv access table entries based on $&{server_name} first and $&{server_addr} later.
2) TLS_Srv:fooexample.com ENCR:112 will not do what you want (in every case)
You may use TLS_Rcptto specify per recipient or recipient's domain requirements in access table

AnFi
  • 5,883
  • 1
  • 12
  • 26
  • Ah! That's great information, thank you. Does `TLS_Rcpt` support partial matches? For example, will `TLS_Rcpt:fooexample.com ENCR:112` work for email going to bob@subdomain.foo.com, jane@subdomain2.foo.com and david@foo.com? – Mike B Jun 27 '14 at 17:40
  • 1
    The entry will cover subdomains too. You may check yourself sequence of access map lookups using the following test command `echo "tls_rcpt user+detail@host.example.net" | sendmail -d60.5 -bt` – AnFi Jun 27 '14 at 17:58
  • 1
    BTW there is non sendmail.org sendmail.cf extension to require SSL key with specific md5 checksum (The key may be not registered in public CA). – AnFi Jun 27 '14 at 18:02
  • I have a few more questions because I'm curious (thanks for your patience). 1) Could I technically have an entire email address if I wanted to just match a single recipient? For example, would `TLS_Rcpt:bob@fooexample.com ENCR:112` only require tls when sending to bob@fooexample.com and NOT require TLS when sending to joe@fooexample.com? 2) Where does Sendmail pull `$&{server_name}` and `$&{server_addr}`? Is that determined via reverse dns lookup? Or is it pulling it from the `EHLO` value? – Mike B Jun 27 '14 at 18:34
  • 1
    1) Yes you can specify requirements for specific email address using `TLS_Rcpt`. It is "Is established connection good enough for sending messages addressed for X?" 2) I do not know (I suspect reverse DNS). The Bar Book is not precise enough, I do not have time to check the source. – AnFi Jun 28 '14 at 13:30
  • Out of curiosity, is there a ruleset for sender address? I didn't see one. I guess that makes sense because the enveloper sender wouldn't be provided until after a TLS session was established. – Mike B Jul 03 '14 at 20:21
  • I do not remember such ruleset. It could work in mode "is connnection good enough for messages from X?". – AnFi Jul 05 '14 at 07:45