On Tue, Aug 24, 2010 at 11:37:26AM -0500, Vernon A. Fort wrote:
> > > # force_tls
> > > 5.4.3.2/32 reject_plaintext_session
> >
> > See however,
> >
> > http://www.postfix.org/TLS_README.html#client_tls_limits
> >
> > the responsibility to encrypt falls largely on the sender. I would
> > encourage you to work with the peer organization to have them encrypt
> > traffic to your domains. Tracking their sending IPs scales poorly.
> >
>
> I agree Victor but I'm approaching this from what I know and don't know
> perspective. I am evaluation IF postfix is the right solution so I
> haven't (at this point) setup the configuration(s).
The issues raised in the above URL are product neutral. All MTAs are
subject to at least the limitations listed in TLS_README. Postfix is not
subject to further substantive limitations, but it does not escape logic.
> These emails are in
> the medical/hippa regulations area so a simple check_box (so to speak)
> may not suffice for an auditor. I'm working with the other side to get
> this email encryption setup but before we commit to a specific solution,
> I want some type of verification that they ARE connecting with TLS.
Your "Received:" headers and mail logs (if the TLS loglevel is 1 rather
than 0) will provide an audit-trail of TLS use.
> A keeping honest people honest kind of thing. The
> reject_plaintext_session is what I was looking for but you're right, it
> may not scale very well. Especially if the sending domain has their
> email hosted and connection are from 20 different smtp hosts that keep
> changing.
It is not possible to ensure communications security at just one end of
a connection. It may be possible to achieve greater regulatory compliance
(legally satisfactory appearance of security).
For the reasons explained in TLS_README, TLS policy is best left to
sender.
--
Viktor.
