Enforced TLS to a Specific Domain
smsadm
We have opportunistic TLS setup by default.
This was setup by a mail admin who has since been let go by our
company.
He was the only person that understood Sendmail at all.
So I am an extreme newbie who is eager to learn, but I'm a bit stumped
by this request.
We have a request from a another company to enable Enforced TLS
between our two companies.
Our Sendmail version = 8.13.1-3.2.el4 running on Enterprise Linux AS
release 4
I just bought the Sendmail "Bat" book by O'Reilly.
It infers I can accomplish what I need by adding the following to the
access db:
TLS_Srv:hostA.domain ENCR:128
TLS_Rcpt:hostA.domain ENCR:128
Will that suffice or is there more that needs to be done.
Thx in advance for any insight you can offer.
smsadm
Grant Taylor
> Will that suffice or is there more that needs to be done.
If you already have an existing configuration for one (or more)
domain(s) I'd look in the Access DB and see how that domain is configured.
A quick skim for TLS in the cf/README file (in the source code)
indicates that Sendmail will try to use TLS when ever it can, "By
default STARTTLS is used whenever possible.", and you have to disable it
when you want to /not/ use it.
The same section in the cf/README file refers to the "Sendmail
Installation and Operations Guide" (doc/op/op.ps file) for more details.
I have not messed with SSL to the extent you are wanting to, so I can't
say for sure. However I have found that between the cf/README,
doc/op/op.ps "Sendmail Installation and Operations Guide" most of what
I'm wanting to do has been documented. Follow that up with some
Googling and a few questions to this newsgroup and you should be golden.
> Thx in advance for any insight you can offer.
*nod*
Grant. . . .
smsadm
That is opportunistic TLS which, if TLS is not available, will send
the email anyways.
I need Enforced TLS for this domain which, if TLS is not available for
the email, then the email is rejected and not send.
I've Googled a bunch, but much of what is available online, is
directed towards Opportunistic TLS, not Enforced TLS .... sadly.
I'll check the docs you referred me to and keep looking. Thx.
Anyone else?
Grant Taylor
> I'll check the docs you referred me to and keep looking.
I *think* you may be able to define a new mailer (based on the esmtp
mailer) that will only use TLS. I think this is a matter of what flags
are set up in the mailer. Again, I'm not sure on this.
You will then need to use MailerTable to instruct Sendmail to use the
new TLSOnly mailer to communicate with the domain(s) in question.
Grant. . . .
Andrzej Adam Filip
> Thx in advance for any insight you can offer (in
1) Why have you chosen ENCR:128 instead of VERIFY:128 in TLS_Srv?
(or even PERM+VERIFY:128)
Do not you want to verify validity of the key provided by the other side
as extra security precaution?
2) Do you want to enforce encryption of incoming connections from the
company? [Does their domain uses strict SPF record?]
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
Talkers are no good doers.
-- William Shakespeare, "Henry VI"
Per Hedeland
<mailman.1.1240951248.1...@maillists.riverviewtech.net>
Grant Taylor <gta...@riverviewtech.net> writes:
>On 04/28/09 11:55, smsadm wrote:
>> I'll check the docs you referred me to and keep looking.
>
>I *think* you may be able to define a new mailer (based on the esmtp
>mailer) that will only use TLS. I think this is a matter of what flags
>are set up in the mailer. Again, I'm not sure on this.
Not needed (actually I don't think it's doable with mailer flags) - your
reference to cf/README was quite sufficient, it describes in detail how
to set this up, in the STARTTLS section.
To smsadm: Your initial idea is sufficient for requiring that mail *to*
the domain in question is sent encrypted, but you may also want to
require that mail *from* (hosts in) the domain is encrypted - this is
covered in cf/README, as well as how to select that a permanent type of
error (=> immediate "bounce") is generated (the default is temporary).
--Per Hedeland
p...@hedeland.org
smsadm
wrote:
> Open-Sendmail:http://open-sendmail.sourceforge.net/
> Talkers are no good doers.
> -- William Shakespeare, "Henry VI"
*********************************************************************************************
Excuse if this is a repeat. I've tried to send twice previously and it
does not show up.
*********************************************************************************************
Answers to above:
1. I do want to verify validity. I just provided a quick example from
the Sendmail Bat book by O'Reilly. I'm a very experienced newbie
looking for assistance :)
2. We want Enforced TLS in both directions. Thx
Thx for any help you or anyone else can provide.
smsadm
> Open-Sendmail:http://open-sendmail.sourceforge.net/
> Talkers are no good doers.
> -- William Shakespeare, "Henry VI"
1. The provided example including the ENCR:128 came straight from the
Sendmail Bat book from O'Reilly. I'm a very inexperienced newbie
looking for direction.
2. We want TLS Enforced in both directions.
Thx for your help.
smsadm
> Open-Sendmail:http://open-sendmail.sourceforge.net/
> Talkers are no good doers.
> -- William Shakespeare, "Henry VI"
1. I do want to verify the validity of the key. I just provided an
example from the Sendmail Bat book from O'Reilly. I'm a very
inexperienced newbie looking for direction. :)
2. I want to use Enforced TLS in both directions, yes.
Thx for your help
Andrzej Adam Filip
To force certificate validation use VERIFY:128 (or PERM+VERIFY:128)
instead of ENCR:128. PERM+ makes sendmail generate permanent errors
(5??) instead of default temporary errors (4??).
> 2. We want Enforced TLS in both directions. Thx
TLS_Clt is for incoming connections just like TLS_Srv is for outgoing
connections.
> Thx for any help you or anyone else can provide.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Open-Sendmail: http://open-sendmail.sourceforge.net/
< jaybonci> actually d-i stands for "divine intervention" ;)
-- in #debian-devel
Snuff
> Let me preface my question with some history.
> We have opportunistic TLS setup by default.
> We have a request from a another company to enable Enforced TLS
> between our two companies.
> It infers I can accomplish what I need by adding the following to the
> access db:
> TLS_Srv:hostA.domain ENCR:128
> TLS_Rcpt:hostA.domain ENCR:128
>
> Will that suffice or is there more that needs to be done.
I've seen a variety of replies, but wanted to provide a summation here
along with various caveats to be aware of. Also, a general overview
of things to consider when deciding to enforce TLS and the reasons
you're doing the enforcement.
Since you have opportunistic TLS in place (good for you!) the entries
in the access.db are all you need to add. There is no need for an
additional mailer nor any other configurations.
Given that the other company's FQDN is domain, your entries can be:
TLS_Srv:domain ENCR:128
TLS_Clt:domain ENCR:128
TLS_Rcpt:domain ENCR:128
The 'Srv' entry will cause TLS to be utilized for connections to
systems in domain. The 'Clt' entry will require TLS be utilized for
connections from systems in domain. And the 'Rcpt' entry will require
TLS be utilized for connections to any system if the recipient's RHS
is in domain.
I personally recommend using 'ENCR' over 'VERIFY' because many
organizations simply use a self-signed certificate for their TLS
cert. Only if the cert used at domain is from a trusted source, OR if
they provide you with a copy of their self-signed CA, then you can use
'VERIFY'.
Some companies have outsourced their mail services to organizations
that provide anti-virus/anti-spam scanning. Messages addressed to
recipients in domain may be routed through systems in a different
domain, managed by a different company. In these scenarios, I
encourage people to include a mailertable entry and route directly to
systems in domain. If you are enforcing TLS with company A because
you don't want anyone to see the data, then why would you route
messages to company B? In addition, once you relay to company B, you
have no way to know if TLS is used when they hand it off to company A.
If you will be routing to company B, and you're okay with that, and
you want to use VERIFY, make sure they have appropriately configured
certificates.
The only drawback I see in enforcing TLS is that you cannot enforce on
the From in a message. If company A changes their outgoing systems
and they are now in another domain, and those systems do not support
TLS, then you will essentially be receiving mail from them with no
encryption and your systems cannot enforce it; due to the different
domain. Regular log monitoring can help detect this, but only after
the fact.
Hope this helps,
-Darryl